Thanks a lot. That will help me sleep easier :) I'll check indices, schemachecking & the schema elements for may/must.
Thanks, Amol Kulkarni.
On Fri, Nov 28, 2014 at 12:49 AM, Michael Ströder michael@stroeder.com wrote:
Howard Chu wrote:
Amol Kulkarni wrote:
I've a openldap 2.4.30 syncrepl setup which is used by our applications. There are over 50 servers in the setup. I want to upgrade our application to the next version. In a single downtime, all servers cannot be upgraded. So the application will be upgraded in phase wise manner. Application upgrade requires some changes in ldap schemas. I want to update the schemas in same phases as the application so as to avoid separate downtime for schema update. I'm planning to update schema on the consumers first and provider last so that during the phases, some servers with old schemas and others with new schemas both replicate properly.
That's fine.
I'd also start with the consumers.
schemachecking is set to off on all servers.
That's dangerous. You have no idea how long garbage data will persist in
the
system.
I'd also rather try not to disable schema checking.
Note that with some older versions (IIRC 2.4.31) in my setup slapd providers crashed when slapd consumers noticed a schema problem and took down connection immediately. Yes, the provider.
I'm not using cn=config - if that is a consideration.
Makes no difference.
Hmm, with static configuration schema elements can be easily *removed*. Which is the trickier thing to deal with. In general I recommend not to remove schema elements but rather use OBSOLETE in the schema description (see RFC 4512). Even using OBSOLETE there are some corner cases though.
So first check whether the application changes removes schema elements or even alter from MAY to MUST or similar.
Ciao, Michael.