World: r3wp

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/

or sbin

then how could Cheyenne know where to look for config file ?

the only way I see is passing the config file path as command-line 
argument, something like:
cheyenne -p 8001 -conf /home/devel1/app/current/

Would such feature cover your needs for user autonomy?

if it still looks in the current directory for a httpd.cfg by default, 
then it's not even necessary

cd approot; cheyenne

cheyenne --conf approot

not a big difference

doesnt worth the trouble, i guess

is approot linux specific?