[PATCH] New external idmap module

Gautier, B (Bob) Bob.Gautier at rabobank.com
Wed May 31 09:46:00 GMT 2006

> -----Original Message-----
> From: Volker Lendecke [mailto:vlendec at sernet.de] On Behalf Of 
> Volker Lendecke
> Sent: 31 May 2006 10:09
> To: Gautier, B (Bob)
> Cc: simo; Gerald Carter; Samba Technical
> Subject: Re: [PATCH] New external idmap module
> On Wed, May 31, 2006 at 09:36:05AM +0100, Gautier, B (Bob) wrote:
> > Not fine by me!
> Ok. I would be fine adding a negative cache to the id map.

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

> 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.
I do know that if I was using another mechanism (e.g. the plain old
passwd file, or an LDAP directory) then I could change users' uidNumbers
at will.  Of course I understand that leaves me some mess to clean up
regarding file ownership etc.

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).

> > FWIW I would love to see a mechanism that would allow all the idmap 
> > functionality to be segregated into a separate process, 
> independent of 
> > the mainline Samba code, so that 1) we have complete 
> control over the 
> > idmap algorithm and 2) we can use a custom algorithm whilst still 
> > using a standard, out-of-the-distro-vendors-box, build of Samba for 
> > which we can get support.
> Both of these features I think are provided by the script 
> solution. What is it specifically that this script solution 
> does not give you?

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.

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.

> > Although I have not followed the discussion in every 
> detail, I think 
> > that means I am in support of the original external idmap module 
> > proposal, complete with TCP socket support (because I think if it's 
> > not in the basic module, someone will write a proxy 
> eventually anyway).
> > 
> > Isn't an external, TCP-reachable idmap module relevant to the Samba 
> > clustering work?  I wonder if their messaging protocols are worth 
> > using here, at least.
> It is, but I do not expect clusters to change existing 
> mappings on an ongoing basis, so for this application I would 
> very much assume that the script solution would be fine.

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.

> Volker

This email (including any attachments to it) is confidential, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this email in error, please advise us immediately and delete it. You are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Although we have taken reasonable precautions to ensure no viruses are present in this email, we cannot accept responsibility for any loss or damage arising from the viruses in this email or attachments. We exclude any liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided in this email or its attachments, unless that information is subsequently confirmed in writing. If this email contains an offer, that should be considered as an invitation to treat.

More information about the samba-technical mailing list