Package: ntp
Version: 1:4.2.0a+stable-2
Severity: minor
I suggest the following changes. (Sorry about the long lines - if
they don't survive the mail, let me know and I'll send revised files
as encoded attachments.)
- Jim Van Zandt
diff -r ../../ntp-4.2.0a+stable-orig/html/notes.html ./notes.html
27c27
< <p>The NTP Version 4 distribution includes, in addition to the daemon
itself (<tt><a href="ntpd.html">ntpd</a></tt>), several utility programs,
including two remote-monitoring programs (<a
href="ntpq.html"><tt>ntpq</tt></a>, <tt><a href="ntpdc.html">ntpdc</a></tt>), a
remote clock-setting program similar to the Unix rdate program
(<tt>ntpdate</tt>), a traceback utility u seful to discover suitable
synchronization sources (<tt>ntptrace</tt>), and various programs used to
configure the local platform and calibrate the intrinsic errors. NTP has been
ported to a large number of platforms, including most RISC and CISC
workstations and mainframes manufactured today. Example configuration files for
many models of these machines are included in the distribution. While in most
cases the standard version of the implementation runs with no hardware or
operating system modifications, not all features of the distribution are
available on all platforms. For instance, a special feature al
lowing Sun workstations to achieve accuracies in the order of 100 microseconds
requires some minor changes and additions to the kernel and input/output
support.</p>
---
> <p>The NTP Version 4 distribution includes, in addition to the daemon
> itself (<tt><a href="ntpd.html">ntpd</a></tt>), several utility programs,
> including two remote-monitoring programs (<a
> href="ntpq.html"><tt>ntpq</tt></a>, <tt><a href="ntpdc.html">ntpdc</a></tt>),
> a remote clock-setting program similar to the Unix rdate program
> (<tt>ntpdate</tt>), a traceback utility useful to discover suitable
> synchronization sources (<tt>ntptrace</tt>), and various programs used to
> configure the local platform and calibrate the intrinsic errors. NTP has been
> ported to a large number of platforms, including most RISC and CISC
> workstations and mainframes manufactured today. Example configuration files
> for many models of these machines are included in the distribution. While in
> most cases the standard version of the implementation runs with no hardware
> or operating system modifications, not all features of the distribution are
> available on all platforms. For instance, a special feature all
owing Sun workstations to achieve accuracies in the order of 100 microseconds
requires some minor changes and additions to the kernel and input/output
support.</p>
42c42
< <p>Normally, it is not considered good practice for a single
workstation to request synchronization from a primary (stratum-1) time server.
At present, these servers provide synchronization for hundreds of clients in
many cases and could, along with the network access paths, become seriously
overloaded if large numbers of workstation clients requested synchronization
directly. Therefore, workstations located in sparsely populated administrative
domains with no local synchronization infrastructure should request
synchronization from nearby stratum-2 servers instead. In most cas es the
keepers of those servers in the lists of public servers provide unrestricted
access without prior permission; however, in all cases it is considered polite
to notify the administrator listed in the file upon commencement of regular
service. In all cases the access mode and notification requirements listed in
the file must be respected. Under no conditions should servers not in these
lists be us
ed without prior permission, as to do so can create severe problems in the
local infrastructure, especially in cases of dial-up access to the Internet.</p>
---
> <p>Normally, it is not considered good practice for a single
> workstation to request synchronization from a primary (stratum-1) time
> server. At present, these servers provide synchronization for hundreds of
> clients in many cases and could, along with the network access paths, become
> seriously overloaded if large numbers of workstation clients requested
> synchronization directly. Therefore, workstations located in sparsely
> populated administrative domains with no local synchronization infrastructure
> should request synchronization from nearby stratum-2 servers instead. In most
> cases the keepers of those servers in the lists of public servers provide
> unrestricted access without prior permission; however, in all cases it is
> considered polite to notify the administrator listed in the file upon
> commencement of regular service. In all cases the access mode and
> notification requirements listed in the file must be respected. Under no
> conditions should servers not in these lists be use
d without prior permission, as to do so can create severe problems in the
local infrastructure, especially in cases of dial-up access to the Internet.</p>
75c75
< If NetInfo support is compiled into NTP, you can opt to configure ntp
in your NetInfo domain. NTP will look int he NetInfo directory
<tt>/locations/ntp</tt> for property/value pairs which are equivalent the the
lines in the configuration file described above. Each configuration keyword may
have a coresponding property in NetInfo. Each value for a given property is
treated as arguments to that property, similar to a line in the configuration
file.
---
> If NetInfo support is compiled into NTP, you can opt to configure NTP
> in your NetInfo domain. NTP will look in the NetInfo directory
> <tt>/locations/ntp</tt> for property/value pairs which are equivalent to the
> lines in the configuration file described above. Each configuration keyword
> may have a corresponding property in NetInfo. Each value for a given property
> is treated as arguments to that property, similar to a line in the
> configuration file.
79c79
< There are several items of note when dealing with a mixture of
<tt>ntp4</tt> and previous distributions of NTP Version 2 (<tt>ntpd</tt>) and
NTP Version 1 (<tt>ntp3.4</tt>). The <tt>ntp4</tt> implementation conforms to
the NTP Version 3 specification RFC-1305 and, in addition, contains additional
feaures documented in the <a href="release.html">Release Notes</a> page. As
such, by default when no additional information is available concerning the
preferences of the peer, <tt>ntpd</tt> claims to be version 4 in the packets
that it sends from configured associations. The <tt>version</tt> subcommand of
the <tt>server</tt>, <tt>peer</tt>, <tt>broadcast</tt> and
<tt>manycastclient</tt> command can be used to change the default. In
unconfigured (ephemeral) associaitons, the daemon always replies in the same
version as the request.
---
> There are several items of note when dealing with a mixture of
> <tt>ntp4</tt> and previous distributions of NTP Version 2 (<tt>ntpd</tt>) and
> NTP Version 1 (<tt>ntp3.4</tt>). The <tt>ntp4</tt> implementation conforms to
> the NTP Version 3 specification RFC-1305 and, in addition, contains
> additional features documented in the <a href="release.html">Release
> Notes</a> page. As such, by default when no additional information is
> available concerning the preferences of the peer, <tt>ntpd</tt> claims to be
> version 4 in the packets that it sends from configured associations. The
> <tt>version</tt> subcommand of the <tt>server</tt>, <tt>peer</tt>,
> <tt>broadcast</tt> and <tt>manycastclient</tt> command can be used to change
> the default. In unconfigured (ephemeral) associations, the daemon always
> replies in the same version as the request.
159c159
< <p>Ordinarily, the authentication delay; that is, the processing time
taken between the freezing of a transmit timestamp and the actual transmission
of the packet when authentication is enabled (i.e. more or less the time it
takes for the DES or MD5 routine to encrypt a single block) is computed
automatically by the daemon. If necessary, the delay can be overriden by the
<tt>authdelay</tt> line, which is used as a correction for the transmit
timestamp.</p>
---
> <p>Ordinarily, the authentication delay; that is, the processing time
> taken between the freezing of a transmit timestamp and the actual
> transmission of the packet when authentication is enabled (i.e. more or less
> the time it takes for the DES or MD5 routine to encrypt a single block) is
> computed automatically by the daemon. If necessary, the delay can be
> overridden by the <tt>authdelay</tt> line, which is used as a correction for
> the transmit timestamp.</p>
165c165
< 29233E0461ECD6AE # des key in NTP format
---
> 29233E0461ECD6AE # DES key in NTP format
173c173
< ; # des key as an ASCII string
---
> ; # DES key as an ASCII string
184c184
< <p>The big trouble with the authentication facility is the keys file.
It is a maintenance headache and a security problem. This should be fixed some
day. Presumably, this whole bag of worms goes away if/when a generic security
regime for the Internet is established. An alternative with NTP Version 4 is
the autokey feature, which uses random session keys and public-key cruptography
and avoids the key file entirely. While this feature is not completely finished
yet, details can be found in the <a href="release.html">Release Notes</a>
page.</p>
---
> <p>The big trouble with the authentication facility is the keys file.
> It is a maintenance headache and a security problem. This should be fixed
> some day. Presumably, this whole bag of worms goes away if/when a generic
> security regime for the Internet is established. An alternative with NTP
> Version 4 is the autokey feature, which uses random session keys and
> public-key cryptography and avoids the key file entirely. While this feature
> is not completely finished yet, details can be found in the <a
> href="release.html">Release Notes</a> page.</p>
231c231
< <p>Thus, to make very sure it avoids problems related to the
roundoff, the <tt>tickadj</tt> program can be used to adjust the values of
<tt>tick</tt> and <tt>tickadj</tt>. This ensures that all adjustments given to
<tt>adjtime()</tt> are an even multiple of <tt>tickadj</tt> microseconds and
computes the largest adjustment that can be completed in the adjustment
interval (using both the value of <tt>tick</tt> and the value of
<tt>tickadj</tt>) so it can avoid exceeding this limit. It is important to note
that not all systems will allow inspection or modification of kernel variables
other than at system build time. It is also important to know that, with the
current NTP tolerances, it is rarely necessary to make these changes, but in
many cases they will substantially improve the general accurace of the time
service.</p>
---
> <p>Thus, to make very sure it avoids problems related to the
> roundoff, the <tt>tickadj</tt> program can be used to adjust the values of
> <tt>tick</tt> and <tt>tickadj</tt>. This ensures that all adjustments given
> to <tt>adjtime()</tt> are an even multiple of <tt>tickadj</tt> microseconds
> and computes the largest adjustment that can be completed in the adjustment
> interval (using both the value of <tt>tick</tt> and the value of
> <tt>tickadj</tt>) so it can avoid exceeding this limit. It is important to
> note that not all systems will allow inspection or modification of kernel
> variables other than at system build time. It is also important to know that,
> with the current NTP tolerances, it is rarely necessary to make these
> changes, but in many cases they will substantially improve the general
> accuracy of the time service.</p>
diff -r ../../ntp-4.2.0a+stable-orig/html/ntpd.html ./ntpd.html
54c54
< <p>This version of NTP includes an intricate state machine to reduce
the network load while maintaining a quality of synchronization consistent with
the observed jitter and wander. There are a number of ways to tailor the
operation in order enhance accuracy by reducing the interval or to reduce
network overhead by increasing it. However, the user is advised to carefully
consider the consequences of changing the poll adjustment range from the
default minimum of 64 s to the default maximum of 1,024 s. The default minimum
can be changed with the <tt>tinker minpoll</tt> command to a value not less
than 16 s. This value is used for all configured associations, unless overriden
by the <tt>minpoll</tt> option on the configuration command. Note that most
device drivers will not operate properly if the poll interval is less than 64 s
and that the broadcast server and manycast client associations will also use
the default, unless overriden.</p>
---
> <p>This version of NTP includes an intricate state machine to reduce
> the network load while maintaining a quality of synchronization consistent
> with the observed jitter and wander. There are a number of ways to tailor the
> operation in order enhance accuracy by reducing the interval or to reduce
> network overhead by increasing it. However, the user is advised to carefully
> consider the consequences of changing the poll adjustment range from the
> default minimum of 64 s to the default maximum of 1,024 s. The default
> minimum can be changed with the <tt>tinker minpoll</tt> command to a value
> not less than 16 s. This value is used for all configured associations,
> unless overridden by the <tt>minpoll</tt> option on the configuration
> command. Note that most device drivers will not operate properly if the poll
> interval is less than 64 s and that the broadcast server and manycast client
> associations will also use the default, unless overridden.</p>
diff -r ../../ntp-4.2.0a+stable-orig/html/ntpdc.html ./ntpdc.html
67c67
< <dt><tt>timeout <i>millseconds</i></tt>
---
> <dt><tt>timeout <i>milliseconds</i></tt>
94c94
< <p>The <tt>stability</tt> is the residual frequency error
remaining afterthe system frequency correction is applied and is intended for
maintenance and debugging. In most architectures, this value will initially
decrease from as high as 500 ppm to a nominal value in the range .01 to 0.1
ppm. If it remains high for some time after starting the daemon, something may
be wrong with the local clock, or the value of the kernel variable
<tt>tick</tt> may be incorrect.</p>
---
> <p>The <tt>stability</tt> is the residual frequency error
> remaining after the system frequency correction is applied and is intended
> for maintenance and debugging. In most architectures, this value will
> initially decrease from as high as 500 ppm to a nominal value in the range
> .01 to 0.1 ppm. If it remains high for some time after starting the daemon,
> something may be wrong with the local clock, or the value of the kernel
> variable <tt>tick</tt> may be incorrect.</p>
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.29
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages ntp depends on:
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
ii libreadline4 4.3-11 GNU readline and history libraries
ii libssl0.9.7 0.9.7e-2 SSL shared libraries
ii perl-modules 5.8.4-6 Core Perl modules
ii psmisc 21.5-1 Utilities that use the proc filesy
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
