[LUG] OpenLDAP as Address Book Server for Netscape Messenger and Outlook address books.
So you'd like to share all the Netscape or Outlook Express or Outlook
address books across your company, but you don't want to buy expensive
proprietary mail software from people who try to lock you into their
brand, you'd prefer free, open source software. Well here are some
List - I finally got some more time to try this again - and it took a
while for my first successful OpenLDAP install - however the task is
pretty straightforward and with detailed instructions I think an hour or
two would be enough to get things pretty much sorted (Except perhaps
cleaning the data in the address books!!!) for a big company.
I'm posting to the list - not least because I haven't found a good HOWTO
despite this being a frequently asked question on the LDAP lists - and
having found my original question to the D&C LUG list in a Google search
I figure we get them indexed okay.
Get latest OpenLDAP and install.
Follow getting started quick guide;
Edit the slapd.conf guide to include relevant schema - this is where
actually knowing LDAP in depth would help.
Better men than I suggest including all the schema files provided. In
theory you can hunt down the Netscape schema files, and make a Netscape
import that doesn't lose any data - see later - but all we are likely to
lose is "date modified" and whether they "like html mail", which will
now be today, and 'why would you send mail in html format ?' (Maybe some
odd address fields - I'm still working on this).
Extract of slapd.conf
Create somewhere in the hierarchy to store all your addresses (I did
dc="eighth-layer",dc="com" - but maybe somewhere else would be better)
as explained in the guide.
Create the manager person as explained in the getting started guide.
Export you address books in 'ldif'. This could be fun. Netscape
Messenger can export LDIF on Linux. Netscape Messenger can import many
formats and export LDIF on Windoze. So yet another use for a Windoze
box, but then if your importing Outlook address books you probably have
the odd Windoze box.
Cleanup your address book ldif. The LDIF format is easily machinable, I
used vi with 'ex/sed' like commands - others use PERL but I haven't
learnt it yet.
Netscape produced something like the Aaron entry below..... well there
were 700+ other entries. You can of course concatenate all your address
books when doing this to get as many as possible in.
dn: cn=Aaron Trevena,mail=betty at termisoc.org
cn: Aaron Trevena
xmozillanickname: Aaron Trevena
mail: betty at termisoc.org
LDIF is very sensitive to white space, at the start of lines it means
continued from above, at the end of lines it gets included in the data,
and a blank lines mean a new record. Junk looking lines are probably
base64 encoding - they'll look okay in applications - honest.
Two big hacks are required to the above.
First we want to change the "dn:" so it goes where we want it in the
LDAP hierarchy. So I made them all something like;
dn: cn=Aaron Trevena, dc=eighth-layer,dc=com
Second we need to add to the list of objectclass's so that the schema we
are importing into is more similar to the Netscape schema. Thus these
two lines were appended to each entry (Oh and I forgot that a carriage
return is "crtl-v <CR>" when entered in vim as part of a substitute
Basically now you do an 'ldapadd' as in the getting started guide,
logging in as manager. You can use "-c" to ignore errors, but I'd
suggest taking the first ten records or so of the top of the list and
figuring out what causes the errors before using "-c".
Doing it the way I have suggested will mean some attributes are not in
the schema, and so you need to delete some lines from the ldif file you
want to import. If you have the schema viewer tool (latest gtk required
to compile) you can probably look up what works , or even add the
relevant onjectclass - but I found trial and error worked okayish. The
error messages are not brilliant.
Once I was happy importing the first ten records - I spewed the whole
list through with the "-c", it will then take the first copy of
duplicated records, and spit problems to standard error, I got about 80%
of my Netscape address book in first time. You can rerun having fixed
the LDIF file as duplicates are discarded.
Now I opened the Netscape address book, and added a new LDAP server
(Starting at dc=eighth-layer,dc=com) - changed my preferences to use the
LDAP server when looking up entries for addressing e-mail - and voila -
an open protocol, open source, network sharable list of addresses - no
more - "What is Aaron's e-mail address?" from my numerous co-workers
(Urm - okay I'm working on getting enough business to employ some
What I learnt - what needs improving - where next.................
Basic LDAP and LDIF are pretty straightforward despite appearances to
the contary, a little patient reading the OpenLDAP web site pays of.
This is probably why the documentation is so lacking *8-).
I have too simplistic a hierarchy, at the very least I probably should
have created some sort of "container" under dc=eighth-layer,dc=com for
the company address book in case I want to use LDAP for other things in
future (You don't need the LDAP hierachy to reflect the DNS hierarchy -
but hey why not - I want to go where everyone knows my name *8-)
I should probably have persisted with finding the Netscape schema - as
Netscape have a huge amount of poorly indexed documentation on these
things as they sell their own directory server, and it will make life
better for Netscape users.
I definitely should have downloaded a point and click schema viewer -
but it required the latest GTK - so I was put off by the effort of
getting libraries etc (My Redhat 7 CD's arrived the morning after, duh)
Indexes - I didn't add any indexes - hmm well 500+ addresses were okay
sorting by all the criteria Netscape allows but I think it would be a
good idea to at least think about such things.
Update tools - I don't have a graphical update tool for the address book
- I found a lot of references to a PHP based tool - so looks like one
for the Intranet master.
Mailing lists - I haven't yet mastered mailing lists - probably the lack
of a relevant schema objects - certainly LDAP understands groups - but
how you get this information to multiple clients......?
Access control lists - I probably should have braved them. Note OpenLDAP
claims to support TCP_Wrappers hosts.allow/hosts.deny security scheme,
so you can restrict access that way as well.
Netscape LDIF export isn't perfect - it happily copies mistakes in the
address book into mistakes in LDIF - although it is better than many
such conversions I have done in the past.
Lots of documentation exists on enabling 'Roaming' where user Netscape
preferences and other files follow them around the network, this is a
spin off of the Netscape LDAP server project.
Perfection - well I'd like perfection in address book handling but
fallible people build fallible address books - Netscape will happily use
it's own address book as well as an LDAP server - so even without
perfection in loading records centrally you get to share the majority of
addresses without any 'loss of information or functionality'. Extra
effort to capture the Netscape schema is probably worth it, better
handling of duplicate entries may also be useful - although not a
problem for me yet - the first step I guess would be to take the latest
'date modified' record over the first record.
Thanks to James Gregory, whose question(!) to the OpenLDAP FAQ-o-matic
was detailed enough to answer all my questions. James is working on a
more advanced FAQ on how to use OpenLDAP and Linux as a full directory
service (Address book, authentication, with replication etc etc) -
Novell eat your heart out.
Disclaimer: Well if you haven't figured it out yet - I'm not an LDAP
expert yet - this is a pragmatic "how I got it working" to help people
trying to do the same thing get over the initial hurdles as quickly as
possible. Use at your own risk.
lug-list - The Mailing List for the Devon & Cornwall LUG
Mail majordomo at lists.termisoc.org with "unsubscribe lug-list" in the
message body to unsubscribe.