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 -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc.
Attachment:
signature.asc
Description: This is a digitally signed message part