Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
First Last Prev Next    This bug is not in your last search results.
Bug 1598478 - If a replica is created with a bindDNGroup, this group is taken into account only after bindDNGroupCheckInterval seconds
If a replica is created with a bindDNGroup, this group is taken into account ...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
7.4
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: thierry bordaz
RHDS QE
Marc Muehlfeld
:
: 1598159 (view as bug list)
Depends On:
Blocks:
  Show dependency tree / graph
 
Reported: 2018-07-05 11:25 EDT by mreynolds
Modified: 2018-10-30 06:15 EDT (History)
6 users (show)

See Also:
Fixed In Version: 389-ds-base-1.3.8.4-4.el7
Doc Type: Bug Fix
Doc Text:
Directory Server now retrieves members of the replica bind DN group when the first session is started Directory Server replicas define entries that are authorized to replicate updates to the replica itself. If the entries are members of the group set in the "nsds5replicabinddngroup" attribute, the group is retrieved periodically based on the interval set in the "nsDS5ReplicaBindDnGroupCheckInterval" attribute. If the entry is not a member at the time the server retrieves the group, any session that is authenticated using this entry is not authorized to replicate updates. This behavior remains until the entry becomes a member of the group and the server retrieves the group again. As a consequence, replication fails for the first interval set in "nsDS5ReplicaBindDnGroupCheckInterval". With this update, the server retrieves the group when the first session is started rather than when the replica is created. As a result, the group is taken into account at the first attempt it is checked.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-10-30 06:14:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:3127 None None None 2018-10-30 06:15 EDT

  None (edit)
Description mreynolds 2018-07-05 11:25:03 EDT 
This bug is created as a clone of upstream ticket:
https://pagure.io/389-ds-base/issue/49818

#### Issue Description
When a replica is created, the time of the last_group_check is set at the current time.
So if the a replica contains a nsds5replicabinddngroup, this group will only be uploaded after a delay of nsDS5ReplicaBindDnGroupCheckInterval.

So in the period [replica_creation, replica_creation+nsDS5ReplicaBindDnGroupCheckInterval] any incoming replication connections, within will fail with NSDS50_REPL_PERMISSION_DENIED , even if the group actually contains the bound DN.

On the supplier side we can see message like 

    [29/Jun/2018:17:21:58.943439172 +0200] - ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=meTo<server_fqdn>" (<server>:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later.



#### Package Version and Platform
Any version


#### Steps to reproduce

1. IPA server-replica install
2. or create a replica with a group/check interval and verify that for the first check_interval period all replication session fail
3.

#### Actual results
It fails


#### Expected results
should not
Comment 2 Viktor Ashirov 2018-07-09 05:37:33 EDT 
*** Bug 1598159 has been marked as a duplicate of this bug. ***
Comment 4 Simon Pichugin 2018-07-30 05:54:01 EDT 
The test case was automated in 
dirsrvtests/tests/suites/replication/regression_test.py::test_fetch_bindDnGroup

================== test session starts ==================
platform linux -- Python 3.6.3, pytest-3.6.4, py-1.5.4, pluggy-0.7.1 -- /opt/rh/rh-python36/root/usr/bin/python3
cachedir: .pytest_cache
metadata: {'Python': '3.6.3', 'Platform': 'Linux-3.10.0-924.el7.x86_64-x86_64-with-redhat-7.6-Maipo', 'Packages': {'pytest': '3.6.4', 'py': '1.5.4', 'pluggy': '0.7.1'}, 'Plugins': {'metadata': '1.7.0', 'html': '1.19.0'}}
389-ds-base: 1.3.8.4-9.el7
nss: 3.36.0-5.el7_5
nspr: 4.19.0-1.el7_5
openldap: 2.4.44-18.el7
svrcore: 4.1.3-2.el7
FIPS: 0

rootdir: /mnt/tests/rhds/tests/upstream/ds, inifile:
plugins: metadata-1.7.0, html-1.19.0
collected 6 items

dirsrvtests/tests/suites/replication/regression_test.py::test_double_delete PASSED      [ 16%]
dirsrvtests/tests/suites/replication/regression_test.py::test_repl_modrdn PASSED        [ 33%]
dirsrvtests/tests/suites/replication/regression_test.py::test_password_repl_error PASSED [ 50%]
dirsrvtests/tests/suites/replication/regression_test.py::test_invalid_agmt PASSED       [ 66%]
dirsrvtests/tests/suites/replication/regression_test.py::test_fetch_bindDnGroup PASSED  [ 83%]
dirsrvtests/tests/suites/replication/regression_test.py::test_cleanallruv_repl PASSED   [100%]

================== 6 passed in 252.94 seconds ==================

Marking as verified.
Comment 9 errata-xmlrpc 2018-10-30 06:14:34 EDT 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:3127
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.