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.

Meeting Maker to Leopard Migration, Part 1

Back in April I started a new job at an advertising agency here in Dallas.  As part of the job I inherited an installation of People Cube’s Meeting Maker calendaring software running on Mac OS X 10.4 Server.  One of my first thoughts was to get all of our servers off of 10.4 and on to 10.5 Leopard.  As part of that process, I would obviously need to migrate Meeting Maker over to the new server software as well.  Seems pretty simple, right?  It wasn’t, trust me.

My train of thought was simple, create a 10.4 Open Directory replica, promote that box to master, upgrade it to 10.5, then use similar methods to get the actual OD master up to 10.5 and master again.  Sounds simple, right?  I thought it was too, that’s until I ran into Meeting Maker and its extended attributes.  (of course Kerio has the same problem, but it is easier to get around)

Well, I did just what I said, I created a 10.4 replica and upgraded it to 10.5 and guess what, the users did not come with it.  Well, not all of the users came with the upgrade.  For some reason, the users showed up in Workgroup Manager, then I upgraded to 10.5 and alot of the users were gone.  Like more than 75% were gone.  Hmmm, interesting phenomenon going on here, I wonder what it could be.

Well, I beat on the problem a bit more, re-installing 10.4 on the replica and re-creating the replica.  This time I went in to WGM before doing the upgrade.  Sure enough, all of the users were there, so I restarted the server and wouldn’t you know it, 75% of them were gone again.  I smell a conspiracy here.

So I got to looking at the ones that were left, and they all had a common thread:  no extended attributes in the LDAP database for Meeting Maker.  See, the way that Meeting Maker was set up by the consultant from People Cube was to use extended attributes in the LDAP database to put the server and login name.  In our case the attributes were comMeetingMakerSignInName and comMeetingMakerCurrentServer.  So, I did what any good sys admin does:  I tried and tried and tried to get the data in.  I tried importing via ldapadd, I tried archiving the 10.4 and restoring it into 10.5, I think I might have even tried sacrificing a small animal on the server, but nothing worked.  So I resorted to the only thing I had left:  calling People Cube support.

I received a call back from one of the engineers at People Cube who had no clue what was going on, so he got the consultant on the phone that helped with our original installation.  Now, he listened acutely to my woes, and proceeded to inform me that Meeting Maker was never officially intended to run on Open Directory, but that it was more intentioned for OpenLDAP.  Then, he told me that as far as he knew no one had put Meeting Maker on 10.5 yet.  Huh?  10.5 has been out since November and no one has put it on?  Crazy.  He gave me some ideas, and after thinking it thru, he actually came up with something that worked.

I was able to utilize information from NetMojo, specifically this article, and sed to get it done.  In the next article I’ll give the specific steps I used to get the LDAP info out and into the 10.5 server.

Macintosh Deployment Images – InstaDMG

During the day I make my living as a techno weenie for a local ad agency. I manage the systems, network, and all that goes along with that. Part of the process of managing the systems is the deployment, or re-deployment, of desktops and laptops. Being an ad agency, this means deployment of Apple Macintosh systems.

For many years, all the way back to my days with Jeff Turner and Ad/Out, I have been a big proponent of disk imaging for deployment. Back then, in the days of OS 8 and OS 9, it meant carrying around a Syquest drive with a copy of a system on it, dragging that to the system and then blessing the System Folder. For those of you that remember this method, it was easy to do for one or two systems, but when you had over 100 systems to deploy, it took time. As the Macintosh system moved to OS X, imaging systems for deployment got easier and easier. Well, it got less cumbersome to do, and easier for large scale deployments.

For the last several years building an image usually meant one of two things: installing everything on a machine and imaging that (I call it fat Imaging), or installing a base OS and imaging that (layered imaging I call it). When a new machine comes in, you lay on the base image, then lay on the applications (done in packages of course), and away you go, or you lay on the fat image and away you go. The problem with this method has always been the amount of maintenance required to “clean up” the image after configuring preferences, installing apps, setting bookmarks, etc. You always wound up with “cruft” on the image.

I realize this isn’t new to a lot of people, in fact most sys admins already know this, and they already know about a great tool developed by Josh Wisenbaker from AFP548.com, InstaDMG. InstaDMG takes system imaging and deployment to a new level. Using a series of folders with a retail disk image, along with your updates and custom packages, InstaDMG spits out an image that is ready for deployment, having never been run on a computer. This means you don’t get the “cruft” on the system that comes from booting the image, and, best of all in my opinion, the image is Universal so it will work on PPC and Intel machines.

I realize this article is a re-hash of some, if not most, of the information on AFP548 about InstaDMG, but I am so jazzed about this tool, and about what it’s possibilities are, that I want to make sure more people hear about it, and more junior admins learn there is a better way than installing systems using CDs and DVDs.

Sell my Apple Stock

Are you nuts?  I don’t get it.  Apple reported their Q2 2008 earnings this afternoon after the stock market closed, and their stock took a slight hit.  Forbes is reporting that Apple is wobbling, even though their numbers were great.

Just how great?  Check it out, they posted a 36 percent jump in profit and they beat Wall Street estimates by 9 cents a share (they posted $1.16 per share profit).  So tell me how all of that equals sell off or wobble?  I just don’t get it.

My Music was Lonely

Back in February the Lifehacker web site ran a Top 10 article on smart playlists for iTunes.  It has turned out to be an article that has helped me discover a lot of lonely music.  If you are like me, I’m sure you have a few select play lists that you listen to over and over.  Or you have artists that you like depending on the mood.  But think about all of that music you are missing.

When I set up my “Ignored Music” playlist, I found over 80gb of music that I hadn’t ever played.  Or at least, I hadn’t played in a really long time.  So now everyday when I sit at my desk I go straight for the Ignored smart list and play it all day long.  I’m now down to 22 days of music as compared to 25 days when I started.  I have a ways to go, but….what will I do when I get done?  Guess I’ll start over with items played once.

Remember what the ultimate question:  How do you eat an elephant?  One bite at a time.

WWDC 2008

Three years ago my Apple sales rep talked me into going to the World Wide Developer’s Conference (WWDC).  At the time I wasn’t sure if I should go or not, I mean come on, I’m not a developer.  But, he assured me that I would get something out of it.  Well, he was right, I got a lot out of it.

I had the opportunity to meet a lot of fellow system admins, I was able to sit in on some really cool discussions about Apple in the Enterprise, and I got to laugh my tail off at Stump the Experts (how many shirts will Mark wear this year?).

So, since I had such a great time in 2005, it was natural that I would get my company to send me in 2006, and again in 2007.  Well, now I’m at a new company, and getting them to foot the $3000 (ticket, air, hotel) to go there is looking pretty bleak.  Not to mention the fact that there is a doctor’s convention in town at the same time, and all of the hotels around San Francisco have upped their prices.  Oh well, I guess I’ll have to settle for the play by play on Twitter or some other site.