World: r3wp

what would cause sudden 403 Forbidden errors on certain pages? Everything 
was fine, restarted the server.. 403

403 is also Access Restricted, so it depends what's in your settings.

But as I'm checking the sources, in Cheyenne itself there is no code 
forcing 403.

nvm - i had a rogue apache service firing up on boot.

Has anyone run pmwiki or any of the other php wiki's with Cheyenne?

All the buzz in javascript land of late is around  Node.js and Redis.. 
And I've been in a heated debate with the Redis group over the latency 
issues. Cheyenne + Rocket (a Rebol key/value store I've been working 
on) makes the Node.js + Redis throughput look sick.
Why do these inferior technologies always get the buzz?

anyone used Bernstein's daemontools to control Cheyenne?

I did my own using SSH and a few server-side scripts and tricks.

I can start/restart the server without it requiring to be setup as 
a daemon.

and without requiring any active ssh session open.

by active I mean persistent.  even when I close the ssh session cheyenne 
remains running.

why not use the embedded remote console? cheyenne/UniServe/services/RConsole.r

you can use the remote, if the server isn't running ;-)

can = can't

humm... true.. 8-)

the usual problem is that when you do a remote login, whenever you 
logout, any application you launched gets killed with the session 
when it quits.

Cheyenne should just be started by the system's init scripts (or 
whatever equivalent on Windows)

If you don't want to kill your running apps on session end, use  
"disown" command.

Would it be possible to encap cheyenne with webapp files into single 
exe?

daemontools are for keeping things going if stopped, as well as starting 
them.

webapp.exe is on Doc's todo liset

Hey Doc.. I can access a websocket page from the interweb, but the 
socket communcations isn't working at all? However, it works fine 
accessing on the local network? Any ideas?

Maybe it's some FW issue.

Is there a core version of cheyenne for windows that can run as a 
service without issues?

 AFAIK, encaping Cheyenne with enpro should work ok with Windows XP 
 (not sure for Vista/7).

Has anyone created any multi-tenanted applications?
 Could you be more specific?

Has anyone run pmwiki or any of the other php wiki's with Cheyenne?

 Yes, Cheyenne docs wiki is running on pmwiki : http://cheyenne-server.org/wiki

anyone used Bernstein's daemontools to control Cheyenne?

 I think some french reboler did in the past, but not sure it was 
 with Cheyenne, try searching through the french rebol forum.

I can access a websocket page from the interweb, but the socket communcations 
isn't working at all? However, it works fine accessing on the local 
network? Any ideas?

 Is there any HTTP proxy in between? Does it require SSL? Cheyenne 
 current websocket implementation doesn't support HTTPS yet.

good to see pmwiki working .... I hadn't realized before when on 
your site that it was a php wiki!

BTW, it looks like your "print" link menu item doesn't do anything.

 Is there any HTTP proxy in between? Does it require SSL?
 - No proxy, no ssl.

Seems like a port / FW issue, but not sure why that would be?

can I somehow automatically execute run one file or a pack of code 
before each page load If I am not in webapp? I added do %... to each 
html file now but it's not very elegant.

I'm having this issue with the cheyenne binary.

I start it up with sudo under linux and the very first time it works.
I reboot, and then try again, and it just quits ... everytime.

I then use rebol/core and when I do %cheyenne.r it complains it can't 
write the cache efs file.  

I allow it, and then restart the cheyenne binary and then it runs 
okay.

So my question is, does the cheyenne binary need to write the cache 
efs file each time?

What do I need to do to allow Cheyenne to start reliably each time 
...?

When it doesn't work, are you still starting it under sudo?

yes, always so it should have write privs

this is the problem I have after restarting ubuntu
http://screencast.com/t/NDgyYzBlM

going to copy the .cache.efs file to cache.efs and then copy it back 
each time with a shell script to see if that fixes it

That's odd; with regular Unix file permissions, the only way you 
could not have access as super user is if the file is read-only, 
but cache and log files would be unlikely to be that

I can write the .cache.efs file as sudo in rebol, but no sudo in 
cheyenne.  Bizarre huh?

Are you switching the user account in the Cheyenne config file?

Also, in the screencast you're starting Cheyenne when it is already 
running, so it may be a legitimate fille locking error

No and I'm not.

After the first pwd you see that I get a message to say that my process 
was stopped.

I then do a ps aux | grep cheyenne to confirm that it is no longer 
running

Any harsh protection subsystems running on that Ubuntu besides the 
traditional Unix file security?

Nope. This is a new ubuntu default installation.  I am *presuming* 
cheyenne quits because it can't write the .cache.efs file  but don't 
know for sure

running cheyenne in verbose mode doesn't help because it never gets 
to start logging the error