From SambaWiki
Revision as of 19:26, 10 June 2011 by Ekacnet (talk | contribs)

Hello this is my page ! I'm Matthieu Patou, you can reach me on #samba-technical with the nick ekacnet.

I'm now a Samba team member (yeah !) since May 2010.

I try to keep the fantasy page up to date with what I'll try to do in the short term.

What I've done / For what you can blame me !

  • Upgradeprovsion, a script to update your running provision to adapt to the perpetual changes we do in the Samba Domain controller code (aka Samba4 so far).
  • DFS referral resolution, so that multi DC setup can work correctly with newer client when accessing sysvol and netlogon share
  • Protected storage, a protocol to decrypt selected user secrets with DCs private key, used mainly for certificates
  • Dirsync, an LDAP control used for polling changes
  • Pseudobacklinks, a technical artifact so that all attributes with DN syntax are updated when the targeted DN change its name, allow moving DC between sites

Short term jobs

  • None

Medium term jobs

  • File Replication Service
  • Change indexing

About indexing

For the moment LDB use DN as entries of a index, as DN can be quite long we use a lot of space and memory for this. The idea is to use instead GUID at least in indexes.

Currently an indexed search on attribute samAccountName for the value mat is done like this:

  2. get the different DNs in the @IDX attributes
  3. fetch each objects for which the DN was return in step 2
  4. do the filtering

The idea is to do like this:

  1. search for DN: @INDEX:SAMACCOUNTNAME:MAT (via ltdb_search_indexed)
  2. get the different objectGUIDs in the @IDX attributes (through ltdb_index_dn or ltdb_index_dn_one is scope = ONELEVEL or directly if scope = BASE)
  3. for each GUID search the associated DN
  4. fetch each objects for which the DN was return in step 3 (in ltdb_index_filter)
  5. do the filtering (in ltdb_index_filter)

The following approach has the advantage of not modifying to much stuff while allowing to reduce index size, but it means that if an index contains 100 entries then we will do 201 fetchs (1 for the index, 100 for the index guid -> dn, 100 for each DN).