--On Tuesday, June 27, 2017 2:04 AM -2100 Zeus Panchenko zeus@ibs.dn.ua wrote:
syncrepl rid=123 provider=ldap://master.example:389 starttls=critical searchbase="ou=ABC,ou=Sendmail,dc=example" bindmethod=simple binddn="uid=replABC,ou=repl,dc=example" credentials="***" tls_cacert=/usr/local/etc/openldap/ssl/ca.crt tls_cert=/usr/local/etc/openldap/ssl/ABC.crt tls_key=/usr/local/etc/openldap/ssl/ABC.key tls_reqcert=try type=refreshAndPersist retry="60 +" logbase="cn=example-accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog
- ---[ slave configuration quotation end ]----------------------------
Wouldn't it be simpler to define ACLs on the master that limit what the replication identity has access to that matches your filters?
I would also note that your stanza limiting what attrs are replicated is missing the operational attributes that are necessary for sync replication to function, so I would fully expect errors. As Andrew already noted (and you later fixed), syncrepl RIDs are required to be unique, as documented in the man page. Given that OpenLDAP functions off of CSN values, partial replication is tricky, as the master can then have a contextCSN that does not correspond to anything in a partially replicated database, depending on how you slice it.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount quanah@symas.com wrote:
Wouldn't it be simpler to define ACLs on the master that limit what the replication identity has access to that matches your filters?
emm ... I was sure I can not do that on the master side ... just I try do that, I receive full data ...
looks like some more permittive acl works for the replica ... can I somehow know which acl matched the replica? But I was trying to place replABC ACLs to the end of the list and still was not able to limit data according the filter
I would also note that your stanza limiting what attrs are replicated is missing the operational attributes that are necessary for sync replication to function, so I would fully expect errors.
do you mean entryCSN and entryUUID ?
unique, as documented in the man page. Given that OpenLDAP functions off of CSN values, partial replication is tricky, as the master can then have a contextCSN that does not correspond to anything in a partially replicated database, depending on how you slice it.
I was sure I understood the documentation ...
openldap-technical@openldap.org