[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Suggest 2.0 -> 2.1 migration.
On Sun, 15 Sep 2002 14:28:54 -0500 (CDT)
Caylan Van Larson <caylan@cs.und.edu> wrote:
> and I still did not know the main differnces between the 2. I
> proceeded to install them and see what was up. Well, I found out
> numerous things the first being that when I tried to load my db
> (from ldif) the schemas did not work. Even if I copied them over
> from a working 2.0 install they would not load (did not surprize
> me). I messed around with the db backend. Compiling between the
> new default and ldbm.
With respect to schemas, 2.1 correctly enforces having only a single
structural object class chain per object.
Objectclasses in rfc-2252 can be abstract, structural, or auxiliary.
Multiple sets of auxiliary oc's are allowed to exist on an object;
they serve to augment the object with additional attributes. Only one
inheritance chain of Structural objectclasses may exist, for example
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
...
see core.schema and inetorgperson.schema.
This may require some re-design of the objectclasses to be used on
your objects and then likely mass changes to implement them. As 2.0
is more lenient in this area, these changes can be done to the data as
it sits on your 2.0 server (perl's Net::LDAP makes this real easy).
It is generally much faster to process an ldif file, however.
> I am in now hurry to upgrade (or should I be), so I want to research
> this. Can someone explain what 2.1 dishes out without just pointing
> me to the release notes? I have read them but I am unsure of the
> practacality for myself.
Another large gotcha may be ldapv3 vs. ldapv2. 2.1 supports ONLY
ldapv3, where as 2.0 allows v2 connections. You will likely want to
verify all your systems that touch ldap are happy with the v3
protocol.
Matthew Backes
lucca@csun.edu