Sometimes, OpenLDAP (a key component of Open Directory) will try to launch, and will find itself with a corrupted database. Naturally, when your LDAP server (slapd, which I always imagine as a daemon that constantly slaps you in the face) can’t start, everything that relies on it will fail. That’s usually bad.

You see errors like this:

8/9/10 12:11:55 PM com.apple.launchd[1] (org.openldap.slapd[547]) Exited with exit code: 1 
8/9/10 12:11:55 PM com.apple.launchd[1] (org.openldap.slapd) Throttling respawn: Will start in 10 seconds

If you run slapd in Tool mode, you can figure out the exact problem, and it’ll probably look something like this:

$ /usr/libexec/slapd -Tt
bdb(dc=example,dc=com): PANIC: fatal region error detected; run recovery
bdb_db_open: Database cannot be opened, err -30978. Restore from backup!
bdb(dc=example,dc=com): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem
backend_startup_one: bi_db_open failed! (-30978)

The problem is that the Berkeley DB that holds all of OpenLDAP’s information has become corrupted. It happens, and it’s what the db_recover command is for.
First things first: make sure slapd is not running before trying to recover the database.

$ sudo launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist

By default, db_recover uses the current working directory as the home for the database environment. You can specify that with the -h flag, or you can just go there first.

$ cd /var/db/openldap/openldap-data

You should probably back up the contents of this folder before continuing. You can just copy the openldap-data folder to another folder, or use tar, but you should back it up. Just in case.

Now use db_recover to fix whatever is broken.
$ sudo /usr/bin/db_recover

Once that’s done (and it shouldn’t take long), run slapd -Tt again to make sure it did the trick. It should just tell you that it verified the config file. Reload the slapd launchdaemon, and (hopefully) it will launch.

$ sudo launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist

I should point out that you should absolutely be taking periodic archives of Open Directory. You can do that from Server Admin, or you can script it using the serveradmin command, but you need to do it. The OpenLDAP database isn’t the only thing that can get corrupted, and sometimes restoring from an Open Directory Archive is the only way you’ll get things working again.

Took me a few minutes to figure this out, but I was trying to install a package with Casper Remote, and it was downloading (from all appearances) the package, but then could not verify the package, so it would fail. The logs were like so:

Downloading http://my.jss:8443/Packages/MyPackage.dmg
Verifying DMG...
Error: The downloaded package could not be verified

Turns out the problem was that, for some reason, Casper thought the distribution point didn’t need authentication, so the clients executing the policy were trying to connect anonymously to the WebDAV Realm. Instead of getting the DMG they asked for, they were (I imagine) getting a 404 page. Which, naturally, can’t be verified as a DMG. I turned on authentication for all the distribution points, and all became right with the world.

I was helping somebody set up a LogMeIn account the other day, and when we got around to testing, I figured I’d walk her through it. I told her to go to logmein.com. She opened up Internet Explorer, clicked in the little Google search box on whatever toolbar it was on, entered “www.logmein.com” in the search box, clicked Search, and then actually pondered for a second on which of the results she wanted to use.

Then, she clicked on the sponsored LogMeIn link.

I pointed out that she could have just entered the address in the address bar to begin with, since she went to the trouble of typing the whole thing, including the “www”. I got sort of a blank look in return.

It makes me want to buy some Google stock.

I just signed up for an account on the website of my newest health-care provider. As a part of the process, I was given a choice:

1. Have my password mailed to the address they had one file for me
2. Answer a series of questions drawn from “public databases” and get a password now.

Being impatient, I chose option 2. I was then asked a series of questions.

1. Which of a list of addresses (that included my mom’s) I was associated with
2. Which of a list of cars (including a truck that was my dad’s) I was associated with
3. What city my brother Tom lives in
4. What month my brother Pat was born in
5. What age range best described my mother.

Think about that. From knowing who I was (they have my name, address, and SSN at the very least), they were able to glean slightly more about my family than I even know, since I couldn’t remember when Pat was born. (There’s a lot of us. Cut me some slack.)  So I have to wait for my password to come in the mail. This happened in an automated fashion, and it took about… 7 seconds? Maybe 10?

It was disconcerting.

I can’t decide how I feel about Google Wave yet. In some ways, it seems to me like they took Usenet and IRC, threw them in a blender with Gmail, and then threw the somewhat messy result into my browser. It’s clearly still in beta.

That being said, it’s sorta cool, and I have invites. So if anybody wants one, ping me. All yours.

By “strange places” I mean /System/Library/CoreServices, and by useful things, in this case, I mean Server Assistant. That’s where it lives now, along with Directory Utility, and a few other useful things like Screen Sharing and Kerberos.

This comes up because I needed to create some AutoServerSetup files, something I hadn’t yet had to do for Snow Leopard. Naturally, I go looking for Server Assistant in /Applications/Server, where it would have been under Leopard, and of course it wasn’t there.

CoreServices seems to have become a dumping ground for things that fall into the “Apple would rather you didn’t run these unless you really need to” apps. There’s other ways to get to them, of course. You can start Server Assistant from Server Admin, and Directory Utility is now launched from the Login PrefPane. But it just seems like a pain. Directory Utility is a useful utility. Put it in the Utilities folder. Server Assistant is useful when you have servers to set up. Put it in the Server folder.

I was setting up a fresh new Xsan the other day. All the systems were Intel-based, all of them were running Mac OS X 10.6, and we were installing Xsan 2.2. So I enabled Extended Attributes on the volume. So far, so good.

Towards the end of the engagement, I had reason to share a folder on the volume from the NAS bridgehead via SMB. I connected from my MacBook, moved some files back and forth, and all was good. I connected from a Windows XP machine, and tried to copy a file off the volume. The progress bar got just about all the way to the end before it was rudely stopped by an error.

Error Copying File or Folder
Cannot copy FILENAME: Cannot find the specified file.
Make sure you specify the correct path and file name.

I turns out that Windows (XP, at least - I haven’t tested on anything else) is not so happy with those extended attributes. No big deal, though. You just have to disable those. If you look in /etc/smb.conf, you’ll notice two lines:

stream support = yes
ea support = yes

Just change those both to no. This is the same fix that’s required to get roaming profiles to work properly for Windows clients.

Anybody who knows me knows I’m a Dodger fan. My priorities are, in order:

1. My family
2. Baseball
3. Everything else

I just thought you should know this before continuing.

On July 10, Matt Kemp hit his third Grand Slam of the season. There was a lot of talk about this at the time, since the NL record for most grand slams in a season (tied this year by Albert Pujols, as it happens) is only 5. Three is pretty good.

There was also a lot of talk earlier in the year about Matt Kemp batting 8th in the lineup. So much talk that Dodger Thoughts had to resort to a The Matt Kemp Batting Eighth Get It All Out of Your System Thread.

Nobody, that I saw, really stopped to put these two things together. Think about it - how do you hit a Grand Slam? You have to be able to hit a home run, which isn’t easy, but lots of people can do it. You have to be able to do so with the bases loaded, which I’m sure is an even tougher feat. But the most important part is that you have to come up to the plate with the bases loaded. And there’s nothing you can do to control that. If it happens, it happens. If it doesn’t, it doesn’t.

The middle of the Dodgers lineup was definitely being productive in the earlier part of the season, which meant that in the 8 spot, Kemp was getting to the plate with good odds of having runners on base. It was like a second cleanup spot.

So how, metaphorically, does one hit a grand slam? Somebody needs to have loaded up the bases for you first. If you’re dealing with a computer guy, and he seems to keep hitting those metaphorical grand slams, you should ask yourself who keeps loading up the bases for him. If it’s you/your employees/your business practices that’s creating the situations in which it’s possible for this guy to pull out grand-slam-grade accomplishments, you might want to consider making everybody’s life a bit easier.

If situations like this are arising without apparent outside intervention, you might want to look into your computer guy’s abilities and practices.

If you are the computer guy, and you keep finding yourself in these situations, then you should take a long, hard look at the way you’re maintaining your systems, look at your workflow, and figure out who is loading the bases for you, and find a way to make it not happen.

Anyway. Go Dodgers.

I ran into a strange problem a little while ago, and it seems to be showing up more and more. What happens is, your Xsan clients suddenly can’t mount volumes. Sometimes the mount point is there but the volume doesn’t mount, sometimes neither, sometimes the volume does mount. It’s all very intermittent, and it’s a bit maddening.

It only happens after the 10.5.8 update, and only (from what I can tell) on clients that were originally running Xsan 1.4, and were upgraded to Xsan 2.

serialnumberd, and I’m sure you’re aware, is required for an Xsan client to work properly. With Xsan 1, this got launched by a Startup Item, namely /System/Library/StartupItems/SerialNumberSupport. With Xsan 2, this gets launched by a LaunchDaemon, /System/Library/LaunchDaemons/com.apple.SNServer.plist. If you happened to start with Xsan 1, and upgrade to 2 (and along the way probably went from Tiger to Leopard), you might have both. If you happen to have both, and you ran the 10.5.8 update, things might break.

It’s easy enough to test. Just kill the Startup Item.

sudo SystemStarter stop SerialNumberSupport

Give it a minute. If your Xsan volumes suddenly decide to mount, then you should consider moving that Startup Item out of the way. It will bring you nothing but tears.

Let’s just assume that you have some Macs with an administrative account whose password needs changing. (There’s so many possible reasons for this that hypotheticals are really unnecessary.) They’ve got ARD running, but actually controlling them, and using System Preferences to change the password:

• is time-consuming
• is also tedious
• means you might have to interact with somebody, and
• is time-consuming.

So you select the computers that need passwords changed, click that handy-dandy little “UNIX” button (or go to Manage -> Send UNIX Command…), and enter the following.

dscl -u username -P password . -passwd /Users/username newpassword

If you’re unfamiliar with dscl, I highly recommend you check out the man page. The first username and password are to authenticate as a user than can actually make the change you’re trying to make. The dot is where we specify the data source - which directory node we want to make a change in. Since this is a local acccount, we can just use the local domain. Then we specify the command (in this case, “-passwd” to change a password), the path to the user (relative to the data source - I know that /Users/username would also be the location of their home directory, but that’s just a coincidence), and the new password.

And then, we make extra special certain that we clear our History, because otherwise, anybody who gets their hands on our computer now has both old and new passwords.