Thank you all for the your answers. I did it like I did it before. I put all the ACLs in the global part of the configuration and replicate just e the part with the ACLs, that works fine. I hope replication of attributes from the cn=config will work with 2.5 :-) Stefan Am 13.01.20 um 13:22 schrieb Ulrich Windl: >>>> Michael Ströder <michael@stroeder.com> schrieb am 13.01.2020 um 12:02 in > Nachricht <246dd12f-13ce-1c1d-33a8-36bf807b8231@stroeder.com>: >> On 1/13/20 11:53 AM, Ulrich Windl wrote: >>>>>> Michael Ströder <michael@stroeder.com> schrieb am 07.01.2020 um 20:41 > in >>> Nachricht <771d7e42-1e54-a783-92cb-e3ead597ad12@stroeder.com>: >>>> On 1/7/20 8:13 PM, Quanah Gibson-Mount wrote: >>>>> The admin guide discusses how to replicate cn=config. >>>> Hmm, I vaguely remember that the conclusion on this list was that >>>> replicating cn=config is currently not considered reliable enough. >>> But it works "well enough" for many cases. I think: Let users try it, and >> let >>> users decide whether it does the job. >> Nobody and nothing prevents a user from trying anything and be happy >> with that. >> >> But "users" have to be well aware of what they can expect to be a stable >> and supported configuration (after meeting prerequisites). So that they >> don't complain and blame others later. >> >> E.g. in case of replicating cn=config "users" have to understand the >> strong dependency on stable IP addresses and or hostnames used for >> replicas in LDAP URL part of the serverID. Which is not really obvious >> to beginners. > Agreed (I'd add certificate paths, too). So I'd add such warning to the > configuration guide. > (If it's documented, it's a feature) > >> Ciao, Michael. > > > > > >
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature