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

RE: Suggest 2.0 -> 2.1 migration.



2.1 slapd disables LDAPv2 support by default but it is still present in the
code and can be turned on with an "allow" option in slapd.conf. See the
slapd.conf(5) man page for details.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Matthew J
> Backes
> Sent: Sunday, September 15, 2002 4:54 PM
> To: Caylan Van Larson
> Cc: openldap-software@OpenLDAP.org
> Subject: 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
>
>