yet another idmap rewrite - still for 3.6 ?

[Michael Adam]

Kai Blin wrote:
> On Fri, 30 Jul 2010 17:47:25 +0200
> Michael Adam <obnox at samba.org> wrote:
> 
> > This mail is to request that this code still gets into the
> > 3.6 release, even though I did not manage to polish my
> > patchset before the pre1 release.
> [...]
> > 1. The id mapping API should just consist of the methods
> >     - sids_to_unixids
> >     - unixids_to_sids
> >    These calls should be atomic and the backend should know by itself
> >    whether it needs to allocate some ids, store mappings and how.
> >    To the caller, this should be completely irrelevant.
> 
> 
> I really think this will make using winbindd from Samba4 much, much
> easier. Basically, this is the central API Samba4 is using already.
> Also, this changes allows us to use the concept of SID<->unixid
> mappings in the S3 code, which again matches with what Metze and I came
> up with when working on the S4 idmapping code in 2007.
> 
> I didn't get around to look at the actual patches yet, but I think
> simplifying the idmap code while also moving the S3 and S4
> implementations closer together is a good thing.

Right, this is a good thing. Andrew also liked this when I
chatted with him some 3 or 4 weeks ago.

What I forgot to mention in my initial email are the possible
next steps.

* Further simplify and unify the config (--> "idmap range" already
  mentioned).

  As mentioned in the inital mail, the ldap-related config
  options are basically as is for now to be least disruptive
  for existing installations. I would like to get rid of as
  many of the parameters as possible. (Is it really necessary
  to make all the location and credentials of the id counter
  configurable separately from the id mappings settings now
  that the alloc code is subordinate?..). Remaining necessary
  alloc-parameters should be moved underneath the
  "idmap config DOMAIN : ..." layer for consistency.

* Reconcile the backends tdb and tdb2 into a single backend
  again. As I said, the only differences consist in a format
  upgrade code path that only tdb has on the one hand side and
  the idmap script feature that only tdb2 has on the other hand
  side. These should be only ona backend.

  I even had the idea of making the idmap script more universal.
  Having it as a parametric option "idmap:script" that makes
  the tdb2 backend behave differently is somehow a very arbitrary
  hack. I could imagine making "script" a fully fledged idmap
  backend of its own.

* While the idmap API speaks plural, the server code only uses
  the sids_to_unixids and unixids_to_sids calls only in singular
  through the winbindd api. This should be changed, for instance
  in order to really take advantage of the atomicity of the
  sids_to_unixids calls in tdb and tdb2: Mutlitple SIDS of a
  user's token (e.g.) should be resolved in one atomic operation.

Some more radical changes I would like to see but which I need
to think some more about are these:

* I'd like to have winbindd be responisble for all sid<->uid
  mappings, also for passdb. This would greatly simplify the
  code. THis would also make the "always give passdb a chance
  first" code path vanish - passdb would ask winbindd instead.

* Group mapping always puzzles me, and I think this should
  be integrated with id mapping.

I have probably probably missed something, but anyhow..

Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100802/318440e5/attachment.pgp>