World: r3wp

im running with -w 1. is it debug mode too?

No.

I can't get the error here using -w 1, only using -w 0.

Can you show me the content of %obj.r from : do %../lib/obj.r?

New Cheyenne revision: 138


FIX: RSP code binding issue with nested DO calls (thanks to Tamas 
Herman for
reporting it).


Please pay attention that this fix is really deep in RSP engine, 
I have tested it with all my RSP apps, but regressions are not excluded. 
Be sure to report me any odd changes in your app behaviour after 
upgrading to r138.

Dunno if this is relevant .. but I tend to use 'do* instead of 'do

do* == do/global == native 'do

There are cases where you want to bind your code to global context, 
so you will use 'do/global. For all other cases, you should just 
use 'do (especially now that nested 'do should to be fixed).

my meaning being that 'do did not work as I expected ...

I should go back and see if this new build fixes the issues I've 
had

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.