> -----Original Message----- > From: Ondřej Kuzník <on...@mistotebe.net> > Sent: Monday, June 9, 2025 11:52 AM > To: Windl, Ulrich <u.wi...@ukr.de> > Cc: openldap-technical@openldap.org > Subject: [EXT] Re: Re: Re: Re: Re: Re: using refint overlay for > pwdPolicySubentry > > On Mon, Jun 02, 2025 at 09:58:14AM +0000, Windl, Ulrich wrote: > > Hi! > > > > Sorry for the length delay. I tested again: > > * I copied a policy and assigned that copy to a user > > * then I renamed that copied pppolicy to a new name > > * searching the server I see that the pwdPolicySubentry attribute is > > updated > > > > The confusing part is that I find the rename in accesslog, but not the > > attribute change. > > Of course, the rename triggered an attribute change on the other > > replicated node as well, but I would find it more consistent if the > > change done by refint were reflected in the accesslog (and be > > replicated that way). > > > > Maybe it's my fault to use the accesslog to see all changes applied to > > the local database... > > Hi Ulrich, > as documented, refint-initiated operations are not meant to be > replicated, you are supposed to configure refint on each replica. That > includes they cannot be logged in accesslog either. [Windl, Ulrich] Well, I think they *could* be recorded there, causing some redundancy on the consumer if it also uses refint. What will "plain old LDAP sync" see from the provider then? The requirement that all consumers need to use refint as well seems to break LDAP sync IMHO.
Kind regards, Ulrich
