Back in late 2011 I wrote this scratchpad post to document my efforts to move from Snow Leopard Server to Lion Server. I ran into some configuration problems that stumped the 2nd-level folks at Apple and eventually I abandoned the project and stayed on Snow Leopard.
When Mountain Lion came out, and went through an update or two to iron the kinks out, I decided to have another go at it. I’m crossing my fingers here, but I’ve been on OSX Server (the new/old name under Mountain Lion) for about a month now and things look pretty stable. So here’s another scratchpad post to document what I did to put back a few things that were removed from the standard OSX Server environment.
Stability and Reliability
I found that the standard 4gByte memory that shipped with my server started to get very tight as I started turning on the various Python based services (Calendar, Contacts, Wiki, etc.). In fact, by the time I had all those services running, the machine would lock up and crash after being unreachable for a while. I upgraded the memory to 16 gBytes (not officially supported). Looking at this memory-use graph out of Server, you can see why the server was having trouble with 4 gBytes but it looks like 8 gBytes would work OK as well.
I know, real men are supposed to run their servers for decades without restarting them. But I’ve found that having the server reboot itself every night in the wee hours of the morning clears out a lot of memory-leak cruft and, combined with the added memory, has made the machine quite stable. System Preferences/Energy Saver/Schedule is the place to do that.
I hardly ever use it, but the idea of a completely-under-my-control VPN appeals to my tin-foil-hat privacy side. Setting it up is a little tricky and I found this guide to setting up VPN on a Mac Mini server that’s running Mountain Lion to be really helpful. I stepped through the process exactly as they described it and it worked. I love that.
Replace features that were removed
Replace firewall capability
The nifty firewall in Snow Leopard (IPFW) was replaced with the newer packet filter (PF) firewall in Mountain Lion. And all of the firewall-management features were removed from Server Manager. Most likely because the presumption is that these servers are running on a network that is already behind a firewall — and because these rascals are tricky and hard for Apple to support. But I needed to run the PF firewall on this machine. Doing that by hand is Too Hard, so here’s what I did.
- Consider using IceFloor, a PF front end — http://www.hanynet.com/icefloor/index.html
- Note: firewall logging gets turned on every time you reload the settings. Logging can be disabled (once you’ve got a stable set of rules) by editing the config file from the main rules tree.
Apple dropped MySQL from their distribution (licensing issues would be my guess). But all of the family web sites run WordPress on top of MySQL so I need to add that back. Here’s what I did:
- Downloads are here – http://dev.mysql.com/downloads/mysql/ (roll down to the DMG file — way easier install)
- Installation instructions are here – http://dev.mysql.com/doc/mysql-macosx-excerpt/5.5/en/macosx-installation.html
- Documentation is here – http://dev.mysql.com/doc/index.html (haven’t used it yet)
- PHP needs to be tweaked – https://support.apple.com/kb/HT4844 (I only did the “change-sockets to /tmp/mysql.sock” thingy)
- Installed Sequel Pro (http://www.sequelpro.com/) and tested the installation by creating and dropping a database.
- Used the System Preferences widget for MySQL to tell it to launch at startup
Webmail and email aliases
Webmail is in the “nice to have in travel emergencies” category. But the Roundcube webmail is also the best place I’ve found to replace some of the email-forwarding, email-exploder capabilities that went away in the transition from Snow Leopard to Mountain Lion. So I put it back. Conceptually, it’s an email client running on the server that can talk to the mail server just like any other client. It just happens to use the web as its user interface. Here are useful links to get you started.
- A useful step-by-step guide – http://diymacserver.com/mail/mountain-lion/install-roundcube-webmail/
- I had the devil’s own time getting authentication to work properly. In fact the only scheme that works for me is by allowing “Cleartext” as an authentication option in Server, and using LOGIN as the IMAP_AUTH setting in the RoundCube config file (main.inc.php). Here’s a thread that gives more detail around this, although the fix in that thread didn’t work for me — https://discussions.apple.com/thread/4424570?tstart=0
- Here’s how to add the “filters” capability (the most important part, for me). https://discussions.apple.com/thread/4153247?tstart=0 The only thing to keep an eye on is that the example changes are being made to the main.inc.php.DIST file rather than the main.inc.php file. I think this is just an error — but there may be super-cleverness going on there. In any event, I made the changes to the live main.inc.php file and it’s working. ymmv
- I had to do a lot of debugging on this one. The log/error files (in the /webmail directory where RoundCube is installed) are of great help in figuring out what’s going on.
Once Roundcube is running, and supporting filters you can…
Replace “group” emails (in other words, create multi-recipient email aliases)
Here are the steps I would go through to create an alias email@example.com
- Set up the alias in Server Manager as a local user named “friends”
- Use WorkGroup Manager (download here – https://support.apple.com/kb/DL1567) to add additional email domains, if you need to. In this example the “friends” user needs to have firstname.lastname@example.org added because I host multiple email domains on this server and it would only answer to email@example.com if I didn’t.
- Log into Roundcube with the “friends” user credentials to establish the filter that will redirect the mail to the real recipients
- Go to Settings/Filters
- Create a new filter
- Select the “all messages” option for the filter
- Execute “Send message copy to” rule for each target address (there may be a limit on the number, I only use this for small lists)
- Execute “Redirect message to” for the last addressee on your list if you don’t want to keep copies of the messages in the “friends” IMAP account on your server
- Execute “Stop evaluating rules”
Replace mailing list (Mailman) capability
This was one of the hardest debugging jobs in the whole transition. Now that I’ve been through the manual install of this system, I can see why Apple dropped it. It must be a support nightmare for them. But I host a couple of very active lists and I have to have this capability, losing it in the migration is a non-starter for me.
- Here’s a good step by step guide – http://livetime.com/mountain-lion-mailman-mailing-list/
- And here’s the installation documentation from GNU – https://www.gnu.org/software/mailman/mailman-install/front.html
For most of you, you can stop here. Your email lists will be working on your new server.
I wanted to run parallel lists under two domains, keeping the lists running under the old domain name until I had the new version up and tested on the new server and then cutting all the list members over to the new list. If you have a low-priority list where participants can be down for a while, this is probably overkill. Just let them know that things are going to be broken for a few days, take the lists across, redirect the domain when you change the main DNS MX entry for email and have done. But I was trying for 100% uptime during the transition. I bounced my users over a few rocks during this process, but we were up all the time.
To do email lists under multiple domains in Mailman, you have to pay attention to Alias Maps.
- I used two different sources to piece together a working configuration:
- This link from Mountain Lion documentation – https://support.apple.com/kb/HT3878
- And this link from GNU – https://www.gnu.org/software/mailman/mailman-install/postfix-virtual.html
- The first page, from Apple, gives you the right syntax for the changes you need to make to the Mailman config file (mm_cfg.py). The rest of the steps are useful too, except they are pointing to an older location for the Mailman installation (the files are now in usr/local/mailman rather than usr/share/mailman).
- Here are the key lines in my live mm_cfg.py file, using my real domains. The main server domain is cloudmikey.com, the other three are used for testing or delivering mailing lists. Every goofy quote and comma matters here.
################################################## # Put your site-specific settings below this line. MTA = 'Postfix' DEFAULT_EMAIL_HOST = 'server.cloudmikey.com' DEFAULT_URL_HOST = 'server.cloudmikey.com' POSTFIX_STYLE_VIRTUAL_DOMAINS = [ ‘dissembling.com’, ‘bgnws.com’, 'haven2.com' ]
- Note: do not use <angle brackets> around any of these entries. It took me a week to realize that all the documentation was trying to do is look pretty. But putting <angle brackets> around some of those domain name entries breaks Mailman in a really subtle way. It works fine at receiving and sending posts to the lists. But notification-emails to list-owners and list-admins are malformed and get rejected by the SMTP server.
- That second link, from the GNU documentation, got me to working entries in the Postfix main.cf files. Again, here are the two real working entries from my server. They’re buried in the file, but that second post explains what you’re about:
virtual_alias_maps = $virtual_maps hash:/Library/Server/Mail/Config/postfix/virtual_users,hash:/usr/local/mailman/data/virtual-mailman
alias_maps = hash:/etc/aliases,hash:/usr/local/mailman/data/aliases
- Now that all the plumbing is in place to create email lists under multiple domains, there’s one more trick. The web-based front end to Mailman is fine if you’re creating lists in a single domain. But it doesn’t allow you to specify which domain the list will be created in, so if you want to create a list in a domain other than the server’s default domain name, you have to use the command-line command to create the list. It’s not hard, here’s how.
- Enter the command line
- Go to the following directory — you have to be in this directory in order to launch the program. It will fail if you try it from anywhere else.
$ cd /usr/local/mailman/
- Launch the newlist program and follow the prompts. The key thing is to include the domain name in the name of the list when you’re prompted — that’s the bit that’s missing from the web front end. Again, I’ll use live entries that work with the config stuff above. You type the stuff in bold.
sudo bin/newlist Enter the name of the list: firstname.lastname@example.org Enter the email of the person running the list: email@example.com Initial bgnws-testing password: Hit enter to notify bgnwstest owner...
- To restart mailman
sudo bin/mailmanctl restart
- Finally, once the new list is created, here are the steps I went through to keep people on the air during the transition period. My goal was to have the old list keep working while the new one was being built, and then have it wind up that people could send notes to either the old or the new address of the list and wind up in the same place. This may be needlessly complicated, but it’s the way I did it.
- Create an email alias in WG manager on the old server – same name, but forwards to the new-server address. This alias won’t work until the old list is deleted with the rmlist command, coming up in a second. (note, different domain names are needed for this to work, because I don’t want to migrate all the email/lists at the same time – this would be much easier if you’re just cutting over from an old server to new)
- Create a forwarding account on the new server – NOT the same name as the new list (so it doesn’t conflict with the new list) but with an alias to the OLD domain name. Use Roundcube forwarding to push old-domain posts along to the new-domain address of the list.
- Create a duplicate list on the new server, along with all members and settings
- Delete the old-server list – now the alias on the old server will kick in and redirect mail to the new-server address.
- Transition is complete when old-server DNS is moved to new-server – list continues to answer to either new or old domain name because of the forwarding done by the alias account on the new server.
Update, late 2013: Preparing for the NEXT upgrade — the road to Mavericks
I’ve started a thread over on the Apple Support Community to see if there are any impacts to these additions with an in-place upgrade to Mavericks. It took me a really long time to get from Snow Leopard to Mountain Lion (my attempt to get to Lion never succeeded). I’m hoping that the road won’t be quite as bumpy this time, but we’ll see. Here’s a link to the thread.
So far it looks like Roundcube may need to be updated, although the update looks pretty cool. One of the appealing things is that address books may be available in the Roundcube environment. That alone makes it intriguing.