[FreeNX-kNX] Manually starting a freenx session

[Carlos Matos]

>
> >Well, if you want to rewrite FreeNX ... okay, kidding.


thank god! hehe ;-)


>The point is at the stage, where the client says "bye" or "quit" the
> connetion is either tunneled or closed.


Indeed. I guessed that would be the problem.

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.

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).
>
> This could work like:
>
> 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)
>
> (The frontnode nxserver establishes such a mapping instead of tunneling
> the connection itself.)
>
> nxserver-keyforwarder as shell for nx user on backnodes:
>
> Getting a "key" and either responding:
>
> NX 404> Not found
> NX 999> Bye
>
> and forwarding the connection via netcat to the port from the key file.
>
> This way you have:
>
> - all session logic on the server
> - direct connection to backnodes
> - nxserver-key{daemon, forwarder} as connecting unit in between
>
> 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)



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

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

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

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

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

after succesfull authentication, the client would immediatly send
"restoresession --id=$SESSIONID 'parameters' "


>To summarize what you need to do in pseudo code / pseudo patch:
>
> >Use global usable ip addresses in your load balancing setup.
>
> >- old nxserver code
> >- vorhandener quit command
> >+ case "quitkey")
> >+     echo_x "ByeKey" 1>&2
> >+     echo_x "NX> 999 ByeKey" 1>&2
> >+     let PROXY_DISPLAY=$SESS_DISPLAY+4000
> >+     SESSKEY=$(echo $PROXY_DISPLAY | netcat $SERVER_HOST 6445)
> >+     echo_x "$SESSKEY:$SERVER_HOST"
> >+     exit 0
> >- 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?
> >-> fallback to sending bye and letting the server handle the forwarding
> >-> skip the rest until old
> >+ Server did understood the command
> >+ gets back the key and real ip (key:realip)
> >+ nxssh kill
> >+ nxssh new startup with right ip to nxserver-shell keyforwarder
> >+ send key
> >- Old nxclient code starting with sending Switch command to nxssh.exe
>
> >nxserver-keydaemon running via faucet (netpipes package) like:
>
> >#!/bin/sh
>
> >[ "$(whoami)" != "nx" ] && exec sudo -u nx $0
>
> >if [ "$1" = "readkey" ]
> >then
> >  read line
> >  KEY=$(mcookie)
> >  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.
>
> >nxserver-keyforwarder is run by putting the following keys in node.confon all slave machines:
>
> >ENABLE_NOMACHINE_FORWARD_PORT="1"
> >NOMACHINE_FORWARD_PORT="22" # assuming ssh runs on 22
>
> >NOMACHINE_SERVER="/usr/NX/bin/nxserver-keyforwarder"
> >NOMACHINE_NX_HOME_DIR="/usr/NX/home/nx"
>
> >nxserver-keyforwarder would look like:
>
> >#!/bin/sh
>
> >read -t5 KEY || exit 1 # add a timeout, so no one
> >                       # can hold up the connection
>
> >if [ -r "$HOME/keys/$KEY" ]
> >then
> >  port=$(cat "$HOME/keys/$KEY")
> >  echo "NX> 999 Bye"
> >  netcat 127.0.0.1 "$port"
> >else
> >  echo "NX> 404 Key not found".
> >fi


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.



Good luck!


Thanks :-)


cu
>
> Fabian
>
> PS: This was all written quite fast, so there might be some minor syntax
> errors, but I would do the overall design like that.


No problem. It was a great help and i thank you.


PPS: Once you have it working, I would of course accept a patch and apply it
> to 2x SVN and FreeNX SVN.


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


Carlos Matos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/freenx-knx/attachments/20070908/a2fe7e2b/attachment.html>