<br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>>Well, if you want to rewrite FreeNX ... okay, kidding.</blockquote><div><br>

thank god! hehe ;-)  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">>The point is at the stage, where the client says "bye" or "quit" the connetion is either tunneled or closed.

</blockquote><div><br>Indeed. I guessed that would be the problem.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">So before nxclient sends the Switch command to 

nxssh.exe you send "quitkey" (not bye!), kill the process, startup a new one and use that for the communication.</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

To complicate matters nxssh.exe has the tunneling logic build into the system. So what you need is a special nxserver instance running on all the backnodes, that just gets a key and then forwards the connection from backmachine to nxagent (running on the same machine).

<br><br>This could work like:<br><br>nxserver-keydaemon runs on port 6445 and accepts keys + port number and creates a file called <key> in some directory with the port number in it. (it is protected via firewall rules to be only accessible from frontnode)

<br><br>(The frontnode nxserver establishes such a mapping instead of tunneling the connection itself.)<br><br>nxserver-keyforwarder as shell for nx user on backnodes:<br><br>Getting a "key" and either responding:

<br><br>NX 404> Not found<br>NX 999> Bye<br><br>and forwarding the connection via netcat to the port from the key file.<br><br>This way you have:<br><br>- all session logic on the server<br>- direct connection to backnodes

<br>- nxserver-key{daemon, forwarder} as connecting unit in between<br><br>Btw. Don't use the frontnode as default router for the backnodes, because then you could have done the normal FreeNX scenario as well ... (all traffic will then be routed over the frontnode)

</blockquote><div> Well ... let me try to tell you the details of my implementation, so you can say your opinion... and bare in mind that i came to the nx world 6 months ago.. well...  the client authenticates normally in the frontnode..

<br><br>after authentication is succesfull, he sends a "set capability_redirect" message to the frontnode.. ( the sending of this message depends or wether the user wants to be redirected ( by a means of a button on the configuration GUI )  )

the frontnode will ask the client for it's session parameters ( NX>3899 ), if i remeber correctly.. don't have the implemented code here in front of me the frontnode will receive the session parameters, do the appropriate load balancing to determine the IP of the backnode.. after, it will generate a cookie..

<br><br>the frontnode connects to backserver with nxssh and sends a authentication message ( known only to backnode and frontnode ), sends the username, password and the cookie from which the backnode will soon receive a connection .. this information would be saved in a file on the backnode

<br><br>frontnode would then start a session using the client's given parameters in the backnode ( this is what's failling because after sending "startsession 'parameters'" , i really don't know what to do next.. )

backnode would give the sessionID to the frontnode as soon as possible ( probably not but, in this case, after the server_startrestore_session() ) frontnode would give back to the client the IP:port, cookie and sessionID back to the client...

<br><br>nxclient breaks the connection with frontnode and creates a nxssh connection with the backserver, using his own username, password and the received ( by the frontnode ) cookie<br><br>after succesfull authentication, the client would immediatly send "restoresession --id=$SESSIONID 'parameters' "

<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">>To summarize what you need to do in pseudo code / pseudo patch:<br><br>

>Use global usable ip addresses in your load balancing setup.<br><br>>- old nxserver code<br>>- vorhandener quit command<br>>+ case "quitkey")<br>>+     echo_x "ByeKey" 1>&2<br>>+     echo_x "NX> 999 ByeKey" 1>&2

<br>>+     let PROXY_DISPLAY=$SESS_DISPLAY+4000<br>>+     SESSKEY=$(echo $PROXY_DISPLAY | netcat $SERVER_HOST 6445)<br>>+     echo_x "$SESSKEY:$SERVER_HOST"<br>>+     exit 0<br>>- vorhandener bye command

>- old nxserver code >- Old nxclient code until the bye command. >+ "quitkey" -> server (will establish the mapping with keydaemon) >+ Read code back. If the server did not understood the command?

<br>>-> fallback to sending bye and letting the server handle the forwarding<br>>-> skip the rest until old<br>>+ Server did understood the command<br>>+ gets back the key and real ip (key:realip)<br>>+ nxssh kill

<br>>+ nxssh new startup with right ip to nxserver-shell keyforwarder<br>>+ send key<br>>- Old nxclient code starting with sending Switch command to nxssh.exe<br><br>>nxserver-keydaemon running via faucet (netpipes package) like:

<br><br>>#!/bin/sh<br><br>>[ "$(whoami)" != "nx" ] && exec sudo -u nx $0<br><br>>if [ "$1" = "readkey" ]<br>>then<br>>  read line<br>>  KEY=$(mcookie)<br>>  echo "$line" > $HOME/keys/$KEY

>else >  # FIXME: Possibly cleanup keys here first >  # rm -f $HOME/keys/* >  # FIXME: Add self protecting iptables rule >  exec faucet 6445 -io "$0" readkey >fi >Spawn it as root.

<br><br>>nxserver-keyforwarder is run by putting the following keys in node.conf on all slave machines:<br><br>>ENABLE_NOMACHINE_FORWARD_PORT="1"<br>>NOMACHINE_FORWARD_PORT="22" # assuming ssh runs on 22

<br><br>>NOMACHINE_SERVER="/usr/NX/bin/nxserver-keyforwarder"<br>>NOMACHINE_NX_HOME_DIR="/usr/NX/home/nx"<br><br>>nxserver-keyforwarder would look like:<br><br>>#!/bin/sh<br><br>>read -t5 KEY || exit 1 # add a timeout, so no one

<br>>                       # can hold up the connection<br><br>>if [ -r "$HOME/keys/$KEY" ]<br>>then<br>>  port=$(cat "$HOME/keys/$KEY")<br>>  echo "NX> 999 Bye"<br>>  netcat 

<a href="http://127.0.0.1">127.0.0.1</a> "$port" >else >  echo "NX> 404 Key not found". >fi</blockquote><div> I think i understand your idea... I'm not familiar with netcat or faucet but i will look into it this weekend and try to implement it monday.

Still, there's one thing i didn't understood. Where does in your code/idea does the frontnode starts the session in backnode?  It's because i've been told to implement it so that it's the frontnode that starts the session in the backnode so that the client doesn't request a session on frontnode and then a completly different one on the backnode.

<br><br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Good luck!</blockquote><div><br>Thanks :-)<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

cu<br><br>Fabian<br><br>PS: This was all written quite fast, so there might be some minor syntax errors, but I would do the overall design like that.</blockquote><div><br>No problem. It was a great help and i thank you.<br>

</div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">PPS: Once you have it working, I would of course accept a patch and apply it to 2x SVN and FreeNX SVN.

</blockquote><div><br>I'll have to do a report on my implementation soon.. When done, i'll send you and if you like it what was done, i'll send you the code :-)<br> </div><br></div>Carlos Matos<br>