Re: Five fundamental questions from a newbie

[mark@mjwilcox.com]

On 13 Jan 00, at 14:59, Dave Carrigan wrote:

> 
> 
> 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. 
> 
Applications shouldn't care about the DN. They should simply be 
making an API call to retrieve the DN. However I think in Entrust's 
case, they are used to dealing with X.509 certificates which 
typically do have a CN attribute in them (they may even be 
required, it's been a while since I've read the X.509 spec).

> 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.
> 
Being in a university, you may need or want to extend a bit farther. 
In a typical company, the company reorganizes too often and every 
employ is essentialy like the other. However in an university, you 
have at least two very different set of individuals, faculty/staff & 
students. At my university, we've split people based on their role 
(e.g. either fac/staff or student). This also enables us to have two 
seperate entries for people who are both (not really my ideal, but 
we had to for legacy applications).

><bunch of cuts>
> 
> > 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.
I've been using Net::LDAP for 90% of my LDAP work in the past 
year (I do cover both APIs in my book, "Implementing LDAP" 
however). To be honest they are both about even in level of 
maturity. If PerLDAP has anything on Net::LDAP in maturity, it's 
only because of the underlying Netscape C SDK. On the other 
hand Net::LDAP is pure Perl, which makes it more portable.

But what I do in my daily uploads is ldapmodify. I have a Perl 
program that marshalls my mainframe data into an LDIF file. Then 
we use ldapmodify to modify our directory server. I've chosen to 
stick with straight LDIF because it's easier to debug if there are 
problems in our mainframe data or other problems. I'm going to be 
exploring DSML later this year.
> 
> Sorry, I don't know much about mac or NT.
I've never heard of anything for the Mac, but that doesn't mean it 
doesn't exist.

The only thing that I know for NT is Netscape's NT synchronization 
service.

Mark
> 
> Regards,
> Dave Carrigan
> 
> 
> 
>