Over the weekend, I've started investigating the integration of current ntp
4.2.2 into the SFW Nevada consolidation.

I've chosed sfw because it seems to most closely meet our needs, namely the
integration of external software largely unchanged from the upstream
distribution.  Integrating into OS/Net would be much more work to adapt the
build machinery, so (as in the case of BIND 9) sfw should serve us better.

Here's the list of files/directories that need to be changed/added:

usr/src/Targetdirs              + var/ntp/ntpstats, usr/lib/inet
usr/src/cmd/Makefile            + ntp
usr/src/cmd/ntp/DISTDIRS.sfw
usr/src/cmd/ntp/DISTFILES.sfw
usr/src/cmd/ntp/EXFILES.sfw     I'm not yet sure why/when this is neeed.
usr/src/cmd/ntp/Makefiles.sfw
usr/src/cmd/ntp/README.sfw
usr/src/cmd/ntp/configure.diff
usr/src/cmd/ntp/install-ntp
usr/src/cmd/ntp/ntp             The method script, adapted from OS/Net
usr/src/cmd/ntp/ntp-4.2.2.tar.gz
usr/src/cmd/ntp/ntp.client      The template ntp.conf files from OS/Net.
usr/src/cmd/ntp/ntp.server
usr/src/cmd/ntp/ntp.xml         The SMF manifest from OS/Net.
usr/src/cmd/ntp/ntpd.c.diff
usr/src/cmd/ntp/parsesolaris.c.diff
usr/src/pkgdefs/Makefile        + SUNWntp{S,kr,r,u}
usr/src/pkgdefs/SUNWntpS        The usual source package corresponding to
                                the binaries delivered.
usr/src/pkgdefs/SUNWntpkr       If we deliver parse (and other kernel
                                components), they need to go into a
                                separate package that won't get installed
                                into local zones.
usr/src/pkgdefs/SUNWntpr        From OS/Net, modified for ntp4.
usr/src/pkgdefs/SUNWntpu

I'll upload the actual files to opensolaris.org once I've checked the
procedure and licensing details, so I'll go on by describing the changes
I've made:

I'm currently configuring like this:

  CC=cc
  CPPFLAGS='-DCONFIG_FILE=\"/etc/inet/ntp.conf\" 
-DNTP_VAR=\"/var/ntp/ntpstats\"'
  configure
        --prefix=/usr
        --bindir=/usr/sbin                      need to force alls bins here
        --sysconfdir=/etc/inet
        --localstatedir=/var                    ???
        --with-binsubdir=sbin                   default: bin
        --enable-all-clocks
        --enable-parse-clocks
        --with-openssl-libdir=/usr/sfw/lib
        --with-openssl-incdir=/usr/sfw/include

I think we should keep all installed binaries in /usr/sbin as in the
current SUNWntpu package, so we need both --bindir=/usr/sbin and
--with-binsubdir=sbin.

--sysconfdir=/etc/inet is set for a future point in time when ntp honors
it; right now, I need to define CONFIG_FILE in CPPFLAGS to get ntp.conf to
/etc/inet where it currently resides.  I've file Bug 641 in the ntp
bugzilla about this.

It's the same with --localstatedir and NTP_VAR (Bug 643).

I think the OpenSolaris ntpd should include for all available reference
clocks, thus --enable-all-clocks --enable-parse-clocks.

And finally --with-openssl-*dir needs to be set so the crypto code is
built.

At the moment, readline support for ntpq and ntpdc isn't included since
there's no public libreadline in OpenSolaris.  postgres in sfw does have a
private copy, which is ugly, so it might be useful to lobby for the proper
integration of libreadline.  There seem to be licensing issues, though,
since libreadline is GPL, not LGPL, as has been discussed a bit on
tools-discuss when the issue of introducing /usr/gnu has been brought up.

I noticed during the configure run that debug code is included by default:

checking if we're including debugging code... yes

I'm not fully certain yet that it is desirable to include this in
production; on the other hand, it will probably quite handy if there are
any issues to debug with only the binaries present.

A couple of reference clocks are not currently included:

checking Datum/Bancomm bc635/VME interface... no

  HP/UX only (CLOCK_BANC)

checking TrueTime GPS receiver/VME interface... no

  HP/UX only (CLOCK_GPSVME)

checking for PCL720 clock support... no

  only with <machine/inline.h>, <sys/pcl720.h>, <sys/i8253.h> (CLOCK_PPS720)

  This is a bit strange since the latter two headers are present in
  kernel/sys in the distribution.

checking KSI/Odetics TPRO/S GPS receiver/IRIG interface... no

  only with <sys/tpro.h> (CLOCK_TPRO)

  Again, this header is in kernel/sys.

checking TrueTime 560 IRIG-B decoder... no

  defaults to no (CLOCK_TT560)

  Only included if explicitly requested; I haven't yet checked why.

Currently, the parse STREAMS module isn't built on Solaris/x86 (Bug 639,
640).  The configure.diff and parsesolaris.c.diff files allow it to
compile; I haven't yet tried using it on a Solaris/x86 machine.  There are
several issues with this module, which warrants a separate thread.

checking if we want to build the NTPD simulator... no

I've omitted --enable-simulator; this doesn't seem to be useful for
anything but ntp development and thus inappropriate.

During the actual build, I noticed several warnings from cc; they probably
warrant investigation and reports to the ntp bugzilla.

Since ntp honors DESTDIR, the make install phase of the build can use that,
with the exception of the ntpd binary proper, which should be moved to
/usr/lib/inet (like current xntpd).

After the build completed successfully, I've run the resulting binary on my
laptop (without network connectivity), and decided to run it as user ntp
with only the required privileges.  I discovered a couple of issues doing
so, which I'll discuss in a separate message.

Apart from this privileges issue, there's another point for the SMF
integration: currently, ntpdate is used to initially set the clock at
boot.  Since Dave is going to deprecate ntpdate, I'd suggest to use ntpd -g
instead.  Another ntpd option worth considering is -N, so ntpd runs in the
RT scheduling class.  Apart from that, it is probably useful to allow
setting ntpd command line args via SMF properties.

The ntp.client ntp.conf template can probably remain largely unchanged from
xntp3, but ntp.server needs to be updated to the current list of reference
clocks.  I've already started doing this.

        Rainer

-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Reply via email to