Paul B. Henson wrote: >> From: Michael Ströder >> Sent: Friday, May 02, 2014 4:21 AM >> >> If just add "moduleload ppolicy" to your slapd.conf (or similar action for > [...] >> In a second step you have to add "overlay ppolicy" to the database section > > Sweet, I never considered loading the module but not using it. Thanks much > for the follow-up and suggestion, I think that will allow me to stage the > deployment as I wanted without any downtime. > >> all replicas, also one after the other. The replication will catch up even >> though some prior modifications might have failed in the past. > > Will there be any failures? After step one, all of the replicas should have > the schema loaded. As you start migrating servers to step two, they will > start generating and trying to replicate the attribute. As the other servers > already know about the attribute, wouldn't the replication succeed, although > at that point there would be nothing on that particular server paying any > attention to it? In my test setup 1. provider has slapo-ppolicy fully configured in the database section but 2. provider does not have it. The attribute is replicated. BTW: AFAIK write operations to 'pwdFailureTime' are normally not replicated. But with normal syncrepl mode attribute 'pwdFailureTime' will get replicated if there's a change to another attribute. Maybe one could mitigate this by setting parameter 'attrs' to not include all operational attributes. But I would not recommend doing so. It would be nice if one could explicitly exclude attributes with parameter 'attrs' though. This would allow to work around an issue with slapo-allowed in a MMR setup... Ciao, Michael.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature