Bug 1271208

Summary: nsds5ReplicaProtocolTimeout attribute accepts negative values
Product: Red Hat Enterprise Linux 7 Reporter: Sankar Ramalingam <sramling>
Component: 389-ds-baseAssignee: mreynolds
Status: CLOSED ERRATA QA Contact: Viktor Ashirov <vashirov>
Severity: low Docs Contact:
Priority: low    
Version: 7.2CC: mreynolds, nkinder, rmeggins, spichugi
Target Milestone: rc   
Target Release: 7.3   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: 389-ds-base-1.3.7.5-7.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 14:15:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Sankar Ramalingam 2015-10-13 11:44:24 UTC
Description of problem: Test case replica_timeout_05 in mmrepl/accept/accept.sh is checking whether the replica entry accepts the negative(-15). The test case fails since the server accepts the negative value. I encountered the same problem when I manually executed the same tests.

[root@cloud-qe-4 export]# ldapmodify -x -p 24202 -h localhost -D "cn=Directory Manager" -w Secret123 << EOF
> dn: cn=replica,cn=o\=airius.com,cn=mapping tree,cn=config
> changetype: modify
> replace: nsds5ReplicaProtocolTimeout
> nsds5ReplicaProtocolTimeout: -15
> EOF
modifying entry "cn=replica,cn=o\=airius.com,cn=mapping tree,cn=config"

Version-Release number of selected component (if applicable): 389-ds-base-1.3.4.0-19


How reproducible: Consistently

Steps to Reproduce:
1. Create a replication agreement or run mmrepl/accept tests from TET.
2. Check whether the server accepts negative value for nsds5ReplicaProtocolTimeout attribute.
3. Check the test case replica_timeout_05 from TET acceptance mmraccept tests.

[root@cloud-qe-4 export]# ldapsearch -LLLx -p 24202 -h localhost -D "cn=Directory Manager" -w Secret123 -b "cn=replica,cn=o\=airius.com,cn=mapping tree,cn=config" nsds5ReplicaProtocolTimeout
dn: cn=replica,cn=o\3Dairius.com,cn=mapping tree,cn=config
nsds5ReplicaProtocolTimeout: -15

Actual results: Accepts negative value.

Expected results: It should reject the negative value with error 53.

[root@cloud-qe-4 export]# ldapmodify -x -p 24202 -h localhost -D "cn=Directory Manager" -w Secret123 << EOFdn: cn=24202_to_24206,cn=replica,cn=o\=airius.com,cn=mapping tree,cn=config
changetype: modify
replace: nsds5ReplicaProtocolTimeout
nsds5ReplicaProtocolTimeout: -15
EOF

modifying entry "cn=24202_to_24206,cn=replica,cn=o\=airius.com,cn=mapping tree,cn=config"
ldap_modify: Server is unwilling to perform (53)
	additional info: attribute nsds5ReplicaProtocolTimeout value (-15) is invalid, must be a number greater than zero.


Additional info:
Refer:
https://bugzilla.redhat.com/show_bug.cgi?id=918714
https://bugzilla.redhat.com/show_bug.cgi?id=1042855

Comment 2 mreynolds 2015-12-22 21:15:39 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/48393

Comment 4 Simon Pichugin 2017-11-08 12:51:03 UTC
A related issue was found during the verification.

The verification test case was added to the upstream ticket - suites/replication/replica_config_test.py::test_replicaid_modification
https://pagure.io/389-ds-base/issue/48393#comment-477735

Steps to reproduce:
  1. Enable replication
  2. Get current nsDS5ReplicaId value
  3. Set valid value to nsDS5ReplicaId
  4. Set nsDS5ReplicaId to the old value

Expected results:
nsDS5ReplicaId should be successfully changed.

Actual results:
ldap.OPERATIONS_ERROR: {'desc': 'Operations error', 'info': 'replica type is already 2 - not changing'}

Comment 5 mreynolds 2017-11-14 17:40:52 UTC
(In reply to Simon Pichugin from comment #4)
> A related issue was found during the verification.
> 
> The verification test case was added to the upstream ticket -
> suites/replication/replica_config_test.py::test_replicaid_modification
> https://pagure.io/389-ds-base/issue/48393#comment-477735
> 
> Steps to reproduce:
>   1. Enable replication
>   2. Get current nsDS5ReplicaId value
>   3. Set valid value to nsDS5ReplicaId
>   4. Set nsDS5ReplicaId to the old value
> 
> Expected results:
> nsDS5ReplicaId should be successfully changed.
> 
> Actual results:
> ldap.OPERATIONS_ERROR: {'desc': 'Operations error', 'info': 'replica type is
> already 2 - not changing'}

Just adding a note that this behavior is not a regression, but since we improved the overall replication config validation this should also be addressed.

Comment 6 Simon Pichugin 2017-11-22 12:07:13 UTC
====================== test session starts ======================
platform linux2 -- Python 2.7.5, pytest-3.2.5, py-1.5.2, pluggy-0.4.0 -- /usr/bin/python
cachedir: .cache
metadata: {'Python': '2.7.5', 'Platform': 'Linux-3.10.0-768.el7.x86_64-x86_64-with-redhat-7.5-Maipo', 'Packages': {'py': '1.5.2', 'pytest': '3.2.5', 'pluggy': '0.4.0'}, 'Plugins': {'html': '1.16.0', 'metadata': '1.5.0'}}
389-ds-base: 1.3.7.5-9.el7
nss: 3.34.0-0.1.beta1.el7
nspr: 4.17.0-1.el7
openldap: 2.4.44-9.el7
svrcore: 4.1.3-2.el7

rootdir: /mnt/tests/rhds/tests/upstream/ds, inifile:
plugins: metadata-1.5.0, html-1.16.0
collected 32 items

dirsrvtests/tests/suites/replication/replica_config_test.py::test_replica_num_add[nsDS5ReplicaType--1-4-9999999999999999999999999999999999999999999999999999999999999999999-invalid-1] PASSED
dirsrvtests/tests/suites/replication/replica_config_test.py::test_replica_num_add[nsDS5Flags--1-2-9999999999999999999999999999999999999999999999999999999999999999999-invalid-1] PASSED

...

====================== 32 passed in 17.35 seconds ======================

Marking as VERIFIED.

Comment 9 errata-xmlrpc 2018-04-10 14:15:15 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-2018:0811