2014-05-03 13:22 GMT+02:00 Michael Ströder <[email protected]>:

> 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.
>
>
Hi,

I opened an ITS for a similar thing:
http://www.openldap.org/its/index.cgi/Incoming?id=7766

Any feedback about it?


Clément.

Reply via email to