[SAMBA3] using LDAP DirSync Controls in winbindd

[Stefan (metze) Metzmacher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi *,

maybe it would be a good idea to use the DirSync Control
for the windbind caching code, maybe together with the Notification
Control...

this would allow us to hold the cached data when we reconnect to another
DC of a domain, as the current method, with using the usnChanged and
the highestCommitedUsn doesn't allow such things, because the the usn
numbers are local to each DC and not replicated between them.

the DirSync cookies contain info like this:

decode_ldapControlDirSync: struct decode_ldapControlDirSync
 in: struct decode_ldapControlDirSync
  cookie: struct ldapControlDirSyncCookie
   msds                     : 'MSDS'
   blob: struct ldapControlDirSyncBlob
    u1                       : 0x00000003 (3)
    time                     : Thu Oct 13 18:54:13 2005 CEST
    u2                       : 0x00000000 (0)
    u3                       : 0x00000000 (0)
    extra_length             : 0x00000040 (64)
    highwatermark: struct drsuapi_DsReplicaHighWaterMark
     tmp_highest_usn          : 0x0000000000002043 (8259)
     reserved_usn             : 0x0000000000000000 (0)
     highest_usn              : 0x0000000000002043 (8259)
    guid1                    : 64af11a1-7de0-40c6-9ff4-0dd5d86a7bfe
    extra                    : union ldapControlDirSyncExtra(case 64)
    data: struct ldapControlDirSyncExtraData
      h4                       : 0x0000000000000001 (1)
      uptodateness_vector: struct replUpToDateVectorCtr1
       count                    : 0x00000002 (2)
       reserved                 : 0x00000000 (0)
       coursors: ARRAY(2)
        coursors: struct drsuapi_DsReplicaCoursor
         source_dsa_invocation_id : 64af11a1-7de0-40c6-9ff4-0dd5d86a7bfe
         highest_usn              : 0x000000000000204c (8268)
        coursors: struct drsuapi_DsReplicaCoursor
         source_dsa_invocation_id : bc2cdfa1-2b34-4e1f-910c-64124f1ec67f
         highest_usn              : 0x0000000000000f32 (3890)

and this cookie can be passed to any DC that services the given Naming
context...

this highwatermark values and the guid1 are for coordination the
syncronisation with the currently used DC, and the uptodateness_vector
specifies the global state on what data we already have,
so when we do a fresh connection to a DC we should send zero buffers
for highwatermark and guid1 together with the cached uptodateness_vector

Does anyone want to look at this for samba3?

metze
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDzUI+m70gjA5TCD8RAl1xAJ997/X/TJnb38LYSO856xyjY/za3gCbBx1X
svRnt3VRktiI+sSoaU2VtKg=
=QUw/
-----END PGP SIGNATURE-----