[PATCH][WIP] Make the Samba AD DC multi-process
Andrew Bartlett
abartlet at samba.org
Tue Dec 13 09:43:12 UTC 2016
On Tue, 2016-12-13 at 09:11 +0100, Stefan Metzmacher wrote:
> 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.
I'm really sorry to have to trouble you for them, because I've been
working hard to address them.
- I have added an smb.conf option for the lsa over netlogon behaviour
- I have added tests for that option
- I've explained that we can't conditionally check for incorrect
association groups until we know which endpoint we bound to
- I've changed to specifying flags, not just the use of handles
- I've explained why the dcerpc interface should and does declare
about the use of handles, not the ignoring of association groups,
because per your request, only when all interfaces on an endpoint don't
use handles, do we ignore association groups. (And the DCE/RPC server
could track this some other way if it wanted).
- I've explained that unused records are removed in the same way as
the old code, on startup.
- And, as you have seen from Garming, we have shown this makes a
significant improvement to the use case: high-load 802.1x (NTLM)
authentication via winbind on domain members.
We have a customer who suffers significant load on the DCs after a wifi
outage, because the DC needs to suddenly re-authenticate all the users.
That is why we are working on this.
I've re-read your last mail, and I'm honestly at my wits end as what
more you want, so in the desperate hope that we are simply in
miscommunication, can you please make clear again what specific changes
you want? I would really like to move on from this, and lock it in for
4.6.
Thanks,
Andrew Bartlett
> 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
> >
>
--
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
mailing list