Re: Is the Mozilla LDIF export bogus?

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Jonathan Coles writes:
> I wanted to set up a simple LDAP server and thought that the Mozilla's 
> LDAP capabilities would be a good place to begin. However, I notice that 
> their LDIF entries lack any "dc" attribute. For example,
> 
> dn: cn=A User,mail=auser@hotmail.com
> objectclass: top
> objectclass: person
> objectclass: organizationalPerson
> objectclass: inetOrgPerson
> givenName: A
> sn: User
> cn: A User
> mail: auser@hotmail.com
> o: ThisOrg

Well, the entry itself seems valid enough, provided you either already
have an entry named 'mail=auser@hotmail.com' or the LDIF adds that
before adding the entry you show.  Regarding dc, the above entry's
object classes neither require nor allow that attribute.

However, the data is nonsense:  Why create one entry with your mail
address, and another entry below that for the user and which also has a
mail address?  And as you point out, why is there no sensible suffix?
It's tecnhically legal to put things just under the root, but
inconvenient and not How Things Are Done.

Your collected LDIFs should at minimum be something like this:

   # entry matching your suffix in slapd.conf
   dn: dc=something,dc=com
   objectClass: top
   objectClass: organization
   objectClass: dcObject
   dc: something
   o: Some Organization

   # user entry
   dn: cn=A User,dc=something,dc=com
   objectclass: top
   objectclass: person
   objectclass: organizationalPerson
   objectclass: inetOrgPerson
   givenName: A
   sn: User
   cn: A User
   mail: auser@hotmail.com
   o: ThisOrg

   # user entry
   dn: buser@hotmail.com,dc=something,dc=com
   objectclass: top
   objectclass: person
   objectclass: organizationalPerson
   objectclass: inetOrgPerson
   givenName: B
   sn: User
   cn: B User
   mail: buser@hotmail.com
   o: ThisOrg

The suffix entry must exist, otherwise you can't add entries below it,
but need not have a dc name - that's just a common convension.  Could be
an organzation (named by an o), or an ou, or whatever.  We'll be going
to cn=people,dc=uio,dc=no soon.

Similarly, which attribute(s) in your user entries you pick for their
names is your choice.  We use uid.

I wouldn't put the 'o' attribute is the user enties, but I guess that's
a matter of taste - and of what your clients want.  I prefer to put
organizational information in organizational entries and user entries
either below the orgnaizational entries or with references to them.

-- 
Hallvard