The libevent issue (Was: Re: checking in)

[Joel Sherrill]

FWIW I am OK with disabling what requires libevent2 when it isn't available
as long as the waf configure ends with a very clear message of what had to
be disabled.

And hopefully, we can build a table of platforms supporting everything,
missing X, missing y, etc. and file tickets that are referenced in
configure output.
On Nov 25, 2015 5:18 PM, "Mark Atwood" <fallenpegasus at gmail.com> wrote:

> Ive reached out to contacts of contacts at "Red Hat Consulting for the
> Public Sector” about how they deal with libevent2’s absence in RHEL6 on DOD
> systems.  Unfortunately, its now past 6pm in Raleigh and in DC on the US
> Thanksgiving Holiday.
>
> Mayhap I get some suggestions back next week.
>
> ..m
>
>
> On November 25, 2015 at 1:23:02 PM, Eric S. Raymond (esr at thyrsus.com)
> wrote:
> > Joel Sherrill :
> > > I have been attempting to build on CentOS/RHEL 6 and 7. I filed tickets
> > > based on experiences on each
> > >
> > > CentOS 6 does not have an RPM for libevent2. Thus without special work
> by
> > > each person building NTPsec, it won't build. AFAIK this distribution
> is the
> > > latest RHEL approved for use on DoD networks. I could not find a STIG
> for
> > > RHEL 7 so any organization which requires the DISA STIG to be applied
> is
> > > stuck at 6.
> >
> > This is a little bad, but not unrecoverable. Only ntpdig requires
> libevent2;
> > ntpd, in particular, builds without it. If we have to document that as a
> > limitation I don't think we're going to lose customers over it.
> >
> > I have changed the ticket to have the 'build' label and asked Amar to
> change the
> > build so it fails gracefully in the absence of libevent2, making
> everything
> > but ntpdig.
> >
> > > My CentOS 7 was missing a package and the build didn't disable the
> > > reference clocks that depended on it. Ticket filed.
> >
> > This can be fixed with a relatively minor build system tweak. I have
> added
> > that request to the ticket.
> >
> > > The CentOS 6 issue raises some questions. Did we intend to support
> this OS?
> > > Long term, it highlights the problem of assuming a newer external
> support
> > > library is going to be part of a LTS OS distribution. I don't know if
> this
> > > was on the master list of supported OSes and checked when libevent2 as
> a
> > > dependency was discussed. I don't recall having a checklist OSes to
> ensure
> > > we checked all.
> >
> > I guess now is a good time for me to come clean about one of the
> > assumptions behind my original technical planning.
> >
> > I never pushed having a checklist of OSes to support for the same
> > reason I advocated coding to a strict POSIX.1-2001/C99 baseline.
> > (Joel, this discussion took place well before you were on board.)
> >
> > Experience with GPSD had persuaded me that the traditional Unix
> > strategy of keeping a lot of porting code around just in case led to
> > carrying a lot of historical baggage that had outlasted its time. I
> > believed having a large a-priori set of Unix variants to support would
> > pull in that direction as well, and it was not the direction I thought
> > we should go. I believed our overwhelming priority should be reducing
> > attack surface by discarding code.
> >
> > See the project motto: "Perfection is achieved, not when there is
> > nothing more to add, but when there is nothing left to take away."
> > This choice was not just me being cute - I viewed it as a direct
> > implication of our security focus.
> >
> > In accordance, I deliberately went to the opposite extreme - to be as
> > aggressive and strict in platform requirements as I thought I could
> > get away with, in order to throw away as much code as possible,
> > and then patch around the resulting porting issues.
> >
> > So far this strategy has had exactly two real downsides:
> >
> > 1. We've had to simulate POSIX clock_gettime() for MAC OS X using a
> native call.
> >
> > 2. The libevent2 dependency blocks ntpdig on CentOS 6 and older NetBSDs
> as well.
> >
> > If these are the worst problems we have as a result - and that looks
> likely
> > at this point - I'm going to claim a strategic victory. We are, as far
> as I
> > know, good on all *current* LTSes.
> >
> > Now here's the controversial part:
> >
> > In truth, I was anticipating something like the libevent problem
> > (failure to insta-port to older releases) with an attitude almost like
> > hope. That is, if we hadn't run into *anything* like it, I'd consider
> > that I hadn't pushed quite hard enough towards "nothing left to take
> > away". While I would have lived with that outcome, I would have
> > considered it suboptimal.
> >
> > In effect, I was hoping for a sort of optimal pain level, enough to
> signal
> > strong success at the clean-up-and-pare-down without seriously messing
> > up functionality. I think we have that.
> >
> > I'll admit to having been a little quiet and sneaky about that
> > success criterion; I didn't want the arguments I'd get if I made it
> > explicit.
> >
> > Finally, I will observe that if this let-it-break-a-little stance seems
> > like a dicy or over-bold choice to have made, some reflection on why
> > Classic NTP stagnated may be in order. Fear of breaking anything can
> > be a trap; among other reasons you want a system architect around is to
> > exercise judgment about when it's time to bust out, judgment that takes
> > into account the whole-life-cycle perspective. Including considerations
> > like reducing downstream maintainance costs, attack surface and
> > defect rates.
> > --
> > Eric S. Raymond
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20151125/c4510082/attachment.html>