Bug 1463204 - Adding a database entry fails if the same database was deleted after an import
Adding a database entry fails if the same database was deleted after an import
Status: VERIFIED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
7.4
x86_64 Linux
high Severity high
: rc
: ---
Assigned To: mreynolds
Viktor Ashirov
: Regression
Depends On:
Blocks: 1502999 1503001
  Show dependency treegraph
 
Reported: 2017-06-20 07:29 EDT by Sankar Ramalingam
Modified: 2017-11-22 01:22 EST (History)
8 users (show)

See Also:
Fixed In Version: 389-ds-base-1.3.7.5-5.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1502999 1503001 (view as bug list)
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sankar Ramalingam 2017-06-20 07:29:02 EDT
Description of problem:
Adding a database entry fails if the same database was deleted after an import. This was found during troubleshooting of failed import tests.

Version-Release number of selected component (if applicable): 389-ds-base-1.3.6.1-16

How reproducible: Consistently

Steps to Reproduce:
1. Add database and suffix base entry.
[root@bkr-hv01-guest22 389ds-replica]# ldapmodify -x -p 1389 -h localhost -D "cn=Directory Manager" -w Secret123 -af /tmp/tests.ldif

[root@bkr-hv01-guest22 389ds-replica]# cat /tmp/tests.ldif
dn: cn="dc=example,dc=com",cn=mapping tree,cn=config
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend: example
cn: "dc=example,dc=com"

dn: cn=example,cn=ldbm database,cn=plugins,cn=config
objectClass: extensibleObject
objectClass: nsBackendInstance
nsslapd-suffix: dc=example,dc=com
nsslapd-cachesize: -1
nsslapd-cachememsize: 10485760

2. Stop the server and import an LDIF file with few entries.
systemctl stop dirsrv.target ; sleep 2 ; ldif2db -n example -i /var/lib/dirsrv/slapd-deftestinst/ldif/import07.ldif ; sleep 1 ; systemctl start dirsrv.target

[root@bkr-hv01-guest22 389ds-replica]# cat /var/lib/dirsrv/slapd-deftestinst/ldif/import07.ldif
dn: dc=example,dc=com
objectclass: top
objectclass: domain
dc: example

dn: ou=Groups, dc=example,dc=com
objectclass: top
objectclass: organizationalunit
ou: Groups

dn: ou=People, dc=example,dc=com
objectclass: top
objectclass: organizationalunit
ou: People

3. Run ldapdelete to remove all the entries for the database and suffix.
[root@bkr-hv01-guest22 389ds-replica]# ldapdelete -r -x -p 1389 -h localhost -D "cn=Directory Manager" -w Secret123 "cn=example,cn=ldbm database,cn=plugins,cn=config" ; ldapdelete -r -x -p 1389 -h localhost -D "cn=Directory Manager" -w Secret123 "cn=\"dc=example,dc=com\",cn=mapping tree,cn=config"

4. Run ldapmodify to add the same database and base entry for suffix. same as step #1.

[root@bkr-hv01-guest22 389ds-replica]# ldapmodify -xc -p 1389 -h localhost -D "cn=Directory Manager" -w Secret123 -af /tmp/tests.ldif 
adding new entry "cn="dc=example,dc=com",cn=mapping tree,cn=config"

adding new entry "cn=example,cn=ldbm database,cn=plugins,cn=config"
ldap_add: Server is unwilling to perform (53)

Actual results: It throws DSA unwilling to perform(error 53).

Expected results: No errors. Should be able to add the database entry after deleting completely.

Additional info:
This was found during troubleshooting of import failed tests. This can be verified by running import tests from TET.

[root@bkr-hv01-guest22 389ds-replica]# rpm -qa |grep -i 389-ds
389-ds-base-1.3.6.1-16.el7.x86_64
389-ds-base-debuginfo-1.3.6.1-16.el7.x86_64
389-ds-base-libs-1.3.6.1-16.el7.x86_64
Comment 4 Sankar Ramalingam 2017-08-09 01:41:09 EDT
Automated in Pytest - ./suites/import/regression_test.py
Comment 8 mreynolds 2017-10-12 15:59:31 EDT
Upstream ticket:
https://pagure.io/389-ds-base/issue/49402
Comment 10 Oneata Mircea Teodor 2017-10-17 03:46:50 EDT
This bug has been copied as 7.4 z-stream (EUS) bug #1503001 and now must be
resolved in the current update release, set blocker flag.
Comment 12 ashiveka 2017-11-22 01:22:50 EST
    ============================================================================ test session starts ============================================================================
    platform linux -- Python 3.5.1, pytest-3.2.3, py-1.4.34, pluggy-0.4.0 -- /opt/rh/rh-python35/root/usr/bin/python3
    cachedir: .cache
    metadata: {'Packages': {'pytest': '3.2.3', 'py': '1.4.34', 'pluggy': '0.4.0'}, 'Python': '3.5.1', 'Platform': 'Linux-3.10.0-748.el7.x86_64-x86_64-with-redhat-7.5-Maipo', 'Plugins': {'metadata': '1.5.0', 'html': '1.16.0'}}
    389-ds-base: 1.3.7.5-6.el7
    nss: 3.33.0-1.el7
    nspr: 4.17.0-1.el7
    openldap: 2.4.44-5.el7
    svrcore: 4.1.3-2.el7
     
    rootdir: /export/tests, inifile:
    plugins: metadata-1.5.0, html-1.16.0
    collected 2 items                                                                                                                                                            
     
    suites/import/regression_test.py::test_del_suffix_import PASSED
    suites/import/regression_test.py::test_del_suffix_backend PASSED
     
    ------------------------------------------------------- generated xml file: /mnt/tests/rhds/tests/upstream/report.xml -------------------------------------------------------
    ------------------------------------------------------ generated html file: /mnt/tests/rhds/tests/upstream/report.html ------------------------------------------------------
    ========================================================================= 2 passed in 27.61 seconds =========================================================================

Note You need to log in before you can comment on or make changes to this bug.