A few weeks back I re-published a great article on setting up a PXE server.  Since then I've had to use this server for a number of other tasks, from cloning 15 machines to running Ubuntu LiveCD over a PXE network.  I'd like to share with you a couple more tips on getting the most from your PXE Server.

NFS

In order to get the most out of your PXE, I recommend install nfs on your machine.

With this you'll be able to share more than just the initial boot - but mount directories after boot to have a fat-client setup.
My exports file (directories which I've explicitly shared via NFS looks like this:

I don't currently have a fat-client setup, but the above directories are a good introduction to two ways of extending the PXE Server.

Clonezilla

Clonezilla Live, based on DRBL, Partition Image, ntfsclone, partclone, and udpcast, allows you to do bare metal backup and recovery.  That means it reads the physical hard disk, and copies the blocks one-for-one.  This is pretty useful when cloning identical machines (which is what I was doing) - but there's also a Server Edition - which uses multicasting and is capable of cloning a 5.6GB Disk Image onto 42 machines simulteneously in around 10 minutes.

I downloaded Clonezilla Live! from the UK Mirror Service.

wget http:////www.mirrorservice.org/sites/download.sourceforge.net/pub/sourceforge/c/cl/clonezilla/clonezilla-live-1.0.11-19.iso
Once that's done, I mounted it at /media/clonezilla

mount -t loop /tmp/clonezilla-live-1.0.11-19.iso /media/clonezilla
then copied the entire iso into /exports/clonezilla

Since that was now setup - and using the PXE configuration from the previous post, I created the folder clonezilla in /var/lib/tftpboot/ and copied the kernel and initrd there.

I then edited /var/lib/tftpboot/pxelinux.cfg/default to include the following

Once that was saved, I could then boot up a machine over the network - and typing 'clonezilla' at the prompt allowed me to boot into clonezilla and clone my computers :)

Ubuntu LiveCD

The Ubuntu live CD pretty much followed the same configuration as the Clonezilla setup (except, of course, downloading the iso of ubuntu, not Clonezilla).

The pxelinux.cfg/default entry is also slightly different (NB: casper), and as I already had ubuntu intrepid and hardy directories in the tftpboot directory - I created a new directory called /live (which has the latest iso in it).

The next stage for me is to set up the /var/lib/tftpboot dir to automatically rsync the latest version of all the files, and for the /exports/ directories for the isos to do the same.  However, as this is currently a 'work setup,' I don't have the time available to implement this.  I hope that I can get something sorted for India though, as I've been asked to look into setting up a mini computer suite - and having second hand computers booting over PXE would be a pretty good way of managing them (and lowers the overhead in setting up the PCs individually).  I'm also looking at ltsp, so if anyone can give me some advice I'm sure it'd be welcome in the not-to-distant future.

This is my take on the Drabble meme, from Scott James Remnant

A drabble, simply put, is a story, normally science fiction or fantasy that is exactly one hundred (100) words in length.  No more, no less.

To participate, all you have to do is write a story in 100 words and post it on your blog.

This is my attempt, entitled "The Void"

Finally the lid was lifted.
Nothing could be seen in the darkness.
Drip, drip drip.
Footsteps could be heard from beyond the now passable void; were they human feet?
“Sam,” he shouted. “Come hither.”
At once Sam was there, trembling in the cold and damp.
“You're the only one that can fit through, Sam.”
Sam held her breath, and ducked down past the rubble.
The air was pungent with the smell.
Sam entered the void, and at once realised the enormity of the task that lay ahead.
“We're going to need dyno-rod to fix this leak!”

There are lots of issues that I'm semi-preparing myself for when I'm out in India. My attitude so far has been a 'laissez-faire' approach - whereby I'll solve problems as I come across them whilst out there. I think this is the only sane way for me to view the situation without overloading myself with ideas/problems/solutions.

The one good thing I don't have to worry about is that I do have an internet connection over in India - or at least will have at the main site. Whether or not I'll have one where I'll be living - I'm not yet sure. However, having read a little about Keryx - I'm pretty sure I'll have no issues.  It looks to be a very clever way of updating ubuntu computers without a network connection.

One of the other things I've been looking at this week is mesh networking - using olsrd I should be able to set up a mesh network covering the site for the clinic we're hoping to build.  Stuff like these are solutions for problems I'm not sure I yet face - but it's great to have a background knowledge of potential solutions - even if the problem has not yet been identified.

With this in mind, I urge you guys to please keep me up to date with any cool features or solutions you think could possibly have some use for me out in India.  I'm going to be setting up an instance of the ubuntu brainstorm software, but for people to publish solutions to actual problems that we face.  I'm not sure how much mileage is in it - but expect an announcement in the next couple of weeks with a site-launch!

I'm hoping people have ideas as random as DUMBO - they're Indian Elephants too!

I was at the Ubuntu Bug Jam today, at the offices of the Linux Emporium in Sutton Coldfield, Birmingham.

I think it was a pretty successful day, and sets a good precedent for the next two days (though unfortunately I shall not be there).  Was also great to see the Ubuntu-UK PoC Dave Walker there, as well as Mez who led the session and helped clear up any queries held regarding the bugfixing.

I'd just like to say thanks to the guys @ Linux Emporium for putting up such a great venue for the BugJam, as well as providing all the necessities (tea and biscuits).

Also kudos to all the other guys that took the effort to make it to the Jam, and special praise to those who are giving their weekend up to continue the great work.

The following article was originally published @ http://www.debian-administration.org/articles/478

If you're looking to perform a lot of system recovery, or system installation, then network booting with PXE is ideal. PXE allows you to boot up a system and have it automatically get an IP address via DHCP and start booting a kernel over the network.

PXE itself stands for "Pre-boot eXecution Environment", which describes how it works in the sense that the clients using it haven't booted in a traditional manner.

In order to use PXE you need to setup a boot-server which will allow client systems to :

• Request an IP address (via DHCP)
• Download a kernel (via TFTP)

With both of these services in place any system which supports PXE/network-booting (you might need to enable it in the BIOS) should be able to gain an IP address, fetch a kernel, and boot without an installed operating system.

(This is ideal for systems which can't be booted by a traditional approach; for example your new AMD-64 system which doesn't have a CD/DVD drive!)

Our SetupFor the purposes of this article we'll assume:

• We're working with a small network 192.168.1.0/24
• We'll allow all local machines to boot and get an IP address via DHCP from the range 196.168.1.70-192.168.1.100
• Our "boot-server" is the host "itchy" with IP address 192.168.1.50
• We will serve the same kernel to each host.

In our example we'll configure a PXE-server which will allow remote systems to run the Debian Etch installer, but nothing here is specific to that. PXE allows you to configure a system to boot from an arbitrary kernel (and matching ramdisk if you wish to use one). With the correct configuration you can even cause the clients to mount a remote file-system via NFS and have a diskless thin-client system.TFTP SetupTFTP is a very simple file-transfer protocol, which is very similar to FTP but which doesn't use any kind of authentication. If you're not already running a TFTP server you can install one by running:

root@itchy:~# apt-get install tftpd-hpa

Once installed you'll need to enable it by editing the file /etc/default/tftpd-hpa. You should change RUN_DAEMON to yes, leaving you with contents like these:

#Defaults for tftpd-hpa
RUN_DAEMON="yes"
OPTIONS="-l -s /var/lib/tftpboot"

Now create the root directory, if it is missing, and start the server:

root@itchy:~# mkdir -p /var/lib/tftpboot
root@itchy:~# /etc/init.d/tftpd-hpa start
Starting HPA's tftpd: in.tftpd.

Once our systems have retrieved an IP address via DHCP they will request files from beneath the /var/lib/tftpboot root directory. We'll come back to the contents of this directory shortly.DHCP SetupIf you don't already have a DHCP server configured upon your LAN you'll need to install one. If you're using a small home router, or similar, to provide local DHCP services you must disable this first. (Since we require the DHCP server to pass back some extra options to clients which the majority of routers won't allow).

Discussing a full DHCP installation is mostly beyond the scope of this introduction but the thing we're trying to do is fairly simple. The goal of the DHCP server in this setup is twofold:

• We obviously want to use it to allow clients to request and receive an IP address.
• We want to cause the DHCP "answer" to give some extra details to the clients which are requesting an address:
  • The address of the TFTP server.
  • The initial filename to request from the TFTP server.

root@itchy:~# apt-get install dhcp3-server

Once installed the server is configured in the file /etc/dhcp3/dhcpd.conf, and there are a lot of available options described there. For our example we'll use the following configuration:

option domain-name-servers 62.31.64.39, 62.31.112.39;
default-lease-time 86400;
max-lease-time 604800;
authoritative;

subnet 192.168.1.0 netmask 255.255.255.0 {
        range 192.168.1.70 192.168.1.100;
        filename "pxelinux.0";
        next-server 192.168.1.50;
        option subnet-mask 255.255.255.0;
        option broadcast-address 192.168.1.255;
        option routers 192.168.1.1;
}

Here we've configured the server to give out IP addresses from the range 192.168.1.70-100, set the default gateway to be 192.168.1.1 and use our ISP's nameservers.

We've also used next-server to point to the TFTP server we're using (which is the same host as our DHCP server, but doesn't need to be). We've chosen the default name of pxelinux.0 as the name of the file for booting clients to request.

Using dnsmasq instead

Personally I use the dnsmasq package to provide DHCP services upon my LAN, since this is small and simple and provides other useful abilities, setting up PXE booting with dnsmasq just requires the addition of the following line to /etc/dnsmasq.conf:

dhcp-boot=pxelinux.0,itchy,192.168.1.50

(Again we've setup the filename along with the name and IP address of the TFTP server which is "itchy" / 192.168.1.50 in this example)

Restarting the service after this change is as simple as:

root@itchy:~# /etc/init.d/dnsmasq restart
Restarting DNS forwarder and DHCP server: dnsmasq.

PXE ConfigurationNow that we've configured the TFTP and DHCP servers we need to go back and complete the configuration. By default when a client boots up it will use its own MAC address to specify which configuration file to read - however after trying several options it will fall back to requesting a default file.

We need to create that that file, which will contain the list of kernels which are available to boot, we'll firstly need to create a directory to hold it:

root@itchy:~# mkdir /var/lib/tftpboot/pxelinux.cfg

Now save the following as /var/lib/tftpboot/pxelinux.cfg/default:

DISPLAY boot.txt

DEFAULT etch_i386_install

LABEL etch_i386_install
        kernel debian/etch/i386/linux
        append vga=normal initrd=debian/etch/i386/initrd.gz  --
LABEL etch_i386_linux
        kernel debian/etch/i386/linux
        append vga=normal initrd=debian/etch/i386/initrd.gz  --

LABEL etch_i386_expert
        kernel debian/etch/i386/linux
        append priority=low vga=normal initrd=debian/etch/i386/initrd.gz  --

LABEL etch_i386_rescue
        kernel debian/etch/i386/linux
        append vga=normal initrd=debian/etch/i386/initrd.gz  rescue/enable=true --

PROMPT 1
TIMEOUT 0

This file instructs the client to display the contents of the file boot.txt so create that too:

- Boot Menu -
=============

etch_i386_install
etch_i386_linux
etch_i386_expert
etch_i386_rescue

The only remaining job is to download the official Etch installer kernel and associated files and save them in the directories specified in the default file we created:

root@itchy:~# cd /var/lib/tftpboot/
root@itchy:~# wget http://ftp.uk.debian.org/debian/dists/etch/main/installer-i386/current/images/netboot/debian-installer/i386/pxelinux.0root@itchy:~# mkdir -p /var/lib/tftpboot/debian/etch/i386
root@itchy:~# cd /var/lib/tftpboot/debian/etch/i386
root@itchy:~# wget http://ftp.uk.debian.org/debian/dists/etch/main/installer-i386/current/images/netboot/debian-installer/i386/linuxroot@itchy:~# wget http://ftp.uk.debian.org/debian/dists/etch/main/installer-i386/current/images/netboot/debian-installer/i386/initrd.gz

When these commands have been completed we'll have the following structure:

root@itchy:~# tree /var/lib/tftpboot/
/var/lib/tftpboot/
|-- boot.txt
|-- debian
|   `-- etch
|       `-- i386
|           |-- initrd.gz
|           `-- linux
|-- pxelinux.0
`-- pxelinux.cfg
    `-- default

4 directories, 5 files

(We only used debian/etch here in case we want to offer other installers in the future. You can put everything in one directory if you wish, just update pxelinux.cfg/default to match.)

We should now be ready to test the setup.

We've installed a pxelinux.0 file which will instruct booting clients to request pxelinux.cfg/default. This will then make a list of boot options available, which are displayed by the simple boot menu file we created.

The files which are used for booting are stored beneath the TFTP root directory and thus accessible to booting clients.Sample RunA sample remote boot looks like this:

PXE entry point found (we hope) at 9AE5:00D6

My IP address seems to be C0A80146 192.168.1.70

FTFTP prefix:

Trying to load: pxelinux.cfg/01-00-14-22-a1-53-85

Trying to load: pxelinux.cfg/C0A80146

Trying to load: pxelinux.cfg/C0A8014

Trying to load: pxelinux.cfg/C0A801

Trying to load: pxelinux.cfg/C0A80

Trying to load: pxelinux.cfg/C0A8

Trying to load: pxelinux.cfg/C0A

Trying to load: pxelinux.cfg/C0

Trying to load: pxelinux.cfg/C

Trying to load: pxelinux.cfg/default

- Boot Menu -

=============

etch_i386_install

etch_i386_linux

etch_i386_expert

etch_i386_rescue

As you can see the system here attempted to load several configuration files, based upon its MAC address (01-00-14-22-a1-53-85) initially then falling back to the octets in the IP address it was given by DHCP (192.167.1.70).

Finally it managed to load a working configuration using the last-chance default file we created. This in turn instructed it to show the boot menu we created.

From here on the system will boot into whichever kernel you specify. (We could configure the system to timeout here and just boot into a default option, but we didn't.)
From here on you should understand how PXE can be used to boot an arbitrary kernel and initial ramdisk. Later we'll look at mounting a remote file-system over NFS to provide a diskless thin-client.