[ntp:hackers] Build failure

Rainer Orth ro at TechFak.Uni-Bielefeld.DE
Wed Sep 3 16:36:02 PDT 2003


Dave,

sorry for the late reply: I've just returned from a three-week vacation and
try to catch up with the mail received.

> A test build on the campus flock turned up errors on pogo and malarky.
> The build stopped in ntpdc:
> 
> /bin/bash: ./nl.pl: bad interpreter: permission denied

I suppose this is the build in pogo:/pogo/dist/A.{pogo,malarky}?  The
problem is that autoconf found /usr/local/gnu/bin/perl first in PATH and
used it as the interpreter of the nl.pl script.  Unfortunately, that
instance of perl is

orth at pogo 30 > ls -l /usr/local/gnu/bin/perl*
-rwx------   2 root     daemon    367368 Feb 22  1994 /usr/local/gnu/bin/perl*
-rwx------   2 root     daemon    367368 Feb 22  1994 /usr/local/gnu/bin/perl4.036*

both quite old (shouldn't matter for the script, which doesn't use perl5
features) and not executable by non-root users, thus giving the error
above.  I suggest simply removing the useless /usr/local/gnu/bin/perl;
afterwards there should be two good instances of perl available
(/usr/bin/perl or /usr/local/bin/perl).

Anyway, it's clearly a bug for the build to fail if perl is missing.  I've
created a bug report for this (http://bugzilla.ntp.org/show_bug.cgi?id=197),
but I may be unable to fix this immediately since I will be away next week
as well.

> I then found massive evil in the ./ntpdc directory, including a
> profusion of perl. Whattheheck is going on? The ntpdc program is headed
> for retirement with functions to be assumed by ntpq. A far better
> expenditure of effor would be to further that agenda at the expense of
> wasted time with ntpdc.

I'm fully aware of this.  Let me explain: while testing ntp-dev on a wide
range of platforms (both 32 and 64-bit), I noticed that (unlike ntp-stable
aka 4.1 and also the older xntp releases), ntpdc didn't interoperate
between different platforms.  It turned out that the IPv6 changes had not
been careful about the layout of the structures exchanged by the mode 7
protocol.  Instead, there existed at least three incompatible variants,
depending on both 32 vs. 64-bitness and the variant of struct in6_addr
used.  I have been able to fix this as a stopgap measure, even at the
expense of breaking compatibility with some intermediate versions of
ntp-dev, arguing that the current way was inherently and unfixably broken
and had to be repaired before the release.

To make sure that no such incompatibilites creep in unnoticed in the
future, I created a little perl script to extract the mode 7 structures
from ntp_reqest.h and generate a C program to print their layout.  This is
checked against a reference layout at ntp-dev build time, so the build
bails out if the layout is changed inadvertently.  This is the source of
the evil you currently see in ./ntpdc.

This whole mess is only a short-term fix to retain an interoperable mode 7
protocol implementation, since I don't think we will be able to get rid of
ntpdc for the 4.2.0 release.  Anyway, I suggested the following future
course: 

* As a first step, identify the information currently only available via
  ntpdc and integrate this into the mode 6 (ntpq) protocol.  This should be
  relatively easy, since it only involves reading information.

* The harder part is the runtime configuration feature ot ntpdc.  To
  integrate this into ntpq probably requires the config parser rewrite,
  which is more effort.

I'll probably look at least into the first of those steps, but am somewhat
time limited by job duties, among others.

I hope this explains the stuff you're seeing and allows you to get along
with testing.

More discussion on those issues can be found in the audit trails of the bug
reports related to the problem:

* Interoperability problems with ntpdc

	http://bugzilla.ntp.org/show_bug.cgi?id=164
	
* 64-bit ntpdc may display incorrect hostnames or addresses

	http://bugzilla.ntp.org/show_bug.cgi?id=165

* Verify NTP mode 7 packet layout at build time

	http://bugzilla.ntp.org/show_bug.cgi?id=180

Sorry for the breakage.

	Rainer



More information about the hackers mailing list