PXE: Not Just for Server Networks Anymore!

Using a combination of open-source technologies, you can build an unattended network-based OS installer that can save you huge amounts of time and even can install Windows.

In the April 2008 issue of Linux Journal, Kyle Rankin's article “PXE Magic” explains how PXE (Preboot eXecution Environment) works and how you can install your own PXE server and integrate rescue tools like Knoppix along with a PXE-capable Kickstart installation. I've used much of Kyle's PXE Magic before (he and I worked together in a previous life), but recently I found myself managing not only a network of Linux servers, but also the entire LAN, encompassing Ubuntu laptops, desktops and servers, along with Windows laptops, desktops and servers. I found myself imagineering a PXE server that would not only allow me to kickstart servers and boot rescue tools off the network, but that also could provide a temporary environment for my users in the event that their computers broke. In my mind, the Holy Grail of this PXE server even would be able to install Windows machines via the network. After a fair amount of trial and error, I finally figured out the recipe, and in a strange twist, I was able to automate a network-based Windows installation...by bootstrapping Linux first.

Setting Up an Ubuntu Terminal Server

I knew one of my goals for this system would be to give the users of my network an environment they could PXE boot to in a pinch—something that would appear familiar to them, as well as allow them the ability to perform basic tasks like check e-mail, surf the Web, instant message and so on. Luckily, much of our staff here runs Ubuntu on the desktop, so the decision to implement an Ubuntu Terminal Server using the Linux Terminal Server Project (LTSP) was a simple one.

Like any PXE implementation, the LTSP server requires a TFTP server, a properly configured DHCP server and the syslinux software. In a nutshell, the client boots; the PXE code in the network adapter runs; the machine gets a DHCP address and the address of a server to grab the syslinux code via TFTP; and then, it actually runs a TFTP client and downloads that code and executes it, starting the boot process. Thanks to the hard work of the Ubuntu LTSP maintainers, setting up the server was fast and easy.

There are two paths you can take to install an LTSP server: normal or standalone. A normal LTSP installation assumes you have a pre-existing DHCP server on your network, and a standalone LTSP install assumes no DHCP server, and it will install the DHCP infrastructure and integrate it with the LTSP server automatically. There already was a DHCP server on our corporate LAN, so I elected to do the normal LTSP installation and integrate it with our existing Microsoft Windows DHCP server.

I began the installation by installing a standard Ubuntu 8.04 desktop on a Dell 1950 server, as the LTSP server will have to act as a GNOME desktop for anyone who would be logging in to it. After that, I assigned the server a static IP on our LAN (on the same subnet as the desktops and laptops). Installing the LTSP server was a piece of cake—a simple sudo apt-get install ltsp-server openssh-server at the GNOME terminal, and that task was complete. The final step on the LTSP server was to build the thin-client environment. Simply running sudo ltsp-build-client at the GNOME terminal fired off the remaining configuration steps and built the LTSP chroot.

Now that the LTSP server itself was ready, I had to enable our network for PXE booting, and this meant messing with the Windows DHCP server. It took a little bit of trial and error, but much like in the DHCP server config that Kyle mentions in his article, there were only two configuration options that needed to be added to the DHCP scope. In Microsoft-ese, these were Option “066 Boot Server Host Name”, which I set to the IP address assigned to the LTSP server and Option “067 Bootfile Name”, which I set to “ltsp/i386/pxelinux.0”. The last DHCP option seemed a little obscure, until I realized that the Ubuntu TFTP server's root directory was /var/lib/tftpboot. If you're running some other DHCP server, see the DHCP Notes sidebar, or refer to your DHCP server's documentation on adding options to the DHCP scope.

Figure 1. The Ubuntu LTSP GDM Login Screen

At this point, I could boot a PC on our LAN, press F12, select Onboard NIC as the boot device, and in about 30 seconds, I got a GDM login screen! I could log in to an LTSP session at this point, but I had to do it as one of the users that already was on the Ubuntu server. It was close, but not quite what I wanted, as the ideal setup would allow anyone on our Windows domain to log in to an LTSP session. Fixing this would have meant integrating the server with our corporate Active Directory. That used to be a major chore unto itself, but with Ubuntu 8.04 and higher, it's just an apt-get and a couple commands away.

The package that makes all this magic happen is called likewise-open. First, I ran:

sudo apt-get install likewise-open


Bill Childers is the Virtual Editor for Linux Journal. No one really knows what that means.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Using Abbreviations Indiscriminately

~weatherguy's picture

It is foolish and acts as a point of abandonment for a technical article not to have the acronym or abbreviation identified. It requires the reader to have the specialized vocabulary as part of their working vocabulary. Those who might eventually come to trust your message are tempted to abandon your article when it has acronyms and abbreviations that have not been identified at the first use.

In most scholarly or technical writing--other than the Internet--there are standards for what is allowable in technical writing. Not adopting some standard for minimum levels of communication both in writing and in what amounts to a complete explanation in a tutorial is an egregious lapse.

It will cost you readers and credibility.


FOG Server a possible PXE solution for some

Anonymous's picture

Some may find a FOG server may be suitable (http://www.fogproject.org/) for managing windows images. It lives nicely in a PXE environment as well.

As far as Windows SPs &

Anonymous's picture

As far as Windows SPs & drivers go, you just need to slipstream them into the install image using something like nlite (XP - http://www.nliteos.com/) or vlite (Vista - http://www.vlite.net/) - works beautifully, even for the real PITA drivers like strange SATA raid controllers that you'd normally manually need to load from floppy.

The Windows unattended

T-One's picture

The Windows unattended installations are very interessting but without vista and server 2008 support not useable for a systembuilder like me.

LTSP with dnsmasq

Kenneth Finnegan's picture

I don't know if it's just me, but I couldn't get your dnsmasq conf lines to work in Tomato 1.23. I'd expect it to need the /ltsp/i386/ prefix, but even with that, it didn't work for me. However, I stopped pounding on it when I got this to work instead:
Thanks for putting me on the right track though! It's so much easier not having to manually switch CAT5 cables and configure multiple interfaces + another DHCP server every time I want to boot one of my hosts off another (broken CD drives + multiple users on main desktop mean I use this a lot!).


Josh's picture

I worked w/ the enterprise version of Ghost a year or so back. All of the docs said that PXE-style imaging was supported, but through multiple support calls, I was finally informed that it wasn't gonna happen...I spent a LOT of time trying to get it to work. (Granted, it probably *was* possible, but I wasn't smart enough/skilled enough/etc.)

That being said, I am extremely happy to see this. All of our machines at work are currently able to PXE boot, but we don't have the budget to purchase any high-end imaging stuff. I'm really, really excited about this article, and I can't wait to try it. Thanks so much for the article!


nfsmount error

senshikaze's picture

If you are runnign the LTSP server on a Debian Etch/Lenny machine, make sure to set the windows DHCP option "017 Root Path" to "/opt/ltsp/i386" (minus quotes) to get rid of the "nfsmount: need a path" error.
Also, if your server is running on AMD64 (x86_64), run this command "sudo ltsp-build-client --arch i386" to make a x86 compatible image.
Thanks for the article, Mr. Childers. Will see if I get images installed instead of an unattended install of XP (we have ALOT of programs installed by default). Good article.