World: r3wp

I confirm this behaviour, but if you launch Cheyenne by using right-click 
on cheyenne.exe and select "Run as administrator", then once in service 
mode, it works ok.

Yes, though oddly that's is what I first tried and it didn't work. 
 Which is why I switched to running from the dos shell.  Maybe I 
didn't get the right sequence!

Kaj: I can't find your patch, can you give me any pointer to your 
code? IIRC, there was some hard-to-fix issues with running in user-mode, 
like not being able to use the verbose/debug/trace mode anymore.

*there were

It's above here, at May 11:

--- mod-userdir.r.original	2010-05-09 19:28:10.000000000 +0200
+++ mod-userdir.r	2010-05-11 00:45:24.000000000 +0200
@@ -12,40 +12,81 @@
 	on-started: does [do boot-code]
 	on-reload:  does [clear boot-code]
 	
-	get-ugid: func [name [string!] /local file uid gid][
-		if none? attempt [file: read %/etc/passwd][
+	get-ugid: func [name [string!] /local file line uid gid][
+		unless attempt [file: read/lines %/etc/passwd][
 			log/error "accessing /etc/passwd failed"
 			return none
 		]
-		unless parse/all file [
-			thru name 2 [thru col]
-			copy uid to col skip
-			copy gid to col
-			to end
-		][
-			log/error "reading /etc/passwd failed"
+		foreach line file [
+			if all [line: find/case/match line name  col = first line][
+				return either parse/all next line [
+					thru col
+					copy uid to col skip
+					copy gid to col
+					to end
+				][
+					reduce [to-integer uid to-integer gid]
+				][
+					log/error "invalid format reading /etc/passwd !"
+					none
+				]
+			]
+		]
+		log/error "user not found in /etc/passwd"
+		none
+	]
+	
+	get-gid: func [name [string!] /local file line gid][
+		unless attempt [file: read/lines %/etc/group][
+			log/error "accessing /etc/group failed"
 			return none
 		]
-		reduce [to-integer uid to-integer gid]
+		foreach line file [
+			if all [line: find/case/match line name  col = first line][
+				return either parse/all next line [
+					thru col
+					copy gid to col
+					to end
+				][
+					to-integer gid
+				][
+					log/error "invalid format reading /etc/group !"
+					none
+				]
+			]
+		]
+		log/error "group not found in /etc/group"
+		none
 	]
 	
-	change-id: func [id [word! integer!] /user /group][
-		if word? id [
-			if none? id: get-ugid mold id [return none]
-			id: pick id to-logic user

+	change-id: func [id [string! integer!] /user /group /local gid][
+		either string? id [
+			unless id: get-ugid id [return none]
+			set [id gid] id
+		][
+			gid: id
 		]
-		either user [
+		if group [setgid gid]
+		if user [
 			;logger/file.log: join logger/file ["-" id %.log]
 			setuid id
-		][setgid id]
+		]
+	]
+	
+	change-gid: func [id [string! integer!]][
+		if string? id [
+			unless id: get-gid id [return none]
+		]
+		setgid id
 	]
 	
 	words: [
 		user: [word! | integer!] in globals do [
-			repend boot-code ['change-id/user to-lit-word args/1]

+			repend boot-code either word? args/1 [['change-id/user/group 
mold args/1]] [['change-id/user args/1]]
 		]
 		group: [word! | integer!] in globals do [
-			repend boot-code ['change-id/group to-lit-word args/1]
+			unless empty? boot-code [change boot-code [change-id/user]]

+			insert boot-code reduce ['change-gid either word? args/1 [mold 
args/1][args/1]]
 		]
 	]
 ]
\ No newline at end of file

I don't know why that would break debugging, so that sounds like 
an extra issue

Because Cheyenne must start as root user to be able to open listen 
ports < 1024, then only, SU to a non-root user. Unfortunately, all 
the log files generated during the root phase of Cheyenne's boot 
process are owned by root, so can't be used anymore once su-ed to 
a non-root user. An easy way to fix that (but looks a bit ugly to 
me) could be to chown( ) / chgrp( ) all generated log files before 
giving up root rights...A cleaner way would involve rethinking the 
whole boot up process of Cheyenne and Uniserve with deep code architecture 
impacts (too much work). Any idea on the best way to solve these 
issues are welcome.

There's also the Cheyenne PID file written in /tmp/cheyenne.pid that 
will suffer the same issue.

separate logging service?

So then all Cheyenne instances could use the same logger

Yes, using the system logger daemon would be good

By the way, /tmp/cheyenne.pid contains "none" on my server, so that 
looks like a bug

http://www.rebol.it/power-mezz/mezz/logging.html

re System logging service: it's not an option because :
- not a cross-platform solution

- some files *have* to be generated directly by Cheyenne (like the 
HTTP log file)

- the trace output in debug mode can generate huge entries that are 
inappropriate for syslog

- the trace output needs to be free from non-Cheyenne entries (or 
it might become unpractical to use for developers)

re Cheyenne PID: your OS ID returned by system/version/4 might not 
be the same as the Linux one. Open %misc/os.r and add a new entry 
in the SWITCH block with your system/version/4 value and [%misc/unix.r], 
then try again.

Anyway, sending a few messages to syslog daemon to notify Cheyenne's 
starting/stopping or signals received might be a useful thing to 
be more sysadmin-friendly.

My system/version/4 on Syllable Server is 4, so something else is 
wrong

I see it only evaluates that when it finds the library interface, 
and that is still not available in R2/Core

Kaj, can you please post your patch code on http://pastebin.comor 
anywhere else where I can download it properly or at least copy/paste 
it?...AltMe is such a PIA to copy large parts of code (unless I missed 
some hidden feature for that).

Just right-click on it

I see PID works when starting Cheyenne with View, but I can't do 
that on Syllable Server proper

Strangely, it just worked now...I've tried it several times a few 
minutes ago and was getting only some parts or nothing at all...

By the way, the convention for PIDs is to have them in /var/run/, 
not /tmp/

/Library component is required to be able to use Cheyenne fully. 
I thought it was now available in latest R2/Core?

No, I complained about it on RebDev, but no response, and no promised 
2.7.8

Is /var/run/ available on OS X too?

Not sure, but I would think so. Otherwise they'd have to patch all 
ported software

I'm changing PID file path to /var/run/

Thanks

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.