Few points:
I am using the latest freenx (0.4.4) & nx 1.5.0 & nomachine's nxclient
and I have found the following:
- the nxproxy is never started. Once you connect and start a session,
only nxagent, nxserver and nxnode instances are running on the server.
- If the user has already suspended session suitable to reconnect, user
is automagically reconnected to the suspended session instead of
starting a new one.
- If the user has already running session with another terminal and
tries to connect from another one, new session is started.
- To suspend the session, just CTRL-ALT-F to exit fullscreen and click
the "x" icon in the left upper corner. You will be offered to terminate
or suspend the session.
- the suspended session can only be reconnected from suitable terminal.
Example: session started from terminal running Xsun X server can not be
resumed from Xorg or Windows terminals and so on.
Regards,
Ondrej
Anselm Martin Hoffmeister wrote:
Am Freitag, den 02.09.2005, 12:47 +0100 schrieb pandarinathan raman:
--- Anselm Martin Hoffmeister
<[EMAIL PROTECTED]> wrote:
[...]
A solution for roaming users with persistent
sessions (quite like the
Sun solution, if you happen to know it) is to run a
X-proxy on the
server, and on every client connect to check wether
there already is a
session for that user - in case yes, connect to the
X-proxy where that
session lives, else create a new session in the
X-proxy and connect
there. afaik, some Gnome people started playing on
that.
This sounds interesting. Can you please throw some
more light on how this can be done or please point
some web reference.
For running a short test I recommend you get the Opensource version of
NoMachine's MX technology. I just downloaded it and had a try, so I'll
give you some hints how you could configure it. Search for "freenx" - if
you use Debian, .debs are available on (/etc/apt/sources.list)
deb http://debian.bootsplash.de unstable main
deb-src http://debian.bootsplash.de unstable main
You need the server as well as the client (deb packages
freenx expectk nxdesktop nxviewer nxlibs nxproxy nxviewer nxclient)
Now, you need to setup a session. Let's assume you want to test all this
as user "anselm" (because that is what I did :-). Then, login as
"anselm" to any terminal as usual. Get a shell window and type the
following:
/usr/lib/nx/nxclient --wizard
Input a session name ("local", for example), set hostname "localhost",
Port 22, connection type LAN. On the next screen, select Unix->Custom,
click on "Settings..." and choose "run the following program". Type
"/usr/bin/icewm" there (or whatever desktop your users are supposed to
have) - for testing, I recommend indeed using icewm as it is rather not
running into problems as KDE if started twice by the same user - and
that might happen right soon while testing. "New virtual desktop" is OK
also. Size of remote desktop should be fullscreen, but you do not want
SSH on that connection. You can also do without a shortcut on the
desktop.
Go for the advanced settings, and check wether General->Desktop
(Unix/Custom) -> Settings still has "/usr/bin/icewm" set - my copy of
the nxclient tends to forget that setting once in setup.
Now click "OK", and save the configuration. Input your password and
connect. This should fire up a fullscreen icewm. To get out of there,
open a shell and type "killall nxproxy".
You did all this to have a ready-set-up NX connection config. Now the
trick is to define a new session type for your login manager (you know,
where you can choose between KDE, Gnome, whatever....). This depends, of
course, on wether you use KDE or GNOME. Go and define a new session type
that (taking the "icewm" session as template :-) runs
/usr/lib/nx/nxclient --session ~/.nx/configs/local.conf
instead of /usr/bin/icewm.
Now, the next time you log into the terminal, choose session type "NX".
It should show the "NX connecting" screen for two seconds or so and then
popup the full icewm desktop.
The setup you got up to now looks like this.
Client XServer
II LAN (X-Protocol)
Server Application "nxproxy"
II localhost network connection (NX protocol)
Server Application "nxagent"
II localhost network connection (X protocol)
Server regular X applications (icewm, xterm, ...)
The trick for getting session persistance now is telling the "nxproxy"
to exit, but keep the session running on the nxagent. Some testing found
the solution of sending a "SIGQUIT" signal to all "nxproxy" client
processes EXCEPT the master nxproxy, waiting half a second and sendingn
SIGQUIT to the master. Then, the session gracefully bumps you back to
the terminal login screen. Once you login again (might even be from a
different terminal, as it seems ;-)) instead of firing a new session,
the old session, including all open apps, is restored and connected to.
This is a very "raw" procedure, just what an hour's work could do for
me. There are lots of things to be improved. I am not too much after it,
but if people are interested, I could give some work into this.
Wishlist:
- Run NX proxy on the terminal instead of the server (thus offloading
the server). Make using the NX compression optional, so that terminals
with low bandwidth could profit double so (session persistance +
connection performance).
- Create some kind of mechanism to detect an X server breakdown (like
clients pressing Ctrl+Alt+Backspace) and "hibernate" the session instead
of killing it (what happens currently on Xserver death).
- Also create a procedure to care for client terminal machines dying
away (power outage or whatever) to hibernate the session, instead of
killing it (what happens currently)
- Once working on it, finding out wether "VNC" style connections for
administrative purposes could be implemented easily (school setup:
Teacher watching pupil screen from remote) makes sense. If indeed
possible, find out how to reasonably use it and document that.
- Tons of features and gimmicks :-)
You see, there is a lot of work that could be done.
Ideas welcome, anyway. Someone already did something more on NX?
Regards,
Anselm
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net
