Installing FreeBSD as a Web Server - 1/6/2002

• Selecting FreeBSD
• Ten Disk FreeBSD Power Pak
• Using an Old Pentium 133
• Partitioning Choices
• The Install
• Apache SSL Disappointment
• Performance Comparisons

As a quick review, my original plan (late 1999) called for mirrored Windows NT, Red Hat Linux, Solaris, and OpenBSD web servers, set up on identical hardware. When I couldn't get Solaris to recognize the network card and needed a test machine, Solaris was dropped from the mix. From the spring of 2000 until late August 2001, I did run mirrored Linux, OpenBSD and Windows NT web servers. By then I'd decided not to continue with the Microsoft Windows line. When bad memory triggered an NT crash and server self-destruct, I decided it was time to drop the NT server.

Since then, I've considered alternatives, including if there was any point in keeping a third mirror. I've thought about trying the SuSE, Mandrake, and Debian, Linux distributions. SuSE may be regarded as the most comprehensive professional competitor to Red Hat, Mandrake the ease of use leader among the large distributions and Debian the purist's minimal system for advanced users. In some ways though, I've come to regard Linux's relation to open source software much as I see Microsoft and Windows in relation to proprietary software. It's much more widely known, has more applications and is easier to learn but has few technical advantages over the competition. The competition is mainly the BSD family of Unix like systems, primarily FreeBSD, NetBSD, and OpenBSD. Though getting something new to work the first time is sometimes much harder on OpenBSD, I prefer just about everything else I know about OpenBSD to Linux.

When I made my first four server selections each of the products I included was in some way a leader. In various ways Microsoft was the leading software company and NT servers were increasingly dominating the server market in small to medium size companies. Sun was the leading Internet UNIX company and Solaris a major NT competitor or perhaps more accurately, NT was eating into what had been areas dominated by Sun and Solaris. Solaris was also available for media costs only, making it much more attractive for my purposes than its commercial competitors. Linux and in particular the Red Hat distribution was the leading open source system. OpenBSD was widely acknowledged as the leading OS for security purposes.

I considered leaders in various areas but didn't look at systems that might represent an optimal compromise of different features. Over the past two years, as I learned more about OpenBSD, I also often learned about FreeBSD, at least vicariously. On most comparisons that ranked Linux, FreeBSD, and OpenBSD, FreeBSD would likely fall somewhere between the Linux and OpenBSD.

As I learned more, it seemed increasingly like this between meant much closer to Linux in terms of application availability and ease of setup and much closer to OpenBSD in terms of system organization and cohesiveness as well as security. In other words, while FreeBSD might not be a leader in any specific category, it was never very far behind the leader in each important category. FreeBSD was increasingly looking like a contender for the best all around OS where Mandrake and SuSE looked increasingly like simply alternatives to Red Hat without any fundamentally important differences. Debian looked like a less extreme version of the security oriented Linux distributions, Trustix and EnGarded, that I've already tried.

Several weeks ago I bought I bought a FreeBSD 4.4 "Power Pak" including four install CDs and six extra "Toolkit" CD's with "5800 additional third party applications". FreeBSD seems to take a rather unusual approach to CD layout compared to other systems I've worked with. It appears that the four install CD's aren't four parts of one install but each is a complete install CD in its own right and all that differentiates one from the other is the mixture of supplementary packages included on the disk. Disk 1 appears to have the really common add-ons like Apache and mod_perl. Perl and the GNU development tools appear to be part of the base system and automatically installed even when the "Minimal", smallest possible install is selected. Network Time Protocol (NTP) as ntpd and related utilities, is also included in the base, install which I think is smart, as it is the one piece of software I add to every system I own.

Disk 2 includes a rescue mode that lets you run a single user system from the CD and demonstration versions of commercial products that run on FreeBSD. These are at least license limited if not time or function limited versions. Disk 3 includes a wide variety of common software. Each disk has categories of packages. All include the obvious choices such as Databases, Editors, Shells, Www and X11 as well as less obvious, Astro, Cad, Misc, Perl5, and Security; several other categories appear on all disks. Some categories such as various language specific versions and more specialized application areas (Zope) appear only on selected disks. Disk 3 was especially heavy on Web applications. It appears that Disks 1, 3 and 4 are organized to include the most widely used packages with the most common applications on the lowest numbered disks. Each disk apparently includes all the libraries or language products that are necessary to run applications included on the disk. Any application you select to install will automatically install all required packages necessary to actually use the applications, without CD swapping. At least so far, I have yet to find one that doesn't run.

Disk swapping is not required to complete the install of any package selected on a CD. Quite a bit of CD swapping is required to find specific applications. I have yet to find anywhere on the CDs, any comprehensive list of applications and on which CD, the packages for specific applications are located. This is especially troublesome with the 6 Toolkit CDs. There appears to be no way to find what's on the disks without very laboriously putting each disk in the drive and using sysinstall to review the category lists which always include an "All" category that lists each package on the disk alphabetically.

The http://www.FreeBSD.org web site is in contrast, a model of clarity and organization. The main links on the home page include a "Software" section with a link to Ported Applications This page includes a search function to search for a specific application as well as more than 6400 products listed in over 70 application or function categories. Where a product naturally appears in more than one category, it's listed in each applicable category. The package name is listed with a one line description, and links to a long description, package binaries, source, home web page, all packages on which the package depends, and an e-mail address of a maintainer.

The web site package list is so well done, it largely eliminates the need to buy CD ROMs except as a means of supporting the FreeBSD project. Under the "Documentation Section" there is a link to a Handbook which is a large tutorial on using FreeBSD with numerous links to the appropriate online man page. The Handbook is also available in a printed version. There is a large FAQ section and even a link For Newbies.

The most interesting thing I found about the install disks, is that Disk 1 and 3 included every application that I've tracked down and installed on any of my web servers. Besides including several versions of Apache without SSL and with SSL as well as additional combinations of options, the Swish-e web search product that I chose and the Analog web log analysis tool were on Disk 3. Even Nmap which I use from time to time is on the basic install disks as well as Dig which was the other web search tool I carefully considered after narrowing the field and Weballizer, another web log analysis tool that I want to evaluate. It seems that whoever put the install disks together either used popularity or best of breed as the basis for including software on the install disks. If the price is free, as is generally true of open source software, there is at least some reason to assume that popularity will have a high positive correlation with quality, i.e., the software that best meets the widest number of user's needs is likely to be most used when not constrained by high license fees.

For the FreeBSD web server I made a very different install choice from the other servers. Instead of installing FreeBSD on a server that matches the other servers (P3 500Mhz, 256MB, 13+GB 7200 RPM EIDE drives) I put it on the oldest PC I still have, a P 133 with 128MB ram and 1.6GB IDE disk. I made this choice for multiple reasons. It's clear that the least used machine I have is the OpenBSD mirror. This machine serves a handful to a couple hundred web pages a day, depending on how many visitors to the main site (Linux) choose to look at the mirror, and otherwise sits idle except for routine cron jobs. The P3 500s are obsolete in the sense that machines this slow are generally not available as new machines anymore. Today, as server hardware many would consider them a joke, but they are overkill for the way I've been using them. By selecting the really old P 133, I wanted to show that with the right operating systems, which means any of FreeBSD, Linux, or OpenBSD, otherwise obsolete hardware still has useful life.

There was another reason for using the P 133. It has an Exabyte 8mm DAT SCSI tape drive which was is good condition but never used because it was never connected to the network. I'm very reluctant to try to move this. The P 133 case hasn't been opened in about 5 years. The last time I started moving boards around in an old PC (about '94), resulting failures or incompatibilities resulted in replacing every component inside the case except the power supply, before I had a working PC again. The old Adaptec SCSI board may work in the newer PCs I have but I don't intend to find out. If I did successfully move it, it would create another difference between machines I'm trying to keep similar.

The first two install attempts I made on the P 133 were FreeBSD 4.3 and OpenBSD 3.0 from downloaded images. The CD-ROM drive seemed unable to read these CD-R disks. An install from the purchased OpenBSD 3.0 disks worked fine and as soon as I verified everything was successful, I did a FreeBSD 4.4 install, with the purchased disks over the OpenBSD install. For the first time in a long time I really had to think about disk partitioning. While the 1.6GB drive is more than adequate for a FreeBSD install, it obviously doesn't have room for multi gigabyte /tmp and /var partitions.

I decided up front to do two installs, using the first to get an accurate picture of how much space FreeBSD would likely use for the components I expected to install. When I got to the disk partitioning section, I let it do a default partitioning but did not like the result. This gave 100MB to / and 260MB to swap which looked OK but only 20MB to /var and all the rest to /usr, which makes no sense to me. It was very easy to delete these partitions and add a new usr with 600MB and leave the rest (666MB) to /var. The install put 35MB in / and 182MB in /usr. I started with a "Minimal" install which is described as "The smallest configuration possible". I added Apache in both standard and SSL configurations, several web related packages and included Linux compatibility.

The second install was partitioned as follows:

I thought this would leave plenty of room for growth of both the web site and additional software if the need arose. Var would be large enough to hold lots of logs and online differential backups. For full backups, I expect to use the tape drive, or do network backups to a machine with more disk capacity.

Following the minimum install, FreeBSD had placed just under 30MB in / and about 78MB in /usr for a about a 110MB minimum install. This did include ftpd, telnetd, the rpc and yp programs, the GNU development tools, Perl 5.005. It did not include man pages. Like OpenBSD and unlike Linux (at least Red Hat), FreeBSD has a base install that does not consist of discrete packages. The components in the base install are not listed by pkg_info.

When I finished adding the packages I wanted, /usr had almost 123MB and the total install was about 153MB. / was at 34% and /usr at 33% leaving more than enough room for growth. /home and /var were 0%. I'd added the man pages, Apache with SSL and mod_perl. Also included were Swish-e, Analog, Checkbot and several other web utilities I thought I'd actually use or at least wanted to try. I'd dropped Linux compatibility and some other web utilities that did not expect to use.

Almost immediately, it became apparent that I'd misjudged on /home. I should have made this 100MB. Though the web site is only 20MB, I forgot how quickly a few runs of the site standardization / maintenance script could inflate the size of the site. Repeatedly erasing the automated backups defeats their purpose and creates a maintenance chore.

Generally the FreeBSD install was smooth and well thought out. In some ways it's roughly comparable to a text mode Red Hat install. The basic configuration choices are to install everything, the minumum install I used, a user install, an X-User install, a Kern-Developer (kernel source only), an X-Devloper (X only source), an X-Kern-Developer (X and kernel source) and a Developer (full source) install. All the developer modes include full binaries and documentation except games. There is no server mode as the base install appears to include all the "standard" Unix daemons but not the more specialized ones such as HTTP, WU-FTP. There is a Custom install mode where you can manually select all optional components to be installed but these are distinct from the installation of packages which are not regarded as part of FreeBSD per se.

There are some nice touches missing in the other installs. There are several useful networking related choices, including explicit options related to DHCP, NFS client and server, IPv6, the inetd initiated utilities, and a default security level. The medium security level (default) starts sshd and sendmail in a configuration that will accept connections from any remote host. The install suggests turning off sendmail if external mail is not needed. No other services are started by default with the medium security level unless you asked for them in one of the explicit options. If you choose to install Apache or one of several web servers, the startup scripts are adjusted to start httpd on reboot. Root can rerun the install or any part of it at any time by running /stand/sysinstall. "# /stand/sysinstall configPackages" starts the install so that any packages on the current CD ROM can be selected and installed.

There are also some rough areas in the install. The kernel configuration is certainly not a model of clarity. A back option is not available. Pressing [Ctrl+Alt+Delete] or [Ctrl+C] at any time brings up a dialog that lets you abort the install, restart the install (losing all choices made) and continuing from where you were. At times the use of "OK" and "Cancel" are confusing as there are points where you can only continue by canceling; OK takes you in a loop through what you just finished.

Installing the missing man pages seemed somewhat difficult on the second install. To get these, I had to run /stand/sysinstall and select a Custom install, then select Distributions to extract, then select Custom ("Specify your own distribution set"), mark the man pages for install, and then install them. There is a question, following the configuration selection and install, defaulted to "No" that will let you install the man pages or other components after doing any of the standard installs. You need to change the default response and the question is not very clear but if you change the response to "yes", you can install additional components without restarting the install.

There was one thing I did not like about the Standard Install which leads you step by step through each necessary process. At the completion of the install you are returned to the opening install menu with the Standard Install highlighted. If you press Enter instead of moving the highlight to "Exit Install", you are dropped back into the disk selection and partioning steps. Fortunately a [Ctrl+C] brings up choices that let you exit or return to the main menu. Returning to the main menu makes sense in the Custom install where it may be necessary, but the Standard install should either default to having "Exit Install" selected if you return to the menu or simply exiting and rebooting as all necessary steps have already been done.

One thing that very much surprised me after the install was that mounting a CD seems to require mount_cd9660 rather than a simple mount command figuring out the file system type. Both Linux and OpenBSD accept a simple mount command and when the device is a CDROM, issue the right command necessary to mount a CDROM type file system.

In late November 2001, I replaced my Red Hat 6.2 Linux web server with a Red Hat 7.2 server. This came with an Apache that included SSL. When Apache was selected, you were led through the SSL setup steps, and the included Apache configuration file started SSL. Getting SSL to work on my main site, which is in different directory location than the default document root, was a straight forward, if somewhat time consuming matter of comparing httpd.conf files, and merging the new SSL related Options into my custom configuration file, with different document root and virtual site directory locations.

The FreeBSD 4.4 ports tree includes a couple of versions of Apache with SSL support enabled. I selected the most basic Apache with SSL and without some addition features I'm not familiar with. Unfortunately, it seems that various related FreeBSD packages do not interact gracefully with each other. I wanted to install mod_perl which is on the Install Disk 1. When I selected that package, it added the basic Apache package as a required package on which it depends. I could find no way to prevent the installer from adding Apache when I installed mod_perl. I decided not to install mod_perl at that time but to come back to it after installing an SSL version of Apache assuming, incorrectly, that it would recognize the installed Apache.

After installing the SSL version of Apache, which turns out to be 1.3.12 instead of the more current 1.3.20 on which the basic Apache package is based, I returned to mod_perl. It did not recognize the installed Apache and again marked the basic Apache package as a dependence. I went ahead and installed mod_perl, which reloaded the basic Apache overwriting all of the Apache with SSL components that had the same name. The core component, httpsd, which has a different name than the standard httpd was left but other components needed for SSL were replaced.

After loading an up-to-date mirror of my web site, I merged the customizations of in the Linux httpd.conf file with the completely different directory locations used on FreeBSD. I could start httpd but not httpsd. After fixing a couple errors that appeared when httpsd but not httpd started, I was able to start httpsd but despite the absence of startup error messages all was not well. When httpsd stopped it left 16 error messages in the error log file indicating that most modules could not be removed because they were not found in the module list. Once I realized that most of the components installed with httpsd had been overwritten, it was clear that the httpsd executable daemon was not fully compatible with the other Apache components installed with the basic Apache install. The SSL keys were not created, and SSL was not working, even though basic web pages were being served by httpsd.

I decided to re-install Apache with SSL to see if SSL would work. The install program would not let me install it because it thought it was installed so I had to run pkg_delete first. After Apache with SSL appeared to install, I tried starting it with the customized httpd.conf file I'd been using, which was not replaced in the install. The results were the same as before; startup looked OK but there was no SSL and many error messages on exiting. I saw an httpsd.conf.default file, which I may have missed before and copied it over httpd.conf. The server did not start because of "Required SSLCacheServerPort missing". There were no sample lines in the provided httpd.conf for this. I then quit trying to get SSL to work.

Since the basic Apache install had been partly overwritten by the SSL version, I needed to reinstall the basic Apache package but that was not straight forward. The system still thought it was installed. When I tried pkg_delete on it, I was informed that mod_perl was installed and depended on that. I ran pkg_delete on mod_perl but one file was missing. As a result, the pkg_delete failed. Though mod_perl was almost completely removed and Apache was in pieces, pkg_info reported both as installed. I renamed the matching subdirectories of /var/db/pkg. Pkg_info reported the renamed packages as installed, i.e. pkg_info sees any subdirectory in /var/db/pkg as the name of an installed package. I then installed both Apache and mod_perl. The installer said both were installed successfully. After verifying that httpd was starting and stopping cleanly and serving web pages, I returned to /var/db/pkg and deleted the renamed directories.

It's clear that FreeBSD's package management system is no more robust than any of the others which includes all the Linux and OpenBSD package managers as well as Windows install/uninstall programs. All seem highly vulnerable to other products stepping on existing installs as well as manual file and directory changes creating various situations the installers can't handle.

My inability to install Apache with SSL is a pretty serious disappointment. The primary attraction of FreeBSD compared to OpenBSD is it's large ports list. I'd assumed, or at least hoped, that getting new applications (from the ports list) to work on FreeBSD would be much more like the generally easy to use Linux packages than the often tricky OpenBSD installs. While a couple applications so far (Perl scripts) have installed and run right away, the first significant application that typically requires more than trivial configuration, Apache with SSL, has consumed considerable time and not worked. It's also clear there is no way to install mod_perl and SSL from the install CDs, without deliberately overwriting one Apache version with another. It's not clear there is any way to get these modules to work together using ports available on the distribution CDs.

A check of the on-line FreeBSD ports lists includes almost current versions of Apache (1.3.20) with SSL and some of the other major modules. After reviewing the on-line ports list there really appears to be almost no reason to purchase the packaged CD sets as newer software can be located and installed more easily via FTP than via CD. The only reason for purchasing the packaged software that I can think of is to support the FreeBSD project and contributions may not be tax deductible where purchased software should be.

While Red Hat has created Apache with all the important (SSL, PHP, MySQL, mod_perl, etc.) modules dynamically linked, so that you can load any combination that you might need by adjusting the httpd.conf file only, so far, the BSD Apache ports appear to be statically linked versions with different combinations of modules that may or may not meet the needs of any specific site. I decided the only way to get control of Apache on FreeBSD and OpenBSD is to build it from source with the desired modules included. After I've tried Swish-e and Analog, I'll have a much clearer idea of how the systems compare. If these are as much trouble as SSL has been, I may conclude that FreeBSD lacks any meaningful advantage over OpenBSD.

After FreeBSD was installed and set up as a fully functional mirror of the Linux and OpenBSD sites, I did some very crude performance comparisons. I doubt that any site visitors will be able to detect any performance differences retrieving static pages, between the FreeBSD machine and the Linux or OpenBSD machines which are about 4 times faster by any measure. On static page retrieval, this ancient (1994) P 133, should serve more pages than my SDSL line can handle. Some very preliminary tests suggest the old FreeBSD machine may actually outperform the new Linux and OpenBSD machines on some static page performance measures.

On CGI pages the differences become apparent. Here the Linux machine is fastest and FreeBSD the slowest with OpenBSD falling between. Please don't try to generalize from these comparisons; they are not equal. At present the OpenBSD machine is 2.8 which is almost 15 months old and has half the RAM of the Linux machine. The Linux machine is the current Red Hat release, 7.2 and has Apache 1.3.20 versus 1.3.12 on OpenBSD. The Apache builds and configurations are different. In addition to these significant differences, Red Hat may be much more optimized for Apache than OpenBSD. In varying situations, I've seen both OpenBSD and Linux significantly outperform the other. Though FreeBSD is on by far the slowest hardware, it's also the current release at 4.4. Linux and OpenBSD are using Perl 5.6.0 where FreeBSD has Perl 5.005_03 which is older but could be faster (or slower). On FreeBSD, Apache is 1.3.22 and has been statically linked without a number of modules normally included, which should be faster.

Despite the largely indistinguishable static page performance (at least at low loads) the hardware and many installation differences result in CGI performance that is noticeably different between all three machines. At present, all CGI on all systems is traditional, with the full Perl executable loaded, and the script interpreted from scratch for each CGI request. After the Perl load and script interpretation are allowed for, password.pl is mostly CPU intensive. With default settings Linux is noticeably faster than FreeBSD but both are hard to measure as they are sub second. If the password count is increased to the maximum, 1000, Linux slows to about a second, but the slower hardware FreeBSD is on, pushes it to about 5 seconds.

Password Evaluator can be both CPU and disk intensive. Particularly when a password contains multiple dictionary words there is a lot of disk activity against a 16MB DBM dictionary. On all systems, if it hasn't been used for some time, it's noticeably slower, taking two or more times as long as subsequent checks. I botched timing the first Linux evaluation but it was under 5 seconds and well over twenty seconds on FreeBSD. Subsequent passwords with two dictionary words take about a second on Linux and about 10 seconds on FreeBSD. Good passwords come back too fast to measure on Linux but take 2 to 3 seconds on FreeBSD. All OpenBSD times fall between Linux and FreeBSD, typically about mid way between but there is no perceptible difference on fast processes like 10 generated password runs.

The point of these comparisons is not to distinguish between FreeBSD, Linux, or OpenBSD, but to suggest that in properly selected circumstances, any of them may make effective use of old and otherwise obsolete hardware, but the use of such hardware needs to be carefully matched to the task. Modestly active, static web sites, with little or no CGI is a good use for old hardware but a dynamic PHP site, heavily dependent on a moderate to large MySQL database, would be a poor choice, even for development. Other suitable uses might include a lightly used FTP server, a dedicated DHCP server, or a firewall on a connection slower than a T1. Reliability considerations may make old hardware inappropriate, even where it provides adequate performance.

I haven't done any benchmarking since early 2000. If I wanted to, the production web servers would not be suitable as light but unpredictable loads would negate the validity of any tests performed. Setting up the FreeBSD web server on an older and slower machine is the beginning of migrating all publicly visible servers to my slower machines. This will free 4 identical P3 500 machines that have been used as web servers for use as pure test and development systems, and allow useful benchmarking.

Top of Page - Site Map

Copyright © 2000 - 2014 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth in http://GeodSoft.com/terms.htm (or http://GeodSoft.com/cgi-bin/terms.pl). These terms are subject to change. Distribution is subject to the current terms, or at the choice of the distributor, those in an earlier, digitally signed electronic copy of http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) from the time of the distribution. Distribution of substantively modified versions of GeodSoft content is prohibited without the explicit written permission of George Shaffer. Distribution of the work or derivatives of the work, in whole or in part, for commercial purposes is prohibited unless prior written permission is obtained from George Shaffer. Distribution in accordance with these terms, for unrestricted and uncompensated public access, non profit, or internal company use is allowed.