Hi Andrey,
You are right. Sorry, I haven't tried the subtree rename case... Let
me investigate it some more.
On 01/26/2010 01:23 PM, Andrey Ivanov wrote:
Hi Noriko,
Thank you for your patch. The patch you provided does take into
account the modRDN with new superior but it does not seem to take care
of subtree renames (smth like rename "ou=users" to "ou=utilisateurs"
with child entries). For subtree renames all the entries in the
renamed subtree change their DNs so for each of these renamed
entries we have to make the search
"slapi_search_internal_set_pb(search_result_pb, search_base,
LDAP_SCOPE_SUBTREE, filter, attrs..." with a different filter.
So for each modrdn we should verify if the renamed entry has any child
entries and if it is the case then treat them either directly or
recursively...
As for the modrdn with newsuperior part i have a question : if
newsuperior=NULL you take the parent of the original entry
slapi_dn_find_parent(origDN) (btw, i haven't found this function in
RHDS plug-in documentation). What does this function return for the
base suffix? Or any rename/move operations are forbidden for the
suffix?
We don't allow rename/move the suffix. I've just tried that and got
unapproriate errors depending upon the newrdn. They need to be fixed...
ldap_rename: Invalid DN syntax
ldap_rename: additional info: invalid RDN
ldap_rename: DSA is unwilling to perform
ldap_rename: additional info: Cannot move entries accross backends
Bug 559016
- Attempting to rename suffix returns
inappropriate errors
Thanks,
--noriko
2010/1/26 Noriko Hosoi <nhosoi@xxxxxxxxxx>:
https://bugzilla.redhat.com/show_bug.cgi?id=557224
Description of problem:
Analysis by andrey.ivanov@xxxxxxxxxxxxxxxx
I'm pretty sure the referential integrity plug-in will not work for
modrdn operations with a new superior. Looking more thoroughly through
the code ( ldap / servers / plugins / referint / referint.c) confirms
my suspicion that new rdn superior is not taken into account. The
function referint_postop_modrdn extracts from the parameter block
only SLAPI_MODRDN_TARGET and SLAPI_MODRDN_NEWRDN, it does not extract
SLAPI_MODRDN_NEWSUPERIOR neither passes it further down the utility
functions - update_integrity(argv, dn, newrdn, logChanges) and
writeintegritylog(argv[1],dn, newrdn). The same applies to the delayed
referint operations (the plug-in writes to the special integrity log
file only the old DN and the new RDN, but never the new superior :
writeintegritylog(argv[1],dn, newrdn);)
Another thought on the subject of referential integrity plug-in - in
the previous mail i have only mentioned one-entry renames with a new
superior. The things get even worse when we rename a whole non-empty
sub-tree. It means that the referential integrity plug-in should
change to the new DNs all the references to all the entries of the
whole sub-tree, not only for one entry.
And what if we rename a sub-tree containing both the referenced entry
and the entry referencing the first one's DN in one of its "integrity"
attributes? It actually means that we need at first make the rename
and then all the searches and replacements. Though it seems it's
already the case as it's a post-op(?) plug-in...
Fix Description: The referential integrity plugin has not supported
the subtree rename (modrdn with newsuperior). This patch is adding
the support.
Created an attachment (id=386896)
git patch for ldap/servers/plugins/referint/referint.c
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-devel
|
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-devel
