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
> As metioned on openldap-devel, I've hit up against renaming DNs onto
> For example, I previously mentioned
> cn=ldaptestuser2,cn=users,DC=samba,DC=example,DC=com into
> 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
>> 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
> 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.
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.
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.