Ryan Tandy wrote:
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?
SID 000 modifications are ignored in multimaster replication; you're going to need to use a valid SID.
thanks, Ryan