[Date Prev][Date Next]
Re: Is the Mozilla LDIF export bogus?
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,firstname.lastname@example.org
> objectclass: top
> objectclass: person
> objectclass: organizationalPerson
> objectclass: inetOrgPerson
> givenName: A
> sn: User
> cn: A User
> mail: email@example.com
> o: ThisOrg
Well, the entry itself seems valid enough, provided you either already
have an entry named 'firstname.lastname@example.org' 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
o: Some Organization
# user entry
dn: cn=A User,dc=something,dc=com
cn: A User
# user entry
cn: B User
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.