[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Offline modification in replicated environment
- To: openldap-technical@openldap.org
- Subject: Offline modification in replicated environment
- From: Ryan Tandy <ryan@nardis.ca>
- Date: Fri, 22 Apr 2016 21:34:19 -0700
- Content-disposition: inline
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nardis.ca; s=google; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-disposition:user-agent; bh=23/bwIoaxozV6heNjAEYtrZb3LWQLdCwzQRm4tPJEqA=; b=YkcoBaF83EiBvxs7CsG2vD1Sf4VkI+VgAVb+o7cVSMzJLr+Rg8H/qgCK9/mGFmgjBk 0hgvK4XcC+0qq2wdRTtaOsfRn/DCJU7uV8EQZG72owgADap94vOEgAzeeNgxxcKdwXn4 DsCuNlQMB6o4BPBtDuD2BoyvGLzPFPEMzoc8c=
- Mail-followup-to: openldap-technical@openldap.org
- User-agent: Mutt/1.5.23 (2014-03-12)
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