World: r3wp

there are so many layers and un-obvious dependencies ( and little 
details like the error code return on top of it ) in the structure 
of the server that it gets really

onetom: yes the path in the shebang line usually needs to be adapted 
for each local configuration.

Maxim: please throw together a blog entry at least about your rambles, 
so later we can use it to extend the documentation

Mods hierarchy: there's no such relation between modules, it is more 
an event matrix as described here: http://cheyenne-server.org/blog.rsp?view=25
(slide 5)

Priorities are fixed per-mod and/or per-callback.

Running Cheyenne with -vvvvv (should be enough) will give you a view 
of the matrix (line by line, per event) when Cheyenne starts.

Dockimbel: I have to thank you for your presentation. Just saw it 
yesterday finally. Now I understand Cheyenne a bit more. Im curious 
about the tricky parts though. Like how do u handle forking and the 
communication between the master and the forks and stuff like that. 
I know it's handled by UniServe

Just hinting what should you write and talk about the next time; 
not asking for explanation now, of course :)

Forking is done when Cheyenne starts, more precisely when the task-master 
service is loaded by UniServe. It starts with a default of 4 workers 
processes. If more than 4 simultaneous RSP or CGI requests are received, 
one or several workers are forked (up to 8). You can change those 
values in %cheyenne.r (search for pool-start and pool-max). It is 
planned to expose those values in the config file for easier access.

Oh, well, you got a quick explanation right now. :-)

Doc yeah... I'm starting to be pretty knowledged on the phases (though 
some things still elude me a bit).


I'm just saying that some mods... like extapp, expire, action, alias, 
internal, etc...  probably have non-negligible effects in the chain 
that some other modules might react to or not (depending).  and its 
currently quite tricky to understand what effects the mods actually 
have on requests and response.


anyhow, as usual, Its not critique its just observation from someone 
"outside the box"   :-)

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?