From: Harlan Stenn Date: Thu, 22 Oct 2009 09:02:37 +0000 (-0400) Subject: Cleanup from Dave Mills X-Git-Tag: NTP_4_2_5P236_RC~1 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=676fc01ee25acf0ba784e629824e7e350c859e6b;p=thirdparty%2Fntp.git Cleanup from Dave Mills bk: 4ae01fadV_p6SGIs4HZaHlXPGAtPPw --- diff --git a/ChangeLog b/ChangeLog index bd006cac2..ae367bd19 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,4 @@ +* Cleanup from Dave Mills. * [Bug 1343] ntpd/ntp_io.c close_fd() does not compile on Solaris 7. * [Bug 1353] ntpq "rv 0 settimeofday" always shows UNKNOWN on unix. * Do not attempt to execute built binaries from ntpd/Makefile when diff --git a/html/authopt.html b/html/authopt.html index d39dbe53a..788592dc6 100644 --- a/html/authopt.html +++ b/html/authopt.html @@ -23,7 +23,7 @@

Our resident cryptographer; now you see him, now you don't.

Last update: - 29-Sep-2009 13:34 + 16-Oct-2009 15:14 UTC


@@ -59,7 +59,11 @@ UTC

While the algorithms for symmetric key cryptography are included in the NTPv4 software distribution, Autokey cryptography requires the OpenSSL software library to be installed before building the NTP distribution. This library is available from http://www.openssl.org and can be installed using the procedures outlined in the Building and Installing the Distribution page. Once installed, the configure and build process automatically detects the library and links the library routines required.

-

Note that according to US law, NTP binaries including OpenSSL library components, nothwithstanding the OpenSSL library itself, cannot be exported outside the US without license from the US Department of Commmerce. Builders outside the US are advised to obtain the OpenSSL library directly from OpenSSL, which is outside the US, and build outside the US.

+

Note that according to US law, NTP binaries including OpenSSL library components, + notwithstanding the OpenSSL library itself, cannot be exported outside the + US without license from the US Department of Commerce. Builders outside the + US are advised to obtain the OpenSSL library directly from OpenSSL, which is + outside the US, and build outside the US.

Authentication is configured separately for each association using the key or autokey option of the server configuration command, as described in the Server Options page, and the options described on this page. The ntp-keygen page describes the files required for the various authentication schemes. Further details are in the briefings, papers and reports at the NTP project page linked from www.ntp.org.

@@ -90,7 +94,14 @@ UTC

NTP Secure Groups

-

NTP secure groups are used to define cryptographic compartments and security hierarchies. All hosts belonging to a secure group have the same group name but different host names. The string specified in the host option of the crypto command is the name of the host and the name used in the host key, sign key and certificate files. The string specified in the ident option of the crypto comand is the group name of all group hosts and the name used in the identity files. The file naming conventions are described on the ntp-keygen page.

+

NTP secure groups are used to define cryptographic compartments and security + hierarchies. All hosts belonging to a secure group have the same group name + but different host names. The string specified in the host option of + the crypto command is the name of the host and the name used in the + host key, sign key and certificate files. The string specified in the ident option + of the crypto command is the group name of all group hosts and the + name used in the identity files. The file naming conventions are described on + the ntp-keygen page.

Each group includes one or more trusted hosts (THs) operating at the root, or lowest stratum in the group. The group name is used in the subject and issuer fields of the TH self-signed trusted certificate for these hosts. The host name is used in the subject and issuer fields of the self-signed certificates for all other hosts.

@@ -102,7 +113,12 @@ UTC

All configurations include a public/private host key pair and matching certificate. Absent an identity scheme, this is a Trusted Certificate (TC) scheme. There are three identity schemes, IFF, GQ and MV described on the Identity Schemes page. With these schemes all servers in the group have encrypted server identity keys, while clients have nonencrypted client identity parameters. The client parameters can be obtained from a trusted agent (TA), usually one of the THs of the lower stratum group. Further information on identity schemes is on the Autokey Identity Schemes page.

-

A specific combination of authentication and identity schemes is called a cryptotype, which applies to clients and servers separately. A group can be configured using more than one cryptotype combination, although not all combinations are interoperable. Note however that some cryptotype combinations may successfully interoperate with each other, but may not represent good security practice. The server and client cryptotypes are defined by the the following codes.

+

A specific combination of authentication and identity schemes is called a + cryptotype, which applies to clients and servers separately. A group can be + configured using more than one cryptotype combination, although not all combinations + are interoperable. Note however that some cryptotype combinations may successfully + intemperate with each other, but may not represent good security practice. The + server and client cryptotypes are defined by the the following codes.

NONE
@@ -192,9 +208,19 @@ UTC

Autokey has an intimidating number of configuration options, most of which are not necessary in typical scenarios. The simplest scenario consists of a TH where the host name of the TH is also the name of the group. For the simplest identity scheme TC, the TH generates host key and trusted certificate files using the ntp-keygen -T command, while the remaining group hosts use the same command with no options to generate the host key and public certificate files. All hosts use the crypto configuration command with no options. Configuration with passwords is described in the ntp-keygen page. All group hosts are configured as an acyclic tree with root the TH.

-

When an identity scheme is included, for example IFF, the TH generates host key, trusted certificate and private server identity ley files using the ntp-keygen -T -I -i group command, where group is the group name. The remaining group hosts use the same command as above. All hosts use the crypto identgroup configuration command.

+

When an identity scheme is included, for example IFF, the TH generates host + key, trusted certificate and private server identity key files using the ntp-keygen + -T -I -i group command, where group is the group + name. The remaining group hosts use the same command as above. All hosts + use the crypto ident group configuration command.

-

Hosts with no dependent clients can retrieve client parameter files from an archive or web page. The ntp-keygen can export these data using the -e option. Hosts with dependent clients other than the TH must retrieve copies of the server ley files using secure means. The ntp-keygen can export these data using the -q option. In either case the data are installed as a file and then renamed using the name given as the first line in the file, but without the filestamp.

+

Hosts with no dependent clients can retrieve client parameter files from an + archive or web page. The ntp-keygen can export these data using the -e option. + Hosts with dependent clients other than the TH must retrieve copies of the server + key files using secure means. The ntp-keygen can export these data + using the -q option. In either case the data are installed as a file + and then renamed using the name given as the first line in the file, but without + the filestamp.

Examples

@@ -239,7 +265,9 @@ UTC

ntp-keygen -p yyy -e >ntpkey_gqpar_green
ntp-keygen -p yyy -q zzz >zzz_ntpkey_gqkey_green

-

The first two lines serve the same purpose as the preceeding examples. The third line generats a copy of the private GREEN server file for use on another server in the same group, say YELLOWm but encrypted with the zzz pasword.

+

The first two lines serve the same purpose as the preceding examples. The + third line generates a copy of the private GREEN server file for use on another + server in the same group, say YELLOW, but encrypted with the zzz password.

A client of GREEN, for example YELLOW, uses the configuration commands

@@ -265,7 +293,12 @@ UTC

Specifies the key ID to use with the ntpq utility, which uses the standard protocol defined in RFC-1305. The key argument is the key ID for a trusted key, where the value can be in the range 1 to 65,534, inclusive.
crypto [randfile file] [host name] [ident name] [pw password]
-
This command requires the OpenSSL library. It activates public key cryptography and loads the required host key and public certificat. If one or more files are left unspecified, the default names are used as described below. Unless the complete path and name of the file are specified, the location of a file is relative to the keys directory specified in the keysdir configuration command or default /usr/local/etc. Following are the options.
+
This command requires the OpenSSL library. It activates public key cryptography + and loads the required host key and public certificate. If one or more files + are left unspecified, the default names are used as described below. Unless + the complete path and name of the file are specified, the location of a file + is relative to the keys directory specified in the keysdir configuration + command or default /usr/local/etc. Following are the options.
diff --git a/html/ntpq.html b/html/ntpq.html index 542d19a8f..7ebd6baf0 100644 --- a/html/ntpq.html +++ b/html/ntpq.html @@ -14,7 +14,7 @@ giffrom Pogo, Walt Kelly

A typical NTP monitoring packet

Last update: - 15-Oct-2009 1:09 + 16-Oct-2009 19:51 UTC


More Help

@@ -205,16 +205,17 @@
readvar assocID name [ = value ] [,...]
rv assocID [ name ] [,...]
-
Display the specified variables. If assocID is zero, the variables - are from the system variables name space, otherwise - they are from the peer variables name space. The assocID is - required, as the same name can occur in both spaces. If no name is +
Display the specified variables. If assocID is zero, the + variables are from the system variables name space, + otherwise they are from the peer variables name space. + The assocID is required, as the same name can occur in both spaces. If no name is included, all operative variables in the name space are displayed. - Multiple names are specified with comma separators and without whitespace. + In this case only, if the assocID is omitted, it is assumed zero. Multiple + names are specified with comma separators and without whitespace. Note that time values are represented in milliseconds and frequency - values in parts-per-million (PPM). Some NTP timestamps are represented in - the format YYYYMMDDTTTT, where YYYY is the year, MM the month of year, DD - the day of month and TTTT the time of day.
+ values in parts-per-million (PPM). Some NTP timestamps are represented + in the format YYYYMMDDTTTT, where YYYY is the year, MM the month + of year, DD the day of month and TTTT the time of day.
saveconfig filename
Write the current configuration, including any runtime modifications given with :config or config-from-file, to the ntpd host's file filename. This command will be rejected by the server unless saveconfigdir appears in the ntpd configuration file. filename can use strftime() format specifiers to substitute the current date and time, for example, saveconfig ntp-%Y%m%d-%H%M%S.conf. The filename used is stored in system variable savedconfig. Authentication is required.
writevar assocID name = value [,...]
diff --git a/ntpd/ntp_loopfilter.c b/ntpd/ntp_loopfilter.c index ad1c8c639..1d9259567 100644 --- a/ntpd/ntp_loopfilter.c +++ b/ntpd/ntp_loopfilter.c @@ -154,7 +154,7 @@ int state; /* clock discipline state */ u_char sys_poll; /* time constant/poll (log2 s) */ int tc_counter; /* jiggle counter */ double last_offset; /* last offset (s) */ -static int clock_stepcnt; /* step counter */ +static u_long last_step; /* last clock step */ /* * Huff-n'-puff filter variables @@ -389,12 +389,12 @@ local_clock( tc_counter = 0; clock_jitter = LOGTOD(sys_precision); rval = 2; - clock_stepcnt++; - if (state == EVNT_NSET || clock_stepcnt > 2) { - clock_stepcnt = 0; + if (state == EVNT_NSET || (current_time - + last_step) < clock_minstep * 2) { rstclock(EVNT_FREQ, 0); return (rval); } + last_step = current_time; break; } rstclock(EVNT_SYNC, 0); @@ -410,7 +410,6 @@ local_clock( LOGTOD(sys_precision))); clock_jitter = SQRT(etemp + (dtemp - etemp) / CLOCK_AVG); - clock_stepcnt = 0; switch (state) { /*