[PATCH] bug 11259 - get smbd to use winbindd to prime the netsamlogon and name2sid caches.

[Uri Simchoni]

On 09/28/2016 11:35 PM, Jeremy Allison wrote:
> On Wed, Sep 28, 2016 at 11:03:34PM +0300, Uri Simchoni wrote:
>> On 09/28/2016 09:28 PM, Jeremy Allison wrote:
>>> On Wed, Sep 28, 2016 at 09:01:15PM +0300, Uri Simchoni wrote:
>>>
>>>> That would be great.
>>>>
>>>> I haven't researched this fully and right now I have other duties to
>>>> attend to, but I see signs of fishiness with the sequence number refresh
>>>> from the parent process (I made two session setups 7 minutes apart, got
>>>> a new ldap connection opened for each one instead of reusing the
>>>> connection, with all the discovery enchilada). This could be some
>>>> consequence of my setup, or it could be a bug, which went undetected
>>>> because the sequence number from parent code path is not used often.
>>>>
>>>> I'll be happier knowing that we don't introduce another blocking network
>>>> request in the parent.
>>>
>>> Feel free to add this to the patchset once it's gone
>>> in if you want it.
>>>
>>> Cheers,
>>>
>>> 	Jeremy.
>>>
>> I'll figure out why I get those reconnects (not today, maybe tomorrow or
>> during the weekend), and then decide what to do. I certainly didn't get
>> those reconnects before the patch, but I also switched envs to test the
>> multi-domain case (the reconnect is all in our domain, no relation), so
>> that may be the cause.
> 
> Actually, adding this is no-cost and removes any potential
> reconnect, so I'm just going to push it (Guenther already
> reviewed) once my current autobuild finishes.
> 
> I'll add the whole set to the bug report as the 4.5.x, 4.4.x
> back-ports once they land in master.
> 
Some things I don't quite get:
1. When we store the name2sid in the cache without refreshing sequence
number, we store it with the parent winbindd's sequence number, but when
we fetch it, it's done with the child sequence number (each process has
its own copy of the domain object). Perhaps we need to refresh the
sequence number from tdb first, using fetch_cache_seqnum() ?

2. I don't quite get this whole seqnum business. It seems to be about
EARLY expiration of cache data, because entries expire if either of the
following is true:
a. The sequence number has changed
b. They are older than "winbind cache time".
However, the USN is also cached for "winbind cache time" seconds,
meaning that this early expiration is not that dramatic. Maybe it's a
coherence mechanism - if there are several related cached items, this
mechanism makes sure that if one expires, so do the rest.

3. The function names and patch comments on the last patch - I can't see
why it's about trust. Seems to me that we only store things we trust.
It's just that we're taking the risk that the entry will expire sooner
(because we haven't taken care of the USN), because we don't want the
blocking call at the parent winbindd process.

Thanks,
Uri.