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" section below.)

We've got 2 ProLiant 6400R systems. They're pretty substantial. See the hardware page for full details.

The primary system is named bud. It will likely host most of the production services. The secondary system is named budlight. The systems have equivalent specs, except that bud has a second (currently unused) NIC.

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…

We originally tried using a Compaq ProLiant 5500R for bud. Unfortunately, we weren't able to get Debian to play nice with the hardware. The original budlight was a loaner system, courtesy of Craig Buchek.

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

• List installed packages:
  

dpkg –list

• 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^H^H^H^H^Hcredit 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-02-19:

(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

The following people helped finish building the production servers on 2005-09-10:

(TODO)

The following people helped move the production servers to Primary Networks on 2006-01-16:

• Lee Lammert
• Craig Buchek
• Jeff Muse
• Ted Palmer
• Gary Meyer

The following people met on 2006-03-18 to come up with a migration plan and continue working on adding services:

• Mike Knight
• Fred Smith
• Lee Lammert
• Craig Buchek
• Gary Meyer
• Ed Wehner
• Carl Fitch
• Phil Bunch
• Anthony Lordi

The following people met on 2006-05-20 to work on email, mailing lists, and webmin:

• Lee Lammert
• Craig Buchek
• Stan Reichardt
• Gary Meyer
• Ed Wehner
• Fred Smith
• Anthony Lordi

The following people met on 2010-11-13 to work on RedHook (Possible Bud Light replacement):

• Lee Lammert
• Jeff Muse
• Don Ellis