These instructions document the installation and configuration of Debian 5.0 on the RedHook server (possible replacement for BudLight).

We downloaded and burned the Debian 5.0 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. This initial installation process will take about 30 minutes.

1. Select English as the language.
2. Select United States as our location.
3. Select American English keymap.
4. Select eth0 as Primary network interface.
5. Initial setup in The Bat Cave uses DHCP for network address setting.
   • Hostname: redhook
   • Domain name: sluug.org
6. Select Manual partitioning method.
   • See below for details.
   • Write changes to disk when completed with partitioning.
7. Select 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. Create the first user when prompted.
   • Use a temporary account named build, so that account does not get confused with any real user accounts.
10. Set the options for APT packages.
    • Use a network mirror? Yes
    • Country: United States
    • Site: ftp.us.debian.org
    • Accept blank entry for the HTTP Proxy information.
11. If prompted to participate in package popularity contest, say No.
12. Select Standard system software to install, and unselect everything else.
13. Skip the package installation, if asked.
14. Say yes when asked to install GRUB boot loader to the master boot record.
15. The CD ejects at this point.
16. Hit Continue to reboot the system.

The system came with 4 x 36 GB drives. With all four of the drives in a RAID 5 array, this gave us 108 GB of usable storage.

We decided upon the following partition setup. The table lists the partitions in the order they are listed by df.

All file systems were formatted as ext3.

Here's the result of running df:

Filesystem               1K-blocks      Used Available Use% Mounted on
tmpfs                       453140       512    452628   0% /dev
/dev/hda                    153936    153936         0 100% /cdrom
/dev/mapper/redhook-root   2951120    155704   2645504   6% /target
/dev/mapper/redhook-home  79694712    184216  75462216   0% /target/home
/dev/mapper/redhook-temp    983704     17628    916108   2% /target/tmp
/dev/mapper/redhook-usr    3842104    197584   3449348   5% /target/usr
/dev/mapper/redhook-var   11534616    213936  10734748   2% /target/var
/dev/mapper/redhook-root   2951120    155704   2645504   6% /dev/.static/dev
tmpfs                       453140       512    452628   0% /target/dev
/dev/hda                    153936    153936         0 100% /target/media/cdrom0

We started with a minimal ("netinst") 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.

[TODO: Adjust these values for RedHook when available]

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.160
        broadcast 206.196.99.175

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.
   • NOTE: The firewall on RedHook doesn't allow responding to ping, so don't try pinging it.
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).

[TODO: Adjust this section for redhook]

Ensure that the hostname is correct:

hostname

If it is not, change it:

hostname redhook

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
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. You may need to add the contrib and non-free items on each line. The /etc/apt/sources.list file should look like this:

deb http://ftp.us.debian.org/debian etch main contrib non-free
deb-src http://ftp.us.debian.org/debian etch main contrib non-free
deb http://security.debian.org/ etch/updates main contrib non-free
deb-src http://security.debian.org/ etch/updates 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:
 apt-get upgrade
as root on $HOSTNAME.

If a package is listed as "held back", then also run:
 apt-get dist-upgrade
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.

NOTE: We should probably replace this custom script with cron-apt.

This script works much like the previous script, sending an email only if any partition is over 90% full. Save the following code to /etc/cron.daily/check-disk-space:

#!/bin/sh

HOSTNAME=`hostname`
MAILTO="sysadmin@sluug.org"
MAILFROM="Drive space checker <sysadmin@sluug.org>"

DF_OUTPUT=`df -h | grep '^/' | sort -r -n -k5 | awk '$5 > "90%" {print "  " $6 " is " $5 " full"}'`

if [ ! -z "$DF_OUTPUT" ]
then
 mail -a "From: $MAILFROM" -s "Drive space report for $HOSTNAME" $MAILTO <<EOF
Drive space on $HOSTNAME is critical:

$DF_OUTPUT

Please clear up some space on the listed partitions.

EOF
fi

exit 0;

Change the permissions on the script to make it executable:

chmod 755 /etc/cron.daily/check-disk-space

Root passwords should be changed at least every 6 months. We decided to send out an email reminder to help ensure that we do that.

Save the following code to /etc/cron.monthly/root-password-reminder:

#!/bin/sh

HOSTNAME=`hostname`
MAILTO="sysadmin@sluug.org"
MAILFROM="Root password reminder <sysadmin@sluug.org>"
MONTH=`date +'%1m'`

# This checks to see if it is July or January. If so, send out the reminder.
# Since this script is in cron.monthly, it only runs on the 1st of the month.
if [ $MONTH = '07' -o $MONTH = '01' ]; then
  mail -a "From: $MAILFROM" -s "Change root password on $HOSTNAME" $MAILTO <<EOF
Please change the root password on $HOSTNAME.

Whoever changes the root password, please reply to this email to
let everyone know that you've changed it. Provide your phone number
so that the other admins can call you to get the new password.

This script is located in /etc/cron.monthly/root-password-reminder,
and send emails out on July 1 and January 1.
EOF
fi

exit 0;

Change the permissions on the script to make it executable:

chmod 755 /etc/cron.monthly/root-password-reminder

Adding this script to the /etc/cron.monthly directory will cause it to be run on the 1st day of every month. The script itself checks to see if it's January or July, and only sends an email for those months. By default, the daily cron scripts run at 6:52 AM.

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.

Lee Lammert led the inital installation effort, 2010-11-13, assisted by Jeff Muse and Don Ellis.

Don Ellis was the primary documentor.

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