AddThis Social Bookmark Button

Listen Print Discuss

Building a Unix Server
Pages: 1, 2

Post-Install Configuration

When the installer finishes, follow through the post-install configuration menus. When it asks to create a user, make sure to create an account for yourself with a good password. Create an excellent password for the super-user account. When asked to view the ports collection, I say "yes" so I can install cvsup-without-gui and porteasy.

One of the first tasks I do after rebooting into the new system -- before I even begin installing the required server applications -- is to cvsup all of the changes to the operating system that have occurred since its release.

However, the very first thing I do once the install is complete is to grab my server binder. Up to this point I've taken only rough notes on my network settings and partition sizes. Even I have trouble deciphering my handwriting, so it's time to create some printable documentation. This is where scp (secure copy) comes in handy. I make sure to have sshd running on another system with a configured printer, then copy over my hardware information:

% scp /var/run/dmesg.boot dru@192.168.1.10:/usr/home/dru

The above command will access the SSH daemon running on 192.168.1.10, login as the user dru and copy /var/run/dmesg.boot from this system to dru's home directory on the other system. As you can see, scp works just like the cp command, but allows the source or destination file to be on another system.

I'll then send the output of my NIC settings:

% ifconfig > nic_settings && scp nic_settings dru@192.168.1.10:/usr/home/dru

Default gateway settings:

% netstat -rn > gateway && scp gateway dru@192.168.1.10:/usr/home/dru

DNS settings:

% scp /etc/resolv.conf dru@192.168.1.10:/usr/home/dru

And partition and swap settings:

% df -h > disk_usage && scp disk_usage dru@192.168.1.10:/usr/home/dru
% swapinfo > swap_usage && scp swap_usage dru@192.168.1.10:/usr/home/dru

From the system running sshd, I can now print the copied files and add them to my binder.

Securing the OS

Now it's time to start securing the system. First, I create a cvs-supfile:

more /root/cvs-supfile
*default host=cvsup.ca.freebsd.org
*default base=/usr/local/etc/cvsup
*default prefix=/usr
*default tag=RELENG_5_2_1_RELEASE
*default release=cvs delete use-rel-suffix compress
src-all

Choose a host= geographically close to you and make sure that the tag= matches your OS. (See the cvsup section of the FreeBSD Handbook for details.)

I'll then create the base directory and download the changed source:

# mkdir /usr/local/etc/cvsup
# cvsup -L 2 /root/cvs-supfile

While the download continues, I start my hardening routine. I covered many of the steps in Securing FreeBSD. I'll also create an SSH banner on the server and use the AllowUsers option to limit SSH access to myself and other authorized staff.

When the download finishes, it's time to rebuild the world and the generic kernel:

# cd /usr/src
# make buildworld
# make buildkernel KERNCONF=GENERIC
# make installkernel KERNCONF=GENERIC
# make installworld

After rebooting into the up-to-date OS, it's time to strip the kernel. I'll carefully review each line in /usr/src/sys/i386/conf/GENERIC to remove the hardware and options that aren't relevant to the server. I'll then read through NOTES (or LINT) to see if there are additional options that will increase the security or performance of the server. Avleen Vig's Tuning FreeBSD for different applications has some recommendations to get you started.

Next, I install and reboot into the new kernel, printing out a copy of the kernel configuration file with comments explaining why I added the options I did, for my server book. I then copy my kernel config file to another location such as /usr/local/etc. At this point, it's a design decision whether to remove /usr/src from the system. Removing it frees up about 400 MB of space; however, /usr/src is sometimes necessary to implement the solution to a security advisory.

Installing Software

Now that you have an up-to-date OS and an optimized kernel, it's time to start installing software. While using pkg_add -r to install pre-compiled binaries is quick and convenient, it isn't the best choice for a server. The same goes for installing a port without first reading its Makefile and combing through the installation instructions at the application's web site. Server applications come with make options which influence the application's behavior and performance. Be aware of these options before you compile the binary. This brings us back to the "99% preparation, 1% configuration" truism.

It also brings us back to your server documentation. As you install a service, carefully note the make options you used. For example, here are two entries from one of my server installs:

#installed from /usr/ports/www/apache2
#use "make show-options" to see available make options
#use "make show-modules" to see available modules
#use anon auth and disable SSI and autoindexing:
make -DWITHOUT_AUTH -DWITHOUT_MODULES="autoindex" \ 
-DWITHOUT_MODULES="include" install clean

#installed from /usr/ports/ftp/pure-ftpd
#install as stand-alone server with privilege separation
make -DWITH-PRIVSEP -DWITHOUT-INETD install clean

Knowing what options you used to compile the binary will greatly assist in troubleshooting future configuration issues. You'll also be able to repeat these options when you eventually upgrade the software.

How did I get those port directories to cd into when I didn't install the ports collection? This is where porteasy comes into play: it downloads just the ports skeletons you need. To do so, first set up your environment:

# setenv CVSROOT :pserver:anoncvs@anoncvs.at.FreeBSD.org/home/ncvs
# touch /root/.cvspass

Then, as you need a ports skeleton, tell porteasy what you want:

# porteasy -u www/apache2

That's it — all the convenience of the ports collection without maintaining the entire collection.

Keeping Software Up-to-Date

porteasy will also assist in keeping your software up-to-date. I create a script like this:

echo "Updating installed ports skeletons"
porteasy -uI

echo "The following ports need upgrading:"
porteasy -s |grep "<"

Note that this script will keep my ports skeleton up-to-date and inform me of out-of-date ports; however, it won't upgrade them for me. This is actually ideal for a server as you never want to upgrade applications blindly. Instead, carefully plan the upgrade, research any changes to the new version and their impact on your current configurations, and schedule the upgrade for a time that will least impact users on the off-chance that the upgrade results in an unforeseen glitch. Yes, I'm talking about more preparation. Most major server applications have an upgrade section to their documentation; all applications have an UPDATING or README that comes with the new version. Read them all.

A Final Word on Configuration

The actual configuration of an application will definitely depend on the application. Fortunately, most of the major server products provide excellent documentation at their web sites. If anything, a poor sysadmin might suffer from information overload!

If it's your first time plunging into a product, especially something as complicated as a web or mail server, take the time to skim through all of the documentation before you install anything. Much of it won't apply, but it will give you a good idea of what options you have and what the configuration will entail. You'll probably also find sections that you'll want to print out and add to your server binder until you're more familiar with the product.

I always print out a copy of the original configuration file(s) that come with an application and store it in my server binder. I find it convenient to pencil in the changes that I made with comments to myself reminding me why I did so. An alternate approach is to carefully comment your changes as you make them and to print out the final result. Either way, you do want a hard copy to refer to. (It goes without saying that you'll have at least one software backup copy of both the original and modified configuration files.)

Dru Lavigne is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.

Read more FreeBSD Basics columns.

Return to the BSD DevCenter.