access idmap cache directly from smbd

simo idra at samba.org
Sun Aug 17 14:02:54 GMT 2008


On Sun, 2008-08-17 at 10:48 +0200, Volker Lendecke wrote:
> On Sat, Aug 16, 2008 at 09:56:05AM -0400, simo wrote:
> > I find it very desirable to be able to read the cache directly from
> > smbd, but I think you should treat the cache as read-only from it. If
> 
> True, that was my first thought as well.
> 
> > the mapping is not found you should always go to winbindd (if possible)
> > where an idmap backend could have different ideas on mapping than smbd,
> > or do some special logging or other actions that would be bypassed if
> > you store directly form smbd.
> 
> But then we need a tdb-based cache in pdb_ldap.c for the
> case I mentioned in my mail. Is that better?

Not sure what difference it would make ?
The idmap cache is already a tdb based cache, and you already go through
winbindd in the normal case. I think just removing the operations that
save ids in your patch is close to what is needed.

> > Also the 1 full week positive caching is probably too much for a
> > default, although I agree we should probably change the cache to a few
> > hours and not just 15 minutes. Mapping for weeks is almost the same as
> > mapping forever.
> > 
> > The reason for positive mappings with a time limit is that this way
> > admins that uses ldap or ad backends can change these mappings and
> > expect the change to reflect in the server in a reasonable time.
> 
> A simple "net cache flush" helps here. And I would consider
> changing mappings an operation where the admin has to touch
> the server console anyway for the chown/chgrp operations on
> existing files.

That's not necessarily always the case, and anyway it would be an admin
choice. It's just a default, each admin can choose what's best for them,
if there is a general strong opinion in favor of a long timeout by
default that's fine too by me.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Senior Software Engineer at Red Hat Inc. <simo at redhat.com>



More information about the samba-technical mailing list