pseudobacklinks: problems with dynamic search of ntds setting for the current server
Matthieu Patou
mat at samba.org
Mon Jul 25 15:09:46 MDT 2011
Hello Andrew,
Following your discussion on IRC and remarks you made by email about the
patch set for pseudobacklinks (available here:
http://git.samba.org/?p=mat/samba.git;a=shortlog;h=refs/heads/pseudobacklink
and
http://git.samba.org/?p=mat/samba.git;a=shortlog;h=refs/heads/pseudobacklink_dynrootdse).
I made more search about this, to sum up you would like that the rootdse
module do a dynamic search for the NTDS entry when asked for the
dsServiceName attribute (and also for serverName).
The only approach that can work appart from changing rootdse entries
when the DN of the DC's NTDS has changed (due to site change for
instance) is to use an hybrid approach based on the GUID.
When the partitions are not completely loaded (that is to say before the
end of partitions_init), the dsServername is used in the pdc_fsmo and
naming_fsmo modules as they try to determine if they are master for this
role. At this moment the ldb_context object passed to
samdb_ntds_settings_dn() will allow search only on the entires really
inside the sam.ldb file, that is to say that at this moment the rootdse
module can not resolve the real DN of dsServiceName from its GUID (the
search return object not found), so the solution is to check if the DN
returned by samdb_ntds_settings_dn (which makes a search in the rootdse)
is the same as the one in fsmoRoleOwner entry if not we check GUID of
both DNs and if equal then we know that they are the same (even if the
string value of DN differ). When the partitions are completely loaded
the rootdse module can then do a full resolution of the GUID to return
the correct DN for dsServiceName. That's a bit complicated but not too
much in fact (look at commits 0bc4fce to 3c3abe9).
The other option is to track change on our NTDS either done by us or
through DRS, for some reasons it seems that you don't like this one but
I don't understand too much why.
Nevertheless both approach have a major drawback: if the DN of the NTDS
settings change, it stays in cache with the OLD value, for this there is
not a lot of solutions, we can instead of the DN store the GUID in cache
(or both) and do the search with the GUID and if it fails (or if the
GUID is not present) then we return the cached DN version. It might be a
bit too complicated for just a cache that didn't seems to be used so
often (unless you keep the way too aggressive settings for DRS
notification to 5 seconds).
Any remarks ?
Note: last patches need some cleaning maybe.
--
Matthieu Patou
Samba Teamhttp://samba.org
Private repohttp://git.samba.org/?p=mat/samba.git;a=summary
More information about the samba-technical
mailing list