Recent changes to autorid (was Re: [SCM] Samba Shared Repository - branch master updated)

[Michael Adam]

Hi Simo,

On 2014-04-28 at 10:52 -0400, Simo wrote:
> On Mon, 2014-04-28 at 11:48 +0200, Michael Adam wrote:
> > On 2014-04-28 at 00:47 +0200, Michael Adam wrote:
> > > On 2014-04-27 at 22:02 +0200, Christian Ambach wrote:
> > > > Am 25.04.14 20:36, schrieb Simo:
> > > > >On Fri, 2014-04-25 at 17:53 +0200, Michael Adam wrote:
> > > > >>
> > > > >>+#define IDMAP_AUTORID_ALLOC_RESERVED 500
> > > > >
> > > > >but I think this fiddling and making
> > > > >strange exceptions with autorid is a bad idea.
> > > >
> > > > I somehow agree with Simo.
> > 
> > Ok, here we go:
> > ...
> > Thanks to anyone who has read this far... ;-)
> 
> Thank you, but this is broken.
> If you change the allocation range you are in the same problem as with
> the old code, so I fail to see the utility of this patch.

You can't change the alloc range.
idmap_autorid has a protection mechanism
by storing the config in the db:
You can't change the range size, and you can't
decerase the upper bound of the idmap range.

Or I don't understand what you mean...
Please elaborate, how this is broken.

> I would rather say you ask people to crate a new small range (of 500
> ids) for the "wellknown" domain and you are all set.

autorid currently only has ranges of a fixed size
("idmap config * : rangesize = ...").
And, by "people", do you mean the developers?
We don't have a configuration means to create a range
for the wellknown sids, currently.

> If it is available, on first init, you allocate all the wellknown ones
> there in a predetermined order, if it is not you do as the old code did
> unchanged for compatibility reasons.
> 
> In general I find that using alloc with autorid defeats the point of
> using autorid, which is that of having always predictable mappings even
> if they may be incomplete at times, so I do not agree very much with the
> whole setting around this change.

Well, firstly autorid is only kind-of predictable, in that it
uses a first-come-first-serve mechanism for allocating not the
id-mappings but the range-mappings.

You are right of course that the alloc-range somhow contradicts
the simplicity auf autorid, and you may notice that the first
incarnation didn't sport ALLOC, but this broke e.g. group
mappings (which need an ID pool that is currently served out of
the "idmap config * : range"), and the wellknowns could not be
treated either.
So the alloc range was needed because of the way, Samba currently
works...

> > Opinions?
> 
> I think we should withdraw this approach, it makes things more
> unpredictable, not less, IMHO.

Let's hear a few more voices, please.

But attached find a patchset that reverts the three decisive
patches. (I think the rest is good code hygiene.)
If there is consensus to do the revert, that should be it.
(The patch that adds high-id could also be left in the tree,
since it does not do any harm, but the current code does not
need it.)

Cheers - Michael


-------------- next part --------------
A non-text attachment was scrubbed...
Name: autorid-revert-wellknown-speciality.mbox
Type: application/mbox
Size: 5975 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140428/b123bdb6/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140428/b123bdb6/attachment.pgp>