World: r3wp

Doc, you are not imagining the problem with copying from AltME; it 
doesn't always work for me. (I'm unaware what causes the problem.)

Rodney:~ peter$ ls /var/run

DirectoryService.pid			mds.pid

SCHelper				ntpd.pid

appfwd.pid				pcscd.pub
.
.
.
httpd.pid				utmpx
mDNSResponder			vpncontrol.sock

mds

Rodney:~ peter$ 

OS X 10.6

Anton, for me right-click copy only works the first time in AltME. 
Then it stops working.

PeterWood: thanks for the test!

Kaj: I'm applying your patch on mod-userdir.r. I'm changing the user 
/ group arguments datatype from word! to string!, this both reduces 
the code size in mod-userdir and makes the dialect less confusing 
IMO when you use named uid/gid. So, instead of :

user www
group users

we'll have now :

user "www"
group "users"

Do you agree with that change?

Certainly, thanks!

Kaj: your patches have been applied to the SVN repository.

Still, I can't make Cheyenne work as non-root user : the HTTP log 
file keeps being written as root:root even if the main Cheyenne process 
is own by a non-root user. The culprit seems to be the REBOL helper 
process, forked by the main one during REBOL internal boot process 
(so before starting to run user code). I found no way to setuid this 
child process (seems forbidden by the OS?), so it keeps being owned 
by root...


Here's my typical test case under linux (Ubuntu 8.04, /enpro 2.7.6, 
latest SVN revision,using [user "dk"] in config file). I'm running 
the test from a root shell to avoid issues of sudo with REBOL binaries 
(RAMBO #4306) :

;--- launching  Cheyenne process  ---
[root-:-dknux]:/mnt/dev/Cheyenne# ./cheyenne &
[1] 20179


;--- notice the root process below (the only one that Cheyenne can't 
setuid( ) ---
[root-:-dknux]:~# ps aux
[...]

dk       20179  0.2  1.3   9028  6716 pts/0    S    22:21   0:00 
./cheyenne

root     20180  0.0  0.1   2360   600 pts/0    S    22:21   0:00 
./cheyenne

dk       20182  0.1  0.9   6264  4964 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20183  0.0  0.0   2184   236 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20184  0.1  0.9   6264  4964 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20185  0.0  0.0   2184   232 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20186  0.1  0.9   6264  4968 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20187  0.0  0.0   2184   236 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20188  0.1  0.9   6264  4964 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20189  0.0  0.0   2184   232 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

;--- no HTTP log file for now ---
[root-:-dknux]:/mnt/dev/Cheyenne# ls -l log/
total 0

;--- I'm sending a request to http://localhost/---
[root-:-dknux]:/mnt/dev/Cheyenne# ls -l log/
total 1
-rw-r--r-- 1 root root 77 2010-09-09 18:19 default-access.log


The log file belongs to root:root, so it must have been generated 
by process 20180. Killing that process prevents Cheyenne from outputing 
any new log file (but Cheyenne keeps serving all requests). I thought 
that the helper process was only used for enabling async dns requests 
when OS doesn't support it natively?...<vent>Like REBOL GC's rules, 
this helper process remains a mystery even after 10 years of reboling...I 
guess these secrets are worth millions of $ to be kept undisclosed 
so far...</vent>

Any ideas?

My websocket chat demo now works again with Chrome 6: http://demo.cheyenne-server.org:8080/chat.html

Yeah, Carl has given different statements about the helper process. 
Years ago he said garbage collector, lately he said async DNS

Neither explains file handling

I think the main win is getting the UniServe task master processes 
to run as non-root. Is that feasible?

It's always been DNS -- never was GC.

I saw you write that many years ago, but I don't know if I could 
find it again

It didn't come from me, I promise!

I'd like to make that side proc an option.  Holger added it for async 
DNS lookup, but a great deal of the time no lookup is being done, 
or sync DNS lookup is just fine.

Perhaps it could be an R/Command build option?

And, in Core and others, could be cmd line option.

that was the infamous zombie dns process in older r2 version

I'm wrapping up R3 A107... so if we want to do some test builds for 
2.7.8 on this, let me know.

Carl, did you see our above discussion on getting Cheyenne to shed 
root access, and my request in R3 Chat to have Library access enabled 
in R2/Core?

It's essential for getting R2 up to a professional level for web 
serving

do the latest core have odbc as well?

It doesn't have Library

The 2.7.8 planning seems to include some goals in that direction, 
making View not bomb out when X11 is not running, but the time plan 
was abandoned

rebcmd has odbc, ssl and library access.

Sure, but I need Library in Core to have it be meaningful in Syllable 
Server

So, it's just simply releasing rebcmd as core ....if the will exists

Making the REBOL side process a command-line option for /Core and 
build option for /Command would be a good improvement.

What causes this error?


15/9-02:54:33.067-## Error in [task-handler-4721] : Make object! 
[
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'protected-exec
    arg2: 'code
    arg3: [block! function!]

    near: [protected-exec/event request/parsed/file get in session/events]
    where: 'fire-event
] !

I'm trying to display the login.rsp page of a webapp

the login.rsp is straight from svn

looking at login.rsp...

maybe it's a httpd.cfg error?

From the error message, the error would come from an incorrect event 
definition in %app-init.r

errors like this are usually coaused by error in app-init.r yes

I deleted the app-init.r and still get the error

In fact I didn't have an app-init.r so added one

IIRC, app-init.r is mandatory for a webapp, even if you don't use 
it.

so maybe that was the first issue.

put it back and restarted cheyenne

very odd .. I deleted the comments in on-application-start and it 
works now!

I can only guess that I didn't complete shut down and restart Cheyenne

You should just "Reset Workers", it's enough to reload all the webapps. 
You should also consider running your dev instance of Cheyenne with 
-w 0 command-line option to make it reload all apps on each request.

I'm looking at the code in RSP.r and I can't figure out how you could 
raise such internal error. Can you please describe me the simplest 
way to reproduce that error?

reload all apps on each request?

The first thing I did was create a web app with no app-init.r

When I tried to access the login.rsp page I got that error.

yes, the -w 0 option asks Cheyenne to maintain a pool of 0 worker 
process and launch one only when required (killing it when the request 
is completed). That has the side-effect or "reloading" all webapps 
and cleaning any corrupted data in memory produced by user-scripts.

what impact does that have on performance?