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.

> 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