I decided it was time to place a PXE boot install image on my network for installing Ubuntu 10.04 Lucid desktops. For the most part everything went as expected (see this post) but during the install I got an error that "restricted/binary-amd64/Packages was corrupt".

It turns out there are no restricted packages on the alternate installer image, and the lack of an empty "Packages" file at "/dists/lucid/restricted/binary-amd64" where the networked install image is located was causing it to bomb.

Simply doing

touch Packages

in that shared directory within the install image seems to have fixed the issue. For some reason the fact that the Packages.gz ungzips into a zero byte file was throwing it, but having an already existing zero byte file seemed to fix it.

In yesterday's post I described how to install Linux over the network. Now I'm going to polish that off with a bit of post-install scriptery that does a bit more customization.

This part of the tutorial makes use of several different concepts to provide a customized install experience. First is the use of LDAP authentication on the domain. Your network may or may not use this. If you aren't already authenticating with LDAP you'll want to adapt this tutorial to your needs. Next is the use of the new user "Skeleton" configuration where you can place items that are automatically copied into a user's home directory the first time they log in. Last is using the rc.local file to run a script in such a way that it only runs the first time the computer is booted. This could be adapted to ask for the name of the computer during that step or other things to allow even more customization during install. A common practice instead of using a bash script like I did is to use a Python script at this point to allow for a more pleasing and customizable setup.

If you are trying to run an enterprise in Linux, one of the key components needed is a way to automatically deploy and configure Linux on the desktop. With this you can also make a memory test utility available over the network.

Enter LinuxPXE.

With LinuxPXE and Ubuntu you can easily push desktop installs out over the network to computers without CD drives, and have it preconfigure most of your common settings.

You'll need the following components on a server:

tftpd-hpa  (TFTP Server)
A DHCP Server
An Ubuntu Jaunty Alternate CD ISO Image file

Notice I said "tftpd-hpa" - the openbsd-tftpd server will not work for this.

You'll also need an Ubuntu Jaunty desktop with:

system-config-kickstart

I'm going to assume a rather high level of network design knowledge in this and not tell you silly things like "you can only have one DHCP server on the network at a time" - wait, I just told you that. Anyway, if you aren't already familiar with configuring an Enterprise grade network then this may go a bit fast for you.

TFTP

First, configure your TFTP server. You must edit /etc/default/tftpd-hpa to enable it:

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

Now start it with:

Tonight was a good test of our disaster action plan. Lighting struck either our building or our water tower and took down two of our three phases of power. The one remaining phase was producing extremely dirty power that made me afraid of frying anything plugged in.

For our network, in an extended power outage I really only have one server that MUST stay up and running. It's the server that customer's use.

For our two racks I have four large rack mounted UPS's. On average I get around 45 minutes of power out of them before we have to switch to generator. That gives me enough time to get to the office, flip a switch and fire up the generator.

This time however, we found that we were able to get clean power out of one of the subpanels so I decided to run an extension cord to power just the server I needed, the network switch, the router and the firewall. The firewall and switches pull very little power and the server I need to run is a 1U with only 2 hard drives, so it's not really pulling a heavy load either.

So, I set about shutting down the rest of the network until the main was back up. That's when I learned for all my planning that my server could not be an island.

The first thing I noticed was that e-mail couldn't get out. So, I thought "no big deal, I'll go ahead and fire up the internal email server." I hadn't realized that it was configured to relay all e-mail through the internal mail server.

Next, I noticed that e-mail still wasn't getting out. That's when I realized that all the DNS was being handled by one of two other servers, neither of which was online. So, I had to bring up one of the DNS servers. Really I should have brought one of those online anyway because one of the DNS servers is also the phone system.