terminal services prototype

[James Laska]

Nice work!

I've been looking for something like this ever since I came across
`screen`.  A few quick questions:

- How should physical console logins and logins over VNC for the same
user at the same time be handled?  Should both be accessing the same VNC
session?  I notice that if I login on VNC, and attempt to login on the
physical console...the session is not shared.  This results in
gnome-session and gconf getting confused.  One session seems to get the
*locks* for gnome-settings-daemon and uses the configured theme?  While
the other session defaults to the stock GNOME icon set and theme.  I
believe this is already a known issue with running multiple
gnome-sessions at the same time.  

- The VNC session will not be able to do hardware acceleration?

- Launching desktop screensaver preferences shows:

xscreensaver-demo is running as "root" on "myserver".  But the
xscreensaver managing display ":1.0" is running as user "nobody" on host
"myserver".  Since they are different users they won't be
reading/writing the same ~/.xscreensaver file, so xscreensaver-demo
isn't going to work right.

- The window title for the VNC session is: "VNC: x11".  Probably want
something more descriptive like the user name, or the host?

- Perhaps a way to list *active* VNC sessions?  The modified gdm doesn't
appear to add entries to utmp/wtmp.  Once you login, perhaps you are
prompted with a dialog like:

"There is already an active desktop running for $USER from $HOST.  Would
you like to create a new desktop, or join one from the list below?"

- Should the gdm xdmcp configuration settings hold true for the remote
VNC gdm mode also?  Meaning, if you set the gdm theme to be the
"old-style" greeter for remote consoles...

Great work!
-jlaska

On Thu, 2004-06-03 at 13:11, Mark McLoughlin wrote:
> Hey,
> 	Caolán and I have been working on prototyping a VNC based terminal
> services system which also allows hot-desking.
> 
> 	The idea is that we allow GDM to accept VNC connections, spawn a VNC
> server for each new connection and display a login screen. The user then
> authenticates through the login screen as normal and GDM starts a new
> session on the VNC server. However, if you then close your VNC client,
> the session doesn't go away. GDM continues to manage that session.
> 
> 	You may then go to a different terminal, the server will spawn off a
> new VNC server with a login screen through which you log in. However,
> once you log in, GDM detects that you already have a session running and
> switches you to your original session rather than starting a new
> session.
> 
> 	You could imagine terminals which are very similar to LTSP terminals,
> but instead of starting an X server which queries the server for a login
> using XDMCP, it starts a fullscreen vncviewer which connects to the
> server.
> 
> 	We've reached a stage where we can demo the basic idea, so here's the
> results:
> 
>  1) On a test machine which will act as the terminal server, install
>     the "gdm" and "vnc-server" packages from:
> 
>         http://people.redhat.com/markmc/terminal-services-demo
> 
>     Note: there are packages built against both FC2 and rawhide.
> 
>  2) Punch port 5900 through the firewall on the server - i.e. 
>     system-config-securitylevel, Other ports, "5900:tcp"
> 
>  3) Reboot for good luck.
> 
>  4) From another machine, vncviewer -FullScreen -FullColor myserver
> 
>  5) Log in as normal, play around, start a few apps.
> 
>  6) Close vncviewer (F8, Exit viewer)
> 
>  7) Start vncviewer as in (4)
> 
>  8) Log in as normal, you should be immediately switched back to your 
>     original session.
> 
> 	Caveats:
> 
>   + You don't want install these packages on a machine which you need to
>     stay working. We're making no stability/security guarantees 
>     whatsoever yet.
> 
>   + The VNC protocol stream is unencrypted. When you type in your 
>     password to the login screen its going across the network in plain 
>     text. Don't test this on an untrusted network. We'll be making all 
>     this work using the SSL extension used in Vino[1].
> 
>   + Right now, the client will be encoding the pixels using the "raw" 
>     encoding. No compression, so it'll be slow. We'll be fixing that 
>     soon too.
> 
> Cheers,
> Mark.
> 
> [1] - http://www.gnome.org/~markmc/blog/05022004
>