On Fri, 2016-10-07 at 17:58 +0200, Ludwig Krispenz wrote: > there is a problem not yet covered in the proposal: setting the backend > to "referral-on-update" until the topology is in sync prevents to ealry > client updates, but what to do about internal updates, eg passwordpolicy > attributes. > > I have a wild idea, but maybe someone has a suggestion on how to handle > this I think the accept-updates state is better managed in a separate pre-operation plugin which is able to distinguish internal vs external updates. I'm actually writing something like this at the moment in my free time which could work here. ... > >> > >> nsslapd-replica-accept-updates-state: on/off > >> nsslapd-replica-accept-updates-delay: -1/0/n > >> nsslapd-replica-accept-updates-auto: on/off > >> This configuration is really confusing. I can see how it's meant to work, but I don't like it. Again, I'm really against adding more configuration options. We should do "the right thing by default, always". Admins are lazy and aren't going to fine tune their replication for fun. My vote is scrap these two configuration options, and just make it "auto" behaviour. -- Sincerely, William Brown Software Engineer Red Hat, Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
