[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Building an LDAP database "for dummies"

Jonathan Coles wrote:
Howard Chu wrote:
So - "What is this tree?" - the tree is the structure you design to contain the data you're going to store. Schema is just a description of what kinds of data will be recognized by the server, but it doesn't say anything about the location of the data. The tree structure gives you the location.

But WHERE is this structure I design? Is it the statements in my LDIF file? Is it in slapd.conf? That file includes a suffix statement and some include statements for schema files. Is the schema the definition of the hierarchy?

The schema is not the directory. The schema describes what kinds of information are allowed to exist in the directory. Schema is not a hierarchy, it has nothing to do with the layout of the records stored in the tree. You might think that the schema looks like a hierarchy, as some schema elements inherit from others. But the directory schema supports multiple inheritance, and this by definition is not a hierarchy. Stop mixing the two together - the schema is not the data, and has no bearing on the shape of the directory tree.

The suffix defined in slapd.conf identifies the root of your tree. That just establishes a name for that record. The record itself must still be created.

The records that comprise your tree are fed in from your LDIF file.

I understand the concept of hierarchy. Do I have to define everything up to the entire universe? There is an "objectClass: top" statement that should allow me to stop at some lower level.

In any directory system (filesystem, DNS, LDAP/X.500) you must have a starting point, a "root." But what you consider to be the "root" is not necessarily the universal root. As a filesystem example, I may have / on one disk, and some other disk mounted under /var/tmp. These subordinate mounted filesystems all have their own "root" nodes, but they are not *the* root.

I could create a directory for the ACME Widgets Company, and call my suffix "dc=acmewidgets,dc=com" - I don't have to create "dc=com" and I don't have to create "" (the LDAP root). I just have to tell slapd my root/suffix. Of course, X.500 was envisioned as a universal directory system, and in a "proper" installation you would configure "knowledge references" to point to other servers in the hierarchy (parent, sibling, children, whatever relationships might exist). This concept pretty much fell on the floor when LDAP was created, but it is slowly being reintroduced...

Again, the same idea can be seen in the operation of DNS - if I'm the hostmaster for acmewidgets.com, running my own nameservers, I just need to configure my nameservers with information for my domains, and set up forwarders to point to superior servers. Any hosts in my domain can get information about other hosts in my domain directly from my servers; queries for foreign domains get routed up to a superior server and so on.

My hierarchy is:

 This database
         Users with attributes such as email address, phone number, etc.

My suffix statement (organization is the top of my hierarchy):
suffix o=MyOrg

My LDIF (just one user entry):

dn: o=MyOrg
objectclass: top
objectclass: person
objectclass: organization
o: MyOrg

There are a couple problems with this entry. What error messages you see as a result depends a great deal on which version of OpenLDAP you're using, as older versions were very lax about schema checking and newer versions are more strict.

Both "person" and "organization" are structural objectclasses, and an entry is only allowed to have one structural class. Since you really intend this entry to be an organization, there's no need for the person class here. Also, assuming that the server accepted the person class here, the entry is still invalid because it doesn't contain the attributes that the person class requires (e.g., cn, sn).

dn: cn=A User,o=MyOrg
objectclass: top
objectclass: person
objectclass: organization
givenName: A
sn: User
cn: A User
mail: auser@hotmail.com
o: MyOrg

Again you have a clash here between the person and organization class. In this case, it would make the most sense to omit the organization class and the organization ("o") attribute.

I run:

ldapadd -v -f /home/jont/ldap/myaddr.ldif -h thispc -p 389 -x

result:

add objectclass:
    top
    person
    organization
add o:
    MyOrg
adding new entry "o=MyOrg"
ldap_add: No such object

It would help if the error message stated WHICH object doesn't exist.

It would help if you mentioned what version of software you're using. Newer ones have improved diagnostics relative to older ones.
--
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support