Tuesday, October 6, 2009

Snow Leopard Server Upgrade Hell

Let it be known my last words were "Remember the DNS" as I go stark raving mad after upgrading to Apple 10.6 Server. What I am saying with so much drama is remember that working DNS is paramount. There is no log file for it, but if you don't get it right the first time you are screwed. Not completely but it will likely be painful once you get to the end.

I started on a Saturday morning like any other only I had to go to work an extra day when no one was in the office. I have a brand new Xserve ready to migrate to and had already installed 10.6 Server two days prior. I read through the upgrade instructions over and over to make sure I had it down and I began the process.

Here is something you may want to remember. If you are moving to a new machine Please unbind the old machine from your Open Director Master First. This will help when you want to bind the new machine under the same name.

I followed the instructions for upgrading from Mac OS 10.5 Server, but the Mail migration didn't succeed correctly it turns out the New Mail server "Dovecot" needs to rename the user files when it is done importing them from the old server. Well Mine didn't do this. So I wound up using the Migration script on Page 42 of the Upgrading and Migrating Instructions.

Turn off Mail

Before I run the Migration command I do the following because I Just want to make sure I backup the original migration in case, you don't have to do this, but I recommend it if you want a clean Mail DB.

Sudo MV /var/spool/imap/dovecot/mail /var/spool/imap/dovecot/mail.old
sudo mkdir /var/spool/imap/dovecot/mail
sudo chown _dovecot:mail /var/spool/imap/dovecot/mail
sudo chmod 775 /var/spool/imap/dovecot/mail

(APPLE's Script to run copied directly from Pg. 42)

sudo /usr/libexec/dovecot/migrate_mail_data.pl —moveMail 0 —cyrusBin "/

Volumes/Leopard Server/usr/bin/cyrus/bin" --database "/Volumes/

Leopard Server/var/imap" --sourceSpool "/Volumes/Leopard Server/var/

spool/imap" --targetSpool "/var/spool/imap/dovecot/mail"


(My Script to use)

sudo /usr/libexec/dovecot/migrate_mail_data.pl --moveMail 0 --cyrusBin "/Volumes/10.5 Server Volume Name/usr/bin/cyrus/bin" --database "/Volumes/10.5 Server Volume Name/var/imap" --sourceSpool "/Volumes/10.5 Server Volume Name/var/spool/imap" --targetSpool "/var/spool/imap/dovecot/mail"


Here is some fun news, If anything is wrong in the script above it throws errors telling you what to do. For instance, I inferred to replace the three places where it says "Leopard Server" in the script with my Hard Disk Drive Volume name from the Old 10.5 Xserve, No Problem, but what I didn't read into it was the quotations are there for a reason. I put in "/Volumes/Server\ HDD/" Being that my volume was called "Server HDD" It threw an error saying "Server\\ HDD" could not be found. So that meant the locations with space in between the quotations would be automagically escape character-ed. Easy Nuff. I just went back and pulled the backslash. But there was another typo or two. Thanks to the copy/paste from PDF the script has some spaces that don't need to be there at the ends of the three first lines of the PDF so make sure to pull those out. Lastly the part that says "—moveMail 0 —cyrusBin" Needs to say "--moveMail 0 --cyrusBin" Two dashes in front of each instead of a hyphen.

Run the script and wait forever while the 40 GB of mail is transferred a second time. Hopefully you don't have 40 GB of Mail.

After your migration, you should notice the user names on the folders in /var/spool/imap/dovecot/mail have changed to a hash. This is something that Dovecot uses to secure the e-mail. If you super user into terminal and change directory to the aformentioned directory and run an "ls -l" command you will see the user names as the owners; one for each of the hash folders. So you can tell who is who.

Anyway. Now is a good time to check your DNS Records.

Go to Server admin and make sure nothing looks wrong after the migration. I didn't notice anything off hand, but this got me later.

So long as your DNS is good, you should be able to bind the server to your OD Master to get up and running. Tell you the truth I wish I had skipped the Upgrade part all together and Migrated the mail separately onto a clean server.

After my migration the Mail stopped delivering about two hours in. This should have told me something right off bat because I had this issue two or three years ago, but it didn't because I had already checked the DNS records.

Binding to the Directory Server kept throwing issues, I assumed because the old server was still bound, so I booted it up and unbound it. While that stopped one issue, the new server still wasn't talking to the director server. Four days later, after rebooting the server every two to four hours I went back to the DNS records using nano (pico). To read the files from /var/named/zones . I found settings in there were incorrect,

sudo nano /var/named/zones/db.company.com.apple.zone

Sure enough, Here was my problem somehow my DNS records were misconfigured. I don't know weather to blame myself, two years ago, or Apple Server Admin. Whatever the problem, the issue was here.

So I clean the zone file up, making my internal Server the DNS SOA instead of the external SOA. I made sure mycompany.com was my main Nameserver. I aliased mail.mycompany.com to mycompany.com and made an MX entry for mail.cvaadv.com, I aliased several other names to mycompany.com and just to be on the safe side all entries were in FQDN.

Finally! Stability. The server has been up a week now without hiccups. Next, re-training the junk-mail filter.

7 comments:

BrianPassante said...

Thanks for the help. I am a newbie MacMini 10.6 small office, and the migration of mail failed for me. Apple support said to run this script from page 42. Your tips on the typos in manual were spot on! But I get a strange message on running script….cvt_cyrusdb does not exist in : "."?

Does the Terminal need to be in a particular directory to run the script correctly?

Or is this error really telling me something else? Thanks in advance. BJP

BrianPassante said...

Opps! Now I have it. The bad dash in the Upgrade PDF must be deleted entirely and two new dashes inserted in both of the two places in the long command! That seemed to get it moving…..Thanks for your helpful posting! It was very helpful.

Apple's automated migration process to newer versions of server is getting better and easier….but it not perfect yet!

Anonymous said...

How long did it take to migrate 40 GB of mail, I am going to do this soon, we have 32 GB of mail just want to know what to expect as far as time to complete.

Unknown said...

Good post. I ran into some difficulty myself with the same type of upgrade. I am curious why you used the script /usr/libexec/dovecot/migrate_mail_data.pl as opposed to the "65_mail_migrator.pl" that they put in /System/Library/ServerSetup/MigrationExtras.

Twintails said...

Sorry for the late response, this think wasn't telling me I had comments and I don't go through posting phases very often. I used the dovecot script because the Migration Extras didn't work properly. Something to do with screwing up the permissions for the old Cyrus Folder and all the child files. Which then caused Dovecot to make new folders anyway. So I had a bunch of old folders that went nowhere and new folder that had no contents. (and a few angry words)

Mauricio said...

I get succes after the migration with the migrate_nail_data tool but all my users obtain the old IMAP mail like NO READ
I thing a flag problem in the migration, do you know how repair?

Twintails said...

I don't think I have the answer you are looking for.

I think this is the correct action. As the messages are imported they are not marked read by the import tool. An unfortunate drawback, meaning each user must go select all the messages and mark them as read.

but the bright side is. they have their mail still.