This is what happens if you try to rename an non-existent user:
$ ldapmodify -x -D 'cn=directory manager' -W Enter LDAP Password: dn: uid=tuser1,cn=users,cn=accounts,dc=example,dc=com changetype: modrdn newrdn: uid=tuser deleteoldrdn: 1 modifying rdn of entry "uid=tuser1,cn=users,cn=accounts,dc=example,dc=com" ldap_rename: Operations error (1) additional info: Another entry with the same attribute value already exists (attribute: "ipaUniqueID")
I discovered this using the ipa command:
ipa user-mod --setattr=uid=tuser tuser1
It should return a no such entry error
This is causing a slew of our in-tree tests to fail making it difficult to certify that things are operating as they should.
Rob, I tracked this error down to preop_modify() in ldap/servers/plugins/uiduniq/uid.c
Should we open a dirsrv bug ?
This should be a dirsrv bug, but please reproduce it with plugin level error logging on. The attribute uniqueness plug-in should provide a little more information about what is happening.
This is what I get in error log with level 65536:
[20/Dec/2010:09:13:45 -0500] NS7bitAttr - MODRDN begin [20/Dec/2010:09:13:46 -0500] NS7bitAttr - MODRDN newrdn=uid=tuser [20/Dec/2010:09:13:46 -0500] NSUniqueAttr - MODRDN begin [20/Dec/2010:09:13:46 -0500] NSUniqueAttr - MODRDN newrdn=uid=tuser [20/Dec/2010:09:13:46 -0500] schema-compat-plugin - searching from "uid=tuser1,cn=users,cn=accounts,dc=example,dc=com" for "(|(objectclass=*)(objectclass=ldapsubentry))" with scope 0 [20/Dec/2010:09:13:46 -0500] schema-compat-plugin - slapi_be_exists("uid=tuser1,cn=users,cn=accounts,dc=example,dc=com") = 0, ignoring search [20/Dec/2010:09:13:46 -0500] NSUniqueAttr - Internal error: 35 [20/Dec/2010:09:13:46 -0500] NSUniqueAttr - MODRDN result 1
This is a Directory Server bug but it is not critical for the beta. Proposing for deferral.
Replying to [comment:7 simo]:
Was the bug ever opened? Was it addressed? Please put a BZ reference here.
Please close if the DS bug is addressed.
https://bugzilla.redhat.com/show_bug.cgi?id=674430
Bug is closed upstream, we need to determine what build it is in and re-test. We will need to update the min 389-ds value in our spec file.
Replying to [comment:12 rcritten]:
https://bugzilla.redhat.com/show_bug.cgi?id=674430 Bug is closed upstream, we need to determine what build it is in and re-test. We will need to update the min 389-ds value in our spec file.
According to git log, the fix (http://git.fedorahosted.org/git/?p=389/ds.git;a=commit;h=da533838fd9e804ff5f8a10f97b8b813bbd38d43) went into what was later tagged and released as 389-ds-base-1.2.8.a2
That version is in both F14 and F15 now and we actually require it, too. So I think we can just close this ticket.
Also my testing went fine:
$ cat rename.ldif dn: uid=tuser1,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com changetype: modrdn newrdn: uid=tuser deleteoldrdn: 1 $ ldapmodify -x -D 'cn=directory manager' -w password < rename.ldif modifying rdn of entry "uid=tuser1,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" ldap_rename: No such object (32) additional info: Error checking for attribute uniqueness.
Confirmed, closing.
Metadata Update from @rcritten: - Issue assigned to simo - Issue set to the milestone: FreeIPA 2.0.2 RC2 (bug fixing)
Login to comment on this ticket.