RE: Schema Replication

["Mark Mcdonald" <mmcdonald@staff.iinet.net.au>]

> -----Original Message-----
> From: Howard Chu [mailto:hyc@symas.com]
>
> In OpenLDAP 2.3 you can add new schema definitions on the fly, but you
> cannot
> modify existing definitions. In OpenLDAP 2.4 you can do full schema
> modifications on the fly.

Are they replicated from master to slaves in 2.3?

> Read the Admin Guide. I think you'll be better off using OpenLDAP 2.4 for
> this project. We should be pushing out a new 2.4 alpha release pretty
> soon.

Is version 2.4 likely to become stable in the near future?  Does anyone have any stories from a production environment?  We've just updated to 2.3 stable & HDB (from 2.1/LDBM) and would rather not repeat the process so soon!

I'm playing around with cn=schema,cn=config now, and my changes are not preserved after slapd is restarted, is there a way around this?  Any recommended methods to take (excluding minor revision increments)?

My current thoughts are to push the schema updates as both LDIF and schema files so a restart will pick up the changes from disk, although an alternative I'd like would be to build the schema dynamically.

I've noticed also that schema updates done dynamically don't pick up data already recorded, for example (the testTwo attribute is the only one defined through the dynamic schema):

$ ldapsearch [blah]
dn: cn=test,o=base
cn: test
objectClass: device
objectClass: testObject
testTwo: w00t

[restart slapd]

$ ldapsearch [blah]
dn: cn=test,o=base
cn: test
objectClass: device
objectClass: testObject

$ ldapadd [blah]
dn: cn=test,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: test
olcAttributeTypes: ( 1.1.1 NAME 'testAttr' EQUALITY integerMatch SYNTAX
 1.3.6.1.4.1.1466.115.121.1.27 )
olcAttributeTypes: ( 1.1.2 NAME 'testTwo' EQUALITY caseIgnoreMatch SUBSTR
 caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
olcObjectClasses: ( 1.1.3 NAME 'testObject' MAY ( testAttr $ testTwo )
 AUXILIARY )
adding new entry "cn=test,cn=schema,cn=config"

$ ldapsearch [blah]
dn: cn=test,o=base
cn: test
objectClass: device
objectClass: testObject

Does this mean the schema needs to be present before the database is loaded to pick up these attributes?

And to pre-empt the inevitable response, I'm guessing this all works beautifully in 2.4?