Tiger to Leopard Server Migration, Part Two
In Part One, I described the installation of Mac OS X Server 10.5, and the migration of settings from my old 10.4 Server to the new one, for a couple of services. In this article, I’ll go through the importing of user accounts and data from 10.4 (Tiger) to 10.5 (Leopard).
Migrating User Accounts From LDAP
The method that Apple recommends in their Upgrading and Migrating manual is to select user accounts in Workgroup Manager (WGM), and choose Export from Server menu. This creates a comma-delimited text file of your user account data which can be imported with WGM in Leopard. However, the passwords are left out of the export.
I don’t want to manually change the passwords of every user on my server, so I’m doing a different approach. This thread on afp548 was of some help. Instead of getting the user records using slapcat, I used ldapsearch on a running server to get only the user records:
ldapsearch -v -x -D 'uid=dirmanager,cn=users,dc=netmojo,dc=ca' -W -b "dc=netmojo,dc=ca" -s sub "(objectclass=apple-user)" > users.ldif
There are two things to note about the above command: my directory manager account is named “dirmanager”, which is not the default name for the directory manager. This is the account that you would authenticate to the directory with in WGM. However, any account that has global read permissions in your directory will do.
The second thing to note is the search base, dc=netmojo,dc=ca. Yours will be different. Make sure that the search base in your ldif file is the same search base that you setup in Leopard’s Open Directory.
Next, I opened the users.ldif file in my text editor, and removed some old accounts, the root account, the directory administrator (dirmanager) account, and the ldapsearch stats from the bottom of the file. As the AFP548 article recommends, I also did a search and replace on the 1024-bit RSA key, swapping out the key from my 10.4 server with the new one in my 10.5 server. You can get the new key in 10.5 by running “mkpassdb -key”.
Note that Open Directory and Kerberos are already up and running in my 10.5 server. I covered that in the last article. To import the LDIF file, run (substituting your values appropriately):
ldapadd -v -x -D 'uid=dirmanager,cn=users,dc=netmojo,dc=ca' -W -f /tmp/new-users.ldif
After restarting WGM, all of my users appeared in the Accounts tab.
You may have noticed that the LDIF file contains the same string of gibberish in the userPassword field for each user. OSX Server stores the passwords in a separate password database, which you can access with the “mkpassdb” command. I will come back to this later.
Migrating Computer Accounts
Just like the user accounts, I imported the client computer accounts from LDAP using ldapsearch, a text editor, and ldapadd.
ldapsearch -v -x -D 'uid=dirmanager,cn=users,dc=netmojo,dc=ca' -W -b "dc=netmojo,dc=ca" -s sub "(objectclass=apple-computer)" > computers.ldif
Editing computers.ldif in my text editor, I did a search & replace on the RSA key, removed the entry for the server itself, removed an old computer, removed the “apple-mcxflags” attributes, and the stats from the bottom of the file.
One difference between 10.4 and 10.5 seems to be the addition of an “ipHostNumber” attribute in the computer records. You can add these to the LDIF file (ipHostNumber: 123.456.789.111), or simply fill out the IP Address field in the Network tab of the computer section of WGM after the ldap import. Importing the LDIF file is the same as it was for users:
ldapadd -v -x -D 'uid=dirmanager,cn=users,dc=netmojo,dc=ca' -W -f computers.ldif
The first time that I tried, I got an error:
ldap_add: Naming violation (64)
additional info: value of naming attribute 'cn' is not present in entry
That was strange, because the cn attribute was present. I moved it to the top, right under the dn: attribute, retried, and it worked.
Migrating Passwords
To migrate user passwords in Mac OS X, it is necessary to export them from the password server using the “mkpassdb -backupdb” command, as noted in the AFP548 article. Before proceeding with this method, you should read it through to the end. I encountered problems during the process, and there could be repercussions that I have not yet discovered. It might be worthwhile for you to manually change passwords, as Apple recommends…
On the running 10.4 server:
cd /Volumes/disk2/passwords
sudo mkdir tiger_passwords
sudo mkpassdb -backupdb tiger_passwords
Do the same in 10.5:
cd /Volumes/disk2/passwords
sudo mkdir leopard_passwords
sudo mkpassdb -backupdb leopard_passwords
In my case, “/Volumes/disk2/passwords” is a directory that exists in both my 10.4 server, and my 10.5 server. So this path is probably different for you, or maybe you need to copy the “tiger_passwords” directory over to your 10.5 server some other way.
I am assuming that in 10.5 you have a configured and running Open Directory and Kerberos server. This being the case, merge the differences between the tiger passwords and the leopard passwords, preserving the current identity of the password server by running:
cd /Volumes/disk2/passwords
sudo mkpassdb -mergeparent tiger_passwords leopard_passwords
Problems with Kerberos
As the AFP548 article suggested, I ran “mkpassdb -kerberize”, since I am using kerberos on my network. I’m not so sure that it was a good idea. After a reboot, the Kerberos server wouldn’t start, and these errors appeared in my kdc.log:
krb5kdc: Cannot find master key record in database - while verifying master key for realm LEOPARDSERVER.NETMOJO.CA
And in my kadmin.log:
kadmind[332](Error): Cannot find master key record in database while initializing, aborting
To fix the broken Kerberos server, I had to recreate a Kerberos master key. Basically, I had to wipe out the kerberos database, and start over. This thread on a Kerberos forum at MIT was of great help; I basically followed the given instructions:
cd /var/db/krb5kdc
rm -i * .*
(say 'y' to everything except kadm5.acl and kdc.conf)
kdb5_util -r LEOPARDSERVER.NETMOJO.CA create -s
After that, I rebooted, and the Open Directory panel of Server Admin reported that Kerberos was once again running.
Most users can authenticate, however one of them cannot. Examining that user’s record in WGM, using the “Inspector” (to enable it, check off “Show All Records and Inspector” in the WGM Preferences) I found that it is lacking a Kerberos attribute that the other accounts have. Other accounts have two “authAuthority” attributes, one for “ApplePasswordServer”, and one for “Kerberosv5″. The one that doesn’t work has only “ApplePasswordServer”. I have not yet resolved this issue, but I could probably just delete and re-add the account, or just change the password. I did the latter, and I can login with SSH using that account and the new password.
Migrating Home Directories
Moving home directories is about as simple as it gets: I created a tar archive of them in my 10.4 server:
sudo tar cvf /Volumes/disk2/homes.tar --exclude="Caches" /Users
Then extracted the file in my 10.5 server:
cd /
sudo tar xvf /Volumes/disk2/homes.tar --keep-existing
Check to make sure that the home directories are owned by the appropriate users, and adjust if necessary:
cd /Users
ls -l
sudo chown -R someuser:staff someuser
Migrating SSH Keys
To prevent my users from getting scared by this message when they try to SSH to the new server (yes, I have the kind of users that use ssh):
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
… it is necessary to copy the SSH keys over from the old server. This is straightforward; just copy the /etc/ssh*key* files to the new server:
cd /Volumes/disk2/backup_of_10.4/private/etc/
tar cvf /tmp/oldkeys.tar ssh*key*
ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_key
ssh_host_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub
cd /private/etc
tar cvf /tmp/newkeys.tar ssh*key*
...
tar xvf /tmp/oldkeys.tar
Migrating IMAP Email
This article is already way too long, so email migration will be in my next article of this series :).
Tags: Apple, LDAP, Leopard, Leopard-Server, Mac-OS-X, OS-X-Server, Sysadmin
December 19th, 2007 at 2:08 pm
Why not simply use the Server Admin GUI to Archive/Restore Open Directory database (users accounts and passwords) ?
December 20th, 2007 at 10:42 am
That’s a good question, and I wonder why Apple doesn’t recommend it in their migration documentation. It could be because there have been schema changes to one of the components that make up the Open Directory system, outside of the user accounts.
Have you tried it?
December 21st, 2007 at 3:51 pm
Yes, we migrate from 10.4 to 10.5 this way.
See Upgrading and Migrating manual pages 34 and 41
about OD Archive/Restore.
Thanks for great articles Brent.
January 28th, 2008 at 3:33 pm
Please note that on Mac OS X Kerberos conf files and principals live in /var/db/krb5kdc/ and not in /var/kerberos/krb5kdc/ as the above MIT forum example suggests.
January 28th, 2008 at 3:45 pm
Ivailo Djilianov: thanks! fixed.
January 30th, 2008 at 3:55 pm
Setup:
Xserve G5
OD Master
10.4.10
3gb ram
migrating to:
Intel Xserve
Dual 2 GHz
5 gig of ram
10.5.1
I am just migrating users and passwords at this point. I exported the file and deleted the directory admin and administrator accounts, and I modified the Password and Kerberos entries to match the new server. When I import the file, It gets hung up on the first user and terminates with this error:
modify complete
ldap_add: Server is unwilling to perform (53)
additional info: no global superior knowledge
No user is added to Open Directory. Does anyone have a clue to why it may be hanging up?
January 30th, 2008 at 4:14 pm
According to: http://www.openldap.org/faq/data/cache/1322.html, the partition that you are trying to put the user into (i.e., dc=foo,dc=bar,dc=your,dc=com) probably doesn’t exist. You’ll have to add those to the top of your import file, so they get added before the records that go into them.
For example:
# deptartment, company.ca
dn: dc=department,dc=company,dc=ca
dc: deptartment
objectClass: domain
# users, deptartment, company.ca
dn: cn=users,dc=department,dc=company,dc=ca
cn: users
objectClass: container
January 31st, 2008 at 8:26 am
Did the file you used have this info? If it did not, then why did yours work?
January 31st, 2008 at 9:02 am
Another thing I noticed is that the value for apple-user-homeurl in the file is encrypted, and when I ldapadd is shows the value to be of the old server. I don’t know if this makes a difference. I will try the above and get back to you.
January 31st, 2008 at 9:07 am
Well, now I get:
modify complete
ldap_add: Undefined attribute type (17)
additional info: dn: attribute type undefined
January 31st, 2008 at 9:30 am
I put my users in the default location in my base DN. When I defined the Base DN in the Server Admin, it was created for me.
Have you used Server Admin to change Open Directory’s role to an “Open Directory Master”? You can also achieve this by running the slapconfig command (see the man page).
slapconfig -createldapmasterandadmin diradmin your-password 1000 “dc=netmojo,dc=ca” MYREALM.CA
Regarding your undefined attribute, there is probably an attribute in your old records that doesn’t exist in leopard. Any idea which one was left out when you added the records?
January 31st, 2008 at 9:39 am
The new server is already setup as an OD Master, with the directory administrator account. When I did a slapcat -l and looked at that file, it seemed to have the info you are discussing. Using ldapsearch does not produce the exact same results in terms of what is precisely in the file.
January 31st, 2008 at 9:44 am
It would appear then that the base DN in your already setup OD Master isn’t the same as the DN that you were trying to add your users to.
January 31st, 2008 at 10:10 am
The searchbase was different. I just clicked through the setup on the 10.5 server. It added the server name in the searchbase. The old server was not like that. I demoted it and repromoted it to start from ground 0 and try it again. Thanks for your patience and help.
January 31st, 2008 at 10:39 am
You are welcome. Let me know how it works out. I ended up having more troubles with Kerberos (see my latest post). Single Sign-on wasn’t working. That was at least partly due to the incorrect or missing authAuthority attribute with the “Kerberosv5″ data.
If I were doing it again, I would use the GUI to add a test user, then use ldapsearch to get the proper Kerberosv5 data from the new user’s record. I’d then add that attribute + data to my LDIF import file by search & replacing the old data, or adding it if it doesn’t exist, using sed, a perl script, or a quality text editor like TextMate.
Ringo, the first commenter, said that he successfully used the Archive & Restore functions of Server Admin: Open Directory to migrate. This would, I presume, copy the user data including passwords, and the entire Kerberos setup to the new server. I wonder how that is working out…
January 31st, 2008 at 10:46 am
Well, I started over and when I run ldapadd now I get an error:
ldap_add: Object class violation (65) additional info: object class ‘inetOrgPerson’ requires attribute ’sn’
The thing is there are sn attributes.
January 31st, 2008 at 10:54 am
There must be at least one record either without the sn attribute, or with an empty value in an sn attribute.
February 8th, 2008 at 3:32 pm
Ok. Here is an update. After talking to an Apple SE, he recommended archiving the the OD db from the old server and importing it to the new server. The caveat is that the new server must have the same IP address and hostname as the old server. When you promote the new server to OD master, you must make sure to enter the same search base and kerberos realm and then import the OD archive. I did this on a separate, isolated network. Another issue is DNS. Since we use a separate DNS server that is windows based, I had to setup the new server with DNS so it could resolve itself. After I imported it, I tested it and made sure I could login and it worked. I then used changeip to change the ip address and hostname so I could have the new server and old server co-exist on the same network so as to enable users to migrate their own data. Remember to changeip -checkhostname before running it to make sure the host name and IP address resolve. If there is a problem, it will let you know. The other thing I did out of superstition was to reboot after each change in the process. After all was done I connected to the production network and ran software update. So far so good.
March 5th, 2008 at 10:08 am
Im about to migrate to leopard at a school site with tons of teacher and student accounts.
Can you go more into depth about your step on migrating accounts:
“Moving home directories is about as simple as it gets: I created a tar archive of them in my 10.4 server:
sudo tar cvf /Volumes/disk2/homes.tar –exclude=”Caches” /Users”
I appreciate it.
March 5th, 2008 at 11:36 am
Do you want more detail on migrating accounts, or on the part that you quoted, which is migrating home directories? If the former, please note the first 3 comments on this post.
Do you have two servers for this upgrade, or are you upgrading a single server that is now running Tiger?
March 5th, 2008 at 2:49 pm
Thanks for the speedy response
I would like more detailed information on the migration of home directories.
When you write about creating a Tar and etc.
I have an xserve with three drives: 80gb(running the os), 700(for the directories) and another 700 for backups(sparse).
I will also have a g5 dual 2gig running as a replica to my xserve.
thanks for all your help. looking forward to your response.
March 8th, 2008 at 8:27 pm
All that you need to do is move/copy the data. I used tar, which is a tried and true way to copy large numbers of files and directories, preserving permissions, access and ownership data. I essentially created an archive of the data with tar, then unpacked that archive on the new machine.
For more information on tar, open a Terminal, and run ‘man tar’. Also run ‘tar —help’, which gives you all of the options for tar.
As an example, if I wanted to tar the /Users directory, I would run ‘tar cvf myarchivefile.tar /Users’. To untar that archive somewhere else, I’d run ‘tar xvf myarchivefile.tar’. tar takes other options as well, such as —exclude. In the blog post, my example excludes the Caches directories; I could add to that “.Trash*” to avoid copying files from user’s trashes.
Aside from tar, there are many other ways of copying files that preserve permissions and other attributes; rsync is another of my other favorites.
March 14th, 2008 at 7:38 am
Brent
I’m trying to distill the information posted here, but I think I’m a bit confused. Here is my scenario:
G4 MD 10.4Server (OD Master) hosting xServe RAID. New Xeon xServe to replace G4 MD as host and OD Master). Separate Replica to be deployed afterwards. About 100 very stubborn users.
Gist of the problem: Trying to move over the old OD to the new Xeon host. Xeon will have a new IP and DNS name, but the old DNS name will be added/appended/aliased to the current DNS A record kept by our Hospital. What, exactly, do I have to modify? If I follow the OD backup and restore method (easy way), what exactly needs to be modified, other than removing of certain user accounts (as recommended). Sorry for asking for the easy way out here….
March 14th, 2008 at 10:57 am
Hi Barry,
I haven’t tested your scenario specifically, and I don’t have time at the moment to dig into the documentation (for what thats worth), so bear that in mind. I would suppose that the OD backup / restore is only going to work properly for you if your new machine has the same hostname and DNS settings as the old machine. By “work properly” I’m referring to Kerberos and everything associated with it. Kerberos is inherently tied to host/domain names, so effectively changing those names will break it.
In your case, a better strategy might be to name the new Xserve the same as the old one, then when you are ready to take it online, either take the old one offline or rename it. Or, set up the new server with a new name, and import the data by means other than OD Restore.
Supposing you went ahead with OD restore and everything went perfectly, if you use other Mac OS X services, such as mail and web, you would need to copy the data from those services over to the new server. Same goes for home directories.
April 3rd, 2008 at 4:01 pm
A very useful and informative article, thank you! I am about to migrate a PowerMac dual-G5 from 10.4 Server to 10.5 Server. This is a school with 800+ users on the system. Preserving user data is very important. I have do this in place on the same hardware as I do not have a second/backup/replica machine to use.
My configuration is similar to David’s, above. All the user home directories live on a second drive that will not be directly affected by the install of the new OS on the primary drive. Assuming that I properly export/import the account information from WGM, I’m thinking that there is no need to tar the user accounts. The drive and folders will be just as they were under 10.4 and should just work. Yes? No? Comments?
Thanks for the help.
April 3rd, 2008 at 11:58 pm
Hi Tom,
Apple is getting ready to release 10.5.3 soon; you may want to wait until then for your deployment, as it will fix yet another couple of hundred bugs in Leopard.
To answer your question: yes. The home directories should work just fine on the new server, with the user accounts intact, and if they are mounted/shared at the same location(s). There is no need to ‘tar’, but like all good sysadmins, I know that you will do a complete backup of all data before starting.
Have a good migration.
April 15th, 2008 at 2:41 pm
Hi Brent,
Great info. I really appreciate the detail and accuracy you have put in your article.
I am migrating to 10.5 this summer and though I would love to archive and restore (same Xserve, IP and hostname) as I’ve done before, there are some issues with our OD being corrupt and after many attempts and discussions with Apple SE’s the solution is to go with a clean install and import users and groups (we’re losing pw’s but necessary to move forward)
Though I am very interested in you password migration steps. Have you encountered any repercussions so far?
Also, I have many servers to upgrade this summer. Would I be fine just doing a clean install on the OD master and upgrading the replicas and afp servers? I’m just not looking forward to all the settings I’ll have to redo if I’m doing a clean install on 20 servers.
thanks again