[PATCH] New external idmap module

[Volker Lendecke]

On Wed, May 31, 2006 at 10:46:00AM +0100, Gautier, B (Bob) wrote:
> I actually implemented some negative caching code when I was having
> trouble with performance, but gave up when I realised that without any
> sort of cache *expiry* system (that I could find), once a user was
> 'negatively cached' then they could never be enabled (by giving them a
> valid uidNumber, gidNumber) except by deleting the entire cache (stop
> winbindd, kill winbindd_idmap.tdb) which was not acceptable as a
> solution.  Fortunately I came up with the LDAP filter I proposed in
> BZ3751.

This is certainly one symptom that you have to live with. My
worry is that it only can get worse when you change existing
mappings at will.

> > What I still fail to see is a valid reason to change existing 
> > mappings. Could you please be a bit more specific why you 
> > need to change an existing mapping in a situation that does 
> > not allow you to remove winbindd_idmap.tdb and restart Samba?
> 
> I don't know if we could live without the ability to change mappings
> around here -- I don't make the policy on how such things are managed.

Can you get me a contact of the people who make the policy
decisions? Or get otherwise more information from them to
support the necessity to change some mappings and leave
others in place?

> Whilst such messing around is uncommon, probably *ought* not to happen,
> and has consequences that are messy, I don't see why Samba should make
> it more awkward, especially if there's no technical problem (and
> especially if the code has already been written, which seems to be the
> case here).

The problem I see is that this module, once it is shipped in
the default code it will not only be used in the
well-controlled environment of a NAS cluster for example
where some well-designed manager application carefully
watches that if a mapping changes all file ownership / acl
problems are properly solved the right way. My worry is that
it will also be used in environments where people just mess
up things badly and come back to us asking to fix things.

> My feeling is that it gives me lower performance (if I enumerate 1000
> users, I'd rather be doing 1000 round trips over a socket than 1000 fork
> and execs, of a script that might have to establish connections to some
> database...) and consequently less scalability.

This is a one-time process per SID if you assume that
existing mappings don't change.

> If the API to the external idmap is {Unix|tcp} socket, then of course
> someone can write the script-based implementation if they need to, and
> can tolerate the performance implications, and that seems the right way
> around to me.

Keeping a long-term connection to an external daemon sooner
or later will fail. We have reconnect logic wrapping around
the ldap libraries and our DC connection libs, and this
reconnect logic is one of the hairier parts of Samba. We
would have to put exactly this hairy code into the id
mapping module as well, and I would like to avoid this if
possible at all. If you keep up the assumption that you have
a local cache then I think we can live with a forking model.

You are always free to blow away the whole cache and start
from scratch. We even have 'net idmap restore' so that you
do not have to mess with creating a tdb to pre-populate your
cache.

> I agree: changing mappings isn't likely to be a commmon thing to do.
> But when it happens, it has to be done consistently across the whole
> cluster.  And since clusters will often be deployed where high
> availability is a goal, a stop-delete-cache-restart procedure is
> unlikely to be acceptable.

I have difficulties seeing the scenario where you need to
change existing mappings for a cluster. A uid has been
assigned to an existing Windows user. Why on earth would you
like this user want to use a different uid all of the
sudden?

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20060531/83163821/attachment.bin