On Fri, Aug 31, 2012 at 11:58:44AM -0600, David Burgess wrote:
> 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.

correct.

 
> 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.

Not really; thin clients and fat clients both mount their filesystem via NBD 
or NFS. They both often use a ram-based overlay filesystem 
(unionfs/aufs/overlayfs) for the writeable parts, but again, this is the same
in both thin and fat client environments.


> 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.

If you have enough ram, it would be technically feasible to load the whole NBD 
image into ram and run off of that- it's an idea that's long been on my back 
burner to explore (this is basically what TCOS and some other thin clients do,
I think). 

Also, NFS is fairly resilient to handling some types of disconnects- it will 
just block filesystem access until the connection becomes available again. So 
that might be a short-term way to explore resolving your issues. It is slower 
to boot, but in the case of RDP, that shouldn't be a huge difference and the 
trade-off might be worth it to you.


live well,
  vagrant

------------------------------------------------------------------------------
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

Reply via email to