You address a problem that I had been considering for a long time regarding thin client disconnects.
I haven't been using LTSP for a few months, but as I recall, the thin clients are actually very resilient to disconnects. I ran an experiment where I unplugged Ethernet at the client for 2 minutes, waiting for the NBD errors then replugged and everything continued as normal. If there was a way to have the SSH server, reboot command, and init scripts on the thin client run from ramdisk loaded from initrd instead of NBD, this would solve the problem of losing communication with the thin client and inability to power it off. Has anyone else ran into the problem of losing the ability to restore thin clients remotely when they have unrecoverable NBD errors? On Fri, Aug 31, 2012 at 1:58 PM, David Burgess <apt....@gmail.com> wrote: > > We have roughly 100 diskless thin clients here running LTSP, all for > RDP. This morning I had a thought, so I'm hoping some discussion here > might help to enlighten us on where this might lead me. > > Please correct me if I'm wrong: both thin and fat clients load a basic > Linux OS from the tftp server. From there, thin clients normally > connect to a remote desktop, while fat clients continue to load the > whole OS, desktop and all, locally. Local app setups are a hybrid, > where the desktop is remote, but certain apps are run locally. > > rdesktop/freerdp clients work like a thin client, only the remote > desktop is a Windows server rather than a Linux server. Local apps > don't exist in this case, however rdesktop is already being run > locally as part of the thin image. The only difference I see between a > fat and thin client in this case then, is that the thin client mounts > its root filesystem via NBD (or NFS for some), while a fat client > mounts its fs in RAM. > > The only real beef I have with our current setup is that if the LTSP > server reboots or becomes unreachable to the thin client on the > network for any reason, the client loses its root fs. Although > rdesktop continues to function in most cases, the thin client will no > longer shut down at the scheduled time, and can't be controlled in any > useful manner via ssh. > > So I guess what I'm wondering ultimately is if converting my thin > clients to fat clients would overcome this NBD-unreachable problem we > face from time to time (where clients have to be power cycled to > recover), and whether there might be other consequences to this > change. > > Thoughts before I start to experiment? > > db > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _____________________________________________________________________ > 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 -- Jay Goldberg | AvianBLUE Network Systems ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _____________________________________________________________________ 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
