[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Offline modification in replicated environment



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




--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/