Exporting mozilla address book to openldap.
Hans Deragon
I am trying to export my mozilla address book to openldap. I am new
to LDAP and do not know too much. Does anybody have a quick receipe on
how to do it?
I have tried, but failed. My openldap server is up and running, and
is, as far as I can tell, properly initialized. So, I took a snipet of
the ldif file created from Mozilla 0.9.9 and put it in the file
oneaddress.ldif. Here is the content:
--->
dn: cn=Hans Deragon,mail=ha...@deragon.biz
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
givenName: Hans
sn: Deragon
cn: Hans Deragon
xmozillanickname: moi
mail: ha...@deragon.biz
xmozillausehtmlmail: false
modifytimestamp: 0Z
<---
Now when I try to add this entry, here is what I get:
--->
[root@world root]# ldapadd -x -W -f b -D "cn=Manager,dc=deragon,dc=biz"
Enter LDAP Password:
adding new entry "cn=Hans Deragon,mail=ha...@deragon.biz"
ldap_add: No such object
ldif_record() = 32
<---
Anybody knows what a "No such object" error is and what can be done
to correct this? Or, as I asked earlier, anybody has a direct and quick
way to convert my mozilla address book into an ldap directory?
Sincerely,
Hans Deragon
Rich Megginson
Roland Felnhofer
First of all you have to decide if you want to use schema checking yes
or no.
I would recommend to do so. It will make the initial import a little bit
harder but will pay of later.
If schema check is enabled for all attributes and objectclasses you are
using you have to have a proper definition. Just have a look into your
schema directory and look how they look like.
For Mozilla there is already a proposed schema file available (which has
to be a bit modified to use with what you get when you make an address
book export. (I don't want to discuss here why the proposal and the
current ldif export doesn't match - simply historical reasons.)
Here I'm pasting you will get if you use Mozilla {Build ID: 2002051104)
which should be available in 3-6 hours (just look at
http://ftp.mozilla.org/pub/mozilla/nightly/latest/ until you see a build
from 11th May):
dn: cn=Hugo Test,mail=hu...@mail.com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: mozillaAbPersonObsolete
givenName: Hugo
sn: Test
cn: Hugo Test
xmozillanickname: Hugi
mail: hu...@mail.com
mozillaSecondEmail: hu...@mail.net
xmozillausehtmlmail: true
modifytimestamp: 0Z
telephoneNumber: +99-1-47110815
homePhone: +99-1-47110814
facsimileTelephoneNumber: +99-1-47110813
pager: +99-1-47110812
mobile: +99-1-47110811
homePostalAddress: Hugo Street 15
mozillaHomePostalAddress2: corner Dow Street
mozillaHomeLocalityName: Hugovill
mozillaHomeState: SW
mozillaHomePostalCode: 4711
mozillaHomeCountryName: Fantasia
postalAddress: Fool Street 18
mozillaPostalAddress2: close to Silly Road
l: Foolvill
st: ID
postalCode: 1508
c: Fantasia
title: Fool
ou: Do-noting
o: Lazy Ldt.
workurl: http://www.lazy.net
homeurl: http://www.hugo.net
custom1: Custom1
custom2: Custom2
custom3: Custom3
custom4: Custom4
description: And here you can place some notes!
you have to ensure you have to have at least the following three
includes in your slapd.conf:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
that would cover about have of the attributes used in the AB ldif export.
The following attributes are not defined:
xmozillanickname
mozillaSecondEmail
xmozillausehtmlmail
homePostalAddress
mozillaHomePostalAddress2
mozillaHomeLocalityName
mozillaHomeState
mozillaHomePostalCode
mozillaHomeCountryName
mozillaPostalAddress2
workurl
homeurl
custom1
custom2
custom3
custom4
so you have to generate your own schema file. You can use, as already
mentioned the schema proposal
(http://bugzilla.mozilla.org/attachment.cgi?id=63828&action=view) as a
template.
But be aware that you have either edit the schema so it reflects the
ldif export or edit the attributes in the export so the fit the schema.
I, personally, would edit the ldif file to fit the schema, but that's
just the way I would do it.
(None of them will last for ever - both are preliminary!)
What ever way you will chouse here are the last modifications you have
to do in the ldif file.
1)
You have to get rid of all entry 'modifytimestamp: 0Z'
That attributes are generated automatically by your LDAP server and are
ready only from the user side.
2)
you have to modify the 'dn' entry (in my example 'dn: cn=Hugo
Test,mail=hu...@mail.com') so it reflects the hierarchical structure in
your ldap tree on your ldap server.
Let's assume our top level structure is 'dc=deragon,dc=biz'
and you want to place all our Mozilla AB addresses in an 'directory'
'mailusers'.
you would have to create a 'organization' or 'organizational unit'
'mailuser'. Let' assume you decide to make an 'ou' - the ldif file to
create would look like this:
dn: ou=mailusers,dc=deragon,dc=biz
ou: mailusers
objectClass: top
objectClass: organizationalUnit
After you have created that 'ou' you have to change all 'dn' entries in
your ldif export.
In my example from:
'dn: cn=Hugo Test,mail=hu...@mail.com'
to
'dn: cn=Hugo Test,ou=mailusers,dc=deragon,dc=biz '
that have to be done for all addresses!!
If you just want to export your AB once and have less than 50 address it
might not be worth to write a script you could do it by hand.
Now it should work! None the less the Mozilla LDAP interface currently
does not support all attributes which are supported by the address book.
That’s a bug it's worked on. If you want to track it here are some
relevant links:
http://bugzilla.mozilla.org/show_bug.cgi?id=116692
http://bugzilla.mozilla.org/show_bug.cgi?id=118454
http://bugzilla.mozilla.org/show_bug.cgi?id=118585
http://bugzilla.mozilla.org/show_bug.cgi?id=119360
http://bugzilla.mozilla.org/show_bug.cgi?id=142940
If there are still some questions open - which would not surprise me ;-)
- don't hesitate to contact me.
Cheers
Roland
Roland Felnhofer
I've attached an modified version of the proposed Mozilla ldap schema
from Kristof Petr with some modifications. Either to keep the attribute
syntax consistent or to work with the ldif export.
None the less you have to make modifications to the ldif export file.
But with a 'search replace' job in an editor it shouldn't be too much work.
Cheers
Roland
Michael Ströder
>
> I've attached an modified version of the proposed Mozilla ldap
schema
> from Kristof Petr with some modifications.
Let me comment on this:
1. It justs repeats all the commonly used attributes with prefix
mozilla. Especially I'd like to see a smarter handling for
multi-valued attribute mail in LDAP person entries instead of
seeing a schema with mozillaSecondEmail.
Also I'd like to see a definition which of the commonly used LDAP
attributes are mapped to which Mozilla internal attributes.
2. mozillaCustom* - ouch!
3. mozillaAbPersonObsolete is a structural object class derived
from top. This means Mozilla entries are separate and have to be
copies of other commonly used person entries (with e.g. object
class inetOrgPerson or derivatives). This doubles the number of
entries which is bad for performance and licensing costs.
Frankly, this schema does not make sense to me at all...
Ciao, Michael.
Roland Felnhofer
I'm very sorry to say that. The schema makes a lot of sense! It helps
Hans to use his ldif export NOW. That schema where never ever intended
as an final version nor as an final proposal (I mentioned that!). It
were just intended as an ad-hoc solution for Hans to help him to import
his ldif file. I'm well aware that this schema is far from perfect.
Sorry for my harsh words, but it drives me crazy when people just read
half of the replays and then start complaining.
But your are very welcome to help to develop a 'smart' Mozilla schema. I
mentioned the most important bugs dealing with this issue already in
my first reply to Hans. Further on there is a bug dealing with the
'multivalue' problem (http://bugzilla.mozilla.org/show_bug.cgi?id=119199)
ad 1)
> It justs repeats all the commonly used attributes with prefix mozilla.
Actually I don't know what you mean with that.
All attributes prefixed either with 'xmozilla' or 'mozilla' are not
defined in any RFC.
> Especially I'd like to see a smarter handling for multi-valued
attribute mail in LDAP person entries
> instead of seeing a schema with mozillaSecondEmail.
So I am! ;-) see http://bugzilla.mozilla.org/show_bug.cgi?id=119199
But it's not there jet and so Hans can not use it.
> Also I'd like to see a definition which of the commonly used LDAP
> attributes are mapped to which Mozilla internal attributes.
See above.
If you want to see an mapping between Mozilla internal address book ,
LDAP and MS Exchange have a look at the latest attachment to bug 118454
(http://bugzilla.mozilla.org/show_bug.cgi?id=118454)
ad 2)
> mozillaCustom* - ouch!
Definitely not ideal - but it's there
ad 3)
> mozillaAbPersonObsolete is a structural object class derived
> from top. This means Mozilla entries are separate and have to be
> copies of other commonly used person entries (with e.g. object
> class inetOrgPerson or derivatives)
Yes.
See discussion about that in the already mentioned bugs.
> This doubles the number of entries which is bad for performance and
licensing costs.
What do you mean with that? Why do you have to double the number of
entries and why does it effect the licensing costs?
Cheers
Roland
Michael Ströder
I will take a look at the pointers.
Roland Felnhofer wrote:
>
> Further on there is a bug dealing with the
> 'multivalue' problem
> (http://bugzilla.mozilla.org/show_bug.cgi?id=119199)
This problem most times hit me if I'm just writing new e-mails.
One approach would be to just loop over a multi-valued mail
attribute and display several possibilities in the select list
(exactly like the other completion variants are displayed).
If starting to create an e-mail from the address book all
attribute values of mail could be added as Cc: address lines.
I have no suggestion for how to improve displaying the entries in
the address book.
> But your are very welcome to help to develop a 'smart' Mozilla
> schema.
> [..]
> > It justs repeats all the commonly used attributes with prefix
> > mozilla.
> Actually I don't know what you mean with that.
> All attributes prefixed either with 'xmozilla' or 'mozilla' are
> not defined in any RFC.
Off course these attribute names are not mentioned in any RFC.
I would not define a Mozilla LDAP scheme. I'd just like to see a
mapping which already seems to be there.
And I'd suggest to read through RFC1274 (or
draft-ietf-ldapbis-user-schema), RFC2256 and RFC 2798 to make
comfortable with what is typically used in corporate LDAP
directories holding personal data.
> > This doubles the number of entries which is bad for performance and
> > licensing costs.
> What do you mean with that? Why do you have to double the number of
> entries and why does it effect the licensing costs?
mozillaAbPersonObsolete is defined as structural object class
directly derived from top. Today most times the structural object
class inetOrgPerson defined in RFC2798 is used for person entries.
Many applications deal with attributes allowed in this object
class very well.
Now according to LDAPv3 each LDAP entry may only have one
structural object class assigned to it (which strictly spoken
cannot be altered later without removing and readding the entry).
inetOrgPerson is derived from organizationalPerson (structural)
which is derived from person (structural) which is derived from
top (abstract). Therefore the LDAP server might return all three
object classes as attribute values for attribute objectClass which
looks like a person entry has three structural object classes. But
in fact it only has inetOrgPerson as structural object class.
Having said that it's clear that it's illegal to have an entry
with object classes inetOrgPerson (very common) *and*
mozillaAbPersonObsolete.
=> you have to create separate entries with different
distinguished names to store the Mozilla-specific attributes.
Now licensing costs for e.g. iPlanet or Netscape Directory Server
and many others are calculated by counting distinguished names...
Got the message?
Two possible solutions to add the Mozilla-specific attributes (if
really needed):
1. Derive (sub-class) mozillaAbPersonObsolete from inetOrgPerson.
This has the caveat that it does not work in most corporate
directories where often the schema for person entries is already
extended by sub-classing inetOrgPerson. (No circles allowed in
sub-classing, no inheritance possible from more than one
structural object class...)
2. Make mozillaAbPersonObsolete an auxiliary object class which
can be added and removed to/from any entry. (An entry may have
added or removed auxiliary object classes after creation.)
Ciao, Michael.
Roland Felnhofer
Please post your ideas how to deal with multivalue entries also under
bug 119199 (http://bugzilla.mozilla.org/show_bug.cgi?id=119199) so we
can use your input when we start working on it.
> Off course these attribute names are not mentioned in any RFC.
I think did make clear enough what I meant with that. I didn't mean that
for example 'mozillaHomeLocalityName' is defined in any RFC. What I
meant was that there is no RFC defined attribute which would fit the
purpose of 'mozillaHomeLocalityName'. So there is attribute defined in
any RFC (as far as I know) that would deal with your home town name.
There is only 'l' alias 'localityName' (2.5.4.7) defined in RFC2256
('organizationalPerson') but it's in most of the cases used for a
persons 'working town' name. If the city a person works varies from his
home city you need another attribute.
You could say 'homePostalAddress' (0.9.2342.19200300.100.1.39) defined
and mentioned in RFC2798 ( / RFC1274 ) could be uses to hold a persons
whole address (street, city, state and zip), because it could hold
multiple line separated by LF or CR/LF. You have to admit that this
would neither be very elegant nor make it very easy to deal with the
individual parts of a persons home address.
> I would not define a Mozilla LDAP scheme. I'd just like to see a
> mapping which already seems to be there.
I suggest you read my posts.
>> If you want to see a mapping between Mozilla internal address book ,
>> LDAP and MS Exchange have a look at the latest attachment to
>> bug 118454 (http://bugzilla.mozilla.org/show_bug.cgi?id=118454)
> And I'd suggest to read through RFC1274 (or
> draft-ietf-ldapbis-user-schema), RFC2256 and RFC 2798 to make
> comfortable with what is typically used in corporate LDAP directories
> holding personal data.
Just a two short comment on that.
1) Belief it or not, I've already done that before you made your
arrogant statement.
2) These RFCs and draft are dealing with "organisational" persons and
not with private people. Nonetheless I don't know why for a company a
person's ' favouriteDrink' is more important than his home locality ;-).
So the priority and the scope by defining those attributes and
objectclasses in that RFCs were laid on companies needs and not on
private people's needs. I think you will agree with me that for a
private person having the possibility to store his friends home AND work
address in a proper format in his LDAP directory is more important than
the possibility to store 'teletexTerminalIdentifier'.
> mozillaAbPersonObsolete is defined as structural object class ....
Yes, you've got me ...
By just providing a quick solution for Hans I forgot to change the
objectclass definition.
The last proposal how to deal with that was that most of use agreed on
defining the Mozilla objectclass as an auxiliary object class. So it
should have been :
objectclass (1.3.6.1.4.1.4203.666.3.100 NAME 'mozillaAbPersonObsolete'
DESC 'Mozilla Addressbook personal data'
SUP top
AUXILIARY
...
So I take the responsibility for having totally messed up Hans LDAP tree
:-(
A little bit more serious - a already said multiple times what ever I
provided for Hans was an ad-hoc solution that would work TODAY and never
ever a final proposal.
> Now licensing costs for e.g. iPlanet or Netscape Directory Server and
> many others are calculated by counting distinguished names...
I don't want to comment on that - it would get sued by them ;-)
Cheers
Roland
Roland Felnhofer
I made a lot of typos in my reply. I only want to correct one here,
which changed the sense in a very impolite way:
> I think did make clear enough what I meant with that. I didn't ...
should have been:
I think didn't make clear enough what I meant with that. I didn't ...
Cheers
Roland
Krištof Petr
Hi Michael.
>
> I would not define a Mozilla LDAP scheme. I'd just like to see a mapping
> which already seems to be there.
>
We too, but it is not possible.
To store two different entries - workstreet and homestreet
(both are SYNTAX 1.3.6.1.4.1.1466.115.121.1.15), you must
use two different attributes. Multivalued attributes are
not solution in this case.
>
> mozillaAbPersonObsolete is defined as structural object class directly
> derived from top. Today most times the structural object class
> inetOrgPerson defined in RFC2798 is used for person entries. Many
> applications deal with attributes allowed in this object class very well.
>
> Now according to LDAPv3 each LDAP entry may only have one structural
> object class assigned to it (which strictly spoken cannot be altered
> later without removing and readding the entry).
>
> inetOrgPerson is derived from organizationalPerson (structural) which is
> derived from person (structural) which is derived from top (abstract).
> Therefore the LDAP server might return all three object classes as
> attribute values for attribute objectClass which looks like a person
> entry has three structural object classes. But in fact it only has
> inetOrgPerson as structural object class.
>
> Having said that it's clear that it's illegal to have an entry with
> object classes inetOrgPerson (very common) *and* mozillaAbPersonObsolete.
> => you have to create separate entries with different distinguished
> names to store the Mozilla-specific attributes.
>
> Now licensing costs for e.g. iPlanet or Netscape Directory Server and
> many others are calculated by counting distinguished names...
>
> Got the message?
Not! I drink 1 liter coffee by now, what is too less to wake up my
brain after morning. But Im continue on it ;-)
>
> Two possible solutions to add the Mozilla-specific attributes (if really
> needed):
>
> 1. Derive (sub-class) mozillaAbPersonObsolete from inetOrgPerson. This
> has the caveat that it does not work in most corporate directories where
> often the schema for person entries is already extended by sub-classing
> inetOrgPerson. (No circles allowed in sub-classing, no inheritance
> possible from more than one structural object class...)
>
> 2. Make mozillaAbPersonObsolete an auxiliary object class which can be
> added and removed to/from any entry. (An entry may have added or removed
> auxiliary object classes after creation.)
>
Can you write more details about it, please? Did not you want
to make some examples?
I looked to www.stroeder.com, so I know you are engage
on this branch.
Thanks
Petr