Default DNS server for Samba 4.0

[Michael Adam]

Hi Kai, Andrew, list...

Wow, the conversation has taken up such a momentum, that I can't
reply to all mails in the thread. Just chiming in here...

On 2012-09-06 at 14:03 +0200, Kai Blin wrote:
> On 2012-09-06 13:16, Andrew Bartlett wrote:
> 
> > I'm not sure where you got the idea that it was acceptable to have
> > untested code in Samba.  That the DLZ code is in this state (which I am
> > working to rectify) is no excuse to introduce more untested code.  
> 
> Well, I got the idea by looking at the other DNS implementation we had.
> I agree it's nice to have tests,

Right, I have not seen a strict requirement to have all new code
covered by tests. It is strongly desirable to have it though, of
course! But then the need to cover existing but not automatically
tested code in tests is not smaller.

> and I'd have bought the argument if the tests had been in there
> a couple of betas ago.

I absolutely agree to Kai here: Requiring the code to be covered
with tests for accepting to change a default is invalid and seems
very unfair to me when the code from which the default status is
to be taken has almost no automatic test coverage at all. Starting
to add some tests now seem like a panic action...


My perception of the state of the dns implementations is this:

For the bind backend:

* It used to be a major pain to set the bind backend up.
  This seems to have improved, which means that there is
  by now a small number of people who are comfortable with
  setting it up and running it.

  Even Ricky Nance who seems to have gathered considerable experience
  with samba 4 deployments, nicely summerized the problems with
  configuring the bind backend nowadays in a different mail.

* Using the bind backend adds a dependency to a pretty recent
  version of a complex external software component, possibly
  a hurdle for intededly simple installations.
  It also adds a source of errors that is beyond our control.

* The bind backend, once configured, seems to be reliable
  from the experience of a couple of existing installations.

* The bind backend seems to well suited for bigger, complex
  and for instance heterogenious installations.

For the internal dns:

* The internal dns server is very very easy to set up.

* It uses the same backend store in the AD as the bind dlz
  backend, so it is a very thin layer on top.

* This is new code, of course, so there will be bugs.
  But there are also bugs. But there are more bugs in
  the bind backend code for sure, and there will be bugs
  in the bind software itself which is beyond our control.

* There is not yet a full test suite for the internal server,
  but there is a start. This is certainly more than there is
  for the bind approach. And this can and will be extended
  in the very near future.

* The internal server gives us the possibiltiy for the first
  time to use a proper dns server in our selftest suite,
  hence allowing us to test yet untested code paths in the AD
  client and server implementation. (This needs to be written.)

* This should allow the internal dns server to mature quickly
  in the very near future.

* I should mention that we have been using the internal DNS
  server in the SerNet samba 4 appliance since early this year,
  and our testing has made me very confident with the new code.


Now stepping back a bit, what do we mainly want to achieve with the
samba 4.0 release?

* We want to do the first release with the AD server code
  as a (if not the) major improvement.

* As discussed earlier, we limit ourselves with the AD feature
  set to officially support the single domain single DC setup.
  (All more complex setups are "experimental" and may require
   handwork..)

* As such, setting this default single-dc installation up should
  be extremely easy.


For me this makes the internal DNS server the _ideal_ default
dns server for the Samba 4.0 despite the relative youth of the code.
I am convinced that the internal server will give the 4.0 release
a real boost in distribution due to the ease of use.
I am not suggesting to do something insane - I simply don't think
it is insane, but the reasonable thing to do.


> > Secondly, I'm sorry if you felt that the required feature standard was
> > anything less than DNS forwarding and GSS-TSIG correctly coupled to the
> > directory ACLs.  I'm not sure how that wasn't clear, but you clearly
> > feel mislead.  
> 
> This probably is twenty bloody lines of code, looking at the DLZ plugin.

Ok there is a gap. Let's treat this as a bug.

> > In terms of the deadline, yes, it keeps changing.  When we previously
> > talked about needing to close off Samba 4.0 to new features, you raised
> > that you will not be able to complete this feature in time, and asked
> > that you be allowed an even closer approach to the RC to finish your
> > features off.  Perhaps it would have been kinder to have left this at
> > the beta stage, but then we wouldn't have this impressive facility at
> > all!
> 
> I can't shake the impression that our betas were simply alphas with a
> different name, though. The release candidate stage is where we stop
> working on new features and work on stabilizing the ones we have.

This may sound blunt or brutal, but I think this describes it
quite precisely.

> If "has to be bug free" is the bar, then we probably should just give up.

> But yes, I agree that I'd probably have spent my time differently if it
> had been clear we don't care about the internal DNS a couple of months
> back. This certainly is a reason why this feels like bait-and-switch. It
> sure is the reason why I'm disappointed.

This is a little over the top imho, Kai. Even if we don't switch
the default, then everyone will have the freedom to chose the
internal server for their provision. E.g. distros. E.g. the
SerNet appliance (which has been downloaded many hundred times)
will stick with the internal server. So I am very happy that you
have found the time and energy to settle the signing feature!

But I still think we should make it the default.

> > We should walk before we run:  Get the feature finished, get the
> > automated tests written, make it available and ask that people test it.
> > Test it with the various windows combinations that we need.  Get it into
> > the SerNet appliance.  
> 
> I'm happy to work on all that. I just don't see why this has to be done
> before even considering the implementation. I see this as part of the
> "shake out bugs" phase.

This is my view as well. And we have walked part of the way:
There are some automated tests already, and we have already been
testing what was available from the internal server with good
results over the last 6-9 months. (It _is_ in the SerNet appliance.)


Summing up, I am in favour of switching the default.

But the intenal server will also be very valuable even without switching.


Maybe Metze in his infinite wisdom has written the best
solution for this in his earlier mail:

Let's not set a default. Require the user to specify the
desired backend in provision!


Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120906/04824312/attachment.pgp>