When we first installed Leopard Server, we found that Spotlight wasn’t working on the server by default. A number of people have also found this to be true, and some people have suggested it may have something to do with installing on to a RAID 1 drive setup (as we did).

The following is a possibly solution to get Spotlight working if you are having this issue¹.

1. Login in to your server as an administrator.
2. Open the Terminal application (in your /Applications/Utilities folder)
3. Type the following exactly as written in to the Terminal:
   

   sudo rm /.metadata_never_index

   It will ask you for your password. You may get a “file not found” error, as the file has only been reported as being there for some users. Regardless, move to step 4.

4. Type the following in to the Terminal:
   

   sudo mdutil -i on /

Spotlight in the right corner of the menu of your server login should indicate it is indexing, and before long will start working.

1. This post is based on a discussion in Apple Discussions, and fixed the problem we had been having with our server.

Leopard Server makes use of Open Directory, an LDAP based directory service of resources – including users and shared contact information. As I mentioned in a previous article, you can set up other Address Book software (such as Thunderbird’s) to access the shared contacts using LDAP.

When it comes to editing these shared contacts, things are a little less straightforward. Leopard comes with an application called “Directory”, that allows you add/delete and edit shared contacts. The trouble is, in doing this, it uses non-standard LDAP attributes (not that there is a “standard” as such, but the ones they use aren’t even used by their own Address Book application). So it is best you just ignore this feature of Directory until Apple fix it – (I’ve logged it with Apple – radar bug report number 5801945).

If you are on a Mac, your best bet is to create your shared contact in Address Book, and then drag the entry to Directory. This works great, except that “notes” are lost. – I’ve logged this as a bug with Apple (radar bug report number 5818049)

If you aren’t on a Mac, or you don’t like the Address Book hack to get around Directory issues, you need another tool to edit the shared contacts. I have found very few tools that could authenticate with a default Open Directory set up – mainly because the client needs to be able to authenticate with SASL, and handle CRAM-MD5 challenge responses.

The one LDAP editor I found that works is Apache Directory Studio.

Once installed, the settings are basically (assuming your Leopard server has domain “yamato.internal“):

Network Parameter
Hostname: yamato.internal
Port: 389
Encryption: [No encryption or SSL]

Authentication
Authentication Method: CRAM-MD5 (SASL)
Bind DN or User: [Your OD username]
Bind Password: [Your OD password]

Browser Options
Base DN: cn=people,dc=yamato,dc=internal

Leave all other entries as defaults.

Once setup, you can connect and browse to entries. You can edit the entries and save them as required.

This means you can, for example, easily edit an existing shared contact. You could even use it as a crude way to enter shared contacts, by creating a template entry, and using that for new entries. Not pretty, but at least will give you correct attributes for LDAP Address Book searches.

There are better LDAP based address books with editing capabilities on the net, but I couldn’t find any that could authenticate with Open Directory beyond the one mentioned here. If you find any, leave me a note in the comments.

Leopard Server makes use of Open Directory, an LDAP based directory service of resources – including users and shared contacts. Address book in Leopard client will automatically search Open Directory for users and people, but if you need to access these contacts from other software (Outlook, Thunderbird, etc.), you’ll need to set up your own LDAP search. The following will show you the needed parameters.

Suppose, for example, you are using Thunderbird. For the example, assume your Leopard server has domain name “yamato.internal“. Then you enter the following in the Thunderbird Address Book when creating a new LDAP server entry:

Hostname: yamato.internal
Base DN: cn=people,dc=yamato,dc=internal
Port Number: 389
BindDN: [Leave blank]

This will allow you to search for “people” – i.e. shared contacts entered through Apple’s Directory application in Leopard or some other application. Keep in mind there are huge bugs in the Directory application that ruin this bit – you’ll need to drag people from your local Address Book to Directory to ensure the shared contact works with LDAP search rather than edit them in the Directory application itself, or you may want to enter “people” using some other third party tool (see next blog article I’m writing).

If you want to search on users, change the cn=people to cn=users.

Apple’s Leopard Server appears to have a major bug that is causing havoc for those users unlucky enough to see it occur on a daily basis.

Basically, DirectoryService is crashing on users of Leopard Server. This in itself isn’t a big problem – Leopard Server restarts DirectoryService if it fails. The problem is with AppleFileServer. AppleFileServer seems to lose the ability to authenticate users with the new instance of DirectoryService. This means Time Machine backups stop working, and users can’t mount the server using AFP.

Currently, as of 10.5.2, this has still not been fixed. Apple have apparently given users suggestions such as sending a HUP signal to AppleFileServer at regular intervals to get things back on track, but in my limited testing, this doesn’t work – leaving the user with the ability to only mount certain shares.

The only reliable solution I’ve found is to restart AFP. Obviously we don’t want to do that all the time – it should only be done when DirectoryService crashes. To do this, I’ve built the following launchd daemon. Basically, it works as follows:

The daemon watches the /Library/Logs/Crashes directory, and wait until a crash occurs. When it does, it runs a script that checks to see if the crash was a DirectoryService crash, moves these crash files away in to a sub-directory, and restarts AFP.

Not a great solution, as if someone is connected at the time, they get booted and have to remount. I’m experimenting with other fixes people have listed that don’t require AFP to be restarted, but so far I’ve found they don’t seem to work consistently.

You can download the daemon here.

Once downloaded, uncompress the file (double click in Finder). Safari may unzip it automatically for you.

From a Terminal, cd to the unzipped folder (if downloaded from Safari, by default it will be in ~/Downloads).

cd ~/Downloads/restartafp

Now, type the following. Note that you need to be logged in as an administrator, and you will be asked for the administrator password in order to do the first operation.

sudo mkdir \
/Library/Logs/CrashReporter/DirectoryService
sudo cp com.curmi.restartafp.plist \
/Library/LaunchDaemons/
sudo cp restartafpondscrash.sh \
/usr/local/bin/
sudo chmod a+x \
/usr/local/bin/restartafpondscrash.sh
sudo launchctl load \
/Library/LaunchDaemons/com.curmi.restartafp.plist


To test this is working, you can do the following, and check /var/logs/system.log to see if it mentions the restart.

sudo touch \
/Library/Logs/CrashReporter/DirectoryService_trigger.crash


If for some reason you want to uninstall, run the following commands from the Terminal.

sudo launchctl unload \
/Library/LaunchDaemons/com.curmi.restartafp.plist
sudo rm \
/Library/LaunchDaemons/com.curmi.restartafp.plist
sudo rm /usr/local/bin/restartafpondscrash.sh
sudo mv \
/Library/Logs/CrashReporter/DirectoryService/* \
/Library/Logs/CrashReporter
sudo rmdir \
/Library/Logs/CrashReporter/DirectoryService


I hope this is useful to others out there. I’ve filed this bug with apple (radar bug report number 5836741), and I hope Apple fixes it soon.

The fix I’m currently trialling was listed here, and suggests that rather than doing:

serveradmin stop afp
serveradmin start afp


in the script, we do:

serveradmin settings afp:authenticationMode = "standard"
serveradmin settings afp:authenticationMode = "standard_and_kerberos"

I’ve tested this and it didn’t seem to work, but I’ll try it again just in case. I’m sure DirectoryService will crash on us sometime tomorrow to confirm if the fix works or not.