World: r3wp

Communications with the workers are handled by the task-master UniServe 
service. It is done with a TCP channel (Cheyenne/UniServe process 
is the server, workers act as clients). When a worker is launched, 
the first thing it does is to connect to the server and wait for 
a new job. If the TCP connection is lost, the server considers the 
worker dead and forks a new one to replace it. Workers are doing 
their best to maintain this (umbilical) link open, if they encounter 
a fatal error, they severe the link before quitting.

Max: no problem, I have my own critics about the way mod interact, 
the current system is powerful, but can sometimes be hard to follow 
for mod's developers (including me). When I'll work on Cheyenne v2 
(probably coded in Red), I'll redesign that system to make it more 
simple for developers.

aaah, okay, thanks, so that's why there are so many tcp ports... 
i thought those r just for debugging the workers during operation

(which also lack an example, i guess. but let's focus on this logfile 
issue now :)

Several ports: Cheyenne is using several other listening ports for 
additional internal services:
- task-master: 9799 (worker process management)
- RConsole: 9801 (local debug remote console)
- logger service: 9802 (centralize all worker logs writings)
- MTA: 9803 (Cheyenne's own Mail Transfer Agent)

That's why, when started multiple times or when one of these default 
listen port is already taken, Cheyenne translates the service(s) 
on other free ports.

oh, that's important to know, because my plan to have the users run 
their own cheyennes might have problems

Max:"its currently quite tricky to understand what effects the mods 
actually have on requests and response"


Agreed, some mods, like mod-static or mod-action are catching a lot 
of events and doing important things. The only way to not get lost 
is to treat it horizontally (from the slide), it means see list all 
mods catching a given event, see the process order and the exiting 
condition: 
- none: not processed

- false: processed but let other lower priority mods callback catch 
it too

- true: processed and stopping the event propagation to lower priority 
mods callback

btw, these lots of ports might look scary for the usual paranoid 
sysadmin, so it's not a good selling point. by default these all 
should be closed, but only port 80 or 8080 or something like that 
should be open

Dockimbel: you r actually writing an awesome documentation rightnow. 
if i can get access to the wiki, i would quote these on a sandbox 
page, so later we can massage it into an actual documentation

onetom: it should work OK with the "port translation" system, it 
is just consuming more listening ports.

onetom: those ports I listed are for Cheyenne internal usage, they 
should never be reachable from outside on a properly configured server 
(requires a firewall as REBOL binds ports to all interfaces). You 
should just let the HTTPd ports be reachable from outside.

onetom: if you need a wiki account, let me know.

I've been using Cheyenne for personal web server for a few years 
now ... only issue was when user installed it as a service

usual paranoid sysadmin

: If I was a fulltime sysadmin, I would be much more scared to put 
any PHP app online than to run a webserver written in an obscure 
language. ;-)

No virus has yet found how to use Cheyenne's mta :)

Good to know :-)

Could be a nice selling point.

so, doc, an ideas / questions about my scenario? where all the logs 
should go and whether is it possible or necessary to have 1 system-wide 
cheyenne which connects with per-user ones?

(do u seem my private msgs? im not sure what should i see / notice 
when i get a priv msg in altme...)

Yes, I have answered to them. You should see my nickname go red.

onetom: I started writing you a reply by email, but it might be easier 
to discuss it there.

onetom... ever since the weird user reset bug which affected altme, 
the very first time anyone ever sends you a personal message, you 
won't be notified... you actually have to click on the group to see 
the message updated  :-(

this is true for each user.

Logs: I must say that I don't like much having all logs under current/, 
which is the webapp root folder. Putting all logs there (especially 
error.log which can contain critical information like user logins 
and password hashes) is bad practice  to me.

Maxim: ok, thx. i turned off the dividers and it's great like this

doc: i didnt say current, but current/log/

but in cheyenne's case it could be current/private/log/

Yes, everything that is under current/ might be at risk, so better 
avoid putting critical information there.

Same remark for Cheyenne webapp's private/ folder, you shouldn't 
put critical information there.

what should go there then and how is it more private than the protected 
area? (is it documented somewhere?)

let's collaborate on a directory structure here: http://piratepad.net/KkvkZ9AtME

Those "private" folders are protected from the requests by the webserver, 
but not by the OS. If an attacker finds a way to workaround the server's 
protection, better avoid giving him critical info.

I would say that logs shouldn't have the same user permission than 
the web accounts (prod, stg and devel1 in your example from email).

the devel1 should be able to access his own logs

and also should be able to clear them regularly

i always had to put the developers into the adm group so they can 
access the /var/log/apache2/ directory

where they saw a lot more than their interest

Agreed, but you could create per-user sub-folders there?

running their own app server (mongrel/thin/unicorn) helped a littlebit, 
but they couldn't easily test what was returned just by the webserver 
from cache / static files

the main problem with my setup was always the autonomity of the users

i had to edit config files when a new user joined the company

and i had to be aware where are they checking out the source of the 
projects they were working on and i also had to assign port numbers 
to them, so i could configure the reverse proxy in apache/nginx to 
connect to their app servers

Your need is pretty clear.

You could do the same (reverse proxy/nginx) with Cheyenne instances.

security in such a case is not a big concern (unless the machine 
get rooted :)

Cheyenne just needs to be able to pick the config file from a remote 
folder instead of just current one.

sure, but i would love to get rid of any external component, since 
cheyenne seems to be pretty close being able to cater for such a 
setup

Where would Cheyenne binary be in your scenario?

/usr/local/bin/