Apple promotes Mac OS X Server as its solution for data centers. However, "vanilla" Mac OS X performs quite adequately for small (e.g., SOHO) servers. This article discusses the server transition we made at cfcl.com from a FreeBSD-based PC to an OSX-based Mac mini.
We've been running a Unix-based server since the early 80's, when we installed a brand-new Sun workstation (serial number 285). About a decade later, we shifted to FreeBSD. (We wanted to stay with a BSD system rather than move to Solaris, which was based on UNIX System V.)
Initially, some modems allowed us to "network" via UUCP and offer dial-in access to friends who were located nearby. In the early 90's, the company became one of the initial members of an early "toaster net" known as The Little Garden. This put us on the Net, but the services we offered were minimal: FTP, SMTP, and Telnet.
Still, it gave our local friends a way to log in, send and receive email, and share files. As time went on, we abandoned the modems. We upgraded to broadband, added a web server, and installed POP3 mail services. We continued to support a few dozen friends and family members in a totally noncommercial fashion. As more time passed, our server OS began to get a little ragged around the edges.
FreeBSD is a stable and well-designed system, but we have never found it to be an easy system to keep "current." The prevailing assumption is that you'll maintain a current copy of the source code archives, doing regular builds (and watching for security alerts!).
This requires more attention than we were willing to give, so we resorted to (very) infrequent "binary installs." Unfortunately, this is not an optimal solution. Infrequent upgrades result in long periods when bugs and security holes can fester. Each system upgrade became a major hassle involving days of earnest preparation followed by more days of frantic bug-fixing and recompiling.
Consequently, when our FreeBSD 4.7 system started showing signs of imminent hardware failure, we considered our options with trepidation. To make matters worse, none of the currently available FreeBSD versions seemed very attractive:
Several years earlier, we had discussed the possibility of migrating our server to Mac OS X, "some day". Now, faced by a necessary system upgrade, we started wondering in earnest how much work it would take to turn Mac OS X into a "server" OS.
If we could do this, our maintenance problems would be vastly reduced. In several years of running Mac OS X, we've never had a real problem with Software Update. In addition, migrating our server would remove the only production machine on our network that wasn't running Mac OS X.
Although Apple recommends Mac OS X Server as the preferred answer for running "server" machines, it wasn't an appealing option for us. The most obvious reason was cost: a single OSXS license costs more than twice as much as a (five-unit) OSX Family Pack. The additional cost of keeping OSXS up to date would average out to a few hundred dollars per year.
Another, more subtle reason was compatibility. When we tried out OSXS a few years ago, we were distressed to find that its administrative interface had a number of (seemingly gratuitous) differences. New tools were needed for the same tasks, important nomenclature (e.g., volume naming) varied, etc.
As the saying goes: better isn't always better, but better is always different. It's possible that these incompatibilities have been resolved in the past few years, but we had no compelling reason to find out.
Although there isn't room here to go into much detail, it may be worthwhile to paint a broad picture of what plans we made and how the migration actually went.
To extend the "service life" of the migration, we chose to go with an Intel-based Mac. The top-end Mac mini had enough RAM, speed, and internal disk space to handle our expected needs for several years. And, should a hardware upgrade become necessary, moving the server to another Intel-based Mac should be easy.
We already had a 500 GB FireWire disk drive, so we had plenty of room for user files, etc. However, we found a small gotcha with this strategy: By default, OSX doesn't mount FireWire drives until fairly late in the boot sequence. Until we figured this out, we had assorted problems with "missing" files and directories.
Given that the Mac mini uses laptop components, it may not seem like an ideal choice for applications that have strict uptime requirements. However, several firms offer co-location services that are based on Mac minis, so this problem may be more apparent than real.
In any case, our services are free, so our users will tolerate some downtime if we lose a drive or other critical component. Meanwhile, we take normal precautions: running the mini on a UPS, performing regular backups, etc.
Although we knew that Mac OS X is a fairly complete BSD system (modulo the fact that the "games" are missing), we weren't sure how many packages we would need to locate and install in order to match our current environment.
We knew that Mac OS X includes the Apache (HTTP) server; we were delighted to discover that most Apache modules are built and ready to "turn on." We were also pleased to learn that Mac OS X also includes ready-to-run copies of other well-regarded server applications:
That said, this was not a trivial upgrade. We needed to install (or upgrade) and configure several other packages (Berkeley DB, MediaWiki, Movable Type, MySQL, Perl, Procmail, Ruby on Rails, SpamAssassin, TWiki, and more), but we weren't too concerned by this. Besides, it gave us an opportunity to bring our versions up to date.
Like many small sites, we have needed to support a number of machines on a single IP address. So, we had a NAT-based router, but it was a mass-market product with sharply limited capabilities. To support the migration, we needed something a bit more serious.
Based on some expert advice, we upgraded to a Linksys RV042 router. This unit has a second WAN port, which can also be configured to provide a second, "DMZ" LAN. It can also do port forwarding to multiple machines and perform a number of other nifty tricks.
The enhanced port forwarding let us move (and test) individual services one at a time, eliminating the need for an "all or nothing" move. The dual-WAN capability helped us migrate smoothly to a new ISP. (We could respond to both IP addresses, so there was no loss of connectivity due to DNS changes.)
Name service (BIND) configuration was complicated by the fact that we act as our own DNS primary server, support several DNS domains, and use NAT on our LAN. As a result, we run "split DNS," providing different information (on each domain) for the LAN (us) and the WAN (everyone else).
To ease the maintenance burden, we use a shell script to generate the configuration files. Some simple naming conventions allow us to keep track of the files. For example, generated files live in
/var/named/[lw]an_1. Similarly, our
named.conf equivalents are named
The normal OSX techniques for handling user accounts aren't really meant to handle dozens of users. Nor do they understand that you might want to have users who only access the machine via POP3. (Why provide shell accounts to folks who will never use them?) Fortunately, NetInfo Manager is quite willing to configure/reconfigure these sorts of accounts.
To provide a bit of "security through obscurity," we gave our shell users different "Short Names" than their email addresses imply. We also added distinctive prefixes (e.g., Xp, Xs) to the "Full Names" of external users. This causes those names to sort to the end of assorted display lists, with the added feature of identifying account types.
We had gotten reasonably used to administering Sendmail, but we never grew all that fond of it. Even with the aid of
m4(1) macros, the configuration was too baroque for comfort. So, we were quite willing to give Postfix a try. Besides, it was already installed!
Although there was certainly a learning curve, we found that Postfix does everything we need, uses entirely comprehensible control files, has quite comprehensible documentation, and provides excellent (if somewhat voluminous) logging. In addition, the modular design of Postfix allows us to track its activities very closely.
When we first configured Postfix, we were rather appalled by the volume of its logfiles and the impact it had on the mini's interactive performance. However, some logfile analysis revealed that 99 percent of the log messages (and most of the activity) was generated by email to invalid recipients (nonexistent addresses).
Fortunately, these messages can be filtered out by a properly configured "front end" server. So, we set up a spare machine (B&W Power Mac G3) to perform the function of "email toaster." Its logs are huge, but we don't care, and the mini can easily deal with the remaining 1 percent of the influx.
We did, however, need to work around a bug in
lookupd(8). Apparently, our intensive use of Postfix exercises a memory leak. So, once an hour, a
cron(8) job does a
killall -HUP lookupd. This keeps the daemon from periodically paralyzing the system.
Finally, Postfix made it easy for us to install Procmail and SpamAssassin support for all email accounts. This lets us filter out the majority of spam before our users ever see it, although we retain all filtered spam for a week as a safety net for our users. This "spam dump" also provides a handy source of debugging and tuning information.
As previously discussed, Mac OS X comes with a complete Apache implementation, but it is initially configured to support the fairly simple "Personal Web Sharing." After fiddling a bit with file locations and configuration settings, however, we were able to get all of our old web pages working. The big win here is that most of the major Apache extensions (e.g., mod_Perl, php4) are already installed; just turn on the appropriate configuration variables and restart web services.
The migration took us a month, working evenings and weekends around other projects (such as our "real" jobs). There was some cleanup necessary after that, in large part due to configuration bobbles and over-zealous spam filtering.
Still, we're quite pleased with the results. Most of the mistakes we made were due to our own misunderstandings while climbing several new learning curves. The system itself, as well as the WWW, provided plenty of hints, clues, and assistance. The pain level wasn't much more than a FreeBSD upgrade would have caused and our next system upgrade should be very easy.
We couldn't have done this three years ago, when we first started to discuss the idea. We didn't know enough about Mac OS X and it hadn't reached its current level of maturity. Besides, giving up on FreeBSD wasn't an easy choice.
Looking back, however, we're convinced we made the right decision. The mini is running smoothly. The front-end email toaster has experienced a few hiccups, but we've been tuning it. And, finally, it's extremely satisfying to have consistency among all of the machines on the local net.
Apple tends to incorporate mature, popular, and well-supported Open Source software in its releases. We tend to look for these attributes as well. Consequently, there is seldom any shortage of online documentation, mailing lists, etc.
In many cases, there are books as well. Here are some books we found useful in our migration:
Rich Morin, Vicki Brown are long-time users of both Mac OS and Unix. For obvious reasons, they find Mac OS X to be totally delightful.
Return to MacDevCenter.com.
Copyright © 2009 O'Reilly Media, Inc.