Meeting Maker to Leopard Migration, Part 3

It’s been a few months since I last posted, and during that time one of my fellow co-workers at one of our other locations found an easier way to upgrade to Leopard for us Meeting Maker sufferers. As you recall from Part 1 and Part 2 of this series, in order to upgrade from Tiger to Leopard I was having to strip out all references to Meeting Maker from the LDIF files. Well, there is an easier way, a much, much easier way.

Grab That Custom Schema

When Meeting Maker was first installed on your server, a custom schema file was added to your LDAP server to allow for the new attributes. Well, all we need to do is get that schema file over to the new server and add a few lines to the slapd.conf configuration file.

First step is to grab that custom file. Fire up Terminal on your existing server and go find that file:




cd /etc/openldap/schema
ls -la

Now, most likely the file is named “meetingmaker.schema”, at least that’s what mine was, but yours may be different. Look for file names that don’t look like standard schema files for OS X. You can easily determine if they are Meeting Maker schema files by listing the file contents:




cat meetingmaker.schema | grep MeetingMaker

That snip of code will help you tell if the file is a Meeting Maker file or not. If nothing is returned, you don’t have the right file and need to keep looking.

Once you find the file, copy it over to your new server:




scp /etc/openldap/schema/meetingmaker.schema user@yourserver:/etc/openldap/schema

Tell LDAP What To Do With Your Schema

Now that the file is over on your new server, we need to edit slapd.conf to let it know what to do. First things first, make a backup copy of that file:




sudo cp /etc/openldap/slapd.conf /etc/openldap/slapd.conf.bak

Now open up slapd.conf in your favorite editor and add this line:




include /etc/openldap/schema/yourcustomschemafile.schema

We need to clear out the slapd.d folder now. Make a backup of this folder first:




cp -R /etc/openldap/slapd.d /etc/openldap/slapd.d.bak

Now clear the contents of the slapd.d folder:




rm -rf /etc/openldap/slapd.d/*

Let’s Test It Out

Let’s test to make sure the schema is being picked up right:




slaptest -v -d 68 -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d

This will return a whole bunch of information, the key pieces being Meeting Maker and the last line: “config file testing succeeded”. Here is what the last lines of my test showed:




line 550 (objectclass ( 1.3.6.1.4.1.16291.2.2.1.1 NAME 'comMeetingMakerUser' DESC 'Meeting Maker, Inc.: Meeting Maker User' SUP comMeetingMakerAccount ))
line 562 (objectclass ( 1.3.6.1.4.1.16291.2.2.1.2 NAME 'comMeetingMakerResource' DESC 'Meeting Maker, Inc.: Meeting Maker reservable resource (non-location)' SUP comMeetingMakerAccount STRUCTURAL MAY ( comMeetingMakerAutoAccept $ comMeetingMakerAllowProposals ) ))
line 574 (objectclass ( 1.3.6.1.4.1.16291.2.2.1.3 NAME 'comMeetingMakerLocation' DESC 'Meeting Maker, Inc.: Meeting Maker reservable meeting location' SUP comMeetingMakerAccount STRUCTURAL MAY ( comMeetingMakerAutoAccept $ comMeetingMakerAllowProposals ) ))
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
send_ldap_result: err=68 matched="" text=""
bdb_db_open: dc=server,dc=yourdomain,dc=com
config file testing succeeded
bash-3.2#

Notice the Meeting Maker references. We should be good to go.

Restart and Test ‘er Out

Give your server a quick restart. You can probably skip this part by simply sig hupping the DirectoryService service (killall DirectoryService), but a restart is just cleaner in my opinion.

After the restart, fire up Workgroup Manager and let’s see if the attributes are there now. Click on the Inspector button and then on the drop down list of items:

In the pop-up window, choose OLCSchemaConfig and verify Meeting Maker is now showing up:

If you see it in there, then you are good to go.

Now What?

Now that you have the schema entries in for Meeting Maker, you can simply do an archive of your OD data on your 10.4 server and then a restore on the new 10.5 server. You will want to make sure your kerberos realm is the same on the new server as it was on the old, or you will run into problems importing the data. If you want to use a new realm, well, then you might as well start typing the data in by hand. I know there are ways to change this in the LDIF file on the fly, similar to the way I stripped the Meeting Maker data out in Part 2, but I haven’t messed around with it yet.

I hope these three articles helped you out with your upgrade.

Meeting Maker to Leopard Migration, Part 2

In my last post, Meeting Maker to Leopard Migration, Part 1, I gave some of the background information regarding the problems I was experiencing with upgrading our Mac OS X Server 10.4 environment to Leopard.  Most of the issues revolve around Meeting Maker and the neccessity for extended attributes in Open Directory for Meeting Maker to work.  In this post, I will cover the nitty gritty, down and dirty steps I took to get my Open Directory over to a new server running 10.5.

Export 10.4 Data

In the last post I mentioned how I was using an article from NetMojo and the stream editor sed to get the users and groups out of the 10.4 Open Directory and into the 10.5 Open Directory.  Specifically, the way I did this was to utilize the ldapsearch utility the way that Brent mentioned at NetMojo, but with a twist.  This is what Brent had suggested:

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

Well, I took it a step further and incorporated sed into the mix.  I knew that I had to remove the MM attributes, so why not do it in the stream.  Hence the following was born:

ldapsearch -v -x -D "uid=diradmin,cn=users,dc=yourdomain,dc=com" -W -b "dc=yourdomain,dc=com" -s sub "(objectclass=apple-user)" | sed '/comMeetingMakerSignInName/d' | sed '/comMeetingMakerCurrentServer/d' > newldap.ldif

As you can see, I piped the output from ldapsearch thru sed two times to get rid of the two attributes we use.  I now had a clean ldif file to work with and could use this to test on 10.5

Import LDIF into 10.5

So now that we have our ldif data, we have to get it into the 10.5 directory.  Two hurdles that I was going to have to jump were the Search Base and the Kerberos Realm.  You see, you should be naming these two items the same so that your data flows in nice and smooth.  However, since I had inherited this installation, I wanted to make it more generic by dropping server names from the Search Base and Kerberos Realm.  You see, the default for Open Directory is to create your search base like this:

dc=servername,dc=yourdomain,dc=com

And your Kerberos realm is like this:

SERVERNAME.YOURDOMAIN.COM

As I stated, I wanted these to be generic so I could move to a different server later, if need be.  Well that introduced a little complication to the mix, just meaning I had to force the import into the new OD.  We accomplish this with the following:

ldapadd -v -x -D 'uid=diradmin,cn=users,dc=yourdomain,dc=com' -W -f /tmp/new-users.ldif

So, now that I have the data in, I needed to check to make sure it was working.  Guess what, all of the users showed up in WGM, and even after a restart they were all still there!  Awesome!  Now we’re cooking with gas.

The Monkey Wrench

Everything was looking groovy, and I really thought I had this beast tackled.  Then the monkey wrench dropped in my lap.  I started testing authentication to the directory and couldn’t get it to work.  Okay, I thought, the password server didn’t move over so it was just a password issue.  Wrong.  None of the user accounts, except those that were already there, would authenticate.  Yep, something was wrong.

I figured out that because the Password Server did not come over, and probably because of some Kerberos issues as well, authentication was not going to work.  So I re-imaged the server (you do have an image of the fresh server, right?), set it up as a 10.5 OD Master again, and then I went back to the 10.4 server.

This time, I decided I would incorporate sed in a different manner.

To Archive and To Restore

I went back to the 10.4 Server and this time used the Archive feature inside of Server Manager to get the data out.  Once I had the archive, I mounted the disk image and used the sed commands to strip out the Meeting Maker crap, I mean attributes.

First thing to do is mount the sparse image that is the backup.  With the image mounted, open Terminal and navigate onto the root of the image.  Now that we are there, we just need to list the ldif file and sed it:

cat users.ldif | sed '/comMeetingMakerSignInName/d' | sed '/comMeetingMakerCurrentServer/d' > newusers.ldif

Make sure you verify the name of the LDIF file.  Once this command is finished, verify the newusers.ldif file, then delete the users.ldif file and rename newusers.ldif to users.ldif.  Make sense?

Now we can take this over to the 10.5 server and restore it there.  And guess what?  Once we do that, it works.  I tested with a restart (several restarts in fact) and sure enough, I could authenticate to the directory.

Now, finally, I have a directory without Meeting Maker in it, which means I can now move forward with getting iCal server up and operational so I can get rid of Meeting Maker all together.

I hope these two articles have helped you out of a bind with Meeting Maker and given you the commands necessary to get up to 10.5.