After almost two years or work and 994 commits later made by only 14 contributors, I’m proud to announce that the Linux Terminal Server Project project released LTSP 5.2 on Wednesday the 17th of February.
As we wanted this release to be some kind of a reference point in LTSP’s history, we also released LDM (LTSP Display Manager) 2.1 and LTSPfs 0.6 on the same day.
Packages for LTSP 5.2, LDM 2.1 and LTSPfs 0.6 are already in Ubuntu Lucid and a backport for Karmic is available in my PPA.
For other distributions, I’m expecting packages to be available very soon. If you want to check out the code, it’s on Launchpad.
It would take a lot of pages to describe all that was changed during these two years so I won’t even try to do that 🙂
Instead, I’ll simply give you a short overview of what one can do with LTSP nowadays:
- Boot a Debian/Fedora/Gentoo/Ubuntu environment using PXE (dhcp + tftp) and connect to an application server using SSH and X11.
- Either run the whole session remotely or run select applications locally to use specific hardware or advance 3D capabilities
- If running Ubuntu, run everything locally and only select applications remotely (that’s called Fat Client)
- Support for RDP sessions using rdesktop
- Working local block devices like harddisks, floppy disks and cd-rom drives (thanks to ltspfs)
- Easily extensible thanks to an amazing plugin infrastructure, providing hooks pretty much everywhere
- Multi-lingual support in LDM and most of our scripts
- Scalable to thousands of thin clients, at least on Ubuntu, thanks to LTSP-Cluster
- Complete documentation, in the LTSP handbook
- Active and supporting community, mostly on the various mailing-lists and #ltsp (freenode)
Now, to quickly summarize what changed between 5.1.99 and 5.2, here’s the changelog I used in the Ubuntu package:
- Improve fat client support (a lot faster)
- Update nbd-proxy for stability
- Rewrite of ltsp-update-image
- Updated sound configuration
- Lots of optimizations
- Added ssh and whiptail screen script
LDM was made a bit faster in 2.1 and a few ltspfs bugs have been fixed as well as lot of optimization and code cleanup (in both cdpinger and ltspfsd).
Measure boot time on Ubuntu Lucid is under 10s on an Atom-based thin client (1.6Ghz, Hyper-Threated with 512MB of DDR2). That’s just blazing fast !!
Once again, thanks to everyone who made that possible. I’m really impressed by all the changes made to LTSP over the past few years and I really love being a part of it.
No releases are perfect, so if you find bugs, please report them here (for LTSP), here (for LTSP in Ubuntu) or here (for LTSP-Cluster).
Github
Twitter
LinkedIn
Mastodon
RSS feed
Does an ltsp require a DM like ldm, gdm, etc, or can it boot directly to the console?
It’s not required. If you want to connect to an application server running on Linux, it’s recommended to use ldm as it’ll handle the X11 and SSH part.
If your goal is to show some console interface, then you can simply use a ssh or telnet “screen” script instead of ldm.
I want the server to boot into the console. The clients can boot into ldm.
Every HOWTO on ltsp I’ve read seems to assume that the server also boots into a dm. It’s been a while, though, and maybe I misread them.
Ah, sorry for the misunderstanding.
Of course you don’t have to run a GUI on the server.
In most of my current deployments, I have a server which goal is only to provide the boot environment, then a cluster of servers that only do the GUI part.
If you want to do everything on the same box, you can simply turn off the DM and it’ll work just fine.
I guess that’s where people confuse XDMCP and what LTSP does. With XDMCP you need some kind of component server side to show you a greeter, usually you keep a GDM or other DM running for that reason. With LTSP, we used SSH redirection and our DM is running on the thin client, not the server. Therefor, you have no need of a DM running on the server side and can safely disable it.
Excellent!
It’ll breathe new life into an underpowered laptop I have.
You can disable local session of *dm in case it’s gdm/kdm/whatever serving XDMCP, or did I get you wrong? “ldm *or* gdm” is pretty big difference.
Is there any reason why a “thin” ltsp client wouldn’t work over a wireless link?
Might work but not boot: I’m not aware of PXE implementations for wifi, and it doesn’t seem like an overlooked item.
For several month, I used thin client over Wifi and this is very usable.
If you want to remote boot Wifi you will need to maintain a minimal image (similar to the one send by PXE) in order to fire up your Wifi and access the network.
Once this is done, this is a matter of scalability : number of thin clients over any given Wifi access point compared to bandwidth available. 802.11N improve things quite a bit as well as local applications for bandwidth intensive (understand flash, multimedia) applications but the ratio access point / # of thin clients will have to be monitored and checked.
“in order to … access the network” directly contradicts with “remote boot”.
Running with networked root or booting locally to X -query terminal-server is what’s possible with wifi, but *boot* itself is, again, not (TTBOMK).
Otherwise “yes, of course”.
hi,please how to build this minimal image for boot form wireless
i search info but i cant get any response,you use usb pendrive
to boot form wireless?
thanks
You can’t boot _from_ wireless (there’s no PXE or equivalent there, and rather for a reason). Yes, you can boot the kernel+initrd locally (from usb drive too) then toss root filesystem in over wireless but I’ve considered that and concluded it was not what I really want.
> Boot a Debian/Fedora/Gentoo/Ubuntu environment….
Why is openSUSE not part of this list? AFAIK openSUSE is a contributor to the LTSP project too.
OpenSUSE isn’t in upstream LTSP. It’s using its own LTSP derivative called KiwiLTSP.
…as well as ALT Linux (which was a friendly fork in 2007/2008, and rather frozen after merge due to developers shifting into HPC). It’s still LTSP5.1/4.2 hybrid though working on 16M RAM: http://en.altlinux.org/LTSP
Does it finally support disconnected sessions? I.e. if connection dies for some reason, reconnect to the server and have your programs still running like before the disconnection, with all websites, documents etc. open?
Great work LTSP team!
Hear Hear!
Wow, LSTP is such a interesting project but only 14 developers. hope 5.2 will gain more popularity and ultimately more developers 🙂
I need support for likewise-open in ldm That is posible?
LDM doesn’t need any change in order to support likewise.
It only uses ssh access to the server for authentication, so all you need is likewise installed and configured on your server and you’ll be good.
I can’t download LTSP Handbook! How do I do?
Hi all,
good to hear about improvments on 5.2 version.
Is this version available on Edubuntu 10.04?
Is there documentation explaining how to install LTSP without GUI on server (and how to build the GUI for the client)?
Thank you!
Does rdesktop support means that an rdesktop client now can login to the ltsp server and runing linux under rdesktop protocol ?
Am to understand this as meaning that there’s no support for non-PXE boot methods anymore?
I have installed LTSP on Ubuntu 10.04. I got error on client while booting on network TFTP : Open time out.
Please help.., Thanks.
Hello, congratulations at the LTSP Team, by wonderful work.
I have a problem with USB Devices connected um LTSP stations, what can do it?