yet another idmap rewrite - still for 3.6 ?

[Michael Adam]

Hi Simo,

simo wrote:
> On Fri, 2010-07-30 at 17:47 +0200, Michael Adam wrote:
> > as many of you know, I have been working hard on YAIR -- yet
> > another idmap rewrite for samba3.
> 
> Hi Michael,
> do not read this mail as any sort of veto, but I would like to throw in
> an idea.

Sure, no problem at all.

> The main complaint I hear from everywhere is how difficult it is to
> configure idmapping, and I am wondering if we shouldn't simply decide to
> offer less options and force things a bit.

My approach goes in that direction in principle but goes not as
far: I have taken away the possibility to configure idmap backend
and alloc backend independently of each other, hiding alloc
stuff completetly underneath the idmap stuff.

I have removed the idmap alloc parameter.
After unifying stuff under the hood, I would also like to
deprecate "idmap uid" and "idmap gid" and make them synonym
for a new combined "idmap range". Since this is what these two
options are, internally. I was thinking of proposing this
for 3.6 if the rewrite was agreed upon.

> We could tie back idmapping
> to the passdb module being used and automatically select the backend
> based on the configuration. So if ldapsam is in use idmapping is
> forcibly done through ldap, if tdbsam is used then we use idmap_tdb (or
> automatically base on ctdb configuration idmap_tdb2. If smbpasswd is
> used then idmap_rid.
> Maybe an exception could be for AD membership, if security ads is
> selected then we autodetect if rfc2307bis attributes are availbale and
> if they are not then we automatically fallback to idmap_tdb, same for
> trusted domains.
> 
> I don't know if this is too much of a loss of functionality, but it
> looks like that at least a good chunk of users would probably find it
> easier to understand and manage.

I think the idea certainly has its appeal, but I am not sure how much
it really simplifies. You will still need to configure ranges for
id mapping. And if you have automatically determined backends for
various domains, you will need to specify various ranges: At
least one for the own domain and one (catchall) for the other
domains (trusted...). I.e. the minimal config would be like this:

>> idmap uid = XXX-YYY
>> idmap gid = XXX-YYY
>> # or idmap range = XXX-YYY
>> idmap config OWNDOMAIN : range = AAA-BBB

Or if we introduce proper (non parametric) options
for the own domain's and the default idmap config,
then s/th like this:

>> idmap [default] range = XXX-YYY
>> idmap own range = AAA-BBB

(We could also split out the unixid allocator
for ldapsam:editposix and groupmaping (which should
vanish imho anyways) to introduce a third range
parameter like "unixid range = ..." .)

Currently this would read:

>> idmap uid = XXX-YYY
>> idmap gid = XXX-YYY
>> idmap config OWNDOMAIN : range = AAA-BBB
>> idmap config OWNDOMAIN : backend = somebackend


While I like the idea in principle, there are these concerns:

* When talking about my changes to Volker and Karolin in the
  past, the both were very reluctant to sacrifice backward
  compatibility in configuraiton. Now radical changes call
  like this usually break backward compat. I could have gotten
  rid of more code and simplified config even more (without)
  the extra autodetecting logic of your idea by breaking
  backwards compat.

* A problem would be with stability/reliability: Due to the
  automatic determination of backend for your own domain,
  when switching between security = ads and security = domain,
  you would completely switch the unixids of the windows users.
  Similarly, when switching password backends.
  So I think one would at least still need the possiblity to
  set the backends explicitly, even though there might be
  better and more intelligent defaults.

> Just my 2c. Crazy ideas driven by heat :)

No problem. This is how we can move forward. :-)
And I think that even for a radical change like the one
you are suggesting (of which the details would have to
be fixed still), my cleanup would be a useful preparatory
step.

Need to run now, more later.

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/20100731/ac00f9c1/attachment.pgp>