On Wed, 2008-01-09 at 18:37 -0800, Howard Chu wrote:
Andrew Bartlett wrote:
I'm up against my next challenge in the great challenge of Samba4 and OpenLDAP.
As metioned on openldap-devel, I've hit up against renaming DNs onto themselves.
For example, I previously mentioned cn=ldaptestuser2,cn=users,DC=samba,DC=example,DC=com into cn=ldaptestuser3,cn=users,DC=samba,DC=example,DC=com
This should become:
dn: cn=ldaptestuser2,cn=users,DC=samba,DC=example,DC=com changetype: modrdn newrdn: cn=ldaptestuser2 deleteoldrdn: 1
There appears to be a typo somewhere in your example, but I can't tell if you meant ldaptestuser3 or ldaptestuser2.
Sorry, I was copying and pasting the wrong thing, as you noticed. I meant the problem of a completely identical DN.
RFC 4511 states that a modify DN operation must fail with the entryAlreadyExists result code if there was already an entry with that name. However, a broad interpretation would recognize that such a modify DN operation is going to be a no-op and simply ignore it. The specific case doesn't seem to be explicitly dealt with in RFC 4511.
I've written a module to cause this to never reach the DB, but my next test (which AD also permits) is:
cn=ldaptestuser3,cn=users,DC=samba,DC=example,DC=com into cn=ldaptestUSER3,cn=users,DC=samba,DC=example,DC=com
So it seems I need some backend help. Is there another way I should be handling case changes in a DN, or could/should the DB be modified to allow these operations?
'way back I recall explicitly allowing this case, but the current backend code doesn't. I think it's worth filing an ITS for this.
Done. ITS#5319
As for renaming an entry to exactly the same DN, I could go either way. If we ignore it and silently return success, it will still generate replication traffic, which may or may not be desired.
Naturally, I would prefer that it behave as AD does, and I think that it would ensure things remain tested (less differing behaviours). I don't expect people do this kind of rename while expecting a NOOP, so replication traffic seems reasonable.
Andrew Bartlett