Please review: [Bug 171338] Enhancement: winsync modrdn not synced
by Noriko Hosoi
[Bug 171338] Enhancement: winsync modrdn not synce
https://bugzilla.redhat.com/show_bug.cgi?id=171338
Problem Descriptions:
Rename (modrdn) with newsuperior has not been implemented on the RH/389
DS. Therefore, even if entries were moved on AD, WinSync could not
synchronize the change on the DS. Now, the functionality is being added
to the DS. Using it, the rename operation should be able to get
synchronized.
Fix Descriptions:
windows_protocol_util.c:
1. Implemented process_replay_rename for DS --> AD rename (modrdn)
synchronization. It checks the new local superior and the current remote
superior. If they don't match, it calls windows_conn_send_rename. If the
entry is a user, the leaf RDN on AD is ntUserDomainId, which is not the leaf
RDN on DS. Thus, newrdn passed to windows_conn_send_rename is the leaf
RDN of
AD, which won't be changed in this process_replay_rename. If the entry is a
group, the leaf RDN on AD is the same as the one on DS. Thus, newrdn is
passed to windows_conn_send_rename. If the rename on AD failed by
LDAP_NO_SUCH_OBJECT, the target entry might have been deleted on AD. To
recover the problem, add the renamed entry to AD.
2. Modified windows_update_local_entry to update the local entry if the
rename
operation occurred on AD (AD --> DS). In the function, a code to check
the local and remote superiors is added. If they don't match, the local
entry is
renamed. Similar to DS --> AD, the rename only takes care of newsuperior
change for a user; it could update both newrdn and newsuperior for a group.
windows_connection.c: fixed a typo
Proposed Fix:
https://bugzilla.redhat.com/attachment.cgi?id=385774&action=diff
git diff ldap/servers/plugins/replication/{windows_connection.c,
windows_protocol_util.c}
14 years, 3 months
Re: [389-devel] Please review: Allow modrdn to move subtree and rename non-leaf node
by Howard Chu
389-devel-request(a)lists.fedoraproject.org wrote:
> Date: Thu, 14 Jan 2010 16:45:32 +0100
> From: Andrey Ivanov <andrey.ivanov(a)polytechnique.fr>
> Here are some questions or remarks that i still do have after this reading:
> Citation:
> -------------------
> This function entryrdn_index_read finds out the entry_id of the given
> DN sdn. It starts from the suffix in the entryrdn index following the
> child links to the bottom. If it is successful, the entry_is of the
> target node is set to the address that the argument id points to.
> -------------------
>
> the previously used "entrydn" index and the corresponding function
> needed just one step(?) to find out the entry id from it's dn. Several
> steps are now needed with "entryrdn" index. You talk about an
> expensive entry_id - > dn conversion and you introduce the dn cache to
> take care of it. However you don't mention the expensive conversion dn
> -> entry_id (that was the role of entrydn.db4). As far as i understand
> the standard entry cache should help this conversion? And maybe this
> type of conversion is much less frequent than entry_id - > dn?
>
> It would be interesting to have an estimation of the performance loss
> (or gain?) due to this new entryrdn index for typical read/search
> operations - 3 to 5 levels of rdn in DIT... I think it can be done
> with ldclt in a similar way you've done it for ancestorid index.
Keep in mind that a DN to ID lookup generally only occurs once in any given
operation, while an ID to DN lookup occurs for every candidate entry in a
search. The latter is far more performance-critical. (Of course in OpenLDAP
back-hdb both lookups are performed with the same index, so the question is moot.)
Experience from developing back-hdb in OpenLDAP shows that all of the
downsides are more than cancelled out by the reduction in memory and I/O
footprint gained from the RDN-only index layout.
http://www.openldap.org/lists/openldap-devel/200112/msg00052.html
http://www.openldap.org/conf/odd-sfo-2003/howard-dev.html
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 3 months