I have made a request of this feature some time ago, you can follow its progress and add your comments or requests here : https://bugzilla.redhat.com/show_bug.cgi?id=429005



2009/3/21 Michael Ströder <michael@stroeder.com>
Brown Diego wrote:
> 2009/3/21 Noriko Hosoi <nhosoi@redhat.com <mailto:nhosoi@redhat.com>>
>
>     This is the restriction the current FDS has.  Please see "2.4.2.1. A
>     Note on Renaming Entries" on this Administration Guide page.
>
>     http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Creating_Directory_Entries-LDIF_Update_Statements.html#LDIF_Update_Statements-Renaming_an_Entry_Using_LDIF
> It says really there is no way to move subtrees to different parent.
> Instead I need to create same entry with same attributes under the
> parent suffix to which I need to actually move it and finally delete the
> old ones?

Yes. Unfortunately setting the newSuperior in ModifyDNRequest is not
supported in FDS even when moving entries without subordinate entries.

Having to add/delete an entry to move it is not atomic. So the LDAP
client application has to implement some sort of rollback in case
something is going wrong.

I thought of supporting something like this in web2ldap. But I wonder
which order of the operations is right and how to deal with errors. E.g.
if there's a unique constraint on some of the attributes an
add-delete-sequence will simply fail. And if implementing it as
delete-add-sequence and there's something going wrong when adding the
entry (e.g. newrdn is already present under the newSuperior) the entry
is lost (and has to be re-added at the old superior). Gee, that's bad
and probably not worth the implementation effort.

FDS developers should seriously consider to at least implement handling
the newSuperior in ModifyDNRequest for moving entries without
subordinate entries.

Ciao, Michael.