Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
There was a situation with a 2xMMR 1.2.11-15 master on RHEL 6, in which an on-line would not happen well as entries were mysteriously skipped with no apparent valid reason after trouble shooting schema and data:
in my testing, I got
[04/Mar/2016:18:12:49 -0800] - import userRoot: WARNING: Skipping entry "uid=user1,ou=someou,dc=example,dc=com" which has no parent, ending at line 0 of file "(bulk import)"
[04/Mar/2016:18:12:49 -0800] - import userRoot: WARNING: bad entry: ID 10016
in the customer environment, edited errors log samples:
[04/Mar/2016:16:14:51 -0500] - Bulk import: begin import on 'o=test'.
[04/Mar/2016:16:14:51 -0500] - Entry "dd=ccc,ou=ou1,ou=somedata,o=test" required attribute "objectclass" missing
[04/Mar/2016:16:14:51 -0500] - import example: WARNING: Skipping entry "dd=subou1,ou=ou2,ou=somedata,o=test" which has no parent, ending at line 0 of file "(bulk import)"
[04/Mar/2016:16:14:51 -0500] - import example: WARNING: Skipping entry "dd=xxx,ou=ou2,ou=somedata,o=test" which has no parent, ending at line 0 of file "(bulk import)"
[04/Mar/2016:16:14:51 -0500] - import example: WARNING: Skipping entry "dd=yyy,ou=ou2,ou=Ssomedata,o=test" which has no parent, ending at line 0 of file "(bulk import)"
[04/Mar/2016:16:14:51 -0500] - import example: WARNING: Skipping entry "dd=zzz,ou=ou1,ou=somedata,o=test" which has no parent, ending at line 0 of file "(bulk import)"
[04/Mar/2016:16:14:51 -0500] - import example: WARNING: Skipping entry "dd=aaa,ou=ou1,ou=somedata,o=test" which has no parent, ending at line 0 of file "(bulk import)"
[04/Mar/2016:16:14:51 -0500] - Entry "dd=tcoolApp,ou=ou4,ou=somedata,o=test" required attribute "objectclass" missing
[04/Mar/2016:16:14:51 -0500] - Entry "dd=PSWebApp,ou=ou4,ou=somedata,o=test" required attribute "objectclass" missing
..snip..
And the LDIF data and schema wer verified, and looked all correct (there is no errors from master1 using that same custom schema and data)
I could not verify (not received at this time) the customer's dbscan on master1 for the order of some of those entries.
this issue was added to port389 upstream ticket 48755 by Noriko H.:
https://fedorahosted.org/389/ticket/48755
Version-Release number of selected component (if applicable):
reported and tested for this report with same version as the customer:
389-ds-base-1.2.11.15-69.el6_7.x86_64
but happens on all versions including branch
How reproducible:
on demand
Steps to Reproduce:
Noriko H. provided the test case scenario in the upstream ticket 48755, here a test of mine to verify:
1. Have system and 389-ds-base installed, configured and running with 2xMMR, shown here with suffix dc=example,dc=com
2. add a user entry, for example with DN uid=user1,ou=people,dc=example,dc=com
ldapmodify -xD "cn=directory manager" -w password << EOF
dn: uid=user1,ou=people,dc=example,dc=com
changetype: add
title: got promoted again 7
gidNumber: 10001
uidNumber: 10001
loginShell: /bin/bash
userPassword: password
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
mail: user1.com
sn: user1
cn: user1
uid: user1
homeDirectory: /home/guests/user1
telephoneNumber: +1 111 222 3333
facsimileTelephoneNumber: +1 111 222 3333
mobile: +1 111 222 3333
roomNumber: 0123456789
carLicense: 6ZBC246
displayName: somedisplayname texttexttext
givenName: somegivenname texttexttext
initials: someinitials
departmentNumber: 0123456789
employeeNumber: 0123456789
employeeType: full time texttexttext
EOF
verify:
ldapsearch -LLLxD "cn=directory manager" -w password -b dc=example,dc=com uid=user1 dn
dn: uid=user1,ou=people,dc=example,dc=com
3. add a ou:
ldapmodify -xD "cn=directory manager" -w password << EOF
dn: ou=someou,dc=example,dc=com
changetype: add
ou: someou
objectClass: organizationalUnit
objectClass: top
EOF
verify:
ldapsearch -LLLxD "cn=directory manager" -w password -b dc=example,dc=com ou=someou dn
dn: ou=someou,dc=example,dc=com
4. now the trick to recreate the real scenario, move the test user entry to the test ou:
ldapmodify -xD "cn=directory manager" -w password << EOF
dn: uid=user1,ou=people,dc=example,dc=com
changetype: modrdn
newrdn: uid=user1
deleteoldrdn: 0
newsuperior: ou=someou,dc=example,dc=com
EOF
verify:
ldapsearch -LLLxD "cn=directory manager" -w password -b dc=example,dc=com uid=user1 dn
dn: uid=user1,ou=someou,dc=example,dc=com
5. on master1, do online init to master2 of the db hosting the suffix dc=example,dc=com
6. on master2, review the errors log file
tail -f /var/log/dirsrv/slapd-m2/errors
and notice the
import userRoot: WARNING: Skipping entry "uid=user1,ou=someou,dc=example,dc=com" which has no parent, ending at line 0 of file "(bulk import)"
import userRoot: WARNING: bad entry: ID 10016
Actual results:
[04/Mar/2016:18:12:34 -0800] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=example,dc=com is going offline; disabling replication
[04/Mar/2016:18:12:35 -0800] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database
[04/Mar/2016:18:12:49 -0800] - import userRoot: WARNING: Skipping entry "uid=user1,ou=someou,dc=example,dc=com" which has no parent, ending at line 0 of file "(bulk import)"
[04/Mar/2016:18:12:49 -0800] - import userRoot: WARNING: bad entry: ID 10016
[04/Mar/2016:18:12:51 -0800] - import userRoot: Workers finished; cleaning up...
[04/Mar/2016:18:12:51 -0800] - import userRoot: Workers cleaned up.
[04/Mar/2016:18:12:51 -0800] - import userRoot: Indexing complete. Post-processing...
[04/Mar/2016:18:12:51 -0800] - import userRoot: Generating numSubordinates complete.
[04/Mar/2016:18:12:51 -0800] - import userRoot: Flushing caches...
[04/Mar/2016:18:12:51 -0800] - import userRoot: Closing files...
[04/Mar/2016:18:13:47 -0800] - import userRoot: Import complete. Processed 10018 entries (1 were skipped) in 72 seconds. (139.14 entries/sec)
[04/Mar/2016:18:13:47 -0800] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=example,dc=com is coming online; enabling replication
[04/Mar/2016:18:13:47 -0800] NSMMReplicationPlugin - replica_reload_ruv: Warning: new data for replica dc=example,dc=com does not match the data in the changelog.
Recreating the changelog file. This could affect replication with replica's consumers in which case the consumers should be reinitialized.
[04/Mar/2016:18:13:47 -0800] NSMMReplicationPlugin - Need to create replication keep alive entry <cn=repl keep alive 20,dc=example,dc=com>
[04/Mar/2016:18:13:48 -0800] NSMMReplicationPlugin - add dn: cn=repl keep alive 20,dc=example,dc=com
objectclass: top
objectclass: ldapsubentry
objectclass: extensibleObject
cn: repl keep alive 20
Expected results:
no skipping entry
Additional info:
a test workaround using db2ldif.pl task while the LDAP services were running looked OK, there is apparently no need to shutdown the LDAP service for a db2ldif/ldif2db, there were no more errors like:
[04/Mar/2016:18:12:49 -0800] - import userRoot: WARNING: Skipping entry "uid=user1,ou=someou,dc=example,dc=com" which has no parent, ending at line 0 of file "(bulk import)"
[04/Mar/2016:18:12:49 -0800] - import userRoot: WARNING: bad entry: ID 10016
master1
/usr/lib64/dirsrv/slapd-m1/db2ldif.pl -D "cn=directory manager" -w password -n userroot -r -a /var/tmp/userroot.with.replication.metadata.ldif
scp /var/tmp/userroot.with.replication.metadata.ldif root@master2:/var/tmp/
master 2
chown nobody:nobody /var/tmp/userroot.with.replication.metadata.ldif
ls -lh /var/tmp/userroot.with.replication.metadata.ldif
-rw-------. 1 nobody nobody 21M Mar 4 18:24 /var/tmp/userroot.with.replication.metadata.ldif
/usr/lib64/dirsrv/slapd-m2/ldif2db.pl -D "cn=directory manager" -w password -n userroot -i /var/tmp/userroot.with.replication.metadata.ldif
no more skipped entries due to this issue.
test notes
I also have the skipped entries in this scenario, which may be the customer's situation:
2xMMR on 389-ds-base-1.2.11.15-69.el6_7.x86_64
us01 / c=us,o=sps
with just:
dn: c=us,o=sps
dn: ou=someou1,c=us,o=sps
dn: ou=someou2,c=us,o=sps
spsclassroom02 / ou=spsclassroom,c=us,o=sps
with just:
dn: ou=spsclassroom,c=us,o=sps
dn: ou=someou1,ou=spsclassroom,c=us,o=sps
dn: ou=someou2,ou=spsclassroom,c=us,o=sps
then I created:
sps00 / o=sps
that backend and suffix has 105 entries from the customer data, with the associated custom schema.
in that scenario, everything "nearly" work, except the import with ldif2db.pl or ldif2db skip 8 entries, so the on-line init to m2 sends everything except those 8 skipped entries in m1.
modifying an entry on o=sps works, the changes were replicated from m1 to m2, replication is ok.
the problem is the skipped entries.
I havn't tried yet if I create o=sps first, then the other backend in sub suffixes.
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://rhn.redhat.com/errata/RHSA-2016-2594.html