Improved RPC-DSSYNC

[Andrew Bartlett]

On Wed, 2009-11-11 at 23:16 +0200, Kamen Mazdrashki wrote:
> On Wed, Nov 11, 2009 at 22:53, Andrew Bartlett <abartlet at samba.org> wrote:
> > On Wed, 2009-11-11 at 15:04 +0200, Kamen Mazdrashki wrote:
> >> Main purpose of _drs_util_verify_attids() is to verify decoded OID
> >> is real one - i.e. decoding ATTID based on drsuapi_prefixMap leads
> >> to an OID that actually exists.
> >
> > Doesn't loading the schema already check that?  (If not, should we not
> > do the checks there?).
> >
> No. _drs_util_verify_attids() is to verify ATTIDs got from GetNCChanges
> are properly decoded using the prefixMap we got from GetNCChanges.
> Which helped me to find out w2k8-r2 does not make same ATTIDs as
> described in MD-DRSR.pdf.
> 
> >> So please, don't remove it.
> >> The cache i've implemented lowers execution time significantly.
> >
> > And this cache is simply a duplicate of the schema we already load.  If
> > we must keep this code, then at least let us use the schema, which does
> > a binary, rather than a linear, search of the possible names.
> >
> Yes, you are right. 
> By the time I was implementing this tiny cache I wasn't aware you are
> implementing schema loading - hence we collide :).
> 
> > But I still can't see how it validates anything extra.
> >
> As I noted above - it verifies ATTIDs received against the drsuapi_prefixMap
> we receive.
> The whole ideia was that DSSYNC test to use alternative implementation
> for "drsuapi_prefixMap  + ATTID => OID" encoding/decoding so that we
> can catch regressions in dsdb implementation.

If you want to do that, then write up a test that uses expected values
for the 'fixed' part of the table.  That will give us a real test that
might actually fail on errors.  In the meantime, I do propose to remove
this, as I can't see what extra value it gives. 

That is: by doing a OID -> attr ID load during the schema load, and a
attrid -> attribute lookup during the syntax conversion, and a
comparison on the converted values (by looking up LDAP with a string
attribute name), I think we have a high degree of confidence that we
have the right mapping. 

Can you have a look over my dsdb-dn branch and see if you agree?  

Thanks, 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20091112/7be82f0a/attachment.pgp>