Hi, I wanted to thank all of you who have taken the time to explain the architecture for an LTSP over WAN.
From what you all describe, unfortunately, running LTSP via WAN requires some investment in hardware and may be a little bit complex to maintain remotely. My aim was to reduce the maintenance time and the hardware cost, so I don't think I'll be able to implement your solutions for the project I am currently working on (cybercafés management). I'll try to compile all your answers in the LTSP's wiki as I think it can be relevant for a lot of people. Thanks again, Catherine Le Mardi 29 Novembre 2005 11:MM AM, Anselm Martin Hoffmeister a écrit : > Am Dienstag, den 29.11.2005, 08:57 -0400 schrieb Catherine Stéfan: > > Hello, > > > > I have seen on this list a discussion about LTSP over WAN. I would be > > very interested to implement it but I could not find any documentation > > about it. > > > > Is there any URL where I could find something ? If not, what are tha > > basic steps I should follow ? > > > > As far as I understood, a "boot" server is required. What is it > > concretely ? > > Consider a situation with a LAN, 100 MBit, with several clients on one > end of the WAN, and a comparatively slow WAN connection (2M or > whatever). Now you most surely do not want to boot the clients over the > WAN (load the kernel, access the X fonts via NFS etc). For such a setup > having a small boot server on the client side of the WAN is recommended. > > You would run a DHCP server for your LTSP terminals, and a NFS server > with the /opt/ltsp/i386 tree exported to all those local terminals. > Besides you would need a TFTP server for the kernel and initrd. > Depending on your network, running a firewall is probably a good idea. > If necessary as well, you should set routes correctly so that your > terminal machines can connect to the rest of your network. > > Wether you want the clients to login through the WAN (specify the right > SERVER in lts.conf!) or login to the host near them and just running any > applications through a compressed ssh tunnel (ssh -X -C > [EMAIL PROTECTED] /bin/myapplication) is your choice. This would make > sense if the local proxy machine is all great for serving icewm (xfce, > whatever) sessions but not powerful enough for the real application work > (openoffice, firefox, whatever). Besides having ssh _compress_ > connections gives you a latency penalty, but overall performance could > be better (depending on how much and what kind of data is transferred > over the X protocol) on a limited-bandwidth WAN link. > > I tried running X over VPN over the internet (which kind of compares to > a WAN link in terms of bandwidth) and found the SSH compression to be > really useful. > > Anselm > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id865&op=Click > _____________________________________________________________________ > 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 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _____________________________________________________________________ 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
