Netboot.me turns netboot into internetboot [LWN.net]

September 9, 2009

This article was contributed by Koen Vervloesem

Recent computers support booting over the network by PXE (Preboot eXecuting Environment), an extension to the firmware that allows the computer to boot an operating system from a remote server using a network interface. However, this feature requires the user to setup a PXE boot server with one or more operating system images. A few weeks ago, Nick Johnson released a new service that makes use of PXE to boot into the install program of many popular Linux distributions and FreeBSD, directly over the Internet, and without the need of any local PXE boot server; it is called netboot.me.

Essentially, netboot.me offers a universal boot loader that allows the user to install the most recent version of any of a number of open source operating systems from one single medium. The boot loader makes use of gPXE (GPL PXE); the 1 MB image can be installed on a USB pen drive, floppy disk, or burned onto a CD. From then on, any computer that boots from the image retrieves the current list of available operating systems from the netboot.me website and shows that list in the boot menu. When the user chooses an operating system from the menu, the installer is downloaded over HTTP or FTP and starts running. This currently only works over an Ethernet connection, but WiFi support is in progress via a Google Summer of Code project for implementing 802.11 drivers in gPXE.

Currently the boot menu has installers for:

FreeBSD 7.2
Debian Lenny and Debian Testing
Fedora 11
openSUSE 11.1
Ubuntu 9.04 and 9.10 alpha

It also gives access to some live operating systems and tools that can come in handy. The user can launch live CDs for Tiny Core Linux 2.2, Micro Core Linux 2.2 and MirOS BSD. Other available tools are the GParted Live disk partitioning tool, the Parted Magic 4.4 rescue and partitioning live cd, Memtest86 and Memtest86+ to test system memory, and Hardware Detection Tool, a Syslinux module that displays low-level hardware information.

So on the one hand, this boot loader gives the user the possibility to install some of the most popular Linux distributions and FreeBSD, without the need to first download and burn an installer image. On the other hand, the netboot.me boot loader has a couple of useful diagnostic, partitioning and rescue tools. Users often do not download rescue tools until they need them, at which point it may be too late, so the tools in the netboot.me menu can be a time—and system—saver.

Chainload URLs

Netboot.me refers to each available operating system by what the project calls a "chainload URL", which identifies the operating system image uniquely. For example, the Debian Lenny installer for x86 is located at the chainload URL http://netboot.me/2013. This web page lists the kernel image, the initial ramdisk, and the kernel arguments (vga=normal -- quiet). The details differ slightly among distributions, however: in the Fedora 11 PXE installer, the user has to explicitly enter a URL containing the Fedora installation image, while the openSUSE 11.1 installer already has the repository URL as a kernel argument. The netboot.me website lists the available operating systems in different subcategories.

In fact, the user doesn't even need the boot loader image: most recent computers are perfectly capable of netbooting without a boot disk. This can be used to automatically bootstrap a netboot.me boot loader which netboots the final distribution boot loader over HTTP or FTP. For such a diskless netboot, the user just has to change the settings of his local DHCP server to return the required information to boot over TFTP (Trivial File Transfer Protocol). Because TFTP isn't the most reliable protocol over the Internet, the user can also host his own copy of the bootstrap image on a local TFTP server. Instructions can be found on the Getting started page.

The best part is that netboot.me is hackable and open for contributions. Each user is able to add custom boot configurations to the website, although it unfortunately requires logging in with a Google account. The user then submits the URIs of the kernel image and initial ramdisk, together with any required kernel arguments. Netboot.me is capable of booting any Linux kernel and any other standard boot image, as well as disk images and CD images. To boot this custom configuration from the netboot.me boot disk, the user opens the gPXE command line with CTRL-B right before the netboot.me menu appears, enters autoboot and then chain http://netboot.me/XXXX with the correct chainload URL for the custom configuration.

Security

The security implications of netboot.me need to also be considered. What assurance does a user have that they are really getting the boot loader and OS image that were requested? In general, images on the netboot.me menu originate from either static.netboot.me, in which case Nick Johnson personally downloaded and verified them, or from official distribution web sites such as ubuntu.com. If the user trusts netboot.me and the official sources, the only remaining concern is man-in-the-middle attacks. Johnson calls this a legitimate concern and considers two components that could be secured further: the download of the scripts and menu from netboot.me, and the subsequent download of the boot image from the source. The former can be protected, in principle, by using SSL, which gPXE supports. Unfortunately, Johnson sees two major issues with gPXE's SSL support:

It doesn't do certificate verification, and its random number generator is poor (to say the least - it always fills the buffer with 0x01 bytes). Both of these can be fixed, of course (though getting legitimately random data at boot time is tough), but I have some reservations about the integrity of gPXE's SSL implementation and my ability to secure it. With that in mind, I'm considering a simpler approach: Sign responses from netboot.me with an RSA key, putting the signature in the header, and verifying it in gPXE. gPXE already has the RSA implementation, so in principle this is a fairly straightforward extension.

The second component (the download of the boot image) is somewhat simpler: securing it would require adding support for verifying content hashes of downloaded images. Most of this is already in place, actually, so according to Johnson this would be a very simple extension.

Host your own netboot.me

The code for netboot.me is licensed under the BSD license. Most of the server side is Python code which is meant to run on Google App Engine. The boot loader is a modified version of gPXE. One obvious disadvantage of netboot.me is its dependence on Google App Engine. While there aren't any active efforts to decouple netboot.me from the App Engine, Johnson maintains that this ought to be fairly straightforward:

Netboot.me doesn't use the datastore in a particularly complicated manner, so it ought to be fairly easy to insert an abstraction layer to allow it to run on a relational database. Alternately, there are efforts like AppScale and Twisted AE to make it easier to host App Engine apps in third-party environments. For a purely local network solution, however, hosting using the SDK's dev_appserver would probably be perfectly satisfactory.

Collaboration

How does netboot.me compare with other solutions? There is Billix, a multiboot USB pen drive with network installations for several Linux distributions. Its approach is different: Billix hosts network install ISOs of the distributions on the USB pen drive, while netboot.me bootstraps the user's computer to grab complete ISOs of the distributions via PXE over the internet.

Another more direct competitor of netboot.me is boot.kernel.org (BKO), which is a Google Summer of Code project for gPXE. Although it seems to be less polished than netboot.me and offers fewer Linux distributions at the moment, it has one advantage: it can be installed easily on a local server. The administrator can download the ISO images, and then all users on the local network then can install the available Linux distributions via PXE. Because the ISOs are stored on the local network, this goes much faster than over the internet with netboot.me. This is not a luxury because the experience with netboot.me regularly gets spoiled by slow downloads of the operating system images.

The projects also have a slightly different focus. BKO is aiming more at live distributions that use iSCSI or HTTPFS for mounting filesystems, while netboot.me is concentrating more on netbooting existing images. According to Johnson, the two projects are keeping an eye out for opportunities to collaborate. As part of that effort, he has already added a menu item in the "Tools" category that loads the boot.kernel.org menu from within the netboot.me menu.

In conclusion

For testing out new distributions—or entire operating systems—it is certainly convenient to be able to boot directly from the internet. But, for system recovery tasks, it could easily be indispensable. Being able to access any number of up-to-date distributions, live CDs, and recovery tools, without having to maintain a library of CDs or other media, is something that users and system administrators alike may find very handy.

(Log in to post comments)