RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1364277 - on a read only replica invalid state info can accumulate
Summary: on a read only replica invalid state info can accumulate
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-04 23:02 UTC by Noriko Hosoi
Modified: 2020-09-13 21:48 UTC (History)
5 users (show)

Fixed In Version: 389-ds-base-1.3.6.1-3.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 21:10:21 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 2003 0 None None None 2020-09-13 21:48:53 UTC
Red Hat Product Errata RHBA-2017:2086 0 normal SHIPPED_LIVE 389-ds-base bug fix and enhancement update 2017-08-01 18:37:38 UTC

Description Noriko Hosoi 2016-08-04 23:02:29 UTC 
In a master-master-consumer topology where the account policy plugin is enabled on all servers with always record lastlogin time itcn happe in specific scenarios that on the consumer invalid/ unneeded state information accumulates like:

nscpentrywsi: lastLoginTime;adcsn-579b491a000100c80000;vdcsn-579b491a000100c80000;deletedattribute;deleted:
nscpentrywsi: lastLoginTime;adcsn-579b48ff000100c80000;vdcsn-579b48ff000100c80000;deletedattribute;deleted:
nscpentrywsi: lastLoginTime;vdcsn-579b48dd000100c80000;deletedattribute;deleted:

This can be reproduced by the following steps:

Stop M1,M2,C1
Start M1
bind user1 on M1, lastlogin will be updated with csn time T1
Stop M1
Start M2
bind user1 on M2, lastlogin will be updated with csn time T2>T1
Stop M2

Start C1
Start M2 to ensure the change with  T2 is replicated earlier than T1
we now have this change properly updated

nscpentrywsi: lastLoginTime;adcsn-5799e628000000c80000;vucsn-5799e628000000c80000: 20160728110200Z
nscpentrywsi: lastLoginTime;adcsn-5799e4f0000000c80000;vdcsn-5799e4f0000000c80000;deletedattribute;deleted:
nscpentrywsi: lastLoginTime;vdcsn-5799d191002c00c80000;deletedattribute;deleted:

Now bind user1 to C1, for a readonly replica no csn is generated, the value is replaced and the adcsn is kept.

nscpentrywsi: lastLoginTime;adcsn-5799e628000000c80000: 20160728110449Z
nscpentrywsi: lastLoginTime;adcsn-5799e4f0000000c80000;vdcsn-5799e4f0000000c80000;deletedattribute;deleted:
nscpentrywsi: lastLoginTime;vdcsn-5799d191002c00c80000;deletedattribute;deleted:

Now start M1 to receive the older csn, and the weirdness starts:
nscpentrywsi: lastLoginTime;adcsn-5799e628000000c80000;vdcsn-5799e628000000c80000;deletedattribute;deleted:
nscpentrywsi: lastLoginTime;adcsn-5799e4f0000000c80000;vdcsn-5799e4f0000000c80000;deletedattribute;deleted:
nscpentrywsi: lastLoginTime;vdcsn-5799d191002c00c80000;deletedattribute;deleted:
there is no more proper lastlogintimevalue !!!

Bind on read only replica again:
nscpentrywsi: lastLoginTime: 20160728110525Z
nscpentrywsi: lastLoginTime;adcsn-5799e628000000c80000;vdcsn-5799e628000000c80000;deletedattribute;deleted:
nscpentrywsi: lastLoginTime;adcsn-5799e4f0000000c80000;vdcsn-5799e4f0000000c80000;deletedattribute;deleted:
nscpentrywsi: lastLoginTime;vdcsn-5799d191002c00c80000;deletedattribute;deleted:

There is a new value without any csn, the deleted are still there

Bind to M1 again and there will be a normal value plus deleted,
Comment 1 Sankar Ramalingam 2016-09-15 14:57:37 UTC 
1). Two master and consumers setup with account policy plugin enabled.

[root@ratangad ~]# for PORT in `echo "1189 1289 1389 1489"`; do ldapsearch -D "cn=directory manager" -w Secret123 -h localhost -p 1189 -x -o ldif-wrap=no -b "cn=Account Policy Plugin,cn=plugins,cn=config" |egrep 'alwaysrecordlogin|nsslapd-pluginEnabled' ; done
nsslapd-pluginEnabled: on
alwaysrecordlogin: yes
nsslapd-pluginEnabled: on
alwaysrecordlogin: yes
nsslapd-pluginEnabled: on
alwaysrecordlogin: yes
nsslapd-pluginEnabled: on
alwaysrecordlogin: yes

2). Stop M2, M1 and C1.
[root@ratangad ~]# /usr/lib64/dirsrv/slapd-M1/stop-slapd  ; /usr/lib64/dirsrv/slapd-M2/stop-slapd; /usr/lib64/dirsrv/slapd-C1/stop-slapd
[root@ratangad ~]# /usr/lib64/dirsrv/slapd-M1/start-slapd

3). [root@ratangad MMR_WINSYNC]# ps -eaf |grep -i slapd
dsuser   14061     1  0 19:23 ?        00:00:00 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-M1 -i /var/run/dirsrv/slapd-M1.pid
root     14386 13238  0 19:33 pts/3    00:00:00 grep --color=auto -i slapd

[root@ratangad MMR_WINSYNC]# ./AddEntry.sh Users 1189 "ou=people,dc=passsync,dc=com" newtestusr 1 localhost
No of entries added will be 1
Adding 1 Users to 
adding new entry "uid=newtestusr1,ou=people,dc=passsync,dc=com"

[root@ratangad MMR_WINSYNC]# ldapsearch -D "uid=newtestusr1,ou=people,dc=passsync,dc=com" -w Secret123 -h localhost -p 1189 -x -o ldif-wrap=no -b "uid=newtestusr1,ou=people,dc=passsync,dc=com" |grep -i "dn: "
dn: uid=newtestusr1,ou=People,dc=passsync,dc=com

4). [root@ratangad MMR_WINSYNC]# ldapsearch -D "cn=Directory Manager" -w Secret123 -h localhost -p 1189 -x  -b "uid=newtestusr1,ou=people,dc=passsync,dc=com" '+' |grep -i lastLoginTime
lastLoginTime: 20160915143756Z

5). Stop M1. Start M2. 
[root@ratangad MMR_WINSYNC]# /usr/lib64/dirsrv/slapd-M1/stop-slapd  ; /usr/lib64/dirsrv/slapd-M2/start-slapd
[root@ratangad MMR_WINSYNC]# ldapsearch -D "cn=Directory Manager" -w Secret123 -h localhost -p 1289 -x  -b "uid=newtestusr1,ou=people,dc=passsync,dc=com" '+' |grep -i lastLoginTime
[root@ratangad MMR_WINSYNC]# 

6). To update the lastLoginTime attribute, attempted a bind from M2.
Bind as newtestusr1, gives error 49.
[root@ratangad MMR_WINSYNC]# ldapsearch -D "uid=newtestusr1,ou=people,dc=passsync,dc=com" -w Secret123 -h localhost -p 1289 -x -o ldif-wrap=no -b "uid=newtestusr1,ou=people,dc=passsync,dc=com" |grep -i "dn: "
ldap_bind: Invalid credentials (49)

Hi Noriko, the bug is not in ON_QA state. However, I followed the steps to reproduce the issue. But, I am getting error 49 at M2. Please guide me. Thanks!
Comment 2 Noriko Hosoi 2016-09-15 21:03:01 UTC 
Sankar, why are you trying to verify this bug now?

This bug is targeted to rhel-7.4 and the status of this bug is POST, which means there is no official build to have this fix...  See the empty Fixed In Version box.

Please note that we are including this fix in rhel-6.9 -- bz1316869, but rhel-6.9 has no official build either.
Comment 3 Sankar Ramalingam 2016-09-16 06:58:33 UTC 
Hi Noriko, this was by/my mistake. It was there in RHEL7.3 QE trac ticket. When I started working on it, I didn't notice neither the bug status nor the target release. I was assuming the fix is available with the latest build of RHEL7.3.

Half way through my testing, I realized the bug is not targeted for RHEL7.3 release. However, I wanted to continue with the verification steps and add my comments in the bug for future reference. My query in comment #1, was about whether the steps followed were accurate or not. Anyways, I will investigate further about the test case, after verifying other RHEL7.3 bugs.
Comment 4 Sankar Ramalingam 2016-09-17 00:23:02 UTC 
(In reply to Sankar Ramalingam from comment #3)
> Hi Noriko, this was by/my mistake. It was there in RHEL7.3 QE trac ticket.
> When I started working on it, I didn't notice neither the bug status nor the
> target release. I was assuming the fix is available with the latest build of
> RHEL7.3.
> 
> Half way through my testing, I realized the bug is not targeted for RHEL7.3
> release. However, I wanted to continue with the verification steps and add
> my comments in the bug for future reference. My query in comment #1, was
> about whether the steps followed were accurate or not.
In Step 5, I stopped M1 first and then started M2. So, it didn't sync entry to other masters and consumers. It should be, start M2 first and then stop M1. This will allow the entries to be synced to M2. 

Access log messages
[17/Sep/2016:05:40:41.397036079 +051800] conn=8 op=0 BIND dn="uid=3newtestusr1,ou=people,dc=passsync,dc=com" method=128 version=3
[17/Sep/2016:05:40:41.397493715 +051800] conn=8 op=0 RESULT err=49 tag=97 nentries=0 etime=0 - No such entry
[17/Sep/2016:05:40:41.397775725 +051800] conn=8 op=1 UNBIND


 Anyways, I will
> investigate further about the test case, after verifying other RHEL7.3 bugs.
Comment 5 Noriko Hosoi 2016-09-17 00:39:40 UTC 
Sankar,

1). Two master and consumers setup with account policy plugin enabled.

Please move this part of 3) to the end of 1).
[root@ratangad MMR_WINSYNC]# ./AddEntry.sh Users 1189 "ou=people,dc=passsync,dc=com" newtestusr 1 localhost
No of entries added will be 1
Adding 1 Users to 
adding new entry "uid=newtestusr1,ou=people,dc=passsync,dc=com"

And double check the entry is replicated.  Then, start the rest of the test.
Thanks.
Comment 7 Sankar Ramalingam 2017-06-12 09:05:53 UTC 
=============== test session starts ========================
platform linux2 -- Python 2.7.5, pytest-3.1.2, py-1.4.34, pluggy-0.4.0 -- /usr/bin/python
cachedir: .cache
metadata: {'Python': '2.7.5', 'Platform': 'Linux-3.10.0-679.el7.x86_64-x86_64-with-redhat-7.4-Maipo', 'Packages': {'py': '1.4.34', 'pytest': '3.1.2', 'pluggy': '0.4.0'}, 'Plugins': {'beakerlib': '0.7.1', 'html': '1.15.0', 'cov': '2.5.1', 'metadata': '1.5.0'}}
DS build: 1.3.6.1
389-ds-base: 1.3.6.1-16.el7
nss: 3.28.4-8.el7
nspr: 4.13.1-1.0.el7_3
openldap: 2.4.44-5.el7
svrcore: 4.1.3-2.el7

rootdir: /export/tests, inifile:
plugins: metadata-1.5.0, html-1.15.0, cov-2.5.1, beakerlib-0.7.1
collected 1 items 

tickets/ticket48944_test.py::test_ticket48944 PASSED

================== 1 passed in 85.20 seconds ====================

Marking it as verified based on the automated test results.
Comment 8 errata-xmlrpc 2017-08-01 21:10:21 UTC 
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/RHBA-2017:2086
Note You need to log in before you can comment on or make changes to this bug.