Debian Lenny base server

Debian Etch Base Server setup

Getting the hardware

Note: in the following we're assuming you'll be assembling an x86 or x64 type of machine, as it has about the best price/performance ratio you could wish. Hardware costs for other platforms, e.g. IBM's Series p or HP 9000, can be much higher, while platforms like ARM are just not very powerful. Also, the availability of components and of help can be less than with the ubiquietous x86/x64 platforms.

Naturally, before we can begin to install the operating system, we need to obtain the necessary hardware. Which hardware you require depends on what you want the server for; a testserver on which you will test only a single feature for a short while does not need the same quality of hardware as does a server that's supposed to act as a homeserver for many tasks for a long time. We'll assume your server will be like ours: a home server that must perform many tasks with sufficient performance for a few users, that's reliable and will last for a couple of years. So build or obtain a server with at least the following hardware:

• a spacious casing with big, quiet cooling fans, like the one we have;
• an efficient, heavy-duty power supply that's rated high enough for your devices, and has a decent efficiency. For example, a Corsair HX520 power supply;
• a server class motherboard, e.g. an Intel or AMD based single-processor motherboard. DO NOT go for the cheapest motherboard you can find: if you pay peanuts, that's what you get. Server class motherboards have the quality, stability and durability you'll need from it, and usually also most of the needed peripherals, like multiple ethernet network cards on-board. Usually a Linux server doesn not require much in the way of video performance (and the screen will be used rarely, if ever), so any old integrated graphics will do.
• a matching CPU - or multiple, if you think you need the power and the selected motherboard has the sockets.
• a CD-ROM- or DVD-player
• multiple harddisks - you'll want redundancy, because every harddisk fails at some time. The drive with your data on it will fail fatally when it is most inconvenient to you, and any data on it that you consider valuable will likely be lost forever. To make Murphy's work somewhat harder for him, we're going to store our data redundantly, so that if any drive in the server fails, we'll not lose our data or our server. Thus, get yourself at least two harddisks for your operating system, at least 40GiB in size (don't think you'll be able to buy smaller ones nowadays), and spanking new (NEVER use old harddisks for your production server, new ones are just too cheap to run that risk!).
• (multipe) network card(s) (NICs) if your motherboard does not have enough NICs integrated on-board. You'll want a NIC for your network, and another one for your Internet connection; and possible a third one for the wireless segment of your network.

Now build a machine out of the above, or have someone build it for you.

Preparation of the hardware

(Note: in the following we're again assuming you're running an x86/x64 type of machine. Hardware requirements and preparation for other platforms, e.g. IBM's Series p or HP 9000, can differ significantly)

Next, check the assembled hardware:

• is the configuration complete? If it does not have a CD/DVDplayer from which it can boot, then installing the software gets more difficult - at least get an USB external DVDdrive or something like that.
• are all components connected properly (memory DIMMs seated correctly in their sockets, AGP card inserted correctly into the AGP slot, et cetera) and are all cable connections made (multiple power cables to the motherboard, one power cable plus one data cable to each hard disk, etcetera)?

Following this, you may hook up the machine. It's going to need power, and you will need at least a keyboard and a monitor attached. And if you want to use a Graphic User Interface to install, a mouse is required also. When you've ensured that everything is safe, you can turn on the machine, and continue to check it:

• do all fans start to run when you turn on the machine? (if not, then quickly turn off your machine and correct the problem!)
• does/do the hard disk(s) spin up?
• do the power button and reset button operate correctly?
• are the power led, HDD led and other display gadgetry functional?
• when you let the machine power up, does it emit a single beep? And does it then show a Power-On Self Test screen (POST)?
• Does it show the correct amount of memory in the POST screen? The correct number & speed of the CPU(s)?
• Does the machine recognise all controller cards (SCSI, S-ATA etc)? And all attached DVD-drives and hard disks?
• are all BIOSes/firmwares up to date?
• If you have a hardware RAID controller, are your RAID arrays built already?
• does the machine attempt to boot from at least the hard disk?

...et cetera. If there is any problem, or you want to update the BIOS or firmwares, it's best to do it before the operating system is installed. This Wiki, however, is not the place (yet) to get the information on how to accomplish these type of tasks.

The last steps in the preparation of the hardware, are

• to ensure that the machine can boot from CD/DVD, so that you can start installing Debian from it. It is possible to install Debian over the network, but that requires setting up a PXE Boot server which is (currently) outside the scope of this wiki.
• to connect the hardware to the Internet, so that it can get all required updates etcetera; please do not connect the box straight to the Internet, but make sure that it's safely behind a firewall, or failing that, a NAT router.

By now the system should be almost ready to receive it's Operating System. But first we have an issue to tackle: that of redundancy.

Software or hardware RAID

Your hard disks will fail. They absolutely will. It is never a question of "if", only of "when". So what will you do when the hard disk containing your complete operating system fails (besides pulling your hair out, that is)? What we propose is this: hard disks are pretty cheap nowadays, so let's use RAID technology to make our hard drive space resilient against failure of a whole drive. So first make sure that you have two disks of equal size instead of only one. Had you already been planning to use multiple disks already, then make sure you have at least one disk more than your space requirements prescribe; the space on that extra drive will provide the needed redundancy. Next, click here to learn a bit more about RAID, to make the decision to use hardware-based and/or software-based RAID, and to plan your RAID arrays. In this example, we'll assume you're using hardware RAID on a RAID controller that's supported by the Debian installation software. This means that the installation software will "see" your RAID array(s) and present them as usable drives.

Planning your network names

If your machine must become a part of an existing network, then it's almost certain that you already have a DNS domain in place; in that case: obtain the DNS suffix your machine will get (the DNS domain your machine will "belong" to). However, it's also possible that this machine is going to be the first machine in your new network, in which case the whole issue of DNS suffixes is wide open. If you need more information on DNS, go [here]. For now we'll assume you have (or will quickly obtain) a working knowledge of the DNS system. Here is our tip on choosing a DNS domain for your home network:

• do not use a publicly registered domain name (e.g. "cocacola.com") for any machine that's not primarily intended to serve the public on the Internet;
• for machines serving a private network, we urge you to use Top Level Domain name "lan" (to signify your machine is on a Local Area Network or LAN)
• for the Domain Name itself, we suggest you use a level 2 name, like "saruman.lan", and not a level 3 name, like "mister.saruman.lan".

This is only a short section on DNS, but remember that once a proper DNS system is in place, it's pretty much work to change it. At any rate, this section has most likely showed you that you need to put some thought into the DNS Domain Name design of your home network. OK, with this out of the way, we can get to installing the OS.

Operating System installation

To install an Operating System (OS), it's kinda instrumental that you have one. Here, we're going to use Debian, the biggest Free OS that we know of. Free stands for Freedom, but incidentally that Freedom also means it's gratis, an appealing aspect of Free. To get your own copy of Debian, go to their download site and obtain the latest Stable image - in this wiki it's Debian 4.0, or "Etch" as it's also known.

Besides the choice which release of Debian you want to run, you also have to know for which platform you're downloading (in our case: either amd64 or i386 depending on your hardware platform) and what kind of install you wish - if you have a working, fast Internet connection available at the time of install, then we recommend getting the [netinst CD image; it's a relatively small CD, that'll be able to get you going, but gets most of the software you'll need straight from the 'net at install time.

So, since in the example at hand we're installing on a Xeon server on which we wish to install 32-bits software, we'll download debian-40r3-i386-netinst.iso, the latest netinstall image at the time of writing. Burn this to a CD-recordable and boot your prepared hardware platform from this CD.

After booting from the CD, a friendly prompt invites you to indicate how you want to boot the CD. Your choices are listed under <F3>; we're going to use the standard Command Line installation, so we type "install"<enter> or just simply <enter>.

We could easily use "installgui", in which case we'd have a nice fresh Graphical User Interface for our installation. We're not going to, because we're real men, and Real Men Don't Click. Also, we've found that from the GUI it's hard to switch to a second console and then back. We could also opt for "expert" as installation method, because it gives a much finer grain of control, but we usually don't need that control, and can do without the barrage of extra questions that the "expert" installation method pose. Finally, we could opt for "expertgui", where we have both the barrage of extra questions and the GUI, neither of which we need.

After the Linux kernel finishes initializing the machine, a simple text-based installer appears that immediately starts asking questions. Answer them according to your needs. Our example system uses the following choices:

• Language: english
• country: other > Netherlands
• keymap: American English (since we have a keyboard with US layout)

Some installation software loads, and we get to the next phase: if you have multiple NICs in your machine (which we believe you should have!!), and if they're detected properly, then you're required to indicate which of the detected network interface cards (NIC) is going to be the "primary" NIC.

Here, trouble could begin. If your machine has network cards that are not supported, then you'll see no cards here - but then how are you going to do a NetInstall? A solution would be to (temporarily) install a NIC that is supported, like a cheap Realtek card, or an old 3Com 905 card. Then, when the whole system is installed, up and running, you could compile a new kernel that contains support for your actual NICs, and when these work, remove the temporary NIC. For now, we'll assume that at least one of your NICs is recognised properly by the Debian installation routine.

Select the card that's connected and has (indirect) access to Internet (again: it should not be connected straight to the wild wild web, but sit safely behind a firewall, at least until we've installed our own firewall); if at all possible, let it be the NIC that'll be connected to your home network itself, on the inside of your server. Let's assume that this NIC is designated eth0 by the Debian installation. This card will now be configured using DHCP, so if you're on a network with a DHCP-server, the network will work straight away. If it's not, you can either configure the network manually or fix your DHCP-server and connection between it and eth0.

Next is one of the hardest questions that any OS installation is going to ask you: what will be the host name of the system? You could change it at any time in the future, but with lots of hassle, so you better choose wisely. Here are our tips:

• do not name your machine after the user that's going to use it, e.g. "bernie-pc" (at some time in the future, Bernie's machine will be moved to Alice, so then Alice is working on "bernie-pc" which makes the situation quite unclear);
• do not name your machine after the department or workgroup that's using it most, e.g. "accounting-srv" (same reasoning);
• do not name your machine after it's main function, e.g. "printserver" (at some time in the future, the main function is moved to another machine, and/or an alternative function will become the main function of the machine);
• do not name your machine after it's location, e.g. "srv-boston" (at some time in the future, the box will be moved to another location);
• do not name your machine after it's hardware configuration, e.g. "ibmx346" (at some time in the future, either another xSeries x346 will be wheeled in, or the machine will be upgraded to accomodate increased use or overcome hardware problems - your "ibmx346" could suddenly be running on an xSeries x3650).

What we feel are safe names for any machine in your network are true names, perhaps linked to a common theme: names of European cities, names of movie characters, names of countries or holiday destinations et cetera. Immediately following comes the question of the Domain Name. This is about a DNS domain, so effectively the installation program is asking which DNS suffix the host name should have; if the DHCP-server already provided something it'll be suggested, but you can override it.

Partitioning

Next comes the question of partitioning, or how to divide the available disk space into chunks for the server to use. This is a tricky subject, because if you put all storage space into one partition, then some day a runaway process will fill up the entire disk with useless logs, and the system will crash. On the other hand, if you divvy up all space into little chunks, then some application is going to need space in one of those partitions where there is none, even though there may be plenty in other partitions. To prevent both problems from occuring, we're going to use Logical Volume Management (LVM) so that we can provision enough space to start our server, but keep some space in reserve to apply when needed, where it'll be needed.

So, we have put together a recommended standard partitioning scheme. The basis is this:

Partition	MD	LVG	LV-name	Size (physical machine)	Size (VM)	File System	Mount point
1	/dev/md0			100MiB	100MiB	ext3	/boot
2	/dev/md1			3GiB	1GiB	ext3	/
3	/dev/md2	system	swap	1GiB<ref name="swap">Rule of thumb: twice the size of the machine's RAM, but no less than 256MiB and no more than 2GiB</ref>	256MiB<ref name="swap"/>	swap
			var	2GiB	1GiB	ext3	/var
			appslog	3GiB	-	ext3	/var/appslog
			home	1GiB<ref name="home">Note that this heavily depends on the purpose of the machine; if it is not to house any users, then (almost) no space is needed for /home. But on the other hand if e.g. a virtual user is to be used for keeping mailstores, or other service users need home space, then /home needs to be big enough for that.</ref>	512MiB<ref name="home"/>	ext3	/home
			usr	3GiB	3GiB	ext3	/usr
			tmp	1GiB	512MiB	ext3	/tmp
			opt	1GiB	-	ext3	/opt
Total				18.1GiB	6.9GiB

<references/>