World: r3wp
[!Cheyenne] Discussions about the Cheyenne Web Server
older newer | first last |
Oldes 28-Sep-2010 [9065x2] | So here is my new init.d file: #! /bin/sh # /etc/init.d/cheyenne # # Some things that run always #touch /var/lock/blah STARTSCRIPT=/web/start-ch.sh PID=$(tail /tmp/cheyenne-8000.pid) # Carry out specific functions when asked to by the system case "$1" in start) echo "Starting Cheyenne " $STARTSCRIPT RETVAL=$? ;; stop) echo "Stopping Cheyenne" kill $PID RETVAL=$? ;; reload) echo "Reloading Cheyenne" kill -HUP $PID RETVAL=$? ;; reset) echo "Reseting Cheyenne" kill -USR1 $PID RETVAL=$? ;; restart) echo "Stopping Cheyenne" kill $PID echo "Starting Cheyenne" $STARTSCRIPT RETVAL=$? ;; *) echo "Usage: /etc/init.d/cheyenne {start|stop|reload|reset|restart}" exit 1 ;; esac exit 0 (maybe it should be put on the wiki or into the repository to help other linux newbies) |
(the last line should be: exit $RETVAL instead of: exit 0 | |
Dockimbel 28-Sep-2010 [9067] | Looks much better, thanks for your contribution, I'll copy/paste it on Cheyenne's wiki. |
Oldes 28-Sep-2010 [9068x3] | btw.. the /web/start-ch.sh looks like: #!/bin/bash cd /web/ ./cheyenne & I must use it because running cheyenne using full path like: /web/cheyenne & does not work as expected - it looks it does not gets the httpd.cfg file (probably) |
hm.. maybe I could just skip to the directory in the init.d script. | |
yes.. it works:) | |
Graham 28-Sep-2010 [9071] | and the final init.d script is ? :) |
Oldes 28-Sep-2010 [9072] | replaced $STARTSCRIPT with: cd /web/ ./cheyenne & where the folder may be different so it's probably good to use it as variable |
Kaj 28-Sep-2010 [9073x4] | Kaj: so, this means that an install script would be required for Cheyenne to be able to run on UNIX, this is not something that I want for Cheyenne unless really necessary. Do you see any simple solution to that issue? If not, I'll revert it to write in /tmp by default and add a config option to let users choose alternative location when desired. |
Hm, avoiding installers is good, so I guess a config option is readable | |
Packages for Linux package managers do indeed come with stuff to install into /var/ | |
readable -> reasonable | |
MaxV 7-Oct-2010 [9077] | If you want it, I can make the binary packages for deb, RPM and TGZ. I already done it for Rebol, so it's easy for me. My email is [maxint-:-tiscali-:-it] |
Dockimbel 7-Oct-2010 [9078x2] | MaxV: thanks for the offer, but it's not required for now as there's only one file to distribute (when encapped). |
SVN revision 93: o FEAT: new config keyword 'pid-dir for setting user-defined folder for Cheyenne's PID file. o FEAT: Cheyenne's SVN global revision number now appended to Server response header. o FIX: default location for %cheyenne.pid is reverted back to /tmp. o FIX: PID file now takes the correct process uid:gid when Cheyenne is not run as root. | |
Kaj 7-Oct-2010 [9080] | Nice |
Dockimbel 7-Oct-2010 [9081] | I'm able now to run Cheyenne as not-root, works ok so far, the only remaining issue is the first REBOL side process that stays as root (it's not a serious security threat anyway). I'll write a How-To for that in the next days and will post it in the wiki (with Kaj's scripts also). |
GrahamC 7-Oct-2010 [9082] | I take it we will still be able to run as root if we want to ? |
Dockimbel 8-Oct-2010 [9083] | Graham: sure |
Carl 8-Oct-2010 [9084] | Thanks Doc, this is a really good feature for people who need greater security... Chey.93 now running as user "www" rather than root on our new cloud server. |
Dockimbel 8-Oct-2010 [9085] | Great! :) |
Carl 8-Oct-2010 [9086] | So, finally... it's time that I learn how to use the RSP API. |
GrahamC 8-Oct-2010 [9087] | You've been running cgi ? |
Carl 8-Oct-2010 [9088] | On apache, yes. On cheyenne, no. |
Kaj 8-Oct-2010 [9089] | CGI is nicer on Cheyenne because it acts like FastCGI for R2. But if you want to write your scripts in R3, you'll still need slow CGI instead of RSP |
GrahamC 8-Oct-2010 [9090] | slow CGI ? |
Kaj 8-Oct-2010 [9091x2] | And switching away from root still doesn't work with Core |
Traditional CGI, where you start a new process for each request | |
GrahamC 8-Oct-2010 [9093] | Cheyenne has to invoke the r3 interpreter ..? |
Kaj 8-Oct-2010 [9094] | If you want R3 scripts, how else? |
GrahamC 8-Oct-2010 [9095] | send them to try rebol? |
Kaj 8-Oct-2010 [9096] | Then you'll be starting about three layers of shell processes - for security |
GrahamC 8-Oct-2010 [9097] | Actually I wasn't aware that Cheyenne had a mechanism for external cgi .. but I guess it must |
Kaj 8-Oct-2010 [9098] | The only alternative would be implementing a continuous-running R3 application server, instead of using the UniServe taskmaster server. But you'd still have the communication overhead between the processes |
GrahamC 8-Oct-2010 [9099] | LNS server doing the cgi |
Kaj 8-Oct-2010 [9100] | RIS, I'd figure |
GrahamC 8-Oct-2010 [9101] | call the r3.dll |
Kaj 8-Oct-2010 [9102] | Why? |
GrahamC 8-Oct-2010 [9103] | so r2 can use R3 |
Kaj 8-Oct-2010 [9104] | Sounds messy |
GrahamC 8-Oct-2010 [9105] | anyway, what advantage would there to be use R3 over R2 for cgi ? |
Kaj 8-Oct-2010 [9106] | Well, what advantage does using R3 have over R2? |
GrahamC 8-Oct-2010 [9107] | none in an alpha state |
Kaj 8-Oct-2010 [9108x2] | If you don't use it, it will stay in alpha state |
By the way, my Boron demos are running on Cheyenne in traditional slow CGI mode | |
GrahamC 8-Oct-2010 [9110] | I doubt my personal use of R3 with Cheyenne is going to affect the alpha status at all. |
Kaj 8-Oct-2010 [9111] | Maybe, but we started out talking about Carl's intended use |
Carl 10-Oct-2010 [9112x3] | Long ago, there was a RESET function in REBOL. It would restore the runtime environment without reloading the exe. This allowed REBOL to run as an apache mod, because the process would persist and could start "clean" each time. Such a thing could be done in R3. |
And switching away from root still doesn't work with Core ... I've not tried it in Core, but it works nicely in rebpro. | |
I have a 2.5 K web server here that opens port 80, then switches to www uid, and runs fine. | |
older newer | first last |