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.
