A mini Mac Solution
Pages: 1, 2
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:
- Apache: The Definitive Guide (O'Reilly)
- DNS and BIND (O'Reilly)
- Hacking Movable Type (Wiley)
- Movable Type 3 Bible (Wiley)
- Postfix: The Definitive Guide (O'Reilly)
- The Book of Postfix (No Starch)
- Webmaster in a Nutshell (O'Reilly)
Return to MacDevCenter.com.