Re: Missing DN suffix in Mozilla .ldif

[Peter Marschall <peter.marschall@mayn.de>]

Hi,

On Wednesday 05 February 2003 11:03, Tomas Remotigue wrote:
> I've seen similar sample files to this one, but nobody's posted an answer
> on the list (that I could find anyway). I'm exporting a Mozilla
> addressbook, and the result looks like the following:
>
> dn: cn=Joe User,mail=juser@company.com
> objectclass: top
> objectclass: person
> objectclass: organizationalPerson
> objectclass: inetOrgPerson
> objectclass: mozillaAbPersonObsolete
> givenName: Joe User
> cn: Joe User
> mail: juser@company.com
> modifytimestamp: 0Z
>
> This fails with "Object Not Found" if I try to load it through ldapadd.
> Obviously the DN isn't correct -- if I type in the suffix it works (and if
> I remove the modifytimestamp -- I've already added the mozilla
> objectclass). Is anybody aware of a way to "convince" ldapadd to load this
> data (perhaps this is where the BASE suffix in ldap.conf comes in?) or must
> I resort to massaging the data by hand?

These LDIF exports of Netscape's or Mozilla's address books have
strange DNs.
The RDN of the objects is the common name, while the container
each object is in, is the user's mail attribute.
Above that you do not have any suffix.

Maybe workng with an empty suffix in the server will work, 
but I do not know if OL supports it.

Personally I think, Mozilla / Netscape chose to take the two elements
into the DN to make it unique, but unfortunately did not combine them
into rge RDN, but split them into two parts.

To "cure"  the problem I would convert the cooma (,) into a plus (+) 
sing to make a multi-part RDN, and then append a default suffix to every DN.

A simple sed or perl script should be able to do it.

Peter
-- 
Peter Marschall     |   eMail: peter.marschall@mayn.de
Scheffelstraße 15   |          peter.marschall@adpm.de
D-97072 Würzburg    |   Tel:   +49 931 14721
PGP: 0BB1 04A3 0FB0 E27F 8018 52BA A286 7B23 9C22 2C83