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.
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.
How are you handling device ownership for the hosting machine? I presume the vnc-connected hosts are not getting perms to cdroms and soundcards and what-not. Will any of this be functional to implement limited user-session switching a la XP or OSX?
Thanks, -sv
Hey,
On Thu, 2004-06-03 at 18:33, seth vidal wrote:
How are you handling device ownership for the hosting machine? I presume the vnc-connected hosts are not getting perms to cdroms and soundcards and what-not.
I haven't even thought about it to be honest, but its all handled by pam_console, right? And with a VNC session, you're not on console, so no, you don't get those perms.
Will any of this be functional to implement limited user-session switching a la XP or OSX?
I really wouldn't recommend using this on a single host - VNC over a local socket just seems like a good way to waste memory, CPU and slow down your desktop to me ...
There's already user-session switching in GDM. I don't know much about it, but that's the avenue I'd pursue for this feature.
Cheers, Mark.
On Thu, 2004-06-03 at 19: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:
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-demoNote: there are packages built against both FC2 and rawhide.
Punch port 5900 through the firewall on the server - i.e. system-config-securitylevel, Other ports, "5900:tcp"
Reboot for good luck.
From another machine, vncviewer -FullScreen -FullColor myserver
Log in as normal, play around, start a few apps.
Close vncviewer (F8, Exit viewer)
Start vncviewer as in (4)
Log in as normal, you should be immediately switched back to your original session.
Doesn't work properly. The first time I logon it works nicely. However, I can't get back to my session once I disconnect.
When trying to log in back, GDM simply hangs indefinitely. No CPU cycles are wasted. Nothing seems to happen. I'm using Kerberos V authentication, IPv6 and IPSec.
Please, feel free to contact me for additional information. Thanks!
Hey,
On Thu, 2004-06-03 at 22:59, Felipe Alfaro Solana wrote:
Doesn't work properly. The first time I logon it works nicely. However, I can't get back to my session once I disconnect.
When trying to log in back, GDM simply hangs indefinitely. No CPU cycles are wasted. Nothing seems to happen. I'm using Kerberos V authentication, IPv6 and IPSec.
Thanks for trying it out. Very helpful ...
If you switch on GDM debugging in /etc/X11/gdm/gdm.con:
[debug] Enable=true
you'll get some horrendous spew in /var/log/messages that we may or may not be able to make sense of enough to figure out what the problem is :-)
When the greeter has finished starting up on the primary display you'll see "gdm_slave_wait_for_login: In loop". We'll want everything after that which shows the VNC clients connecting.
Cheers, Mark.
On Fri, 2004-06-04 at 08:43 +0100, Mark McLoughlin wrote:
Hey,
On Thu, 2004-06-03 at 22:59, Felipe Alfaro Solana wrote:
Doesn't work properly. The first time I logon it works nicely. However, I can't get back to my session once I disconnect.
When trying to log in back, GDM simply hangs indefinitely. No CPU cycles are wasted. Nothing seems to happen. I'm using Kerberos V authentication, IPv6 and IPSec.
Thanks for trying it out. Very helpful ...
If you switch on GDM debugging in /etc/X11/gdm/gdm.con:
[debug] Enable=true
you'll get some horrendous spew in /var/log/messages that we may or may not be able to make sense of enough to figure out what the problem is :-)
When the greeter has finished starting up on the primary display you'll see "gdm_slave_wait_for_login: In loop". We'll want everything after that which shows the VNC clients connecting.
Cheers, Mark.
I had similar results but mine came unstuck after a short time. I was able to create two concurrent sessions and detach and attach at will. I also had someone running on the real console. This is all pretty sweet. Coupled with vino, it seems the remote desktop is being taken care of quite nicely...
tjb
On Fri, 2004-06-04 at 08:43 +0100, Mark McLoughlin wrote:
Hey,
On Thu, 2004-06-03 at 22:59, Felipe Alfaro Solana wrote:
Doesn't work properly. The first time I logon it works nicely. However, I can't get back to my session once I disconnect.
When trying to log in back, GDM simply hangs indefinitely. No CPU cycles are wasted. Nothing seems to happen. I'm using Kerberos V authentication, IPv6 and IPSec.
Thanks for trying it out. Very helpful ...
If you switch on GDM debugging in /etc/X11/gdm/gdm.con:
[debug] Enable=true
you'll get some horrendous spew in /var/log/messages that we may or may not be able to make sense of enough to figure out what the problem is :-)
When the greeter has finished starting up on the primary display you'll see "gdm_slave_wait_for_login: In loop". We'll want everything after that which shows the VNC clients connecting.
Cheers, Mark.
Also, any way to specify the size of the vnc-server session? I have my X display set to 1600x1200 and I want the vnc session to be the same.
Thanks,
tjb
Hi,
On Fri, 2004-06-04 at 15:01, Thomas J. Baker wrote:
Also, any way to specify the size of the vnc-server session? I have my X display set to 1600x1200 and I want the vnc session to be the same.
We'll be making the Xvnc command line configurable in gdm.conf and you'll be able to change it there.
In the far distant future, I'd like the VNC client to be able to request the screen size (i.e. different terminals will have different screen sizes) but that requires an addition to the RFB protocol. Hence the "far distant future" bit.
Cheers, Mark.
On Fri, 2004-06-04 at 09:43, Mark McLoughlin wrote:
Hey,
On Thu, 2004-06-03 at 22:59, Felipe Alfaro Solana wrote:
Doesn't work properly. The first time I logon it works nicely. However, I can't get back to my session once I disconnect.
When trying to log in back, GDM simply hangs indefinitely. No CPU cycles are wasted. Nothing seems to happen. I'm using Kerberos V authentication, IPv6 and IPSec.
Thanks for trying it out. Very helpful ...
If you switch on GDM debugging in /etc/X11/gdm/gdm.con:
[debug] Enable=true
you'll get some horrendous spew in /var/log/messages that we may or may not be able to make sense of enough to figure out what the problem is :-)
When the greeter has finished starting up on the primary display you'll see "gdm_slave_wait_for_login: In loop". We'll want everything after that which shows the VNC clients connecting.
Whops! I have enabled debugging, rebooted the machine and now everything is working fine. I can log back to my remote sessions with any delays or hangs.
I'll keep playing with this to see if it breaks or misbehaves. Thanks!
On Fri, 2004-06-04 at 09:43, Mark McLoughlin wrote:
Hey,
On Thu, 2004-06-03 at 22:59, Felipe Alfaro Solana wrote:
Doesn't work properly. The first time I logon it works nicely. However, I can't get back to my session once I disconnect.
When trying to log in back, GDM simply hangs indefinitely. No CPU cycles are wasted. Nothing seems to happen. I'm using Kerberos V authentication, IPv6 and IPSec.
Thanks for trying it out. Very helpful ...
If you switch on GDM debugging in /etc/X11/gdm/gdm.con:
[debug] Enable=true
I can confirm that when debug is disabled, I experience the hangs I just described. However, enabling debugging makes it work flawlessly. I checked this when installing the modified gdm* and vnc* packages on a clean FC2 system: while trying to log back onto a remote session, gdm hung. However, setting debug to true fixes the problem.
Curious, isn't it?
Hi,
Cool! How much work to get this to work with gdm as the login prompt instead of vncviewer, so you auth via gdm which starts a fullscreen vncviewer on the client and connects it to the server without a second login? (Ignore any naive assumptions in the foregoing...)
Havoc
A couple of things...
1) Where should we report bugs about the demo packs?
I tried the fc2 versions.... got the same problem as reported in the thread already first vncviewer connection works fine second connection i get the gdm login...enter name and pass...looks like it hangs checking the server process list..it seems gdm created a second gnome session.
2) is there a potential here to create look but don't touch vnc connections as well as full access connections? Perhaps a secondary password for look-only vnc clients? so you enter username get prompted for a password if it matches the primary password you get the full access... if the password matches the secondary password you get a look only client. Or am I just smoking some very powerful crack?
-jef
On Thu, Jun 03, 2004 at 08:45:54PM -0400, Jeff Spaleta wrote:
A couple of things...
- Where should we report bugs about the demo packs?
I tried the fc2 versions.... got the same problem as reported in the thread already first vncviewer connection works fine second connection i get the gdm login...enter name and pass...looks like it hangs checking the server process list..it seems gdm created a second gnome session.
I see some occasional fuzziness with the second or third reconnection at the moment as well, I'm looking into it at the moment.
C.
On Fri, 4 Jun 2004 03:31:33 -0400, Caolan McNamara caolanm@redhat.com wrote:
I see some occasional fuzziness with the second or third reconnection at the moment as well, I'm looking into it at the moment.
should have known..... i go to play with this again today, and turn on debug in gdm this time to catch the log of the problem and....
things are working... repeated vncviewer client connections and they are dropping back into the running desktop.
-jef"A watched pot never boils and a watched program never bugs out"spaleta
On Fri, 2004-06-04 at 16:06, Jeff Spaleta wrote:
On Fri, 4 Jun 2004 03:31:33 -0400, Caolan McNamara caolanm@redhat.com wrote:
I see some occasional fuzziness with the second or third reconnection at the moment as well, I'm looking into it at the moment.
should have known..... i go to play with this again today, and turn on debug in gdm this time to catch the log of the problem and....
things are working... repeated vncviewer client connections and they are dropping back into the running desktop.
It seems to me that enabling gdm debugging makes those "problems when logging back to a remote session" fade away.
Hey,
On Fri, 2004-06-04 at 16:17, Felipe Alfaro Solana wrote:
On Fri, 2004-06-04 at 16:06, Jeff Spaleta wrote:
On Fri, 4 Jun 2004 03:31:33 -0400, Caolan McNamara caolanm@redhat.com wrote:
I see some occasional fuzziness with the second or third reconnection at the moment as well, I'm looking into it at the moment.
should have known..... i go to play with this again today, and turn on debug in gdm this time to catch the log of the problem and....
things are working... repeated vncviewer client connections and they are dropping back into the running desktop.
It seems to me that enabling gdm debugging makes those "problems when logging back to a remote session" fade away.
That's just what we need. Sob[1] :/
I think we both suspect some racey deadlock thing in the way the GDM daemon talks to the slave using signals. Maybe we can get George to save us on that one ...
Cheers, Mark.
[1] - That's Caolan's sob, not mine. He's the one dealing with it :-)
another smallish thing.... dropping down to runlevel 3 keeps the gdm vnc session hanging around still. Not sure if thats a good thing or a bad thing...but its different from what i expect when dropping out of runlevel 5 down to 3, in terms of shutting down X completely.
-jef
Hi,
On Sat, 2004-06-05 at 04:20, Jeff Spaleta wrote:
another smallish thing.... dropping down to runlevel 3 keeps the gdm vnc session hanging around still. Not sure if thats a good thing or a bad thing...but its different from what i expect when dropping out of runlevel 5 down to 3, in terms of shutting down X completely.
Yeah, that'd be another bug. Probably the same bug which stops the login Xvnc from being shutdown when you get re-connected to the original Xvnc.
Cheers, Mark.
Hey,
On Fri, 2004-06-04 at 01:45, Jeff Spaleta wrote:
- is there a potential here to create look but don't touch vnc
connections as well as full access connections?
Yeah, we'll have something like that.
Part of Vino's preferences dialog looks like:
--- [ ] Allow other users to view your desktop
[ ] Allow other users to control your desktop ---
and I think that's all we might need - i.e. a preference to control whether other users connecting to your session are allowed to "touch".
Its not really a consideration for the terminal services use case though, just the collaboration use case.
Cheers, Mark.
On Fri, 4 Jun 2004, Mark McLoughlin wrote:
Hey,
On Fri, 2004-06-04 at 01:45, Jeff Spaleta wrote:
- is there a potential here to create look but don't touch vnc
connections as well as full access connections?
Yeah, we'll have something like that.
Part of Vino's preferences dialog looks like:
Can someone give me a pointer to vino. Google returns a bunch of info on different wines. While I like wine as much as the next guy I doube that is what you are referring to. :-)
Tom
Hi,
On Fri, 2004-06-04 at 15:00, Tom Diehl wrote:
On Fri, 4 Jun 2004, Mark McLoughlin wrote:
Hey,
On Fri, 2004-06-04 at 01:45, Jeff Spaleta wrote:
- is there a potential here to create look but don't touch vnc
connections as well as full access connections?
Yeah, we'll have something like that.
Part of Vino's preferences dialog looks like:
Can someone give me a pointer to vino. Google returns a bunch of info on different wines. While I like wine as much as the next guy I doube that is what you are referring to. :-)
Footnote from the first mail is about as good as it gets:
http://www.gnome.org/~markmc/blog/05022004
and the (out of date now) doc that's linked from there:
http://www.gnome.org/~markmc/remote-desktop.txt
Cheers, Mark.
Tom
Havoc Pennington wrote:
Cool! How much work to get this to work with gdm as the login prompt instead of vncviewer, so you auth via gdm which starts a fullscreen vncviewer on the client and connects it to the server without a second login? (Ignore any naive assumptions in the foregoing...)
It's pretty trivial to do that. I've got that setup for many of our boxes already. I'll give more details tomorrow, if nobody beats me to the punch.
-- Rex
On Thu, 3 Jun 2004, Rex Dieter wrote:
Havoc Pennington wrote:
Cool! How much work to get this to work with gdm as the login prompt instead of vncviewer, so you auth via gdm which starts a fullscreen vncviewer on the client and connects it to the server without a second login? (Ignore any naive assumptions in the foregoing...)
It's pretty trivial to do that. I've got that setup for many of our boxes already. I'll give more details tomorrow, if nobody beats me to the punch.
Attached is vncts.services and vncts.xinetd.
Append vncts.services to /etc/services
Drop vncts.xinetd into /etc/xinetd.d/
Add/append-to /etc/X11/xdm/Xaccess to add: localhost
enable XDMCP in your loginmanager (gdm/xdm/kdm/whatever)
restart X.
-- Rex
Hi,
On Fri, 2004-06-04 at 18:15, Rex Dieter wrote:
On Thu, 3 Jun 2004, Rex Dieter wrote:
Havoc Pennington wrote:
Cool! How much work to get this to work with gdm as the login prompt instead of vncviewer, so you auth via gdm which starts a fullscreen vncviewer on the client and connects it to the server without a second login? (Ignore any naive assumptions in the foregoing...)
It's pretty trivial to do that. I've got that setup for many of our boxes already. I'll give more details tomorrow, if nobody beats me to the punch.
Attached is vncts.services and vncts.xinetd.
This is the well known hack to allow Xvnc with a GDM to be started by inetd which our work is completely replacing so that we can get the reconnection ability.
I think you've missed what Havoc was asking about - he was asking about the *client* setup, not the server setup.
Cheers, Mark.
On Fri, 2004-06-04 at 00:16, Havoc Pennington wrote:
Hi,
Cool! How much work to get this to work with gdm as the login prompt instead of vncviewer, so you auth via gdm which starts a fullscreen vncviewer on the client and connects it to the server without a second login?
Basically, for the terminal/client our plan is to do something very similar to GDM's auto login thing, but it would log you in as a "vnc" user with very few local privs and just run a fullscreen vncviewer pointing at the server. The vncviewer might lock the display too ...
Cheers, Mark.
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:
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-demoNote: there are packages built against both FC2 and rawhide.
Punch port 5900 through the firewall on the server - i.e. system-config-securitylevel, Other ports, "5900:tcp"
Reboot for good luck.
From another machine, vncviewer -FullScreen -FullColor myserver
Log in as normal, play around, start a few apps.
Close vncviewer (F8, Exit viewer)
Start vncviewer as in (4)
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.
Hey,
On Fri, 2004-06-04 at 14:52, James Laska wrote:
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.
Okay, what I was thinking was that if you first log in on console and then log in using VNC, you'll get connected to the console login (requires work in Vino we haven't even looked at yet). But if you log in from console, you'll never get re-directed to an existing session - it will always start a new one.
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.
Right, we need a gnome-settings-daemon for each display:
http://bugzilla.gnome.org/show_bug.cgi?id=94049
Jody doesn't think the patch I had is viable for reasons I never really understood. And I've not yet succeeded in getting Jonathan interested in the problem. Jonathan ? :-)
Sun have all these same problems with Sun Ray and up 'til now they were the only ones who cared about them. They're our problem too, now. Fun, huh ? :-)
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.
Hmm, nice. No ideas off the top of my head on that one.
- The window title for the VNC session is: "VNC: x11". Probably want
something more descriptive like the user name, or the host?
Yeah, probably. But mostly I expect the viewer to be running fullscreen.
- 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?"
Yes, figuring out something like that is on our immediate TODO list. Not sure exactly what it'll be like yet.
- 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...
Yeah, for no good reason at all we made the graphical greeter the default for the VNC login. Well, for one good reason - the standard greeter sucks.
We also need to add the VNC configuration to gdmsetup. Lots to do :-)
Cheers, Mark.
On Thu, 2004-06-03 at 18:11 +0100, 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:
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-demoNote: there are packages built against both FC2 and rawhide.
Punch port 5900 through the firewall on the server - i.e. system-config-securitylevel, Other ports, "5900:tcp"
Reboot for good luck.
From another machine, vncviewer -FullScreen -FullColor myserver
Log in as normal, play around, start a few apps.
Close vncviewer (F8, Exit viewer)
Start vncviewer as in (4)
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.
Could you yummify your archive so we can just point at it and get updates whenever you make them? (I realize this will probably hit rawhide at some point but I'm taking a breather from rawhide for a while between betas!)
Slightly OT: Do you plan to add vino? I've got it all built (it seems to work) but I'm not sure the rpms are complete. (I had to add vino-session as a startup item.) And along the lines of a bug report, everytime a coworker runs nessus against my system, vino-server goes off the deep end eating 100% of one CPU. Other than that, it works quite well.
Thanks,
tjb
Hey,
On Fri, 2004-06-04 at 14:55, Thomas J. Baker wrote:
- 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.
You did see this, right ? :)
Could you yummify your archive so we can just point at it and get updates whenever you make them? (I realize this will probably hit rawhide at some point but I'm taking a breather from rawhide for a while between betas!)
I look into it ..
Slightly OT: Do you plan to add vino?
Yes, but I haven't decided when yet. I'm planning on changing Vino quite substantially to work under this model (i.e. you connect to Vino through GDM), I don't know when I'll get to that yet and I'm not sure if I should go and add Vino until that work is done.
I've got it all built (it seems to work) but I'm not sure the rpms are complete. (I had to add vino-session as a startup item.)
Yeah, there's a patch in the tarball which we'd add to gnome-session rather than having people use vino-session.
And along the lines of a bug report, everytime a coworker runs nessus against my system, vino-server goes off the deep end eating 100% of one CPU.
vino-server does some intense polling of the screen to keep its copy of the framebuffer up to date. As soon as the DAMAGE extension is in our Xserver, we'll be using that and this problem will go away.
Cheers, Mark.
desktop@lists.stg.fedoraproject.org
-
Caolán McNamara -
Felipe Alfaro Solana -
Havoc Pennington -
James Laska -
Jef Spaleta -
Mark McLoughlin -
Rex Dieter -
seth vidal -
Thomas J. Baker -
Tom Diehl