We'd like to have 2 new Linux systems. See our goals for an explanation of why we're building new systems. We'd like to have 2 systems to provide an extra level of redundancy.

We'd been talking about building some new systems for a long time. Carl and Craig finally decided that it was time to actually do something about it instead of talking about it. So they're heading up this project. Lots of others have helped. (See the "Blame"^W"Credits" section below.)

The primary (larger) system was to be called bud. Unfortunately, we weren't able to get Debian to play nice with the hardware. Our secondary system is called budlight. Currently, that's our only system, so it's effectively the primary.

Budlight is actually a loaner system, courtesy of Craig Buchek. We're not sure what we'll replace it with at this point. We may just buy a replacement system for Craig and use the current system. We may build new systems from components, or we may buy a used server off eBay.

We have a history of naming our systems after Anheuser-Busch products. I (Craig) have no idea when or why that started, but it has nothing to do with the fact that I've worked at A-B for the past 4 years — SLUUG has been using the names before I was a SLUUG member, and before I ever worked at A-B. Of course, I did push to keep the tradition and selected the names of these 2 systems…

Like most volunteer organizations, those who volunteer and do the work get to make the decisions. However, we tend to work by consensus. That doesn't necessarily mean that there's 100% agreement — it just means that the person doing the work generally asks for advice before doing something, because somebody else will probably have to support the program in the future. Doing something new and really useful fails miserably for us if you don't document what was done.

If you need to get access to the system(s), please contact one of the project leaders: Craig Buchek or Carl Fitch.

• Access will be granted by way of sudo commands
• Please do not post any passwords to the wiki

We chose Debian, because most of our members felt that Debian was most appropriate for a server OS. We ran several polls at our meetings over the previous several months. Debian was the clear leader in recommended server-based Linux distributions, and was also the most familiar Linux distro to our members. In fact, it was the most familiar of all UNIX / POSIX systems among our users. Even many of us who are not familiar with Debian believed that it was the appropriate choice for our group.

On our test/development system, we chose to go with Debian 3.1 (sarge) even though it had not yet been released. We installed a release candidate dated from late January 2005. Release seemed to be pretty close. We felt that Debian 3.0 was too old for us to install at this point in time, as we'd then want to upgrade to 3.1 shortly after.

By the time we got our production servers, Debian 3.1 had been out for approximately a month. It seemed like the perfect time to use it.

Debian does some things differently than other distributions. Here are a few pointers to help those of us not quite so familiar with the Debian way.

• Re-run the installation configuration system:
  

base-config

• Search for a package with a given name:
  

apt-cache search string

• Show information about a package:
  

apt-cache showpkg packagename

• Show which installed package owns a given file:
  

dpkg -S file

• List files that belong to a package:
  

dpkg -L package

• Enable service to start at boot time:
  

update-rc.d service defaults

• Disable a service:
  

update-rc.d service stop 0 1 2 3 4 5 6

• Run a service in runlevels 3 and 4, with (boot-sequence) priority of 20:
  

update-rc.d service start 20 3 4 . stop 20 0 1 2 5 6

• Make a kernel package:
  

make-kpkg –initrd –revision=2:my.1.0 –rootcmd fakeroot –uc –us kernel-image

See also Debian Notes and the Debian Reference Card

We're currently using this DokuWiki to record how we installed and configured the system.

To record what you're doing at the command line, use the script utility. To get time-accurate recording specify the -t option and redirect standard error to a timing file:

# script -a script.out -t 2> script.timing

When done type exit or logout or Ctrl-D.

# exit

To replay the script use the replay command.

# replay script.timing script.out

There's plenty of blame to go around. Lots of our members helped out in various ways, including moral support, and just general having fun.

The following people helped build the development server on 2005-07-30:

(TODO: Get list of people who helped on 2005-02-19 from Stan.)

The following people helped build the production servers on 2005-07-30:

• Lee Lammert
• Craig Buchek
• Carl Fitch
• Phil Bunch
• Jeff Muse
• Gary Meyer