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.