NTP versions in production use?

Mon Jul 13 01:12:06 UTC 2015

On Sun, Jul 12, 2015 at 03:23:58PM -0700, Harlan Stenn wrote:
> On 7/12/15 11:31 AM, Valdis.Kletnieks at vt.edu wrote:
> > On Sun, 12 Jul 2015 10:15:20 -0400, "Mike O'Connor" said:
> > 
> >> :Thanks, and I'm kinda stunned that folks are running such ancient
> >> :versions of NTP.
> >>
> >> I suggest you get accustomed to being stunned.
> > 
> > He obviously didn't see my post a few weeks back about hosts that were
> > looking for an NTP server that went out of service back in 1999. And yes,
> > some were still using NTP v1 and v2.
> > 
> > There's a *lot* of stuff on very serious autopilot out there....
> 
> I did see it, and I was assuming it was a "local" configuration problem.
>  This is "death by 1,000 cuts" and when I wrote my recent query I was
> looking for the big offenders.
> 
> To me this situation goes hand-in-hand with the problems getting bcp38
> deployed, and what Dan Geer talked about in his keynote speech at Black
> Hat 2014:
> 
>  http://www.youtube.com/watch?v=nT-TGvYOBpI
> 
> I get that some folks have real problems with their build systems and
> it's hard to upgrade software tools in that environment.  I know it's
> can be expensive to solve that problem.  I'd love to find a way to have
> the "versioned tool chain" stuff that I implemented at Cisco/Andiamo be
> generally available, but I haven't found that many folks willing to
> support it yet and I just don't have the spare cycles to add that to my
> "do it for free" pile.
> 
> I do know that if more companies were to use this sort of tool that the
> argument of "we can't patch older releases because we don't have those
> tools anymore and the Q/A process becomes horribly expensive"  goes
> away.  And that also means that it's far less expensive and therefore
> far more profitable to offer maintenance support on older software
> releases for much longer periods of time.  But I must be missing
> something here as well, as I was never able to make headway with this
> idea when I was at Cisco.

	The problem is people like Cisco don't make it easy
to configure these protocols at all.  You can only insert an IP address
and their configuration system is all fire-and-forget additive causing
config bloat.  What's the harm in putting in a few more NTP lines if it
just works.

	The NTP software does a lot of very esoteric things that don't
matter much to those outside the super-time-geek space.  This isn't blame,
but it makes it harder for the upstream systems to injest them.  Take
JunOS which is effectively a type of FreeBSD port.  The FreeBSD devs
have very strict ideas of what should be part of the core OS, quality
and ideas that prevent injesting something that isn't marked "full release".

	The release-early and release-often mantra comes to mind for me.  If
you do that, it's much easier for downstream people to package your latest
upstream package.  They take the idea of what you consider stable seriously
and many developers i know don't like issuing a release because they know
it does or might have some bugs.  Sometimes that means rapid iterations
which is much better than having stale software for N years where N is
quite large like it is here.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from jared at puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.