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 >
