Offline modification in replicated environment

[Ryan Tandy <ryan@nardis.ca>]

When my (Debian's) users upgrade to 2.4.43 or later, if they use the ppolicy overlay and cn=config, I have to add the pwdMaxRecordedFailure attribute to the schema, otherwise slapd can't start.

Basic steps: slapcat the config database; a few lines of perl to add the new attribute, update the pwdPolicy object class, and strip out modifiersName and modifyTimestamp so they get regenerated; slapadd it back. No problem for a standalone system.

The config database might be replicated, though. For that, I'm also removing entryCSN from the schema entry I modify, and letting slapadd regenerate it. I'm not using -S with slapadd, so the reloaded entry is getting sid 000 every time.

I've tested master-slave and master-master setups, and this seems to be working as intended. But I'd like to ask the people here who have more experience with replication than I do: is this a bad plan? What could go wrong?

thanks,
Ryan