r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!Cheyenne] Discussions about the Cheyenne Web Server

Terry
13-Jan-2010
[7477x4]
Here's an example piece of JS that passes the params to this ws-app


<button onclick="ws.send('[{sofpandv} {} {isa} {person}]');return 
false;">GO</button>
If you want to pull the value of a field for the first param.. 

<button onclick="ws.send('[{'+ $("#elementid).val(); +'} {} {isa} 
{person}]');return false;">GO</button>
Very simple, very cool.
What we need now is a JQuery dialect for scripting the DOM.. never 
needed to pass back JSON, but push well formed JS
Carl
13-Jan-2010
[7481]
Do must people run cheyenne from source or from its encap?
Graham
13-Jan-2010
[7482x2]
I ran my own encap version as I needed /command
and I didn't think the command license permitted me to run command 
on multiple servers
Carl
13-Jan-2010
[7484]
why not?
Graham
13-Jan-2010
[7485]
Irrelevant now
Carl
13-Jan-2010
[7486]
strange... this box runs this altme world, but not cheyenne.
Graham
13-Jan-2010
[7487]
meaning cheyenne won't run?
Carl
13-Jan-2010
[7488x3]
no, it's running. just no access
I see 8 instances of itself.  Is there some kind of setup required?
perhaps I need to uncomment the listen line in the config?
Graham
13-Jan-2010
[7491x6]
it defaults to port 80 ...
8 instances sounds right .. those are the worker processes
You only need the listen line if you are listening on a different 
port ... but did you install Apache ?
ie, did the distro you chose include Apache ...
anyway, you could try listening on a higher port and see if it works 
..
I know Henrik is using Linode and Cheyenne
Carl
13-Jan-2010
[7497]
no apache
Graham
13-Jan-2010
[7498]
firewall?
Carl
13-Jan-2010
[7499]
thinking.... does it need to run as root?
Graham
13-Jan-2010
[7500x2]
does wget work on localhost?
I've usually started cheyenne as root ...
Carl
13-Jan-2010
[7502x3]
there is no wget
read http://localhostfails
It's interesting... my browser hangs on it... so it's like it's not 
sending the http header to get things going.
Graham
13-Jan-2010
[7505]
I guess try root ...
Carl
13-Jan-2010
[7506x2]
must be a config problem. checking
tried 8000 too
Graham
13-Jan-2010
[7508x2]
netstat -an | grep "LISTEN"
( I'm reading from my own installation instructions :) )
Carl
13-Jan-2010
[7510x3]
needed root after all.
So, I wonder how to sandbox it on this server.
http://69.164.199.93
Graham
13-Jan-2010
[7513]
No known vulnerabilities ...
Carl
13-Jan-2010
[7514x5]
rotflol.
Anyway, got it running.  It reminds me of another product that comes 
as an exe only.
Maybe I learned something.  Anyway, good to finally run it on a linux 
box.
I just converted the home page to RSP.
dinner time
Terry
14-Jan-2010
[7519x2]
Doc, do you see any issues with that  on-message function I posted 
above?
If i put a "wait random 10" line within the do-task/on-done function. 
that returns an alert back to the page, then open a couple of browsers.. 
and fire the function in both, I get a lot of strange behaviour.. 
and I'm not convinced they don't block each other?
Henrik
14-Jan-2010
[7521x2]
Carl, it needs to run as root to go below port 1024.
I see you have it running. :-)
Graham
14-Jan-2010
[7523]
Except it would not run for him on port 8000
Dockimbel
14-Jan-2010
[7524x3]
Carl, it's possible to SU to any user while started as root, but 
that will only work for the processes forked, not the first one (the 
Cheyenne/Uniserve main process). In config file, just uncomment those 
lines, choose the adequate user/group targets and restart the server 
:

	;	user  nobody
	;	group nobody


I need to investiguate more in Apache's sources to see how they achieve 
full SU on all processes.
Terry: on-message function => yes, loading a script on each request 
is ok for debugging, but bad pratice for production. I'm not sure 
that WAIT is safe in Cheyenne callbacks, never tested that, this 
function is not supposed to be used in user code inside Cheyenne 
main process (it would work in a RSP script, but will block valuable 
resources and reduce scalability).
You should try with a timer event instead (if you really need to 
delay it server-side).