AltME groups: search

Anyway it seems that restriction is now obsolete as ssl and odbc 
are now free.  And IOS is dead.  The license prevented you from creating 
a clone of IOS

Once I switch it back to a user application using the menu, it starts 
to work again

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.

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

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.

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

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

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?

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.

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

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

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

maybe it's a httpd.cfg error?

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

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

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.

I've removed %app-init.r from %www/testapp in Cheyenne's archive, 
started a fresh Cheyenne session, logged in http://localhost/testapp
and I can't reproduce your error. I only keep receiving this kind 
of (normal) error: 

##RSP Script Error: 

	URL  = /testapp/login.rsp
	File = app-init.r


 ** Access Error : Cannot open /C/Dev/Cheyenne/www/testapp/app-init.r 
	** Where: rsp-script 
	** Near:  [init: load join root %/app-init.r]

looks like the cheyenne I'm using is a build from middle of last 
year

That's usually a good rule.

I'm sure it can be resolved. And if someone else has done it in such 
a way that you and Doc approve, I'll gladly borrow from them. :-)

So, this is a local 'do and not the '*do ?

So, yes, it's a local 'do in my example above.

Thanks again Doc, that lets me run things using INCLUDE. Now I'm 
on to the next issue, which is that it doesn't work (i.e. INCLUDE 
gets messed up) after running any kind of RSP. I'll dig in when I 
get a chance and tell you what I find.

Gregg: I'll give it a try today to see what's going wrong.

Gregg: my solution was missing a 'unset call too (tested with Cheyenne 
sample webapp, works ok) : 

on-application-start: does [
	set 'rsp-include :include
	unprotect 'include

 unset 'include				;-- this one is required to allow %include.r to 
 load properly
	do/global %include.r
	set 'include-path [%//dev/Cheyenne/www/testapp/]
]

Oldes: we have one here somewhere, but I can't find it right now. 
Anyway: 
 

1) "kill -9" is not a good way to stop Cheyenne, a simple "kill" 
is the right way (this signal is caught by Cheyenne to clean up things 
and exit properly).


2) "ps aux | awk ..." is not required, Cheyenne stores its main PID 
in /var/run/cheyenne.pid (or /tmp/cheyenne.pid in revisions < r90). 
Just read this PID and send all signals to that process only. Watch 
out if you run it on port <> 80, you'll find the port-id inserted 
in the PID file name.

It seems that the PID file location recent change was a bad move, 
/var/run is by default only writable by root...To workaround that, 
user should create a sub-folder as root and then chown it to the 
application user to allow it to write PID files there : http://serverfault.com/questions/159334/what-permission-to-write-pid-file-in-var-run

Kaj: so, this means that an install script would be required for 
Cheyenne to be able to run on UNIX, this is not something that I 
want for Cheyenne unless really necessary. Do you see any simple 
solution to that issue? If not, I'll revert it to write in /tmp by 
default and add a config option to let users choose alternative location 
when desired.

I'll have to do some more digging Doc, and maybe see what do* does 
since I haven't tried that. I'll actually read some source if need 
be. ;-) 


What I saw with your new change is something I also saw once with 
the previous approach. Plain CGI worked fine until an RSP was run, 
then the CGI failed, *then* both the test RSP and test RSP web app 
started returning with garbage at the top of the page. More garbage 
each time, like a buffer was being added to. Then the plain CGI worked 
again. Doing a reset on the workers solves the garbage problem.


My Cheyenne EXE is from 2009 so I'll check for a new one before doing 
anything else.

From 2009 -> more than 90 revisions since then, these issues have 
been solved a long time ago :-)

Are you using the official binary v0.9.19?

It looks like I really need to make a new official release with new 
binaries.

Kaj: so, this means that an install script would be required for 
Cheyenne to be able to run on UNIX, this is not something that I 
want for Cheyenne unless really necessary. Do you see any simple 
solution to that issue? If not, I'll revert it to write in /tmp by 
default and add a config option to let users choose alternative location 
when desired.

Hm, avoiding installers is good, so I guess a config option is readable

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

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.

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

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

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.

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

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

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.

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

2.7.7 didn't looked as stable as 2.7.6 when I first tested it (View 
crashed on linux, CALL's code seems to have changed). As I can't 
take any risk with my code in production, I've sticked to 2.7.6 so 
far. Maybe I should give it a more serious try now.

I've switched to 2.7.7 a while ago I don't see problems with it, 
though some things which affect cheyenne more directly might not 
be issues I have relied on.

e.g. you have a different use case so it might be triggering problems 
that I don't usually encounter.

Right, Cheyenne puts /Core and /Pro at stress. 


Today, I spent almost an hour to spot a bug in the RSP engine (it 
was a regression bug), but no way I could figure out the cause or 
what part of the code was producing it. The error raised by REBOL 
was inside ATTEMPT, saying that SET/ANY in ATTEMPT couldn't set the 
value...?? The whole mess was caused by a missing AS-STRING after 
a LOAD/HEADER, branching the RSP engine code into a faultly path 
leading to a corruption of RSP own code and probably of some REBOL 
global words too (my raw guess, but it could have triggered an internal 
REBOL bug as well). That's the dark side of having a fully modifiable 
language, a very small mistake can lead to a total session corruption 
with a cause very hard to track.

Doc - R3 might be better in that regard - it is a bit less "modifiable", 
more precisely defined, and it has modules too. But - there will 
probably be no Cheyenne for R3, so :-)

Doc, only an hour? That's a good day for me with rebol sometimes:-) 
thanks for the new version.

From your Wed 3:01 PM post where you mentioned you "spent almost 
an hour to spot a bug..."

Doing a little catch up here...

I'm having a little fun trying to set far future expiry dates from 
Cheyenne.


There seems to be some conflict between the httpd.cfg and the script 
as to whether the anem is expire or expires.

Thanks  Doc. I must have forgotten to stop a previous session before 
starting a new one.

I'm having problems with post data and Rebol CGI scripts under Cheyenne. 
I ran a simple test scipt to simply echo back the post data:

#!/usr/bin/rebol -cs



REBOL []


data: make string! 1020

buffer: make string! 16380

while [positive? read-io system/ports/input buffer 16380][

    append data buffer

    clear buffer
]


print "content-type: text/plain^/"

print data


The script echoes back the post data when run under Apache but prints 
an empty line under Cheyenne.


(Just to check I ran a similar Ruby script which successfully echoes 
back the post data in Ruby).

I'm running 0.9.20 encmd.

I think this would work if you would force Cheyenne to execute it 
as a real CGI script

But normally, Cheyenne recognises a REBOL script and executes it 
as Fast CGI, in the UniServe process itself

Thanks Kaj. I'll take a look at it.

I would prefer to force Cheyenne to execute the script as a real 
CGI Script as I am trying to run REBOL/Services as a CGI script under 
Cheyenne. Ideally, I don't want to have to change the REBOL/Services 
code. (I am migrating a REBOL/Services application away from its 
existing web server and hopefully to Cheyenne. In the longer term, 
it may be possible to convert it to a Cheyenne web app).


Any hints on how to force Cheyenne to run a .cgi file as a real CGI 
script?

But why? It's a lot slower

Or does REBOL/Services have a CGI interface?

Thanks, I remember now - I'll give that a try.

But I've found a bug in the current version:
5/11-10:57:51.468-## Error in [mod-static] : Make object! [
    code: 500
    type: 'access
    id: 'cannot-open

    arg1: {/F/SVN/cheyenne-server/Cheyenne/log/h-arch.desajn.web:8080-access.log}
    arg2: none
    arg3: none

    near: [write/append join log-dir [req/vhost #"-" log-file] second]
    where: 'do-handler
] !
The #":" is not a valid char for a file name.

Is it possible to disable debuging per page?

Yes, that's a new feature of revision 103, use debug/off (see Changelog.txt).

SVN r105

FEAT: debug mode can now be restricted to a given client IP address: 
debug/options [ip: 1.2.3.4]
FIX: debug menu now inserted only in pages with HTML content-type

FIX: (regression) debug menu and RSP errors now displayed even if 
response/buffer is empty

FIX: inlined colors for debug trace window (to avoid CSS overloading)

FIX: bad log filename generation when using a virtual host definition 
that includes a port-id
FIX: Cheyenne logo updated for default test pages

WOW.. I've been away for a while and cheyenne moves years ahead!! 
very cool!

Is anybody running REBOL/Services as a cgi script under Cheyenne 
?

Tracing it. That's odd: the general binding is done in misc/macosx.r. 
I don't see why cgi.r should do it double

The CGI.r code is run in a separate process, it inherits OS bindings 
from misc/macosx.r only when encapped. It should have worked using 
the  /cmd binary, I need to look into it and patch the CGI code to 
not bind twice when encapped.

.. and am running CGI scripts not fastCGI scripts - I even checked 
that the env variables are getting set by running a trivial Ruby 
cgi,.

The actual system will run under Windows but we've encountered a 
strange problem. I'm trying to do some testing on my Mac to try to 
isolate the problem.

This is a debug print of a correct response:
req/result [

    done [reply seq 1 service "Generic REBOL Service" commands 1 time 
    0:00] 
    ok [date 9-Nov-2010/2:16:33-7:00]
]

As an archive for images collected from remote cameras. (I didn't 
write the system). The system has been live for a few years. It currently 
runs under Xitami and I'm trying to help move it to a more modern 
web server. We are hoping to move to Cheyenne.


After the system has been migrated, we would then have the possibility 
to convert it, or parts of it,  to a Web App.

It's working fine, thanks - I can confirm that I can  access the 
env variables from a Ruby CGI.

Cool Cheyenne on OSX... I will give it a try on our new server.

from a client app (phone app) to my server with my data base.  like 
a json call in js

So the server, assuming it supports a callback, sends back something 
like this, which gets executed immediately:

Commuter.dataSource.setData({ ... JSON data ...});

Maybe i'm confuesed. Is the callback a function of the web server 
or is it just how I setup my cgi script?

I don't think that should be called a callback. The most defining 
nature of callbacks is that they are asynchronous, and that just 
doesn't fit into the browser/web server model

I suspect they would call it a callback because some JavaScript is 
transferred to be executed on the other side, but that's just exchanging 
program code, not asynchronicity

So the answer is indeed that this is nothing more than a normal request 
yielding a response, where the response happens to be JSON or maybe 
even full JavaScript. This depends entirely on your own server and 
client programs, not on the intermediating web server

Graham: Chrome shows the JSON output while FF offers to download 
it. It's better to use a READ and a JSON decoder from the console 
to display JSON strings or a plugin like Firebug rather that rely 
on the browser.

Cheyenne on R3: R3 lacks /Shell and /Library components that Cheyenne 
requires, and R3 is still far from being stable (both in design and 
implementation). Extension is also far from being a /Library drop-in 
replacement, I don't want to have to write and maintain per-platform 
C code, that defeats the purpose of using a (supposedly) cross-platform 
tool and it's, IMHO, a big regression from R2. Moreover, once concurrency 
support at low-level will be ready, a big part of Cheyenne would 
need a re-design and rewrite, so I prefer to wait for that for a 
real added value of a R3 port.

My Firefox 3.5 wants to save the file. Isn't that a normal reaction 
for a bare json file?

Browsers saving a received content with a application/* mime type 
looks logical to me (unless requested from a JS XHR object).

If it downloads the RSP, that would be a problem in the Cheyenne 
configuration, because it is always supposed to execute an RSP

Graham: you should try by adding the following header to your RSP 
script outputting a PDF file in order to display it in the browser 
:
response/header 'Content-disposition  {inline;filename="doc.pdf"}

Seems like a Chrome mime type mapping issue, see : http://www.google.com/support/forum/p/Chrome/thread?tid=43bec1a85f6c7c9c&hl=en

/shell is available, just less powerfull. /wait was added at least. 
/output is not there, but in such a case /wait is sufficient - you 
can redirect to file, and read it after the return from the call/wait 
.... it is just a note, I don't want to lobby for R3 port, that would 
be - preliminary :-) ... at least unless concurrency model is available, 
it would be worthless ...

What is Cheyenne using DLL interface for?
 

- UNIX: CGI support, running as user instead of root, management 
of external servers (like PHP)

- Windows: CGI support, external servers (PHP), Desktop detection 
(for hiding working files), NT Services support, mutiple instances 
support, systray menu

DLLs are generally not cross platform too, no?

DLL are not, but the mappings to the DLL can be written easily in 
REBOL code, no need to go down to C. I see that as a big advantage 
in simplicity and maintainability.

/shell is available, just less powerfull.
Cheyenne requires /info, /output, /input and /error.


/output is not there, but in such a case /wait is sufficient - you 
can redirect to file, and read it after the return from the call/wait

If you want to have the slowest CGI support in the world, that's 
a good way for sure!

That sucks then ... RT's attitude is - do it yourself, as it is 12 
pages of C code, and we don't care about having R3 doing at least 
the same stuff as was possible with R2. I described the syndrome 
here:


http://rebol.net/wiki/What_makes_a_good_beta#Wrong_attitude_towards_finishind_R3.3F

RT's attitude is - do it yourself, as it is 12 pages of C code, and 
we don't care about having R3 doing at least the same stuff as was 
possible with R2. I described the syndrome here


From what Carl told me, producing that code took an enormous amount 
of resources of several of his best coders at the time it was made, 
because there is a lot of trickery involved. It took a lot of research 
and he is therefore probably not inclined to do it again that way 
for R3. Maybe a smarter method will come up, but would you rather 
have him dive into that for 3 months or finish R3?

Henrik - RT should take care of defining a product. No matter who 
does it in the end - RT themselves, contracted developer, sponsored 
developer, whatever. I expect DESIGN of the product being fully in 
hands of Carl - from tasking, to shell interfacing. Here's the guru 
here (that is not to say that other devs can't design the solution), 
but really - Carl should be an architect ...

I don't need it myself now. I might learn to use Extensions, and 
simple /shell might be sufficient for me. But we are in a Cheyenne 
channel - no tasking, no DLL, no /Shell - no Cheyenne for R3. No 
Cheyenne for R3 =  no Cheyenne at all in the long run imo ... easy 
as that :-)

The other thing is that Carl thinks the solution is so obvious that 
he has not told us what to do, because he expects it to be happening 
now on a per-platform basis as part of the hostkit, just as Cyphre 
describes. So while we're arguing here, and no-one is doing anything, 
in a few months time, he'll be surprised that nothing has happened. 
We should probably get him to make a blog post on it for "directions".