Re: Five fundamental questions from a newbie

[Dave Carrigan <dave@rudedog.org>]

On Thu, 13 Jan 2000, Marian Steinbach wrote:

> dn: uid=marian, ou=Design, o=Fachhochschule Koeln, c=DE
> 
> Are there any disadvantages about this? To me this seems more
> usefull and I was wondering why the written guide used
> non-unique names...

I can't think of any disadvantages, and the advantages of a using a
unique attribute in the dn are compelling. Note that some software (for
example Entrust) gets unhappy if a person's DN doesn't contain a CN
attribute. 

You also may want to consider not dividing the tree up along departmental
lines.

 dn: uid=joe, ou=Department, ...

If joe changes departments, then his DN has to change, even though Joe is
the same person. If Joe's department changes names, everyone in
the department will get a new DN, even though nothing has really
changed.

Instead, you might want to consider

 dn: uid=joe, ou=People, ...
 ou: People
 ou: Department

The end result is the same. On the other hand, there may be good reasons
in your organization for dividing the tree up along departmental lines,
so I'm really just giving you some food for thought.

> 2) Different objectClasses in one entry
> 
> What is it good for that one makes an entry belong to more than
> one objectClass? And what is the "top" class good for? For me it
> seems as if this was against real "order" in the directory tree.
> An example explaining the reason would help me a lot!

Belonging to more than one object class is useful. For example, in a
mythical schema, a person may be a

  objectclass: fullTimeEmployee
  objectclass: emailUser
  objectclass: manager
  objectclass: oracleAccountHolder
  objectclass: quickPageUser

In this schema, there may be fullTimeEmployees who don't have email, so
you wouldn't want to have email-specific attributes in the
fullTimeEmployee objectclass. Instead, you create a emailuser objectclass,
and now people who use email are both fullTimeEmployees and emailUsers.
Schema design is really organization specific, but the ability to spread
attributes across multiple object classes and assign the necessary classes
to an entry is very useful.

In the schema definitions that come with openldap, there is sorta kinda an
objectclass inheritance (inetorgperson is a person is a top). This kind of
objectclass inheritance is more emphasized in LDAPv3, (the current version
of OpenLDAP is LDAPv2). The top objectclass contains one or two attributes
that all other objectclasses inherit (such as ACI); that's why it's there.

Also, don't confuse objectclass inheritance with directory tree layout.
Entries in a directory tree don't inherit the objectclasses of their
parents!

> 3) Creation and Maintainance
> 
> As the necessary user information is held in different sources
> (database, user and group files) I wrote a Perl script which
> merges the data into one large LDIF file. What will happen to
> the existing entries in the LDAP database when I (ldap)add data
> from a newer LDIF file? Are they supposed o be overwritten or
> will OpenLDAP respond with an error saying that the entry
> allready exists (which made an update quite difficult)?

Use ldapmodify instead of ldapadd to replace existing entries. Use
ldapmodify -r to completely replace attributes in an existing entry. If
you plan to regularly synchronize ldap with another database, I would
recommend that you use the native LDAP api instead of using ldif/ldapadd.
PerlDAP (www.mozilla.org/directory) and Net::LDAP are both usable for
this, although PerlDAP is more mature.

Sorry, I don't know much about mac or NT.

Regards,
Dave Carrigan