oreilly.comSafari Books Online.Conferences.


Building a Unix Server

by Dru Lavigne

Yes, I know. I promised that this article would continue to cover printing and the CUPS utility. But things didn't work out that way and at this point a second printing article wouldn't do the justice that a Unix GUI printing utility deserves.

Instead, I found myself spending the last few weeks installing servers for a small startup. As I did, I remembered the myriad details needed to create servers optimized for both performance and security. While it would easily take a book to explain all the details, this article can certainly cover some of the common pitfalls to watch out for and the logical approach necessary to do the job correctly. I'll demonstrate for a FreeBSD system, but the same logic applies to your operating system of choice.

Planning the Install

If you're like the typical open-source user, you spend a lot of time experimenting by installing, reinstalling, and uninstalling software. In the beginning, that software usually includes the OS itself as you discover exactly what you can and can't do to a system! While this is a fantastic learning experience, it's a luxury you can't afford when you move on to servers in a working environment. Enter "production systems," "no downtime," and the raised eyebrows and disparaging looks (or worse) from your superiors when something doesn't work.

It's no exaggeration to think of a server install as 99% preparation and 1% configuration. Sure, you can finish quickly by installing the operating system and applications with their default settings. There isn't a sysadmin out there who hasn't had to fix the fallout from such an install — usually done by someone else who left town without a forwarding number.

Related Reading

The Complete FreeBSD
Documentation from the Source
By Greg Lehey

You can save yourself a lot of future grief if you start by clarifying your superiors' needs. Put all of the cards on the table so that you understand exactly what they want and they understand what is technically feasible. You don't want to spend a week configuring and testing Apache 2 only to find out that the web-mail program your manager has his heart set on only works with Apache 1.x. Or to hear, "What do you mean, I have to download all of my email?" after configuring a POP3 server even though you'd originally tried to sell management on the greater security provided by an IMAP server. Yes, there's often a wide gulf between management's software needs and the technical details a sysadmin concerns himself with; it may take all of your communication skills and patience to work through this preparation phase.

Finally, if your manager is the type who is always discovering new software and constantly asking you to install "just one more thing," make sure she understands that servers are special; once you've started, you'll only install what you've agreed on and written down.

The Install

After you've agreed on the software to install, you'll naturally progress to the design phase. Will you install all of the software on one server or will you spread different services out among different servers? The answer will depend upon the company's security policy, the available hardware, and the budget available for acquiring additional hardware.

For each server, go out and buy yourself a binder. You'll need thorough documentation that you create as you go along. I can hear you groaning now — or at least thinking, "I'll write down what I did later when I have more time." You won't. Even if you do, you won't remember half the stuff you did, especially the stuff you did at 3 a.m. because something still wasn't working and the server needed to be live by 6 a.m.

Next, decide whether to install using a CD or the two floppies and an Internet connection. If the system is not behind a firewall, buy or burn yourself a CD. The Number One rule when installing any server operating system is NEVER expose it to the Internet until you have secured the OS and applications. This means it needs a firewall. It also means that you don't start creating rules on the firewall to let connections in to the server until you're satisfied the server is secure. (Instead, start with temporary firewall rules that only allow connections in from a specific testing system.)

When you reach the partitioning portion of the install, pause to consider the purpose of the server you're installing. The default partition sizes are usually fine for a desktop but rarely so for a server. For example, when I chose a for automatic on my 5.2.1 desktop system, I received:

256 MB		/
622 MB		swap
256 MB		/var
256 MB		/tmp
13261 MB	/usr

Every partition (except swap) received 256 MB with the balance of the disk going to /usr. This is totally out of whack for a server. If you start installing web, ftp, or mail servers, you want to log their activities. Logs go in /var where 256 MB of space won't cut it. Things are even worse on a mail server, with mail stored in /var/mail until the user picks it up. Depending upon the type of server, /usr may also need to be fairly big as this partition contains user directories and installed software.

Unless experience has taught you otherwise, a safer assumption is to keep /, swap, and /tmp as-is and divvy up the rest of your disk space between /usr and /var. I usually press a for automatic, then d to delete /usr and /var. I can then use c to create more reasonable sizes. Ideally, I like to use two hard disks where /usr is the rest of disk 1 and /var takes over disk 2.

The other thing to keep in the back of your mind is inodes, those entries the file system uses to keep track of your files. You have a limited number of inodes. If you run out, you can't create any more files on your file system unless you delete files or repartition. Running out of inodes usually isn't an issue unless your partition will store a huge amount of very small files. The periodic script /etc/periodic/daily/400.status-disks emails root each night with the output from the df (disk free) command. After the installation, edit that script to add the -hi switch after df. This will change the output to human-readable with inode information. That way you can monitor both disk and inode usage on a daily basis.

Finally, the installer will ask you what to install. For servers, I fall into the "install the bare necessities then add what you need" group of folks as I find it easier than "installing more than you need than taking out what you don't." To me this means no docs, manpages, or games as I always have an Internet-attached system nearby should I need to look something up or take a break. I do, however, choose src so I can recompile the kernel and rebuild the world. (Yes, you'll be recompiling the kernel to optimize it for the needs of a server.)

I also believe that XFree86 does not belong on a server. Servers should be lean, mean, performance machines without the prettiness, bloat, or security implications provided by a GUI. If other admins or technical support staff will administer the server, I'll instead install /usr/ports/sysutils/webmin and /usr/ports/sysutils/usermin. These applications have configuration options to allow each support staff to access only the services they need to administer, with the added bonus of providing a GUI interface they can access from the comfort of their web browser.

You will most likely be installing software on the server and will want to keep that software up-to-date. While I'm probably the biggest fan of the ports collection out there, I don't install it on my servers as I can make better use of the 500 MB or so of /usr real estate needed to maintain it. This means I also won't use portupgrade to keep up-to-date; instead I'll demonstrate how to use porteasy to make a leaner equivalent.

Pages: 1, 2

Next Pagearrow

Sponsored by: