 Hey folks, folks call me Vagrant Cascadian. I'll be talking a bit about integrating LTSP into Debian. The work we've done over the past two years has led up to what's now being conceived as LTSP 5.0. And that's about it. Figured I'd start out with a little history here. Well, so basically, for those of you who don't know, the Linux terminal server project is essentially a thin client system. Everything is booted over the network. And I tend to describe it as a desktop server. You typically have a server. It provides the disk access and applications running for a bunch of thin clients. So it's useful for an environment where you have one decent machine and a lot of junky old machines, or you don't need to do a lot of maintenance. Typically uses a few services like NFS, TFTP, DHCP, and X. So there's some history behind LTSP. Started off in 99. One of the main differences in the direction we're going with LTSP is how the system was built. So in the first two versions, basically, it built the LTSP environment out of binaries from the host system. So you ran a script on your server, and it would grab binaries, stick them into a charoute, and then it would set it all up to network boot using that as the root file system. This had some problems, maintainability-wise. It also was hard to make it perfectly and support multiple distributions. In the third release of LTSP, they started building the charoute environment from basically an RPM system copying the binaries over, but then releasing tar balls to distribute. And then for several years, they're like, this just isn't going to work. So they spent a long time building the LTSP build environment. Everything was built from source. So you're creating these charoute environments. You're exported over the network. That's the root file system. It was a remarkable concept. A lot of progress went into making that work. But over the long term, it proved to be difficult to maintain security updates. If somebody wanted some random piece of software running on the thin client itself, you had to force it to build inside of this LTSP build environment. They had difficulties with GCC sometimes, being very fussy about which versions. So it started looking for something new. Back in 2001, I had been working on a project basically building a thin client-like environment using Debian packages and Debootstrap. This in 2005, LTSP started looking at doing that kind of a thing. So thus, it was started in originally called the Moocow project and has since become what we're defining as LTSP. What it does is it builds an LTSP environment out of the distribution packages. The only two implementations at the moment are Ubuntu and Debian. And it basically leverages Debootstrap and Cherute to create an environment. The initial implementation was developed by Ubuntu and released with the Breezy Badger release in October of 2005. Debian EdgeU, fairly early on after Ubuntu started releasing some of the code for this, started incorporating it. And it was included in Schole Linux 2.0 in March of 2006. And all throughout that time, we had been working to get it into Edge. And Edge was released just this last April. So that's a little bit of the history of where this has been going. So the main reason why they wanted to switch away from the LTSP build environment is they're basically re-implementing an entire Linux distribution. It sits in a directory on your server. They export it over the network. And basically, they spent a lot of time trying to get the kernel to work, trying to get Xorg to work. Other core software, Glib-C, was a bit of a hassle. All these other Linux distributions do all this same work. So they're like, why don't we leverage all that hard work by other distributions, such as Davian and Ubuntu, and ideally at some point, Fedora, Gentoo, Slackware, whatever? Why don't we leverage all the work they're doing and just basically build an environment out of that? So that's the direction that has become LTSP5. This has huge advantages. Any packages available in the distribution is now suddenly available in your LTSP environment. Because of that, you also inherit security updates, any upgrading possibilities, whatever conventions the distribution itself normally operates. Your LTSP environment operates under similar conventions. So you gain a lot. Another huge advantage is it then becomes easier to integrate into customized distribution because instead of having to distribute a 50 or 100 megabyte tarball on a CD image, you actually only need just a few kilobytes of packages that contain just the specific stuff the LTSP because you're not re-implementing Glib-C, Xorg, all those other parts of a typical distribution these days. And most importantly, we want to have fun. And we don't want to spend all this time trying to force something that a dozen other distros have built just to we want to work on the cool features of LTSP. There's LTSPFS, which is a remote file system support based on Fuse, work on configuration tools, things like that. So building everything from source while it allowed every single LTSP distribution to be almost identical, it brought with it a lot of troubles that this new method will hopefully alleviate. So in order to accomplish this, basically we want to bring everybody into the picture. Collaboration is pretty essential to developing a common code base. We've tried, last year at DevConf, Tavio Salvador, and myself, we worked on creating a plug-in system so that even though every distribution is going to build the charoute environment in a different way, we basically created a plug-in system so that based on which distribution you're running, it might run little different bits of code for the bootstrapping of the environment, those kind of things. Last year in September, a number of folks got together from LTSP, Buntu, Debian, Fedora, Red Hat, and K12 LTSP. And we worked on defining, well, since LTSP is no longer its own distribution, what exactly is it? So we developed specifications for LTSP. And those basically define that an LTSP system needs to support remote sound. It needs to support local device access, network booting. It's some fairly simple guidelines. And then if you meet all these qualifications with your distro, you can call it LTSP. And then more developers are on the way. Every now and then, somebody hops into the IRC channel, and they're like, hey, do you have LTSP working on this distro? And we're like, if you want to make it work, we would gladly help you. Here's the starters. And then as more distros integrate LTSP, we have more LTSP developers in our pool. We're no longer just this rag tag bunch of people developing the LTSP distro. Now we're integrating people from all the other distros and incorporating their skills and diverse opinions. And yeah, here's a picture from our meeting in September. And Jim McQuillan, he's the fellow in the middle there in the black shirt. And then some other people, a number of local people from the local Linux user group and bunch of LTSP developers. So that's pretty key. So we're trying to build a larger community and since we're incorporating other distros, that just happens. So there's some problems with this. Since we're building the LTSP environment out of standard Debian packages or standard Ubuntu packages or whatever distros packages, we're taking a performance hit. LTSP 4 had gotten it down to on some relatively modest hardware down to I think 22 second boot times. And we haven't been able to come close to that yet. So that's one of the main drawbacks. Now that people have moved to LTSP 5, the first thing everybody complains about is it takes forever to boot. There's been some recent progress in that direction. We've had to do some kind of ugly things like tweaking the distro so it doesn't start all the init scripts for things that don't necessarily seem relevant, that save some time, but then it's getting kind of ugly because you're removing init scripts or not running things. The other huge problem is LTSP has developed this huge pool of documentation for other versions of LTSP. And because this is such a major shift in design, a lot of the documentation is no longer relevant and it's really difficult to grab the pieces that are relevant, change them, and for each individual distro the documentation is going to vary slightly. So we haven't really done a good job on that migration, but help is always appreciated. How many people in here run LTSP? Anybody on LTSP 5 yet? Right on. All right. The other downside is as much as we've worked to try and incorporate efforts from other distros, haven't seen much action yet. Early on Ubuntu started working on it. They posted to the Devian edgy list and within a short period of time after it was uploaded to Ubuntu there was packages available in Devian. A lot of that, you know, there's not so many differences between Ubuntu and Devian, so that's understandable. But we're going on two years now and haven't seen any actual effort from some of the other distros. So we're always trying to encourage other distros to jump in and try and help out, figure out what they need to do. I'm sure there's other outstanding issues, but yeah. So future plans. Oliver Gravert, who works for the LTSP packages in Ubuntu, he's started experimenting with using a network block device for root with SquashFS and UnionFS. This is kind of nudging it in a direction similar to the Devian live project. I know they use a SquashFS and UnionFS kind of environment. The MBD route, I'm not sure how well that's going to scale over a large environment. It just largely hasn't been tested yet. But those three features have dramatically improved the boot speed. I think they knocked 20 to 40 seconds off of the boot time on some of our boots. And boot times are anywhere between one minute to two, two and a half on some really slow hardware. It's like five minutes, which is pretty ugly. But yeah. So that's one of the features they're looking at to improve boot times. Configuration helper tools, like a GUI tool to edit an individual thin client's environment and so on to set up the network services like DHCP, TFTP, all that stuff. We try to get it working out of the box as much as possible. But inevitably, I mean, if we're sticking with Devian policy, we have to do some manual configuration in a lot of cases. But we're working to improve that. Another feature which is partially developed is like a workstation or a kiosk mode where rather than like in a traditional thin client where you're running all the applications on a server, what we basically do is basically all the server is for a diskless workstation. It's essentially just a disk server. It's not running any of the applications. You boot locally and it's running just like a normal machine with a hard disk for the most part. So there's more polish that needs to go into that. But it's very useful in an environment where maybe you've got 100 gigahertz plus machines and you just don't want to manage 100 disks or whatever. That takes some administrative overhead. So I kind of ran through this here. Any questions or anything? It's not a question, it's some feedback actually. I work for a company which has quite a few LTSP5 deployments and tools each with about 30ish clients. By and large, you're talking about also what is LTSP5 and we're talking about we need to get with the sound and with local device access and all that kind of stuff. Now that it's working properly with Pulse Audio, that's exactly what we've got. The biggest problem really is the boot time scenario where even on reasonably modest clients, sort of minute, two minute, three minute boot times. As a bit of feedback, the way that we found basically to have vast improvement in the boot time for people that don't know the technical setup, the standard out-of-the-box deployment runs a login manager on the client which has been written in Python. And then instead of doing XDMCP, what it does is it talks to the server via SSH and tunnels X. And that's what really kills the clients. Running a Python based login manager and then doing tunnel decks over SSH. The encryption alone is what's really killing these clients which only have say 200 megahertz CPUs. If it was set up so it was doing XDMCP as standard rather than running the local login manager on the client which is how we then have to force it to do quicker boot times. I mean that has noticeable improvements in the boot times alone. Definitely. We've actually, that's one of the main areas we addressed in some of our recent work. Scott Balneves, he's one of the upstream developers over the last couple of weeks has rewrote the Python implementation in C. Somebody also implemented a feature where it uses SSH to login but from there on out the session is unencrypted so you get performance comparable to an XDMCP session but you're still not sending your login password over the clear. So that's definitely a major point we've been looking at. That's one of the biggest slowdowns and hopefully will be addressed in the near future. And I do try to make sure that there's Edge backports available for all the new packages because when Edge was released it was functional but there's still a lot of improvements that we'll be making over the next couple of years. So I intend to make sure those features are easily installable on Edge. But yeah. Can you talk a little bit about less disks now that's comparable to LTSP and what the situation with less disks is? Right. Yeah, so less disks was basically the same thing as what LTSP 5 is doing now, building an environment out of Debian packages. I started writing it in 2000, 2001 and it was actually released with Sarge with a version that was getting a little out of date and has effectively seen no progress since then. So around 2005 when the LTSP development started appearing to be moving in the same direction I was working I pretty much jumped ship. The maintainer for less disks in Debian, the only action I've seen from him is to when there was a removal request for less disks he said no, no, don't remove it and that's all we've seen from him in like two years. But essentially it's the same kind of a thing. So I've been doing this related stuff for a number of years. I got involved in 2005 when the new LTSP stuff became publicly accessible. But yeah, pretty much as upstream I abandoned less disks in favor of working on LTSP. It's a group project with a number of active developers and some of whom are sitting in the room. And yeah. But yeah, I don't know. How long ago was it? Did you abandon it upstream less disks? A year or two ago? I don't remember exactly. But the version in Debian is even older. Yeah, it's pre-sarge. The version was what was in pre-sarge. So it's just kind of sitting in the archives collecting unused translations and stuff. So yeah, I'd like to see it removed from Debian at this point. But we'll see. Hi. I'm wondering about the workstation mode. That seems quite interesting. How is the performance and it doesn't exist yet, perhaps? It doesn't exist out of the box, but with a few manual tweaks you can make it work performance-wise. I haven't really had opportunity to do much testing. Debian Edu has a script that creates a workstation mode kind of environment. One of the huge advantages is the multimedia apps work a lot better in it because everything's running locally. The whole thing that you're accessing is typically over NFS, accessing the binaries and such. So at the moment, it's very doable. It's not a lot of work, but there isn't just a command-line option you can use when building the environment. Could it be used to replace traditional mechanisms of updating? Having local desktop installations, you could use the LTSP and the workstation mode to make administration easier. That's exactly the intention, definitely. Getting rid of disks. I started working on less disks. I worked at an organization called FreeGeek, which had a community center where there was public access internet terminals. We had all these machines sitting around basically just logging into a server and running their applications. They all had hard drives in them, and a couple of the hard drives failed over the course of a couple of days, and I'm like, this is stupid. They're not running anything locally, really. That's when I started looking into some of these technologies. Definitely a great way to reduce the maintenance overhead. There are some companies like HP and other large hardware suppliers that provide pre-configured thin clients or pre-defined thin clients. Could you use LTSP on those? Anything that'll run Debian, you can use LTSP on. It's pretty much as simple as that. Would that also work cross-architecture, or is it really required to have the same architecture as a server? You still need to boot a machine of the appropriate architecture to build the environment, but since you're serving it out over NFS or NBD, I think I've heard reports that it basically just works. I mean, you're just serving up files. Otavio was kind of keen on trying to... He has an ARM thin client, and he wanted to explore using Chemew. Chemew's user mode emulation to try and bootstrap a system that way. You can create a cross-architecture environment. On an AMD64 server, you can build an i386 environment, which should maybe even be the default. Cross-architecture support, it needs some work, but it's definitely something people are interested in. All right, halfway through. Let's see here. Maybe we'll browse some of the webpages. Is anybody interested in running LTSP who hasn't been? Excellent. So we have some really sparse documentation on wiki.devion.org. Contributions greatly appreciated, and we kind of patrol these pages for stuff to bring into the documentation and the packages. The how-to is pretty minimal. And some of that's because there's really not much to it, but always there's more to it than you think. But basically, there's pretty much one command you run while you install the LTSP server package or the LTSP server standalone package. You run LTSP build client. That basically does the reboot strapping and creates the environment. And then you just have to configure DHCP and NFS through the exports. There you are. That's basically all there is to it. If you want to do some fancy configuration, like getting sound support to work out of the box and stuff like that, by default it'll use eSound, so most GNOME applications should work basically out of the box. Then you can relatively easy configure KDE to use eSound as an output. And then the current packages in SID are actually defaulting to Pulse Audio, which has backwards compatibility with eSound. So I've got a backports repository, which I haven't yet tested the newer SID packages with Edge, but I've got some reports that they're working. It would take a little bit more code to actually get the packages to work easily with backports.org, setting up the appropriate pinning and so on. So we're kind of just hosting it on our package LTSP project on Alioth. Let's see here. Yeah, there's a fact. A lot of this was created from people who are familiar with older versions of LTSP, and then there's some new gotchas or new caveats. Nothing too big. There's an upgrading from fourth to kind of documentation. No other questions. So the main website is LTSP.org. Recently redesigned and directed most of the pages to the wiki page. So most everything will go there. We recently started, because a lot of distros haven't incorporated LTSP 5 yet, Upstream has started packaging a tarball of a Debian LTSP 5 environment and the Ubuntu environment so that you could install on Fedora, but your clients would be running a Debian environment or an Ubuntu environment, kind of as a kick in the pants. So we're hoping, and then of course people on Ubuntu are downloading the Debian tarballs and installing those and we get all sorts of crazy environments on IRC, but yeah, that's pretty much the state of things. LTSP 5 on other distributions. Basically download a tarball, you unpack it into OptLTSP, and you do the manual configuration of DHCP and NFS. So how many LTSP 5 clients you're able to serve at the same time on a 100 megabits network with sound and local device access and so on? You're asking more like the network bandwidth usage or the server resources? Well, both, could be interesting. There is some documentation, the answer of course is it depends. If you're running Nome on all the machines, obviously it's going to require more resources than if you're running IcedWM or something. So I think the general guideline is 256 megabytes of RAM plus 50 megabytes per client, but that highly depends on if they're all running open office, if they're going to be mixing and matching KDE and Nome applications, things like that, or if it's a very controlled environment where everybody's running maybe three applications. Network usage, it varies. I've used it typically, the most environments I've seen don't need gigabit, but it's usually nice to have gigabit to the server and then 100 megabits to each of the clients, but a lot of times it isn't even really, I don't see a huge performance difference. How many you could run, it's hard to say. When you're doing the SSH encryption, that takes more of a hit on the server and the client than the actual network usage, I think. But I haven't really done detailed analysis of the various processes. So I'm sure that barely answers your question. Just to kind of give some kind of statistical result to that. In the deployments that we have in schools, it's always when the kids come in and there's an entire class, 30 kids, all log on at once, and our standard service setups, a single dual core Xeon, a couple of gig of RAM, and it will peak about server load 12 when all the kids log on and then all happily sit there with them all doing open office or watching YouTube, having the sound all come through, server load eight, quite happily. It'll just sit there and do that, no problem. The bandwidth isn't an issue at all. This is on a cheap school network. It's always the megabytes and megahertz on the server. That's the scaling factor. The bandwidth on the network, we've never had that as an issue. Sometimes disk access can be an issue as well. Well, one last comment. I'm really looking into this workstation mode because I know it's pretty easy now, at least in Europe, to get access to maybe three or four years old PC, that are not from companies that have renewed their local hardware. You get one gighertz machine pretty easily nowadays, at least in Europe. It's far more harder to find quad-core Xeon server to run 10 or 20 LTSP at a decent speed than to find five or 10 one gighertz machine that could run open office happily. Yeah, definitely. I came to free software development as an environmentalist and I worked at FreeGeek, which does computer recycling and reuse and gives Linux out to people. Yeah, definitely. In any developed country, there's plenty of hardware to be given away, and that can make a great use of it. I know FreeGeek has the minimum spec, I think, of things they actually even try to reuse is probably over a gigahertz now. Anything under that, they basically just don't have the time to deal with, or they'd be, at some point, throwing out faster machines. So, yeah, definitely a big advocate for using LTSP for computer reuse. And the workstation mode is getting more and more viable each year, definitely. The main thing there is also not just the processor, but you want to have a lot of extra RAM. You don't want to be doing swap over the network. I mean, you can. We support it, but it's not ideal, by no means. Any further questions? All right, well, sorry I didn't have more to offer today.