[RFC][WIP] cache-only name lookups in smbd

[Uri Simchoni]

On 11/28/2016 01:06 PM, Volker Lendecke wrote:
> On Mon, Nov 28, 2016 at 12:59:05PM +0200, Uri Simchoni wrote:
>> On 11/28/2016 11:26 AM, Volker Lendecke wrote:
>>> Hi, Uri!
>>>
>>> Question -- the cache invalidation of winbindd_cache.tdb is fishy at
>>> best. For this type of caching that is pretty much public information,
>>> wouldn't it be better to go to gencache.tdb? In the caching case, we
>>> would avoid the roundtrip to winbind.
>>>
>>> Volker
>>>
>> You mean introduce another cache or leverage an existing one? There are
>> already two of them at least - the winbindd_cache (used to be "backend")
>> and the RPC parent-child cache - I can save the round-trip to the child
>> by using that.
> 
> Both are using the same infrastructure, so for me that is the same
> cache. Yes, we cache things more than once, and this is one of the
> cleanup todos. The main thing here is that winbindd_cache.tdb is only
> accessed from within winbind itself, so every access requires a
> process context switch into winbind.
> 
> What I have in mind is a structure like our idmap cache: We store the
> id mappings with gencache_set and retrieve them with gencache_parse.
> The main advantage is that smbd can access them without asking
> winbind, so gencache is a *little* more of a stable "API". We could
> make winbind store the name2sid and sid2name mappings with
> gencache_set and smbd could retrieve them directly.
> 
> With idmappings our approach is that they are extremely durable: Once
> a sid2unixid is set, it will not change. Period. With name2sid it
> might be a bit more prone to change, so we might want to think about
> cache expiration based on a bit more than just the gencache timeout.
> But as this is very fishy with winbindd_cache.tdb anyway, we have to
> put some thought into that topic regardless of the winbindd_cache.tdb
> vs gencache.tdb decision.
> 
> Hope that helps,
> 
> Volker
> 
In any case, I can see how relying on winbindd cache is a bad idea,
because it is being accessed in the child winbind process, and that can
be blocked by another request if the DC connection is flaky, so I really
haven't fixed anything with this patch. I'll try the id-mapping-like
approach (even though id-mapping still goes to winbind, but terminates
at the parent if cached).

Thanks,
Uri.