yet another idmap rewrite - still for 3.6 ?
obnox at samba.org
Mon Aug 2 03:47:50 MDT 2010
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
* Further simplify and unify the config (--> "idmap range" already
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
Size: 206 bytes
Desc: not available
More information about the samba-technical