I am running 2.4.36 in my sandbox environment and have recently found myself needing to rename some entries in my directory. Slapd is reporting an object class violation when attempting to rename the entries even though all required attributes are present on the entry. I have a sample ldif that reproduces this problem.
dn: cn=testuser,ou=users,dc=example,dc=com changetype: add objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: testuser uid: testuser sn: surname
dn: cn=testuser,ou=users,dc=example,dc=com changetype: modrdn newrdn: uid=testuser deleteoldrdn: 1 newsuperior: ou=users,dc=example,dc=com
When I run this ldif using ldapmodify this is the result I get back.
adding new entry "cn=testuser,ou=users,dc=example,dc=com"
modifying rdn of entry "cn=testuser,ou=users,dc=example,dc=com" ldap_rename: Object class violation (65) additional info: object class 'inetOrgPerson' requires attribute 'cn'
As you can see from the ldif the cn attribute is clearly present. I am assuming this is a bug and needs reported but wanted to review it with the list members before I submitted the ITS entry.
-Jon C. Kidder American Electric Power Middleware Services Email: jckidder@aep.commailto:jckidder@aep.com Phone: 614-716-4970
Jon C Kidder wrote:
I am running 2.4.36 in my sandbox environment and have recently found myself needing to rename some entries in my directory. Slapd is reporting an object class violation when attempting to rename the entries even though all required attributes are present on the entry. I have a sample ldif that reproduces this problem.
dn: cn=testuser,ou=users,dc=example,dc=com changetype: add objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: testuser uid: testuser sn: surname
dn: cn=testuser,ou=users,dc=example,dc=com changetype: modrdn newrdn: uid=testuser deleteoldrdn: 1 newsuperior: ou=users,dc=example,dc=com
When I run this ldif using ldapmodify this is the result I get back.
adding new entry "cn=testuser,ou=users,dc=example,dc=com"
modifying rdn of entry "cn=testuser,ou=users,dc=example,dc=com" ldap_rename: Object class violation (65) additional info: object class 'inetOrgPerson' requires attribute 'cn'
As you can see from the ldif the cn attribute is clearly present. I am assuming this is a bug and needs reported but wanted to review it with the list members before I submitted the ITS entry.
Not a bug.
Since you set 'deleteoldrdn: 1' the old attribute value 'cn: testuser' would be also deleted by this request. Use 'deleteoldrdn: 0' in this case if you want to preserve the attribute value for 'cn'.
Ciao, Michael.
On Wed, 6 Nov 2013, Jon C Kidder wrote:
I am running 2.4.36 in my sandbox environment and have recently found myself needing to rename some entries in my directory. Slapd is reporting an object class violation when attempting to rename the entries even though all required attributes are present on the entry. I have a sample ldif that reproduces this problem.
...
dn: cn=testuser,ou=users,dc=example,dc=com changetype: modrdn newrdn: uid=testuser deleteoldrdn: 1
Since the old RDN is the CN attribute, passing "deleteoldrdn: 1" asks the server to delete the CN attribute from the entry.
...
modifying rdn of entry "cn=testuser,ou=users,dc=example,dc=com" ldap_rename: Object class violation (65) additional info: object class 'inetOrgPerson' requires attribute 'cn'
As you can see from the ldif the cn attribute is clearly present. I am assuming this is a bug and needs reported but wanted to review it with the list members before I submitted the ITS entry.
No, you're telling it to the delete the CN attribute. If you don't want it to do that, put "deleteoldrdn: 0" in your LDIF instead.
Philip Guenther
--On Wednesday, November 06, 2013 6:46 PM +0000 Jon C Kidder jckidder@aep.com wrote:
As you can see from the ldif the cn attribute is clearly present. I am assuming this is a bug and needs reported but wanted to review it with the list members before I submitted the ITS entry.
slapd is doing exactly what you asked of it. You set: deleteoldrdn: 1, so it complied and deleted the cn: value. If you want cn preserved, then I suggest you don't ask slapd to delete it on rename.
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Jon C Kidder -
Michael Ströder -
Philip Guenther -
Quanah Gibson-Mount