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.

After having finished implementing Puppet on our network to simplify management and deployment, I started wondering...

Puppet allows you to set up a series of recipes designed for application deployment on your network. Once you have a batch of recipes, you simply assign those to specific hosts and puppet will do the hard work of making sure everything is installed and configured per your scripts. It takes a bit more work on the frontend but it adds the comfort that you have better documentation, you can easily use version management to archive how all of your machines have been configured, and it makes deploying similar setups or disaster recovery a breeze.

So I started wondering - how long until some vendor sells a Linux "network in a box" for small businesses? I'm thinking a small "cube" computer with Linux preinstalled that has PXE boot, preconfigured LDAP, a nice interface for adding machine accounts and a series of prefab puppet scripts.

Throw a little gem like that online, tell it the names you're going to use for various computers on the network, specify what services each of those computers will run (i.e. LAMP, LDAP Replication, Postfix, Desktop, etc.) and then PXE boot + install workstations and servers automatically.

If you're managing a network of more than say 10 computers, keeping them all updated, secured and managed properly is a big challenge. The more computers you get - both servers and desktops - the worse it gets.

Until recently, Windows really held the market in deploying multiple desktops. Active Directory and WDS makes it relatively easy, even if you do need a degree in Active Directory to not screw something up. On the Linux side most of the enterprise management systems were either for Red Hat or commercial products. Please don't hang me if I'm just not aware of them because I only recently started noticing these apps.

Enter Reductive Labs' Puppet. In the past few posts I've covered how to automatically install Ubuntu Linux over the network to multiple computers quickly and easily using PXE, Kickstart and a simple script. Puppet is the icing on the cake and so much more.

Today we are continuing to polish off how to do unattended installs of Linux.

Yesterday I covered how to run a bash script after a kickstarted installation to do any additional setup that isn't handled by the Kickstart file.

Installation of some packages require user input, which breaks the entire concept of "unattended" installs. Here's a quick fix to get around that.

First, on a setup computer, install the following:

sudo apt-get install debconf-utils

Now, install whatever packages you wish to later install in an unattended mode. Answer the questions for installation appropriately when prompted. Next we will export those answers into a "seed" file that we can use when installing the package on a new machine. For instance, I've installed several ldap authentication packages, so I might want to grab all of the settings those packages ask for.

sudo debconf-get-selections | grep ldap > ldap.seed

If you remember from yesterday, we created an archive that included a setup script and several config files. Place the ldap.seed file inside that archive along with the other scripts, and just before doing the apt-get install add the following line to the add2network.sh file:

debconf-set-selections ./ldap.seed

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:

Pound proxy is a great solution for adding a bit of a security layer, flexibility or scalability to your web server(s). If you're doing anything much more complex than hosting a blog, Pound may have some added value for you.

What Pound Is
Pound is a reverse proxy - that means you put it on the server end in front of your web services, not in front of your clients who need to connect to the general Internet. It takes web requests from end-users and distributes them among several web servers or services you may be running. Pound is also load balancing, so you can run multiple servers that look to the outside world as if they are just one, allowing you to spread the workload around.

What Pound Is Not
Pound proxy is NOT a caching proxy. By itself it won't help to speed up your server or network, but there is a lot of flexibility in Pound that will help you overall.

In Ubuntu, installing and using Pound is very easy. Simply install it and configure two files and you're off and running.

apt-get install pound

To enable Pound, you must edit the following file:

/etc/default/pound

Change it from startup=0 to startup=1. Before doing this, Pound will refuse to start.

The primary configuration file is located here:

/etc/pound/pound.cfg

I stopped relying long ago on RAID-5 after I had two separate installs that the controller card corrupted more than one disk in the array at the same time, causing total data loss.

When you're dealing with more than a terabyte of data, restoring from any sort of backup medium becomes a painful process. All of my data is backed up on DVD (yeah yeah, I've heard the complaints before, but you don't know what I know about DVD backups) but restoring a terabyte of data from DVD's can take a week or so.

Enter DRBD. DRBD stands for Distributed Block Device. Essentially it's RAID-1 that works over Ethernet. DRBD rides on top of whatever physical storage medium and network you have, but below the file system level. You run it on multiple machines, and set up an identical hard drive configuration on each machine. The DRBD partition is automatically replicated from the primary server to the secondary. Using tools like "heartbeat" you can even monitor this system automatically and promote the secondary server to the primary in the event of a failure.