setting up an LDAP-server for use with kaddressbook
This is a summary of my experience in setting up a local LDAP-server for
managing/sharing address data in my tiny home-lan – so don’t expect too much here,
I’m not an expert in LDAP, things mentioned here may be incomplete or even
wrong – I write this mainly as a reference for myself.
First, I will list the software/versions which I ended up to use for the given task,
all the following descriptions are only tested with this environment, and may not work at all
with other packages/versions.
As a first start, I followed the instructions in the openldap quickstart guide to get a basic setup for the server.
This turned out to work with the given example, but failed to import ldif files exported from
kaddressbook – I got all kind of errors, regardless what I tried .
Finally, I found out that these were mostly related to not having included several schemas
into my slapd.conf file – namely the following:
include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/openldap.schema
Another hint is to NOT have any spaces,tabs or whatsoever at the beginning and end of each line in ldif-files – ldapadd is VERY picky about this !
During these investigations, I also tried some GUI frontends to manage LDAP-servers,
namely directoryadministrator, ldapexplorer etc., which would partly work,
but ended up using phpldapadmin (see link above) which turned out to be by far the
best of all I tried – so I can strongly recommend it.
Once a basic server installation is completed, you can do all common tasks such
as add/delete/modify entries, import/export ldif data and so on from phpldapadmin –
Now, let’s take a look at the goal of this project and figure out how to achieve this:
- populate the server’s database with entries currently stored in local ~./kde/share/apps/kabc/std.vcf
- merge with other user’s address data
- adapt user permissions, so that each user can modify/delete his own entries,
but only read those created by others
- connect kaddressbook to the LDAP server
- evtl. try to add/modify/delete entries on server via kaddressbook
As for 1., I exported my addressbook to an ldif file and tried to import this into my LDAP server.
However, this didn’t work without modifications:
First, I had to realize, that the ‚dn: ..‘ line had to be accomplished by my
base definition, e.g.
dn: cn=Mustermann, Hans
had to be replaced by:
dn: cn=Mustermann Hans,dc=mydomain,dc=com
Also note, the comma ‚,‘ after the Name in the exportfile, was not accepted by ldapadd, so it had to be removed.
Another hint is to remove any ‚mail=xxx‘ entry from the ‚dn: ..‘ line,
which are present in each export record that has a ‚mail:‘ attribute.
Then, there are attributes in the ldif export, for which any value is just rejected,
these are uid+modifytimestamp – I just filtered them out using ‚grep -v …‘.
Other attributes which are not accepted may be replaced by equivalents,
a list is as follows:
In addition, each entry with a ‚mail:‘ attribute had to be accomplished by a line:
– otherwise, ldapadd would refuse to import
the ‚mail‘ attribute.
All these quirks lead me to the opinion, that there must be major differences between the
schemas which come with openldap compared to those which kaddressbook export supposes
to be used.
Currently I’m trying to find out which ones these are (the answer I got so far on the kde-pim mailinglist was that they are using ’standard‘ schemas) – this would make import much easier, of course.
If this fails, there is still the possibility to hack together a perl script which does
most (if not all) of the modifications mentioned above – if I do so, this script will be published here (not for the sake of all perl gurus out there who will probably ROTFL ).
Ok – here it is: ldif.pl – usage: ‚ldif.pl export.ldif > import.ldif‘ –
this will create a file ‚import.ldif‘ from kaddressbook export ‚export.ldif‘ which hopefully
needs not much work to sucessfully beeing read by ldapadd.
With all this in mind, here are the basic steps needed to be done:
- adapt slapd.conf to your local needs (see above)
- start the slapd daemon
- create a basic structure – ‚ldapadd -x -D „cn=Manager,dc=mydomain,dc=com“ -W -f base.ldif‘ (example for base.ldif)
- export kaddressbook data to export.ldif
- convert export.ldif to import.ldif (see above)
- edit import.ldif (check double entries, crappy entries..)
- populate your ldap database – ‚ldapadd -x -D „cn=Manager,dc=mydomain,dc=com“ -W -f import.ldif‘
- if anything goes wrong at some point, edit import.ldif to correct for errors, delete everything already imported and try again
Having solved all of the mentioned problems, there will be an LDAP-database, which can now be
searched by the ‚LDAP-search‘ function in kaddressbook, provided kdelibs,kdebase+kdepim
have ldap-support enabled (for me on gentoo here, this meant to
add ‚ldap‘ to my use-flags and re-emerge the mentioned packages, others will have to set
the correct option(s) for configure etc. depending on the distro).
LDAP connectivity is enabeled from the kaddressbook configuration dialog.
From the search-function, one can select entries to import to the local addressbook,
however, this import obviously adds some ‚extra-characters‘ to each attribute –
see the little squares on this screenshot.
After all, I also found that the handy ‚CTRL-T‘ function in kmail, which autocompletes
mailaddresses once they are unique as typed in, does also search the LDAP
This is nice, the only basic missing function in kaddressbook with respect to LDAP seems to be the lack of a
‚List‘ function, showing all entries in the LDAP database.
So, what’s left at the moment (besides what has already been mentioned) ?
Well, for 2. + 3. of the ‚todo-list‘ above, I have not yet done anything,
if 5. will be available in future versions of kaddressbook, will have to be checked
(there is no indication for this in the kde3.3 planned features list – I will evtl. add this to the wishlist ?) – if not, there is phpldapadmin, anyways.
To be continued….
Ok, I know that all the above LDAP stuff can probably be done by just install a
Kolab Server – but I think this comes with tons of
other (for me unnecessary) stuff, and after all, isn’t it also fun to find out how
things work, anyways ?