Bug 1610234

Summary:	nsslapd-defaultnamingcontext does not change when the assigned suffix got deleted.
Product:	Red Hat Enterprise Linux 7	Reporter:	Amita Sharma <amsharma>
Component:	389-ds-base	Assignee:	mreynolds
Status:	CLOSED ERRATA	QA Contact:	RHDS QE <ds-qe-bugs>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	7.6	CC:	bsmejkal, cpelland, nkinder, pasik, vashirov
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	389-ds-base-1.3.10.1-2.el7	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-03-31 19:46:14 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 Amita Sharma 2018-07-31 09:23:41 UTC

Description of problem:
nsslapd-defaultnamingcontext does not change when the assigned suffix got deleted.

Version-Release number of selected component (if applicable):
389-ds-base-1.3.8.4-9.el7.x86_64


How reproducible:
Always

Steps to Reproduce:
1. Add a test suffix - "dc=test2,dc=com"

2. Assign the test suffix to the nsslapd-defaultnamingcontext
ldapmodify -x -h localhost -p 389 -D "cn=Directory Manager"  -w Secret123 << EOF
dn: cn=config
changetype: modify
replace: nsslapd-defaultnamingcontext
nsslapd-defaultnamingcontext: "dc=test2,dc=com"
EOF

3. delete the suffix :
ldapdelete -x -r -h localhost -p 389 -D "cn=Directory Manager"  -w Secret123 "dc=test,dc=com"

4. Check the value of nsslapd-defaultnamingcontext, it is still the same suffix which is already deleted. 
ldapsearch -x -h localhost -p 389 -D "cn=Directory Manager"  -w Secret123 -b "cn=config" | grep -i "nsslapd-defaultnamingcontext"
nsslapd-defaultnamingcontext: dc=test,dc=com


Expected results:
Either nsslapd-defaultnamingcontext should be blank OR it should have the other existing suffix as its value.

Comment 3 mreynolds 2019-08-01 20:45:45 UTC

Note - it is not possible to delete 'nsslapd-defaultnamingcontext', so we can only change it if there is an available suffix configured

Comment 4 mreynolds 2019-08-01 20:49:06 UTC

Upstream ticket:
https://pagure.io/389-ds-base/issue/50525

Comment 6 bsmejkal 2019-09-13 11:19:09 UTC

=============================================================================================== test session starts ===============================================================================================
platform linux -- Python 3.6.3, pytest-5.1.2, py-1.8.0, pluggy-0.13.0 -- /opt/rh/rh-python36/root/usr/bin/python3
cachedir: .pytest_cache
metadata: {'Python': '3.6.3', 'Platform': 'Linux-3.10.0-1090.el7.x86_64-x86_64-with-redhat-7.8-Maipo', 'Packages': {'pytest': '5.1.2', 'py': '1.8.0', 'pluggy': '0.13.0'}, 'Plugins': {'metadata': '1.8.0', 'html': '2.0.0'}}
389-ds-base: 1.3.10.1-2.el7
nss: 3.44.0-5.el7
nspr: 4.21.0-1.el7
openldap: 2.4.44-21.el7_6
cyrus-sasl: 2.1.26-23.el7
FIPS: disabled
rootdir: /mnt/tests/rhds/tests/upstream/ds/dirsrvtests, inifile: pytest.ini
plugins: metadata-1.8.0, html-2.0.0
collected 1 item                                                                                                                                                                                                  

be_del_and_default_naming_attr_test.py::test_be_delete PASSED                                                                                                                                               [100%]

========================================================================================== 1 passed in 9.85s ======================================================================================================

Marking as VERIFIED.

Comment 8 errata-xmlrpc 2020-03-31 19:46:14 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-2020:1064