Full_Name: Fr.d.ric Goudal Version: 2.4.46 OS: ubuntu 18.14 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (147.210.204.135) The global setup is the following : - 1 master ldap (2.4.40) - 1 hidden slave on the master ldap, same suffix, ldap backend - 1 ldap backend on a distant server (2.4.46) When starting synchronisation the following event are happening : - for some reason the sync process ask for creating dn:uid=foo,ou=bar,dc=my,dc=domaine BEFORE the creation of dn : ou=bar,dc=my,dc=domain - on the backend the following entries are created in that order - dn:ou=bar,dc=my,dc=domain with the object class glue - dn: uid=foo,ou=bar,dc=my,dc=domain Than... the sync tries to create ou=bar,dc=my,dc=domain with the correct objectClass : organizationalUnit But, as the object exists on the backend ldap, creation fails, and synchronization stops. Solution -remove by hand the dn: uid=foo,ou=bar,dc=my,dc=domain, that remove the glue object - create by hand the ou=bar,dc=my,dc=domain What IMHO slapd should do : - either check that it does not add an object before its parent objects - either convert the glue object to the correct object when the real creation is needed. f
goudal@bordeaux-inp.fr wrote: > Full_Name: Fr.d.ric Goudal > Version: 2.4.46 > OS: ubuntu 18.14 LTS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (147.210.204.135) > > > The global setup is the following : > - 1 master ldap (2.4.40) > - 1 hidden slave on the master ldap, same suffix, ldap backend > - 1 ldap backend on a distant server (2.4.46) > > When starting synchronisation the following event are happening : > - for some reason the sync process ask for creating > dn:uid=foo,ou=bar,dc=my,dc=domaine BEFORE the creation of > dn : ou=bar,dc=my,dc=domain > > - on the backend the following entries are created in that order > - dn:ou=bar,dc=my,dc=domain with the object class glue > - dn: uid=foo,ou=bar,dc=my,dc=domain > > Than... the sync tries to create ou=bar,dc=my,dc=domain with the correct > objectClass : organizationalUnit > But, as the object exists on the backend ldap, creation fails, and > synchronization stops. > > Solution > -remove by hand the dn: uid=foo,ou=bar,dc=my,dc=domain, that remove the > glue object > - create by hand the ou=bar,dc=my,dc=domain > > What IMHO slapd should do : > - either check that it does not add an object before its parent objects No. This behavior is already documented in the Syncrepl specification. > - either convert the glue object to the correct object when the real creation is > needed. The slapd consumer already does this when running on a local database. It would require Manage privileges when running through back-ldap. Check your back-ldap configuration. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
> Le 11 oct. 2018 à 18:32, Howard Chu <hyc@symas.com> a écrit : > > goudal@bordeaux-inp.fr wrote: >> Full_Name: Fr.d.ric Goudal >> >> Solution >> -remove by hand the dn: uid=foo,ou=bar,dc=my,dc=domain, that remove the >> glue object >> - create by hand the ou=bar,dc=my,dc=domain >> >> What IMHO slapd should do : >> - either check that it does not add an object before its parent objects > > No. This behavior is already documented in the Syncrepl specification. > >> - either convert the glue object to the correct object when the real creation is >> needed. > > The slapd consumer already does this when running on a local database. It would > require Manage privileges when running through back-ldap. Check your back-ldap configuration. Well… I’v read 5 time the documentation on my setup, never seen the manage privilege mentioned anywhere… Even in the example given for the backend configuration the acls don’t mention this « manage » privilege : From page : https://www.openldap.org/doc/admin24/replication.html#Syncrepl # Give the replica DN unlimited read access. This ACL may need to be # merged with other ACL statements. access to * by dn.base="cn=replicator,dc=suretecsystems,dc=com" write by * break access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to dn.subtree="cn=Monitor" by dn.exact="uid=admin,dc=suretecsystems,dc=com" write by users read by * none access to * by self write by * read Wel.. I can accept it’s a documentation bug…but where is the correct documentation ? f.g.
Update admin guide for this configuration?
changed notes
invalid config manage documentation updates already being tracked