Default DNS server for Samba 4.0

[Andrew Bartlett]

On Thu, 2012-09-06 at 08:17 +0200, Kai Blin wrote:
> On 2012-09-06 01:11, Andrew Bartlett wrote:

> 
> So now it's testing? You keep raising the bar on me, every time I
> proposed using the internal server. When I first got it to work, we
> couldn't use it because it didn't do updates. Then I implemented
> updates, and we couldn't use it because they couldn't be signed. Now
> they can be signed, and we can't use them because they have no tests?
> You're telling me that I'm late because I fail to hit a constantly
> moving target for a moving deadline?

Kai,

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.  

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.  

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 do hope you didn't feel I promised you that you would have the
automatic right to change the default, because I always intended to
assess the state of the two options at the time the internal DNS server
is 'finished'.  

> > Now once we have this in, we can gain the confidence of real-world use,
> > with multiple replicating DCs, joining Windows DCs to Samba, migrations
> > from dlz_bind9 etc.  We can refer users who have difficulties with bind
> > to this alternative, and we can understand how it behaves in
> > production. 
> 
> We have real world use data with the DNS server. It's running on the
> SerNet appliance, and turned up a couple of bugs when they first started
> using it. Those were fixed, and I haven't heard any complaints in quite
> a while. Don't tell me that we don't have experience because you don't
> have experience. Otherwise I can make the same claim. I've never managed
> to get the BIND stuff to work for me, and I can set up the internal
> server within minutes.

You described your testing as joining a Windows7 client.  I'm
particularly concerned to ensure that things like DC joins also work, as
do the other things I mentioned.  

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.  

Then, with that backing, you would have good grounds to discuss a change
in the default.  Anything else is premature, particularly as we don't
yet even have correct ACL checking on the updates.  

It is particularly premature to ask to change the default the day you
finish the most complex component, before adding the required tests.  

> > When we last discussed this, we were expecting to have or major features
> > in place before the beta, and it was clear you could not meet that
> > deadline.  However, at least I had the impression that you were planning
> > on working on it during the early part of the beta series.  It's now
> > just before RC1, and it has been great to see these features finally
> > about to make the tree.  
> 
> But we did agree that the target was "before RC1". I was planning on
> working on this sooner, but as it happens, I do have a day job, and
> crypto stuff isn't exactly trivial, so I didn't manage to get it in
> beforehand.

I'm happy that you have managed to almost complete the feature before
RC1.  This means we can include it in the release.  

> > However, the RC1 date looms very, very soon (tomorrow or the start of
> > next week is the agreed date), and so the burden on you to propose a
> > change in the default is now quite high.  It certainly is a higher
> > burden than back in May, because over 3 months of potential testing,
> > particularly with the TSIG code in the real world has passed.  (I'm most
> > concerned about the TSIG code not just because it is new, but because
> > crypto bugs do take time to shake out). 
> 
> As far as I understand we're still holding the release for SMB3 code to
> even hit the tree. Now while you can argue that Metze certainly is a
> more experienced developer than I am, it's still new, untested code.
> Getting things tested and shaking out bugs is what release candidates
> are for. And if things do go wrong, we can tell people to fall back to
> the bind solution. That way they only need to go through the setup
> hassle if the internal dns doesn't work.

No, I don't see the release candidate period as a time to flip features
on and off.  The agreed procedure is for bug fixes, with a genuine
feeling that this is a release candidate, not just another period of
betas. 

> > It is always incredibly painful for everyone when we have to make
> > decisions like this about such a promising feature.  But in the same way
> > that I came to the view that TDB2 was being modified and proposed too
> > soon before our release, this is why I cannot support changing the
> > default DNS server in these circumstances.
> 
> We just changed printing, the file server, parts of the file server
> build system. That was fine. TDB2 was a huge change touching many parts
> of the code base. Comparing the dns server to TDB2 is an apples to
> oranges comparison.
> 
> But I can see that we won't manage to agree on this before the RC1. I
> appreciate your comments, and you certainly defined the roadmap of
> further work on the internal dns server, but I don't consider them to be
> blockers, seeing how much easier this will make it for people to get
> started with a samba AD deployment.

I'm glad you understand my position.  Had we had this code in the tree
even just a couple of betas ago, and the tests had been finished in the
meantime, I think this would be a very different discussion.  

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org