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 1249784 - ipa-dnskeysyncd unhandled exception on named-pkcs11 start
Summary: ipa-dnskeysyncd unhandled exception on named-pkcs11 start
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-03 20:02 UTC by Scott Poore
Modified: 2020-09-13 21:30 UTC (History)
9 users (show)

Fixed In Version: 389-ds-base-1.3.4.0-11.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 11:43:55 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
abrt dir for crash (3.00 KB, application/x-gzip)
2015-08-03 20:03 UTC, Scott Poore 		no flags Details
wireshark capture of a ldap lookup (2.49 KB, application/x-gzip)
2015-08-12 15:22 UTC, thierry bordaz 		no flags Details
Reading the UUID from a repl_sync search (970 bytes, text/plain)
2015-08-14 17:23 UTC, thierry bordaz 		no flags Details
userRoot.ldif for verification (3.26 KB, application/x-fluid)
2015-08-19 13:32 UTC, Viktor Ashirov 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 1580 0 None None None 2020-09-13 21:29:59 UTC
Red Hat Product Errata RHBA-2015:2351 0 normal SHIPPED_LIVE 389-ds-base bug fix and enhancement update 2015-11-19 10:28:44 UTC

Description Scott Poore 2015-08-03 20:02:51 UTC 
Description of problem:

Saw abrt crash report:


keysyncer.py:92:application_sync:AssertionError: modrdn operation is not supported

Traceback (most recent call last):
  File "/usr/libexec/ipa/ipa-dnskeysyncd", line 112, in <module>
    while ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):
  File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 376, in syncrepl_poll
    self.syncrepl_entry(dn, attrs, c.entryUUID)
  File "/usr/lib/python2.7/site-packages/ipapython/dnssec/syncrepl.py", line 75, in syncrepl_entry
    self.application_sync(uuid, dn, attributes, previous_attributes)
  File "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", line 92, in application_sync
    assert olddn == newdn, 'modrdn operation is not supported'
AssertionError: modrdn operation is not supported

Local variables in innermost frame:
dn: 'ipk11UniqueID=56e05fdc-3985-11e5-b5fe-a02bb81f3758,cn=keys,cn=sec,cn=dns,dc=testrelm,dc=test'
uuid: '4d0003c8-7c7f-0000-2c31-5d2e6d616e61'
self: <ipapython.dnssec.keysyncer.KeySyncer instance at 0x25e34d0>
objclass: 'idnszone'
newdn: [[('ipk11UniqueID', '56e05fdc-3985-11e5-b5fe-a02bb81f3758', 1)], [('cn', 'keys', 1)], [('cn', 'sec', 1)], [('cn', 'dns', 1)], [('dc', 'testrelm', 1)], [('dc', 'test', 1)]]
newattrs: {'dn': 'ipk11UniqueID=56e05fdc-3985-11e5-b5fe-a02bb81f3758,cn=keys,cn=sec,cn=dns,dc=testrelm,dc=test', 'objectclass': ['ipk11PublicKey', 'ipk11Object', 'top', 'ipaPublicKeyObject', 'ipk11Key', 'ipk11StorageObject'], 'ipk11wrap': ['TRUE'], 'ipk11label': ['dnssec-replica:idm-qe-03.testrelm.test.'], 'ipk11id': ['\xcer\xfe\xefo\xee\x04\xa9\x03u\xc3\x16\x9bes\xce'], 'ipk11verify': ['FALSE'], 'ipapublickey': ['0\x82\x01"0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x01\x05\x00\x03\x82\x01\x0f\x000\x82\x01\n\x02\x82\x01\x01\x00\xc7\x0f\xad\xe3\xf1@\xbcP\xac\x13\x91q\xb6J6on.\x9e\xa2\xa5\x8f\x08\xfa\xaa\xb8N:\xc2\xc9\xe9\x92\x1f\r\xbb\xaa\xa2\xba\x96\x9dg\x94?\xacu+\xdb\x01\x13N=i\xbd<k+\xb1\xef\xcc\xcc"[\xaa\xb4\xc9\n\x06]<\xe29\x13\xd2\x81\x81\xdbA\xb8Z\x1e\x01\x1e:\x19\x89\x1e\xbe?t\xde\x83\xcf\x12\xd9~/\x03\xc2c\x0b\xd0\x1aD\x12\xad{\xb5N`J\xb2Y\xde\xc9\xde\x07\x8f\xebh:v\x05G\xfa\x05\xf5\xd0\x1d:y>\x85H\x7f\x14\x8f\xf6C\xbae\xf43\xa4<\x9f\xd6 \xb3\xda\xd2<L,\xe8\xc4\xdf\xe2tD\x01\xf3\xffw}\x86.\xedk>Az[f\xbex\xa9\xed\x01\xdbF\x16\xc6\xfd\x9a\xcf\xde\xfa\x13t{\xb36\xa9\x03\x9f\xc2`\x95m\x84\xeb\x88N\xd0r\x9a\x18\x83\xb8\xd0f\x9d.\x8a\x14\xe2Hk\xd8\xf3\x12\xf7\xe6\xc9\xee\xe0\x868!x&0\xaf\n\xee\xef\xa0\x16\xcf\xb3\x97!\xc6\x13J\x8d\xd9\xef\xac\xa5^\x80\xed\xd4\x13?\x02\x03\x01\x00\x01'], 'ipk11verifyrecover': ['FALSE'], 'ipk11uniqueid': ['56e05fdc-3985-11e5-b5fe-a02bb81f3758']}
olddn: [[('idnsname', 'testrelm.test.', 1)], [('cn', 'dns', 1)], [('dc', 'testrelm', 1)], [('dc', 'test', 1)]]
oldattrs: {'idnszoneactive': ['TRUE'], 'idnssoaexpire': ['1209600'], 'nsrecord': ['idm-qe-03.testrelm.test.'], 'objectclass': ['idnszone', 'top', 'idnsrecord'], 'idnsallowtransfer': ['none;'], 'idnssoaretry': ['900'], 'idnssoaserial': ['1438568051'], 'idnssoaminimum': ['3600'], 'dn': 'idnsname=testrelm.test.,cn=dns,dc=testrelm,dc=test', 'idnsupdatepolicy': ['grant TESTRELM.TEST krb5-self * A; grant TESTRELM.TEST krb5-self * AAAA; grant TESTRELM.TEST krb5-self * SSHFP;'], 'idnssoarefresh': ['3600'], 'idnsallowquery': ['any;'], 'idnsname': ['testrelm.test.'], 'idnssoamname': ['idm-qe-03.testrelm.test.'], 'idnssoarname': ['hostmaster.testrelm.test.'], 'idnsallowdynupdate': ['TRUE']}


Version-Release number of selected component (if applicable):
ipa-server-4.2.0-3.el7.x86_64
bind-pkcs11-9.9.4-27.el7.x86_64


How reproducible:
unknown

Steps to Reproduce:
1.  Install IPA on Master and replica.


Actual results:
See this crash if abrt configured.  Else, check logs for crash.

Expected results:
no crash

Additional info:


/var/log/messages:
Aug  2 22:14:15 idm-qe-03 systemd: Starting Berkeley Internet Name Domain (DNS) with native PKCS#11...
Aug  2 22:14:15 idm-qe-03 bash: zone localhost.localdomain/IN: loaded serial 0
Aug  2 22:14:15 idm-qe-03 bash: zone localhost/IN: loaded serial 0
Aug  2 22:14:15 idm-qe-03 bash: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0
Aug  2 22:14:15 idm-qe-03 bash: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
Aug  2 22:14:15 idm-qe-03 bash: zone 02.
3..in-addr.arpa/IN: loaded serial 0
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: starting BIND 9.9.4-RedHat-9.9.4-27.el7 -u named
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-depende
ncy-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include'
 '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstate
dir=/var' '--enable-threads' '--enable-ipv6' '--enable-filter-aaaa' '--enable-rrl' '--with-pic' '--disable-static' '--disable-openssl-version-check' '--enable-expo
rtlib' '--with-export-libdir=/usr/lib64' '--with-export-includedir=/usr/include' '--includedir=/usr/include/bind9' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib
64/pkcs11/libsofthsm2.so' '--with-dlopen=yes' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-dlz-bdb=ye
s' '--with-gssapi=yes' '--disable-isc-spnego' '--enable-fixed-rrset' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' 'build_alias=x86_64-redhat-linux-
gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grec
ord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ' 'CPPFLAGS= -DDIG_SIGCHASE'
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: ----------------------------------------------------
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: BIND 9 is maintained by Internet Systems Consortium,
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: Inc. (ISC), a non-profit 501(c)(3) public-benefit
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: corporation.  Support and training for BIND 9 are
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: available at https://www.isc.org/support
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: ----------------------------------------------------
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: adjusted limit on open files from 4096 to 1048576
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: found 4 CPUs, using 4 worker threads
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: using 4 UDP listeners per interface
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: using up to 4096 sockets
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: loading configuration from '/etc/named.conf'
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: reading built-in trusted keys from file '/etc/named.iscdlv.key'
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: using default UDP/IPv4 port range: [1024, 65535]
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: using default UDP/IPv6 port range: [1024, 65535]
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: listening on IPv6 interfaces, port 53
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: listening on IPv4 interface lo, 127.0.0.1#53
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: listening on IPv4 interface eno1, MY_IP_ADDRESS#53
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: generating session key for dynamic DNS
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: sizing zone task pool based on 6 zones
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: set up managed keys zone for view _default, file '/var/named/dynamic/managed-keys.bind'
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: bind-dyndb-ldap version 8.0 compiled at 10:31:01 Jun 23 2015, compiler 4.8.3 20140911 (Red Hat 4.8.3-9)
Aug  2 22:14:15 idm-qe-03 named-pkcs11[21959]: option 'serial_autoincrement' is not supported, ignoring
Aug  2 22:14:15 idm-qe-03 ipa-dnskeysyncd: ipa: WARNING: session memcached servers not running
Aug  2 22:14:16 idm-qe-03 ipa-dnskeysyncd: ipa         : INFO     LDAP bind...
Aug  2 22:14:17 idm-qe-03 ipa-dnskeysyncd: ipa         : INFO     Commencing sync process
Aug  2 22:14:17 idm-qe-03 python2: detected unhandled Python exception in '/usr/libexec/ipa/ipa-dnskeysyncd'
Comment 1 Scott Poore 2015-08-03 20:03:20 UTC 
Created attachment 1058887 [details]
abrt dir for crash
Comment 3 Martin Kosek 2015-08-04 06:55:18 UTC 
Scott, I assume you tried to rename some DNS entry and it was rejected by the DNSSEC daemon.

I will CC Martin to look at the bug when he returns from his leave.
Comment 4 Scott Poore 2015-08-04 17:05:22 UTC 
From the timing, it looks like the crash occurred during ipa-server-install.
Comment 5 Martin Bašti 2015-08-12 13:01:53 UTC 
I figured out that IPA receives entries with *non unique* UUID.
http://pastebin.test.redhat.com/304726

However, ldapsearch returns entries with unique uuid (nsuniqueid), so error is caused by syncrepl.

I tested python-ldap syncrepl consumer, it worked as expected on F22 (389-ds-base-1.3.4.1-1.fc22.x86_64), but returns nonunique UUIDs from (389-ds-base-1.3.4.0-10.el7.x86_64)

Thierry is investigating.
Comment 6 thierry bordaz 2015-08-12 14:42:59 UTC 
Using Martin machine, I can reproduce using his script or ldapsearch. In fact the uuid in some cookie are looking identical:

ldapsearch -L -D "cn=directory manager" -w hesloheslo -b "cn=sec,cn=dns,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" -E sync=ro nsuniqueid
...
# keys, sec, dns, abc.idm.lab.eng.brq.redhat.com
dn: cn=keys,cn=sec,cn=dns,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com
# control: 1.3.6.1.4.1.4203.1.9.1.2 false MBUKAQEEEBx2AHR5fwAAFwAAAAAAAAA=
nsuniqueid: 1c760040-402911e5-8adbaa93-ff7e4820

# 2dcfe996-4029-11e5-bbe7-001a4a231210, keys, sec, dns, abc.idm.lab.eng.brq.r
 edhat.com
dn: ipk11UniqueID=2dcfe996-4029-11e5-bbe7-001a4a231210,cn=keys,cn=sec,cn=dns,d
 c=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com
# control: 1.3.6.1.4.1.4203.1.9.1.2 false MBUKAQEEEBx2AHR5fwAAFwAAAAAAAAA=
nsuniqueid: 1c760042-402911e5-8adbaa93-ff7e4820


UUID are built from 'nsuniqueid'
It should return different values:

[root@vm-127 slapd-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM]# /root/nsuniqueid_2_uuid 1c760040-402911e5-8adbaa93-ff7e4820
uuid[ 0] = 0x1c
uuid[ 1] = 0x76 ['v']
uuid[ 2] = 0x00
uuid[ 3] = 0x40 ['@']
uuid[ 4] = 0x40 ['@']
uuid[ 5] = 0x29 [')']
uuid[ 6] = 0x11
uuid[ 7] = 0xffffffe5
uuid[ 8] = 0xffffff8a
uuid[ 9] = 0xffffffdb
uuid[10] = 0xffffffaa
uuid[11] = 0xffffff93
uuid[12] = 0xffffffff
uuid[13] = 0x7e ['~']
uuid[14] = 0x48 ['H']
uuid[15] = 0x20 [' ']
[root@vm-127 slapd-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM]# 
[root@vm-127 slapd-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM]# /root/nsuniqueid_2_uuid 1c760042-402911e5-8adbaa93-ff7e4820
uuid[ 0] = 0x1c
uuid[ 1] = 0x76 ['v']
uuid[ 2] = 0x00
uuid[ 3] = 0x42 ['B']
uuid[ 4] = 0x40 ['@']
uuid[ 5] = 0x29 [')']
uuid[ 6] = 0x11
uuid[ 7] = 0xffffffe5
uuid[ 8] = 0xffffff8a
uuid[ 9] = 0xffffffdb
uuid[10] = 0xffffffaa
uuid[11] = 0xffffff93
uuid[12] = 0xffffffff
uuid[13] = 0x7e ['~']
uuid[14] = 0x48 ['H']
uuid[15] = 0x20 [' ']


There is no specific logging at that place, I am debugging it.
Comment 8 thierry bordaz 2015-08-12 15:22:25 UTC 
Created attachment 1062053 [details]
wireshark capture of a ldap lookup

SRCH under cn=sec,cn=dns,SUFFIX. 2 entries have the same uuid
Comment 9 thierry bordaz 2015-08-13 08:16:29 UTC 
Here is the current status

	- The RC is that DS uses slapi_ch_smprintf("%s") to manipulate the UUID
          If the computed UUID contains a NULL character, then smprintf does not copy
          all the computed UUID and the remaining part of the UUID is random
          (depends on what was on the heap at that time)

Breakpoint 4, sync_nsuniqueid2uuid (nsuniqueid=0x7f796c046cf0 "1c760042-402911e5-8adbaa93-ff7e4820")
    at ldap/servers/plugins/sync/sync_util.c:110
110		uuid = slapi_ch_smprintf("%s",(char *)u);
(gdb) n
106		u[15] = slapi_str_to_u8(nsuniqueid+33);
(gdb) 
110		uuid = slapi_ch_smprintf("%s",(char *)u);
(gdb) 
108		u[16] = '\0';
(gdb) 
110		uuid = slapi_ch_smprintf("%s",(char *)u);
(gdb) 
113	}
(gdb) x/16bx u
0x7f79917ead00:	0x1c	0x76	0x00	0x42	0x40	0x29	0x11	0xe5
0x7f79917ead08:	0x8a	0xdb	0xaa	0x93	0xff	0x7e	0x48	0x20
(gdb) x/16bx uuid
0x7f7978341eb0:	0x1c	0x76	0x00	0x78	0x79	0x7f	0x00	0x00
0x7f7978341eb8:	0x17	0x00	0x00	0x00	0x00	0x00	0x00	0x00


	- The buffer is correctly copied if it does not contain NULL

(gdb) x/16x u
0x7f7993fefd00:	0x1c	0x76	0x00	0x42	0x40	0x29	0x11	0xe5
0x7f7993fefd08:	0x8a	0xdb	0xaa	0x93	0xff	0x7e	0x48	0x00
$15 = (void *) 0x7f7993fefd00
(gdb) set {char}0x7f7993fefd02 = 18
(gdb) x/16x u
0x7f7993fefd00:	0x1c	0x76	0x12	0x42	0x40	0x29	0x11	0xe5
0x7f7993fefd08:	0x8a	0xdb	0xaa	0x93	0xff	0x7e	0x48	0x00
(gdb) n
106		u[15] = slapi_str_to_u8(nsuniqueid+33);
(gdb) 
110		uuid = slapi_ch_smprintf("%s",(char *)u);
(gdb) 
108		u[16] = '\0';
(gdb) 
110		uuid = slapi_ch_smprintf("%s",(char *)u);
(gdb) 
113	}
(gdb) x/16x u
0x7f7993fefd00:	0x1c	0x76	0x12	0x42	0x40	0x29	0x11	0xe5
0x7f7993fefd08:	0x8a	0xdb	0xaa	0x93	0xff	0x7e	0x48	0x20
(gdb) x/16x uuid
0x7f797c021670:	0x1c	0x76	0x12	0x42	0x40	0x29	0x11	0xe5
0x7f797c021678:	0x8a	0xdb	0xaa	0x93	0xff	0x7e	0x48	0x20


	- The fact that two entries have same "wrong" UUID is really random
          but in fact it happens very frequently

	- This should also occured in 7.1 but was not noticed

	In conclusion:
		Since 7.1 UUID values may be corrupted. With collision of entries UUID or same entry having a different UUID some time later.

Here are the next steps

	- This is a DS bug. Moving it to 389-ds

	- The fix is easy, allocate+memcopy the final UUID
Comment 10 Noriko Hosoi 2015-08-14 00:58:24 UTC 
Upstream ticket:
https://fedorahosted.org/389/ticket/48249
Comment 11 Noriko Hosoi 2015-08-14 01:02:31 UTC 
Thank you for your investigation, Thierry!
Please use this ticket for the usual review process.
https://fedorahosted.org/389/ticket/48249
Thanks!
Comment 14 thierry bordaz 2015-08-14 17:23:07 UTC 
Created attachment 1063143 [details]
Reading the UUID from a repl_sync search

I borrow that script from mbasti.

It does a search on a subtree using repl_sync control and displays the returned entry DN with their UUID.
Comment 18 Viktor Ashirov 2015-08-19 13:32:27 UTC 
Created attachment 1064853 [details]
userRoot.ldif for verification

[1] Import ldif with user entries, that contain 0x00 in their nsuniqeid:
# ldif2db -n userRoot -i /var/lib/dirsrv/slapd-rhel7ds/ldif/rhel7ds-userRoot-2015_08_19_151141.ldif

# ldapsearch -D "cn=Directory Manager" -w Secret123 -b dc=example,dc=com -o ldif-wrap=no -LLL "(cn=usr*)" nsuniqueid 
dn: cn=usr1,ou=People,dc=example,dc=com
nsuniqueid: 105b0001-465c11e5-aa2ab26e-9f0d9380

dn: cn=usr2,ou=People,dc=example,dc=com
nsuniqueid: 105b0002-465c11e5-aa2ab26e-9f0d9380

[2] Enable retro changelog and content synchronization operation plugins.

[3] With an older version of 389-ds-base script from comment 14 returned the same UUID for both entries, though every time random.
[root@rhel7ds 1249784-ipa-dnskeysyncd-unhandled-exception-on-named-pkcs1]# python replsync_uuid.py 
entry 020ad983-4658-11e5-836e-d1c2fb4ae609 ou=People,dc=example,dc=com
entry 105b0010-027f-0000-6c65-2c64633d636f cn=usr1,ou=People,dc=example,dc=com
entry 105b0010-027f-0000-6c65-2c64633d636f cn=usr2,ou=People,dc=example,dc=com
^C[root@rhel7ds 1249784-ipa-dnskeysyncd-unhandled-exception-on-named-pkcs1]# python replsync_uuid.py 
entry 020ad983-4658-11e5-836e-d1c2fb4ae609 ou=People,dc=example,dc=com
entry 105b00fc-017f-0000-6c65-2c64633d636f cn=usr1,ou=People,dc=example,dc=com
entry 105b00fc-017f-0000-6c65-2c64633d636f cn=usr2,ou=People,dc=example,dc=com
^C[root@rhel7ds 1249784-ipa-dnskeysyncd-unhandled-exception-on-named-pkcs1]# python replsync_uuid.py 
entry 020ad983-4658-11e5-836e-d1c2fb4ae609 ou=People,dc=example,dc=com
entry 105b0008-027f-0000-6c65-2c64633d636f cn=usr1,ou=People,dc=example,dc=com
entry 105b0008-027f-0000-6c65-2c64633d636f cn=usr2,ou=People,dc=example,dc=com


With 389-ds-base-1.3.4.0-12.el7.x86_64:
[root@rhel7ds 1249784-ipa-dnskeysyncd-unhandled-exception-on-named-pkcs1]# python replsync_uuid.py 
entry 020ad983-4658-11e5-836e-d1c2fb4ae609 ou=People,dc=example,dc=com
entry 105b0001-465c-11e5-aa2a-b26e9f0d9380 cn=usr1,ou=People,dc=example,dc=com
entry 105b0002-465c-11e5-aa2a-b26e9f0d9380 cn=usr2,ou=People,dc=example,dc=com
^C[root@rhel7ds 1249784-ipa-dnskeysyncd-unhandled-exception-on-named-pkcs1]# python replsync_uuid.py 
entry 020ad983-4658-11e5-836e-d1c2fb4ae609 ou=People,dc=example,dc=com
entry 105b0001-465c-11e5-aa2a-b26e9f0d9380 cn=usr1,ou=People,dc=example,dc=com
entry 105b0002-465c-11e5-aa2a-b26e9f0d9380 cn=usr2,ou=People,dc=example,dc=com
^C[root@rhel7ds 1249784-ipa-dnskeysyncd-unhandled-exception-on-named-pkcs1]# python replsync_uuid.py 
entry 020ad983-4658-11e5-836e-d1c2fb4ae609 ou=People,dc=example,dc=com
entry 105b0001-465c-11e5-aa2a-b26e9f0d9380 cn=usr1,ou=People,dc=example,dc=com
entry 105b0002-465c-11e5-aa2a-b26e9f0d9380 cn=usr2,ou=People,dc=example,dc=com
^C[root@rhel7ds 1249784-ipa-dnskeysyncd-unhandled-exception-on-named-pkcs1]# 

UUIDs are different for each entry. 

Marking as VERIFIED.
Comment 19 errata-xmlrpc 2015-11-19 11:43:55 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://rhn.redhat.com/errata/RHBA-2015-2351.html
Note You need to log in before you can comment on or make changes to this bug.