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
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?
(These tests arose because a user tried to do exactly this from the windows management tools, and we also failed to allow it in ldb).
Thanks,
Andrew Bartlett
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.
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.
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.
(These tests arose because a user tried to do exactly this from the windows management tools, and we also failed to allow it in ldb).
Thanks,
Andrew Bartlett
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 wrote:
On Wed, 2008-01-09 at 18:37 -0800, Howard Chu wrote:
'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
Preliminary fix in HEAD... For renames that just change the case of the DN, there's no further issues.
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.
Except that it doesn't make sense at the moment. Since renaming to exactly the same DN is treated as a no-op, the entry's modifyTimestamp, modifiersName, and entryCSN are not updated. (I.e., the entry is completely untouched.) There really should not be a replication event in this case. Either that, or we have to actually write the entry and update these operational attributes, so it's not really a no-op any more.
On Thu, 2008-01-10 at 18:25 -0800, Howard Chu wrote:
Andrew Bartlett wrote:
On Wed, 2008-01-09 at 18:37 -0800, Howard Chu wrote:
'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
Preliminary fix in HEAD... For renames that just change the case of the DN, there's no further issues.
Great. This seems to work nicely.
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.
Except that it doesn't make sense at the moment. Since renaming to exactly the same DN is treated as a no-op, the entry's modifyTimestamp, modifiersName, and entryCSN are not updated. (I.e., the entry is completely untouched.) There really should not be a replication event in this case. Either that, or we have to actually write the entry and update these operational attributes, so it's not really a no-op any more.
I'm happy if as the client requests an operation here, that we perform exactly that operation. It might not change the end result in the DN or the RDN attribute, but the client clearly asked for a change, so why not treat it like all other changes?
Does that make sense?
Andrew Bartlett
Andrew Bartlett wrote:
On Thu, 2008-01-10 at 18:25 -0800, Howard Chu wrote:
Andrew Bartlett wrote:
On Wed, 2008-01-09 at 18:37 -0800, Howard Chu wrote:
'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
Preliminary fix in HEAD... For renames that just change the case of the DN, there's no further issues.
Great. This seems to work nicely.
Good.
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.
Except that it doesn't make sense at the moment. Since renaming to exactly the same DN is treated as a no-op, the entry's modifyTimestamp, modifiersName, and entryCSN are not updated. (I.e., the entry is completely untouched.) There really should not be a replication event in this case. Either that, or we have to actually write the entry and update these operational attributes, so it's not really a no-op any more.
I'm happy if as the client requests an operation here, that we perform exactly that operation. It might not change the end result in the DN or the RDN attribute, but the client clearly asked for a change, so why not treat it like all other changes?
Does that make sense?
Yes, sounds fine. Changed in HEAD.
openldap-technical@openldap.org
-
Andrew Bartlett -
Howard Chu