[PATCH][WIP] Make the Samba AD DC multi-process

[Stefan Metzmacher]

Hi Andrew,

I don't see my concerns of my previous mails addressed,
so please don't push it as is.

I can try to explain them again if required later today.

Thanks!
metze

Am 13.12.2016 um 02:53 schrieb Andrew Bartlett:
> On Fri, 2016-12-09 at 17:43 +1300, Andrew Bartlett wrote:
>> On Fri, 2016-12-09 at 07:19 +1300, Andrew Bartlett wrote:
>>> On Thu, 2016-12-08 at 16:04 +0100, Stefan Metzmacher wrote:
>>>> Am 08.12.2016 um 06:39 schrieb Andrew Bartlett:
>>>>>
>>>>> Just a quick update on the easier parts:
>>>>>
>>>>> On Thu, 2016-12-08 at 07:26 +1300, Andrew Bartlett wrote:
>>>>>>
>>>>>> On Wed, 2016-12-07 at 13:09 +0100, Stefan Metzmacher wrote:
>>>>>>>
>>>>>>> Hi Andrew,
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Do you have any other comments?  Is the general approach
>>>>>>>> OK?
>>>>>>>>
>>>>>>>> Can I merge more of the RPC code, like the 'uses handles'
>>>>>>>> declaration?
>>>>>>>
>>>>>>> Do you have a rebased branch somewhere?
>>>>>
>>>>> git://git.catalyst.net.nz/samba.git multi-process-samba-ad-dc
>>>>
>>>> I've pushed the pidl and mgmt change. Can you please
>>>> rebase the conflict resolution should be trivial.
>>>
>>> Sure.
>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Regarding the are_handles_used please make it an
>>>>>>> uint64_t flags (with DCESRV_IGNORE_INVALID_ASSOC_GROUP)
>>>>>>> and move it to the end of the structure.
>>>>
>>>> Can we get a DCESRV_IGNORE_INVALID_ASSOC_GROUP
>>>> instead of DCESRV_INTERFACE_FLAGS_HANDLES_USED?
>>>
>>> The reason for the existing name is that it really is up to the RPC
>>> server as to if it wants to validate association groups.  Across
>>> ncalrpc, handled in a single process, it certainly could (and
>>> should).
>>>  
>>> What the pipe knows, can declare, and is enforced (then handles all
>>> come back NULL) is if it uses handles at all.  I think the
>>> implementation choice of if association groups should be ignored,
>>> or
>>> stored in some global on-disk DB, is a property of the rpc_server.
>>>
>>> Note that in the new code, just as an LSA association group won't
>>> be
>>> be
>>> valid on NETLOGON (and ignored safely), a NETLOGON association
>>> group
>>> won't be valid on LSA (but will be an error).  If this comes up
>>> outside
>>> artificial test-suites, we may have to reconsider our options. 
>>>
>>>> And the .c file should set a
>>>>
>>>> #define DCESRV_INTERFACE_NETLOGON_FLAGS
>>>> DCESRV_IGNORE_INVALID_ASSOC_GROUP
>>>
>>> I'm happy to change the define structure, certainly.  That is much
>>> less
>>> clumsy and means less pidl changes for the next flag.
>>>
>>>> The assoc_group == NULL should not move please use
>>>> the DCESRV_IGNORE_INVALID_ASSOC_GROUP indication on the
>>>> endpoint above the existing check.
>>>
>>> I can't - we don't know the endpoint until then. 
>>>
>>>> Regarding the schannel change shouldn't we try to remove unused
>>>> records?
>>>
>>> We (our team @ Catalyst talked over a number of possible
>>> implementation
>>> ideas for this DB) considered that, but it comes with the cost of
>>> adding a timer process, a timestamp, timeout period and coming up
>>> with
>>> some way of testing it.  It all seemed like a lot of complexity,
>>> and
>>> things that could go wrong, for quite little gain. 
>>>
>>> Instead by using the lossy hash, we ensure that the DB can't be
>>> overfilled anyway, and it has very similar semantics to the old
>>> memcache, because the schannel db is CLEAR_IF_FIRST. 
>>>
>>> Records are deleted as they are used. 
>>>
>>>> More comments tomorrow.
>>>
>>> Thanks!
>>
>> Attached is an updated patch.
> 
> The attached patches implement a new smb.conf option "lsa over
> netlogon" and are otherwise ready for master, as far as I'm concerned. 
> 
> I'll do some performance testing and see if I can get some rough
> numbers.
> 
> Thanks,
> 
> Andrew Bartlett
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20161213/20172a3f/signature.sig>