Hello,
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.
schemachecking is set to off on all servers.
I understand that new attributes added in schema will not be present on provider at the beginning, so there is no question of their replication. I've compared the schemas and found that none of the attributes is deleted. Only change is that for some attributes we have added 'ordering' and for some we have changed the 'equality'.
I'm not using cn=config - if that is a consideration.
So will it all work ? Is there a better way?
Thanks in advance, Amol Kulkarni.
Amol Kulkarni wrote:
Hello,
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.
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 understand that new attributes added in schema will not be present on provider at the beginning, so there is no question of their replication. I've compared the schemas and found that none of the attributes is deleted. Only change is that for some attributes we have added 'ordering' and for some we have changed the 'equality'.
When you change matching rules, any existing index on those values will be invalid and will need to be regenerated using slapindex.
I'm not using cn=config - if that is a consideration.
Makes no difference.
So will it all work ?
Sounds fine overall.
Is there a better way?
Thanks in advance, Amol Kulkarni.
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.
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.
openldap-technical@openldap.org
-
Amol Kulkarni -
Howard Chu -
Michael Ströder