World: r3wp

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.

Nice

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).

I take it we will still be able to run as root if we want to ?

Graham: sure

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.

Great! :)

So, finally... it's time that I learn how to use the RSP API.

You've been running cgi ?

On apache, yes. On cheyenne, no.

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

slow CGI ?

And switching away from root still doesn't work with Core

Traditional CGI, where you start a new process for each request

Cheyenne has to invoke the r3 interpreter ..?

If you want R3 scripts, how else?

send them to try rebol?

Then you'll be starting about three layers of shell processes - for 
security

Actually I wasn't aware that Cheyenne had a mechanism for external 
cgi .. but I guess it must

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

LNS server doing the cgi

RIS, I'd figure

call the r3.dll

Why?

so r2 can use R3

Sounds messy

anyway, what advantage would there to be use R3 over R2 for cgi ?

Well, what advantage does using R3 have over R2?

none in an alpha state

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

I doubt my personal use of R3 with Cheyenne is going to affect the 
alpha status at all.

Maybe, but we started out talking about Carl's intended use

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.

Core still doesn't have the Library component, which Cheyenne uses 
for a number of functions

SVN r95

FIX: boot log improved, now every warning/error during boot will 
be logged in file even when verbose mode is not set

FIX: (UNIX) chey-pid-*.log files are now CHOWN-ed to target user 
when required (fixes verbose mode issue)

FIX: (UNIX) when user ID was not found in system file, it was accidently 
set to root ID resulting in no error reporting

This new revision should fix all known issues with running as non-root.

SVN r96 -> r103 (most of new features were suggested by Carl)  


FEAT: encapped Cheyenne binaries now returns 0 (or, in case of panic, 
a REBOL error code) on exit

FEAT: (UNIX) Added a new command line option: -V or --version. Displays 
Cheyenne's version, then quits.

FEAT: (Windows) Cheyenne's version is now displayed in the tray icon 
help message.

FEAT: RSP debug mode extended to display tail of trace.log file using 
a new [show trace] button.

FEAT: RSP debug bar look improved, menu horizontal alignment fixed, 
direct link to RSP API online
documentation added.

FEAT: RSP errors are now displayed in an overlay popup instead of 
being inlined in the page.

FEAT: RSP debug bar javascript code footprint reduced to a single 
object: rspdbg (avoids polluting global namespace)

FEAT: new RSP API function: debug. Switches the debug mode on or 
off, for the current RSP script.

FEAT: new API function: debug?. Returns TRUE if debug mode is active.

FEAT: 'debug config keyword definition extended to accept an optional 
block of parameters.

FEAT: RSP session/start now returns the session/active? flag as result.

FEAT: (UNIX) Added a new boot option: -h or --help. Displays the 
command line syntax help and quits.

FEAT: Improved RSP function 'validate to accept default values for 
optional parameters when using
the /full refinement.

FEAT: now plain REBOL scripts can also be run by the RSP engine! 
(see www/show.r)

FEAT: new RSP API function: emit. Does a REDUCE on its argument before 
APPENDing to response/buffer.

FEAT: added new RSP syntax for emit-action : <%? ... %>. Does the 
same as 'emit, but inlined in a
template page.

FIX: (Windows) improved child processes termination with a more graceful 
method using JobObject API

FIX: (UNIX) optimized child processes termination using a kill() 
routine! wrapper instead of CALLing the shell command
FIX: flush HTTP logs in cache on exiting.

FIX: mod-userdir was still commented in config file modules list, 
disabling user/group keywords in httpd.cfg

More info on the new RSP functions in changelog.txt file.

I'm freezing the code now to make a new official release in a few 
days. I'll provide the test binaries asap. If you find any bug or 
issue in this version, please post them here.

Revision 103 binaries, encapped with enpro 2.7.6:
- Windows: http://cheyenne-server.org/tmp/cheyenne-r103.zip
- Linux libc6 : http://cheyenne-server.org/tmp/cheyenne-r103.gz

Hi Doc, nice list. But would like to ask you, what about a way how 
to terminate long time unused worker processes? They are started 
automaticaly when needed, but there is no way how to stop them when 
the server has no activity.

Hi Oldes, good point, I was thinking about adding a worker processes 
user-controlled killing policy since years now, but it  has never 
bothered me on my production linux servers. 


Also, if you use the -w command line option, you can (in theory) 
set the threshold for workers kept alive after each request. In practice, 
a worker gets killed only if the threshold is reached and after a 
request is processed, so you might have cases, where more workers 
than should be, remains temporary after a burst of requests.


If it's really an issue for you, I can have a look at this feature 
to see if there's a simple way to implement a killing policy (would 
decrease the number of worker processes using 1 / t or e^(-t) function 
classes). See function plots at :
http://www.wolframalpha.com/input/?i=1+/+t
http://www.wolframalpha.com/input/?i=e^-t

Any reason not encapping with encmd?

Sounds great Doc. A lot of changes in there.

It's not a big issue for me, but sometimes I think about it, that 
the unused processes just sit there with allocated memory. "The threshold" 
sounds good imho.

Graham: I can provide encmd binaries too if it's allowed by RT?

I don't see the issue ... View now has cmd functionality and is free

I've been releasing cmd encapped binaries for cheyenne for a long 
time now