Here's the script I mentioned before in the thread.

It does the following:

1. Establish a local (direct) or remote (SSH tunnel) connection to the (remote) 
client.
2.
Either start nxagent and run a startup script (.nxstartup) or resume a
suspended nxagent instance. If the nxagent is currently serving another
nxproxy you can force that nxproxy to disconnect (-f).
3. Allow local suspension of the session.
4. Secures both the X server started by nxagent and the nxagent-nxproxy 
connection with a generated MAGIC-COOKIE.
5.
The client part of the script can also be used to terminate the nxagent
(or you can close all X clients on its X server, 60 seconds later the
nxagent will die)


Just place this script in your home
directory on both client and server (if you put the remote client side
in a different directory you need to fix the local server part of the
script), and make it executable (please look it over first, if it eats
your lunch you have been warned).

This can probably be made a
little nicer, or one could write this is python, maybe some of the
stuff is not needed (like force disconnecting another nxproxy, etc);
but this works fine for me (and I constantly have to remind myself that
I am not sitting at my work machine, because at home it is just as
snappy as locally). It should probably allow passing NX parameter from
to the remote client side, etc.

The reason that this is more than 5 lines is the NX's suspend/resume stuff.

Currently
it sets the link parameter to LAN for a local session and to WAN for a
remote session. There are *many* more parameters to tweak in nxagent if
you have special connection requirements, for example you can restrict
the maximum bandwidth used, etc.

I usually take some windows of my session on my work machine home to
work of it after hours - by starting a local session at work, and
connecting to it from my home machine through SSH, because it's
rootless I can decide which windows to pipe through the nxagent.

Example... At work:
1.
nxsession 1 ... starts nxagent, executes .nxstartup, start nxproxy and
connects it to nxagent. nxproxy is also an X client and forward
requests to my local X server. Any X client with display=:1 will go
there as well.
2. nxsession 1 -s ... suspends session 1 (optional)

At home:
3.
nxsession 1 -h <work machine> -ssh "<special ssh options, like
user/port/etc>" -f  ... resumes (or starts if not started) the
nxagent on my work machine through an SSH tunnel, will also force
disconnect the work machine's session if I forgot step #2.

-- Lars


----- Original Message ----
From: lars hofhansl <[email protected]>
To: [email protected]
Sent: Monday, August 24, 2009 9:11:38 PM
Subject: [Parti-discuss] Rootless NX

I have since discovered that NX can be used in root less mode as well, and that 
all of the complexity of FreeNX (or NoMachines server)
and NX client, and the cumbersome authentication (nx user and then the real 
user) is not needed to use NX.

All one has to do it start
  nxagent -display nx/nx,link=wan,...:port :port -R
on the remote (client) machine, and
  nxproxy -S machine:port
on the local (server) machine. If you want secure communication just use SSH to 
establish a tunnel (display port + 4000 is used by NX),
and use localhost:port on the local server.

No FreeNX, nxclient, public key huh hah, or anything additional indeed is 
needed.

nxagent acts as an X server (just like Xvfb, Xnest, or Xvnc), and any X 
application can then be used on the remote machine using the given display port.

That is all that is needed to park and forward windows just like with Xpra. A 
little bit trickery is needed to handle nxagents 
resume/suspend logic, but on the oher hand that allows changing 
encoding/caching behavior between suspend/resume cycles.

Anyway, this is not to diminish the ingenuity of Xpra. I just found that using 
NX this way (with a bunch of simple bash scripts to set the SSH tunnel),
is just as simple as Xpra, windows-aware as well, and performs (honestly) far 
better over low bandwidth links. 

_______________________________________________
Parti-discuss mailing list
[email protected]
http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss

Attachment: nxsession
Description: Binary data

_______________________________________________
Parti-discuss mailing list
[email protected]
http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss

Reply via email to