Migrating from Snow Leopard Server to OSX Server (Mountain Lion)

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

Upgrade memory

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.

Memory

Nightly auto-restarts

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.

VPN

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.

Restore MySQL

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:

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 friends@bgnws.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 friends@bgnws.com added because I host multiple email domains on this server and it would only answer to friends@cloudmikey.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.

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:
  • 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: bgnws-testing@bgnws.com
        Enter the email of the person running the list: mike@haven2.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.

https://discussions.apple.com/message/23972346#23972346

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.

4 Responses to “Migrating from Snow Leopard Server to OSX Server (Mountain Lion)”

  1. Jerry Zigmont Says:

    Hi Mike,
    I will be upgrading a 10.6.8 Mini and I am most concerned with Mail (moving existing users and mailboxes - approx 8 people). I assume I should do an "in-place" upgrade and not a migration.

    Once the Server App gets turned on, what has been you experience with the Mail working "out of the box"? We are not likely needing RoundCube.

    Kind thanks
    Jerry

  2. Mike O'Connor Says:

    Hi Jerry,

    I created new accounts for our family (5 users) and had them update their mail browsers at transition time. So for a while they ran two accounts on their browsers and then turned off the old one once the new server had propagated through DNS (about 48 hours). I used two different servers in this project because I knew that there was a really big risk of failure doing an in-place upgrade. It took me about 4 months of chipping away at the project to get through all the stuff in this post.

    One difference is that we do everything with POP and don't use IMAP. So we didn't have mailboxes full of old mail to move across. So I have no experience to relay there at all. The server itself worked fine right out of the box -- but again, this only applies to POP users.

    If I was doing this with one server, I'd do every imaginable backup (TimeMachine probably won't be enough, I'd do that plus making images of the disk and anything else I could think of). Then I'd tell my users that the server wouldn't be available for X hours (24? 48?) while I did the upgrade. Then I'd pull an all-nighter. If things looked bad about 6 hours from my self-imposed deadline, I'd restore from the backup and try another weekend.

    Another thing to try would be running an image of the server under VMware Fusion and doing a trial of the upgrade there. But pay deep attention to DNS and IP addressing in that case -- otherwise you'll collide with the live server.

  3. Jerry Zigmont Says:

    Thanks, Mike. I will take several backups and do an in place upgrade. It will be interesting to see what happens.

    Thanks again!

  4. Mike O'Connor Says:

    Let us know how it goes. Best of luck.

Leave a Reply