#48836 replication session fails because of permission denied
Closed: wontfix None Opened 5 years ago by tbordaz.

Testing with

  • freeipa 4.3.1
  • DS 1.3.5.2

The test case is:
Install a ipa-server, install a replica (client then replica).
The installation of the replica fails with the following logs:

server:
[11/May/2016:14:11:30.127601044 +0200] NSMMReplicationPlugin - agmt="cn=meTo<vm-fqdn>" (<vm-fqdn>:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later.


REPLICA:
[11/May/2016:14:11:30.122294190 +0200] NSMMReplicationPlugin - conn=3 op=5 replica="<suffix>": Unable to acquire replica: error: permission denied

[11/May/2016:14:11:30.105401591 +0200] conn=3 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI
...
[11/May/2016:14:11:30.118457501 +0200] conn=3 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=ldap/<vm-fqdn>@<domain>,cn=config"
...
[11/May/2016:14:11:30.122195525 +0200] conn=3 op=5 EXT oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop"
[11/May/2016:14:11:30.123966521 +0200] conn=3 op=5 RESULT err=0 tag=120 nentries=0 etime=0
[11/May/2016:14:11:30.127679966 +0200] conn=3 op=6 UNBIND
[11/May/2016:14:11:30.127703013 +0200] conn=3 op=6 fd=64 closed - U1

ipareplica-install.log
2016-05-11T12:11:48Z DEBUG   [error] RuntimeError: Failed to start replication

This bug is a regression introduced by https://fedorahosted.org/389/ticket/48597


Hi Thierry, your patch certainly fixes the issue, but it rather looks to me that this function is not doing the right thing... Since it declares the return value is PRBool, it should return PR_TRUE if it is a member...? (and the replica_is_updatedn side should remain intact?)
{{{
PRBool
replica_updatedn_list_ismember(ReplicaUpdateDNList list, const Slapi_DN dn)
{
PLHashTable
hash = list;
PRBool ret = PR_FALSE;

const char *ndn = slapi_sdn_get_ndn(dn);

/* Bug 605169 - null ndn would cause core dump */
if ( ndn ) {
    ret = (PRBool)((uintptr_t)PL_HashTableLookupConst(hash, ndn));
}

return ret;

}
}}}

this was my concern as well, we shouldn't work around a bad return code, but fix it if a boolean is requested, maybe like this

{{{
/ Bug 605169 - null ndn would cause core dump /
- ret = (PRBool)((uintptr_t)PL_HashTableLookupConst(hash, ndn));
+ if ((uintptr_t)PL_HashTableLookupConst(hash, ndn)) ret = PR_TRUE;
+ else ret = PR_FALSE;
}
}}}

Thank you, Thierry!!
You have my big ack! ;)

Thank you so much Noriko !

Counting objects: 8, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 1.10 KiB | 0 bytes/s, done.
Total 8 (delta 6), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
fb39031..35f6fb8 master -> master

commit 35f6fb8
Author: Thierry Bordaz tbordaz@redhat.com
Date: Thu May 12 15:38:28 2016 +0200

Metadata Update from @nhosoi:
- Issue assigned to tbordaz
- Issue set to the milestone: 1.3.5.4

4 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1896

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

a year ago

Login to comment on this ticket.

Metadata