These instructions document the installation and configuration of Debian 4.0 on our servers.

We downloaded and burned the Debian 4.0r0 netinst CD image. We then booted each system with the CD-ROM in the drive. We hit Enter at the boot prompt to accept the default installation mode. We then proceeded with the installation as follows:

1. Selected English as the language.
2. Selected United States as our location.
3. Selected American English keymap.
4. Selected eth0 as Primary network interface.
5. DHCP failed, so chose to Configure network manually.
   • IP address: 206.196.99.162 (for Bud), 206.196.99.163 (for BudLight)
   • Netmask: 255.255.255.240
   • Gateway: 206.196.99.161
   • Nameserver: 205.242.92.2 (for Hostirian/Primary.Net)
   • Hostname: bud (or budlight)
   • Domain name: sluug.org
6. Selected Manual partitioning method.
   • See below for details.
   • On re-install, chose to keep existing partition table.
     • Had to set mount points and FS types for each partition.
     • Kept data on /home and /usr/local; reformatted the rest.
   • Write changes to disk when completed with partitioning.
7. Selected Central time zone.
   • In the extended list, this is labeled as America/Chicago.
   • Was not asked on re-install, but we decided to set the system clock to GMT.
8. Set a new root password when prompted.
9. Created the first user when prompted.
10. Set the options for APT packages.
    • Use a network mirror? Yes
    • Country: United States
    • Site: ftp.us.debian.org
    • Accepted blank entry for the HTTP Proxy information.
11. Selected Standard system software to install.
12. Skipped the package installation.
13. Said yes when asked to install GRUB boot loader to the master boot record.
14. The CD ejects at this point.
15. Hit Continue to reboot the system.

We had 36 GB to work with on each system. The systems came with 4 x 18 GB drives. With 3 of the drives in a RAID 5 array, and 1 hot spare drive, this gave us 36 GB of usable storage.

After some debate, we decided upon the following partition setup. The table lists the partitions in the order they were created.

All file systems were formatted as ext3, except for /var. We formatted /var with reiserfs, because we expected to use Maildir format. Maildir format uses a separate file for each email message, which ends up creating lots of small files within a single directory. Reiserfs is much more efficient at storing small files and having a large number of files within a directory.

Here's the result of running df:

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/ida/c0d0p2         914108     77048    788318   9% /
tmpfs                  1989212         0   1989212   0% /dev/shm
/dev/ida/c0d0p1          91763     15029     71838  18% /boot
/dev/ida/c0d0p6        4807072     32960   4529928   1% /home
/dev/ida/c0d0p11       9879016     32860   9344320   1% /spare
/dev/ida/c0d0p10        914108      8239    857127   1% /tmp
/dev/ida/c0d0p8        3843160    211724   3436212   6% /usr
/dev/ida/c0d0p9        2883376     32896   2704012   2% /usr/local
/dev/ida/c0d0p7        9767184    178060   9589124   2% /var

We started with a minimal installation, with only a few packages installed. We will install all the required packages manually. This provides some added security, as we've minimized our attack surface to only the applications we actually need.

This system is intended to be a server, and should never run any X programs. Any GUI-type administration should be done over HTTPS. So we did not install any X server or X client programs.

Make sure that the network settings are all correct. Review the settings in /etc/network/interfaces. It should look something like this (for Bud at Primary.Net):

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
        address 206.196.99.162
        netmask 255.255.255.240
        gateway 206.196.99.161
        network 206.196.99.0     # NOTE: I think this is incorrect.
        broadcast 206.196.99.255 # NOTE: This may be incorrect too.

Note that you'll need to be at the system console if you make changes to the network settings, because any network connections may be dropped. (You might be able to make the change and re-connect after getting dropped, if you don't take the interface down before making the changes, but it's not as clean, and might not work.)

If you make changes, restart the network:

/etc/init.d/networking restart

Ensure that you can connect to some Internet hosts to make sure that your configuration is correct. If you run into problems, try these troubleshooting steps:

1. See if you can ping another system on the same subnet.
2. See if you can ping the default gateway.
3. See if you can ping the DNS server.
4. Check the routing table (route -n).
5. See if you can look up a name (using dig or nslookup) and get an IP address back.
6. See if you can connect to an Internet service (using ssh, wget, or some other program).

Ensure that the hostname is correct:

hostname

If it is not, change it:

hostname bud

Edit /etc/hosts to add the IP address of the system. We also put the other system in there. Note that the fully-qualified name must come before the short name, so that the system can determine the domain name properly. Also, do not put the hostname on the localhost line. The file should look something like this:

127.0.0.1       localhost.localdomain   localhost
206.196.99.162  bud.sluug.org           bud
206.196.99.163  budlight.sluug.org      budlight

Verify that the system can get the domain name and fully qualified hostname:

hostname -d
hostname -f

Ensure that /etc/apt/sources.list contains a pointer to servers to fetch security updates. Also remove the lines that reference the installation CD-ROM. The /etc/apt/sources.list file should look like this:

deb http://security.debian.org/ etch/updates main contrib non-free
deb-src http://security.debian.org/ etch/updates main contrib non-free
deb http://http.us.debian.org/debian etch main contrib non-free
deb-src http://http.us.debian.org/debian etch main contrib non-free

Update the package list:

apt-get update

Upgrade any new packages:

apt-get upgrade

The first time through, the kernel will likely be updated. If so, it will tell you that you need to reboot.

reboot

It would be nice to have the updates install automatically, but in order to prevent problems, it's best to have a system administrator apply the updates manually, so he can fix any problems that crop up. So instead, we'll alert the system administrators when there are updates available.

We've adapted code from here to check for new Debian updates. Save the following code to /etc/cron.daily/check-debian-updates:

#!/bin/sh
 
HOSTNAME=`hostname`
MAILTO="sysadmin@sluug.org"
MAILFROM="Debian update checker <sysadmin@sluug.org>"
 
apt-get update >/dev/null 2>&1
 
NEWPACKAGES=`apt-get --print-uris -qq -y upgrade 2>/dev/null |awk '{print $2}'`
 
if [ ! -z "$NEWPACKAGES" ]
then
 mail -a "From: $MAILFROM" -s "New Packages for $HOSTNAME" $MAILTO <<EOF
There are new Packages available for $HOSTNAME:
 
$NEWPACKAGES
 
please run:
 sudo apt-get upgrade
on $HOSTNAME.

EOF
fi
 
exit 0;

Change the permissions on the script to make it executable:

chmod 755 /etc/cron.daily/check-debian-updates

Adding this script to the /etc/cron.daily directory will cause it to be run every day. By default, the daily cron scripts run at 6:25 AM. One nice thing about running them daily and sending them to a mailing list is that it's easy to see if the updates have or have not been applied by the next day. The more times the message is sent, the more likely someone will be to log in and run the updates.

The cron job scripts should probably be moved to a different wiki page. Perhaps the security page, or create a new page to document system maintenance tasks.

Check that the update emails are getting sent. Outbound email may not be working (yet), or the list may not accept emails from the source address we used.

Consider replacing allow-hotplug eth0 with auto eth0, per HowtoForge document (linked below). Otherwise restarting the network doesn't work, and we'd have to reboot the whole system.

Consider adding user disk quotas to /home. See the HowtoForge document.

Create a few (temporary?) users for building the system.

Determine how we want to maintain users. If we decide to allow all our users to have accounts on the system, we probably want to keep them in sync with the existing AIX systems. Run periodic reports to ensure that users on systems do not get out of sync.

See the general TODO page for more work to be done.

James Pattie led the installation effort, 2005-02-19.

Lots of other folks helped in the decision-making and installation process.

John House and Craig Buchek were the primary documentors.

Craig Buchek and Jeff Muse led the installation effort on the production servers, 2005-07-30.

Lee Lammert led the effort to move the systems to Primary Networks, 2006-01-16.

Craig Buchek rebuilt Bud with Debian 4.0 on 2007-05-30. Installation took about 2 hours, 1 hour of which was correcting a networking issue due to incorrectly documented network settings.

See this HowtoForge document for an excellent step-by-step guide to installing Debian 4.0, with screenshots.