[PATCH][WIP] Make the Samba AD DC multi-process
abartlet at samba.org
Wed Dec 7 18:26:31 UTC 2016
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?
> 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.
> We need to remember if the whole endpoint may ignores
> association groups and let dcesrv_bind() directly create a new
> association group if the given id is not found. Then we don't need
> any more
> logic changes and hacks in dcesrv_check_or_create_context().
> The trick is that an endpoint can only marked with
> DCESRV_IGNORE_INVALID_ASSOC_GROUP if *all* of it's interfaces
> allow it. And it can only use the top level process model
> in that case.
I'll look into that. I was handling that in the reverse: It creates a
new endpoint if it doesn't use handles, and is over TCP/IP or NP.
The advantage is that the association group behaviour is consistent
across all endpoints to that service, but of course the disadvantage is
the horrible logic changes and hacks
> I don't understand how this can work when the lsarpc interface
> is also registered on the ncacn_np:\\pipe\\netlogon endpoint?
I've simply unilaterally removed that. I don't see any good reason why
we should support it.
I realise I could be totally wrong, and the fact that I had to change
our own torture tests speaks against it, but it just feels wrong. If
for some reason we had to keep it, I would keep it but without support
for association groups, but i would rather simply not keep it.
I would also really, really like to avoid a smb.conf option to put that
back. If we add an option, then we need to test that option, and we
will end up keeping it for a very long time, for (in my estimation) no
users. I would rather do it in a major version and deal with it if it
ever comes up. The cross-over was created with:
Author: Andrew Bartlett <abartlet at samba.org>
Date: Fri Sep 1 07:21:13 2006 +0000
r17987: Make the LSA pipe listen on the \pipe\netlogon interface.
diff --git a/source/librpc/idl/lsa.idl b/source/librpc/idl/lsa.idl
index 3c05ab2..db627ba 100644
@@ -6,7 +6,7 @@
- endpoint("ncacn_np:[\\pipe\\lsarpc]","ncacn_np:[\\pipe\\lsass]", "ncacn_ip_tcp:", "ncalrpc:"),
+ endpoint("ncacn_np:[\\pipe\\lsarpc]","ncacn_np:[\\pipe\\netlogon]","ncacn_np:[\\pipe\\lsass]", "ncacn_ip_tcp:", "ncalrpc:"),
helpstring("Local Security Authority"),
As I added it for no particularly good reason, I would like to remove it on similar grounds :-)
I realise this is a very weak argument by Samba standards however, and
would appreciate some help with a way forward.
> And we also need a way to disable this new behavior.
Would you be OK with that being by patching \\pipe\lsass back into
If I re-worked the code to have it walk all the interfaces on the
endpoint at registration time, that would fall it all back into the old
behaviour and process model and be generic with the ncalrpc case (and
> The dcesrv_get_mgmt_interface patch and (if possible
> the pidl: Make dcesrv\_$name\_interface "static const")
> patch can be pushed to master now.
It just relies on the rest of the restructure for context, that is the
only reason it is pending.
I appreciate your thoughts and your willingness to work with me on
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
More information about the samba-technical