The Cutover

Babbage.cs.qc.cuny.edu has been running on Sparc/Solaris machines since about 1990. (It’s been a web server since 1997.) In February 2008, I installed a MacPro/Leopard server in my office to replace the current Sparc/Solaris machine. It's taken only a year for me to become comfortable enough with the new machine to actually do the cutover: as of now babbage runs on the MacPro. Many of the posts here so far had to do with getting ready for the change. Herewith some more details/reminders.

Background

I use Babbage to support my courses at Queens College (New York), and have few requirements: deliver web pages with student assignments, support development projects related to my courses, act as my email server. As a member of the Academic Senate’s Nominating and Technology/Library ommitteee, I've also developed a pair of application forms for people at the college who want to serve on college committees. Those forms generated email messages that were processed by hand. When the college's web site became too difficult to deal with, I made these forms redirect to babbage where I could manage them more easily.

Last summer someone started abusing the application forms (hard to do, since there’s not much to them) in order to get out the word about their disreputable web site. For the Nominating Committee form it was not really an issue: the email goes only to me and the Senate’s secretary, they were infrequent, and the secretary and I simply ignored them when they came in. But the Technology/Library committee email went to a mailing list, and some of the recipients are the adminstrators of the college. The upshot was two-fold: I changed the Technology/Library committee emails so they don’ go to the distribution list, and the college started supporting work to require people to log into the system using their college credentials in order to submit application forms. A byproduct was that the college created a new domain name, senate.qc.cuny.edu, that is an alias for babbage. The point being that poor little babbage now had to handle virtual domains. (The spammer, meantime, seems to have gotten tired of typing “asdff asdf go to my website asdf asdf” so the whole security thing is moot at this point.)

I took as a constraint that the system changes I made would be as consistent as possible with the standard Leopard server administration mechanisms. Note that I’m running OS X Server, not the plain vanilla version of OS X that I run on my MacBook. I have a lot to learn.

Issues

  • Email: I used pine, procmail, and spamassassin to manage my incoming email and email archives on Solaris; I needed to move all that as seamlessly as possible to OS X.
  • Web: I used Apache on Solaris; OS X comes with Apache pre-installed and with a nice administrative panel for configuring it. Should be easy, right?
  • Database: OS X comes with MySQL ready to go. Maybe it would be smart to go with the flow and convert my near-nil database expertise from PostgreSQL to MySQL. But I like PostgreSQL; started using it when it supported transactions but MySQL did not. See my previous entry on that for more info.

Alpine, procmail, spamassassin

This is a work in progress. I seem to be able to send/receive mail okay, but nothing is going into some of my procmail folders. But maybe it’s because the college’s spam filters (Barracuda, which is also spamassassin) are kicking in all of a sudden. Stay tuned for further developments.

Web

I finally stumbled onto how to do this: both babbage.cs.qc.cuny.edu and senate.qc.cuny.edu are virtual hosts (configured in /etc/apache2/sites/. Most of the configuration options have to be taken out of /etc/apache2/httpd.conf. In the Server Administration’s Web panel, this corresponds to selecting (checkboxes) the two virtual hosts and deselecting the third “host” identified only as '*'.

I use digest authentication for controlling access to certain parts of the web site: the archives of past exams, etc. Copying the file containing the realm and password information directly from the Solaris machine to OS X worked fine. I put it in /Library/WebServer/. The htpasswd command for updating this file is in /usr/sbin/ on OS X. I have not tried it yet.

I use awstats for gathering statistics on the server. On Solaris, I used a script called /usr/local/bin/logrotate to archive my access and error logs, and to update the awstats statistics from a cron job. Well, OS X has “simplified” so it is based on launchd. That is, it’s a bother. I copied and tweaked logrotate from Solaris to the same place (/usr/local/bin/ on the new machine, and then made a link from it to /etc/daily.local, which (if it exists) gets run from /etc/periodic/daily/500.daily. But it just seemed easier to use a cron job for my personal periodic jobs for running sa-learn.