Meta Configuration of Package xntp

<package name="xntp" project="oldschool">
  <title>Network Time Protocol daemon (version 4)</title>
  <description>The Network Time Protocol (NTP) is used to synchronize the time of a
computer client or server to another server or reference time source, such
as a radio or satellite receiver or modem. It provides client accuracies
typically within a millisecond on LANs and up to a few tens of milliseconds
on WANs relative to a primary server synchronized to Coordinated
Universal Time (UTC) via a Global Positioning Service (GPS) receiver, for
example. Typical NTP configurations utilize multiple redundant servers and
diverse network paths, to achieve high accuracy and reliability.
Some configurations include cryptographic authentication to prevent
accidental or malicious protocol attacks.
ntpd is an operating system daemon which sets and maintains the system
time-of-day synchronized with Internet standard time servers. ntpd is a
complete implementation of the Network Time Protocol (NTP) version 4, but
also retains compatibility with version 3, as defined by RFC-1305, and version
1 and 2, as defined by RFC-1059 and RFC-1119, respectively. ntpd does
most computations in 64-bit floating point arithmetic and does relatively
clumsy 64-bit fixed point operations only when necessary to preserve the
ultimate precision, about 232 picoseconds. While the ultimate precision is not
achievable with ordinary workstations and networks of today, it may be
required with future nanosecond CPU clocks and gigabit LANs.
The daemon can operate in any of several modes, including symmetrical
active/passive, client/server broadcast/multicast, and manycast. A
broadcast/multicast or manycast client can discover remote servers, compute
server-client propagation delay correction factors, and configure itself
automatically. This makes it possible to deploy a fleet of workstations without
specifying configuration details specific to the local environment.
Ordinarily, ntpd reads the ntp.conf configuration file at start-up time
to determine the synchronization sources and operating modes. It is also
possible to specify a working, although limited, configuration entirely on the
command line, obviating the need for a configuration file. This may be
particularly appropriate when the local host is to be configured as a
broadcast/multicast client or manycast client, with all peers being determined
by listening to broadcasts at run time.
Various internal ntpd variables can be displayed and configuration options
altered while the daemon is running using the ntpq and ntpdc utility
programs.

Authors:
--------
    Mark Andrews &lt;marka@syd.dms.csiro.au&gt;
    Viraj Bais &lt;vbais@mailman1.intel.com&gt;
    Clayton Kirkwood &lt;kirkwood@striderfm.intel.com&gt;
    Karl Berry &lt;karl@owl.HQ.ileaf.com&gt;
    Piete Brooks &lt;Piete.Brooks@cl.cam.ac.uk&gt;
    Steve Clift &lt;clift@ml.csiro.au&gt;
    Casey Crellin &lt;casey@csc.co.za&gt;
    Torsten Duwe &lt;duwe@immd4.informatik.uni-erlangen.de&gt;
    John A. Dundas III &lt;dundas@salt.jpl.nasa.gov&gt;
    Dennis Ferguson &lt;dennis@mrbill.canet.ca&gt;
    Glenn Hollinger &lt;glenn@herald.usask.ca&gt;
    Mike Iglesias &lt;iglesias@uci.edu&gt;
    Jim Jagielski &lt;jim@jagubox.gsfc.nasa.gov&gt;
    Jeff Johnson &lt;jbj@chatham.usdesign.com&gt;
    William L. Jones &lt;jones@hermes.chpc.utexas.edu&gt;
    Dave Katz &lt;dkatz@cisco.com&gt;
    Craig Leres &lt;leres@ee.lbl.gov&gt;
    George Lindholm &lt;lindholm@ucs.ubc.ca&gt;
    Louis A. Mamakos &lt;louie@ni.umd.edu&gt;
    Derek Mulcahy &lt;derek@toybox.demon.co.uk&gt;
    Damon Hart-Davis &lt;d@hd.org&gt;
    Lars H. Mathiesen &lt;thorinn@diku.dk&gt;
    David L. Mills &lt;mills@udel.edu&gt;
    Wolfgang Moeller &lt;moeller@gwdgv1.dnet.gwdg.de&gt;
    Jeffrey Mogul &lt;mogul@pa.dec.com&gt;
    Tom Moore &lt;tmoore@fievel.daytonoh.ncr.com&gt;
    Rainer Pruy &lt;Rainer.Pruy@informatik.uni-erlangen.de&gt;
    Dirce Richards &lt;dirce@zk3.dec.com&gt;
    Nick Sayer &lt;mrapple@quack.kfu.com&gt;
    Frank Kardel &lt;Frank.Kardel@informatik.uni-erlangen.de&gt;
    Ray Schnitzler &lt;schnitz@unipress.com&gt;
    Michael Shields &lt;shields@tembel.org&gt;
    Jeff Steinman &lt;jss@pebbles.jpl.nasa.gov&gt;
    Harlan Stenn &lt;harlan@pfcs.com&gt;
    Kenneth Stone &lt;ken@sdd.hp.com&gt;
    Ajit Thyagarajan &lt;ajit@ee.udel.edu&gt;
    Tomoaki TSURUOKA &lt;tsuruoka@nc.fukuoka-u.ac.jp&gt;
    Paul A Vixie &lt;vixie@vix.com&gt;
    Ulrich Windl &lt;Ulrich.Windl@rz.uni-regensburg.de&gt;

SuSE series: n</description>
  <person userid="netmax" role="maintainer"/>
</package>

​x
 
<package name="xntp" project="oldschool">
  <title>Network Time Protocol daemon (version 4)</title>
  <description>The Network Time Protocol (NTP) is used to synchronize the time of a
computer client or server to another server or reference time source, such
as a radio or satellite receiver or modem. It provides client accuracies
typically within a millisecond on LANs and up to a few tens of milliseconds
on WANs relative to a primary server synchronized to Coordinated
Universal Time (UTC) via a Global Positioning Service (GPS) receiver, for
example. Typical NTP configurations utilize multiple redundant servers and
diverse network paths, to achieve high accuracy and reliability.
Some configurations include cryptographic authentication to prevent
accidental or malicious protocol attacks.
ntpd is an operating system daemon which sets and maintains the system
time-of-day synchronized with Internet standard time servers. ntpd is a
complete implementation of the Network Time Protocol (NTP) version 4, but
also retains compatibility with version 3, as defined by RFC-1305, and version
1 and 2, as defined by RFC-1059 and RFC-1119, respectively. ntpd does
most computations in 64-bit floating point arithmetic and does relatively
clumsy 64-bit fixed point operations only when necessary to preserve the
ultimate precision, about 232 picoseconds. While the ultimate precision is not
achievable with ordinary workstations and networks of today, it may be
required with future nanosecond CPU clocks and gigabit LANs.
The daemon can operate in any of several modes, including symmetrical
active/passive, client/server broadcast/multicast, and manycast. A
broadcast/multicast or manycast client can discover remote servers, compute
server-client propagation delay correction factors, and configure itself
automatically. This makes it possible to deploy a fleet of workstations without
specifying configuration details specific to the local environment.
Ordinarily, ntpd reads the ntp.conf configuration file at start-up time
to determine the synchronization sources and operating modes. It is also
possible to specify a working, although limited, configuration entirely on the
command line, obviating the need for a configuration file. This may be
particularly appropriate when the local host is to be configured as a
broadcast/multicast client or manycast client, with all peers being determined
by listening to broadcasts at run time.
Various internal ntpd variables can be displayed and configuration options
altered while the daemon is running using the ntpq and ntpdc utility
programs.
​
Authors:
--------
    Mark Andrews &lt;marka@syd.dms.csiro.au&gt;
    Viraj Bais &lt;vbais@mailman1.intel.com&gt;
    Clayton Kirkwood &lt;kirkwood@striderfm.intel.com&gt;
    Karl Berry &lt;karl@owl.HQ.ileaf.com&gt;
    Piete Brooks &lt;Piete.Brooks@cl.cam.ac.uk&gt;
    Steve Clift &lt;clift@ml.csiro.au&gt;
    Casey Crellin &lt;casey@csc.co.za&gt;
    Torsten Duwe &lt;duwe@immd4.informatik.uni-erlangen.de&gt;
    John A. Dundas III &lt;dundas@salt.jpl.nasa.gov&gt;
    Dennis Ferguson &lt;dennis@mrbill.canet.ca&gt;
    Glenn Hollinger &lt;glenn@herald.usask.ca&gt;
    Mike Iglesias &lt;iglesias@uci.edu&gt;
    Jim Jagielski &lt;jim@jagubox.gsfc.nasa.gov&gt;
    Jeff Johnson &lt;jbj@chatham.usdesign.com&gt;
    William L. Jones &lt;jones@hermes.chpc.utexas.edu&gt;
    Dave Katz &lt;dkatz@cisco.com&gt;
    Craig Leres &lt;leres@ee.lbl.gov&gt;
    George Lindholm &lt;lindholm@ucs.ubc.ca&gt;
    Louis A. Mamakos &lt;louie@ni.umd.edu&gt;
    Derek Mulcahy &lt;derek@toybox.demon.co.uk&gt;
    Damon Hart-Davis &lt;d@hd.org&gt;
    Lars H. Mathiesen &lt;thorinn@diku.dk&gt;
    David L. Mills &lt;mills@udel.edu&gt;
    Wolfgang Moeller &lt;moeller@gwdgv1.dnet.gwdg.de&gt;
    Jeffrey Mogul &lt;mogul@pa.dec.com&gt;
    Tom Moore &lt;tmoore@fievel.daytonoh.ncr.com&gt;
    Rainer Pruy &lt;Rainer.Pruy@informatik.uni-erlangen.de&gt;
    Dirce Richards &lt;dirce@zk3.dec.com&gt;
    Nick Sayer &lt;mrapple@quack.kfu.com&gt;
    Frank Kardel &lt;Frank.Kardel@informatik.uni-erlangen.de&gt;
    Ray Schnitzler &lt;schnitz@unipress.com&gt;
    Michael Shields &lt;shields@tembel.org&gt;
    Jeff Steinman &lt;jss@pebbles.jpl.nasa.gov&gt;
    Harlan Stenn &lt;harlan@pfcs.com&gt;
    Kenneth Stone &lt;ken@sdd.hp.com&gt;
    Ajit Thyagarajan &lt;ajit@ee.udel.edu&gt;
    Tomoaki TSURUOKA &lt;tsuruoka@nc.fukuoka-u.ac.jp&gt;
    Paul A Vixie &lt;vixie@vix.com&gt;
    Ulrich Windl &lt;Ulrich.Windl@rz.uni-regensburg.de&gt;
​
SuSE series: n</description>
  <person userid="netmax" role="maintainer"/>
</package>
​