World: r3wp

OTOH, if it's working .. don't touch it!

just for the sake of test, it would be valuable if u could try your 
'do* code using 'do

since we dont have automated tests for this - i guess - at least 
lets do some manual tests

Anyway, thanks for examining this .. I just avoided the issue!

i was going around it too, by putting my DOs into on-app-start, but 
hey, for rapid development, such basics should work too

I was putting my stuff into app-init.r as well but found it did not 
work

So, I was defining my odbc sources there but they were being overwritten

So, now I load the db from a disk file each time ...

:) im loading my db from files too...

on each request actually

I have mutiple users using a web app on different ports.  Each has 
their own vhost, and their own pages but to keep things simple, each 
web app is the same.  I include a config file each time a rsp page 
is loaded with the db definition instead of in the app-init.r where 
it did not work

When I included the definitions in the app-init, users would access 
other users' db!

Data wants to be free

Switching away from root is impossible when the RSP module is disabled:

7-May-2011/20:07:17+2:00 : make object! [
    code: 311
    type: 'script
    id: 'invalid-path
    arg1: 'mod-rsp
    arg2: none
    arg3: none

    near: [if exists? file: service/mod-list/mod-rsp/sessions/ctx-file 
    [try-chown file uid gid]]
    where: 'set-process-to
]

from crash.log

Kaj: pushed a fix for that in r139.

When I included the definitions in the app-init, users would access 
other users' db!
 

Have you used session variables to store user-specific data? Everything 
else is unsafe.

Thanks, nice turnaround :-)

Next problem when trying to switch away from root:

8-May-2011/17:30:23+2:00 : make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'zero?
    arg2: 'number
    arg3: [number! pair! char! money! time! tuple!]

    near: [if any [zero? gid not zero? set-gid gid] [log/error ["setgid 
    '" group " failed!"]] 
        if
    ]
    where: 'set-process-to
]

I've checked that I'm doing everything right according to the latest 
Cheyenne conventions. I have a fairly standard httpd.cfg with this:

globals [
	user  "www"
	group "www"

Odd, maybe a regression in the latest revisions...I will test that 
on my local linux box in a few minutes.

Kaj: can you try with user "www" only?

(without the 'group line)

Also, could you run Cheyenne in verbose mode (-vvvv) and check the 
boot logs for any error message?

The only cause of the error you've reported above, is that something 
unexpected happened when trying to access and parse %/etc/passwd 
and %/etc/group. Anything special with these files on your system 
(compared to e.g., Ubuntu)?

Without group the error is still exactly the same

This is a custom Linux, so no comparison to Ubuntu :-)

One difference is that the root user and group are called "system", 
but I didn't find a problem with that in my Cheyenne patch a year 
ago

It works if I only use group, although it's hard to check that the 
group has actually changed

Could you extract the mod-userdir/get-id function and try to run 
it from a REBOL console using:

    col: #":"
    get-id "www"

Hmm, wait, I think the problem is related to the 'set-gid function.

Are you using the Pro or Command binary? (I guess it is the r139 
one)

I have found a bug with the 'chown function.

Pro 135

Did you see any error in Cheyenne log file (chey-pid-*.log or crash.log)?

Wait, I have r137 now

The errors I quoted are from crash.log. I'll do the -vvvv thing, 
but have to do it later tonight

Ok, I think it is not needed anymore. It seems that the set-gid call 
is failing on your system for group "www". Set-gid returns a logic! 
or none! value if running on a 2.7.8 kernel and an integer! for previous 
kernels (due to different mappings), that is what's causing the error.

If only Carl has freed /Library on Linux instead of adding 'access-os 
native...it would have saved me a lot of coding/debugging time...

Has anyone else than me played with 'access-os native. I can't get 
it return any consistent value...

It seems that the messy behaviour is underneath 'access-os (the setgid/setuid 
OS calls).

i can try on mac too, if u tell me what should be tried

Kaj: I have pushed a fix (needs testing).

Mac: wow, forget about it...

forget => forgot

I am pushing the same fixes for Mac now.

now, im getting multiple errors within the same trace:
	** Access Error : Cannot open /Users/onetom/p/ob/wfm/app-init.r 
	** Access Error : Cannot open /Users/onetom/p/ob/app-init.r 
why is it trying both locations? is it normal?