LDAP addressbook

Sharing the addressbook of two computers means usually one of two things: Having trouble, or using LDAP. I opted for the second variant since my ISDN call monitor also uses LDAP to look up names for telephone numbers.

The OpenLDAP server ships with some standard schemas that can be used to store address data: person, organizationalPerson and inetOrgPerson. A person has a name, description, telephone number and a password. Far from enough for an address book since it doesn't even has an address field. organizationalPerson goes a bit further and has a telephone number, fax number, postal address and some more. Still no email field... So we're going to the next standard one: inetOrgPerson which has a mobile number field, carLicense, mail and a place for a jpegPhoto.

Now we could live happy forever if a) all programs would support the standard fields and b) we wouldn't have any other things to store in the address book. For example: Birthday and anniversary date, IM (instant messaging) account address, second/third email and a second address (to distinguish between home and work address).

I found JXplorer to be the best general LDAP editor, also suitable to create and maintain address book entries.

Schemas used by popular applications

I spent quite a time searching for the golden standard schema that has all the things I need and is supported by most of the programs (Evolution, KAddressbook and Thunderbird/Mozilla Seamonkey). The conclusion: There is none.

Mozilla has its own schema called mozillaAbPersonAlpha since it is in very early alpha stages. I don't really like the schema since it doesn't fully use the existing ones (inetOrgPerson) and prefixes most own values with "mozilla". Great, isn't it? I don't care if it's mozilla's invention to add that field, I want it to work. While Thunderbird supports exporting its address book to a .ldif file, the generated one cannot be imported into you ldap directory without modifications, since the ldif is broken and has some non-existing fields. I almost forgot to add that Thunderbird cannot add/modify LDAP entries which makes it an LDAP-Viewer only.

Evolution on the other side has also its own schema called evolutionPerson. At least the schema file that installed into /usr/share/evolution-data-server-1.8/evolutionperson.schema when installing gnome-extra/evolution-data-server also contains a class called evolutionPersonList to e.g. group persons into a mailing list. The irony is that even this schema does not support all the settings allowed by the evolution address book itself. Great? The good things is the field names are at least half reasonable, and it has birthday field support.

The golden schema

So, where is the golden standard schema? Asking on the LDAP mailing list I got the definitive answer: There is none.

There were, however, some ideas to think about:

Someone also suggested creating your own hybridPerson schema that combines all schemas (altough you can assign multiple classes to an entry, which I do currently):

# Objectclass: mHybridPerson
# Description: Seals the break in objectclass inheritence created
#   by officePerson and evolutionPerson descending from inetOrgPerson
objectclass ( 1.3.6.1.4.1.6921.1.12
  NAME 'mHybridPerson'
  DESC 'Combine several objectclasses to support multiple MUAs'
  SUP ( inetOrgPerson $ officePerson $ evolutionPerson )
  STRUCTURAL )
  

Conclusion

So, where leaves us this? You are on your own, period. Despite many applications support LDAP, they developers did not even try to standardize the schemas. If only all the programs would allow LDAP entry <-> address book text field associations (which Thunderbird does now), it would be a bit better. Setting up an LDAP addressbook is worth the problems, since you really don't have to sync them anymore.

Other pages

Quanah Gibson-Mount wrote an article called Creating a well defined LDAP directory query interface for email clients (local backup) with a list of things to consider when setting up your own directory.

Written by Christian Weiske.

Comments? Please send an e-mail.