[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-software
Subject:    Re: Building an LDAP database "for dummies"
From:       Howard Chu <hyc () symas ! com>
Date:       2004-06-30 13:14:23
Message-ID: 40E2BCAF.2080200 () symas ! com
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]