World: r3wp
[!Cheyenne] Discussions about the Cheyenne Web Server
older newer | first last |
onetom 17-Apr-2011 [9723x2] | 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 :) | |
Dockimbel 17-Apr-2011 [9725x2] | 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. :-) | |
Maxim 17-Apr-2011 [9727] | 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" :-) |
Dockimbel 17-Apr-2011 [9728x2] | 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. | |
onetom 17-Apr-2011 [9730x2] | 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 :) | |
Dockimbel 17-Apr-2011 [9732x2] | 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. | |
onetom 17-Apr-2011 [9734] | oh, that's important to know, because my plan to have the users run their own cheyennes might have problems |
Dockimbel 17-Apr-2011 [9735] | 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 |
onetom 17-Apr-2011 [9736x2] | 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 | |
Dockimbel 17-Apr-2011 [9738x3] | 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. | |
GrahamC 17-Apr-2011 [9741] | I've been using Cheyenne for personal web server for a few years now ... only issue was when user installed it as a service |
Dockimbel 17-Apr-2011 [9742] | 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. ;-) |
GrahamC 17-Apr-2011 [9743] | No virus has yet found how to use Cheyenne's mta :) |
Dockimbel 17-Apr-2011 [9744x2] | Good to know :-) |
Could be a nice selling point. | |
onetom 17-Apr-2011 [9746x2] | 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...) | |
Dockimbel 17-Apr-2011 [9748x2] | 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. | |
Maxim 17-Apr-2011 [9750x2] | 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. | |
Dockimbel 17-Apr-2011 [9752] | 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. |
onetom 17-Apr-2011 [9753x3] | 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/ | |
Dockimbel 17-Apr-2011 [9756x2] | 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. | |
onetom 17-Apr-2011 [9758x2] | 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 | |
Dockimbel 17-Apr-2011 [9760x2] | 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). | |
onetom 17-Apr-2011 [9762x4] | 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 | |
Dockimbel 17-Apr-2011 [9766] | Agreed, but you could create per-user sub-folders there? |
onetom 17-Apr-2011 [9767x4] | 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 | |
Dockimbel 17-Apr-2011 [9771x2] | Your need is pretty clear. |
You could do the same (reverse proxy/nginx) with Cheyenne instances. | |
older newer | first last |