diff -up ntp-4.2.2p1/html/keygen.html.htmldocloc ntp-4.2.2p1/html/keygen.html
--- ntp-4.2.2p1/html/keygen.html.htmldocloc	2008-01-17 18:23:31.000000000 +0100
+++ ntp-4.2.2p1/html/keygen.html	2008-01-17 18:23:31.000000000 +0100
@@ -38,11 +38,11 @@
 		<p>By default, files are not encrypted by <tt>ntp-keygen</tt>. The <tt>-p <i>password</i></tt> option specifies the write password and <tt>-q <i>password</i></tt> option the read password for previously encrypted files. The <tt>ntp-keygen</tt> program prompts for the password if it reads an encrypted file and the password is missing or incorrect. If an encrypted file is read successfully and no write password is specified, the read password is used as the write password by default.</p>
 		<p>The <tt>ntpd</tt> configuration command <tt>crypto pw <i>password</i></tt> specifies the read password for previously encrypted files. The daemon expires on the spot if the password is missing or incorrect. For convenience, if a file has been previously encrypted, the default read password is the name of the host running the program. If the previous write password is specified as the host name, these files can be read by that host with no explicit password.</p>
 		<p>All files are in PEM-encoded printable ASCII format, so they can be embedded as MIME attachments in mail to other sites and certificate authorities. File names begin with the prefix <tt>ntpkey_</tt> and end with the postfix <tt><i>_hostname.filestamp</i></tt>, where <tt><i>hostname</i></tt> is usually the string returned by the Unix <tt>gethostname()</tt> routine, and <tt><i>filestamp</i></tt> is the NTP seconds when the file was generated, in decimal digits. This both guarantees uniqueness and simplifies maintenance procedures, since all files can be quickly removed by a <tt>rm ntpkey*</tt> command or all files generated at a specific time can be removed by a <tt>rm *<i>filestamp</i></tt> command. To further reduce the risk of misconfiguration, the first two lines of a file contain the file name and generation date and time as comments.</p>
-		<p>All files are installed by default in the keys directory <tt>/usr/local/etc</tt>, which is normally in a shared filesystem in NFS-mounted networks. The actual location of the keys directory and each file can be overridden by configuration commands, but this is not recommended. Normally, the files for each host are generated by that host and used only by that host, although exceptions exist as noted later on this page.</p>
+		<p>All files are installed by default in the keys directory <tt>/etc/ntp</tt>. The actual location of the keys directory and each file can be overridden by configuration commands, but this is not recommended. Normally, the files for each host are generated by that host and used only by that host, although exceptions exist as noted later on this page.</p>
 		<p>Normally, files containing private values, including the host key, sign key and identification parameters, are permitted root read/write-only; while others containing public values are permitted world readable. Alternatively, files containing private values can be encrypted and these files permitted world readable, which simplifies maintenance in shared file systems. Since uniqueness is insured by the hostname and file name extensions, the files for a NFS server and dependent clients can all be installed in the same shared directory.</p>
 		<p>The recommended practice is to keep the file name extensions when installing a file and to install a soft link from the generic names specified elsewhere on this page to the generated files. This allows new file generations to be activated simply by changing the link. If a link is present, <tt>ntpd</tt> follows it to the file name to extract the filestamp. If a link is not present, <tt>ntpd</tt> extracts the filestamp from the file itself. This allows clients to verify that the file and generation times are always current. The <tt>ntp-keygen</tt> program uses the same extension for all files generated at one time, so each generation is distinct and can be readily recognized in monitoring data.</p>
 		<h4 id="run">Running the program</h4>
-		<p>The safest way to run the <tt>ntp-keygen</tt> program is logged in directly as root. The recommended procedure is change to the keys directory, usually <tt>/ust/local/etc</tt>, then run the program. When run for the first time, or if all <tt>ntpkey</tt> files have been removed, the program generates a RSA host key file and matching RSA-MD5 certificate file, which is all that is necessary in many cases. The program also generates soft links from the generic names to the respective files. If run again, the program uses the same host key file, but generates a new certificate file and link.</p>
+		<p>The safest way to run the <tt>ntp-keygen</tt> program is logged in directly as root. The recommended procedure is change to the keys directory, usually <tt>/etc/ntp</tt>, then run the program. When run for the first time, or if all <tt>ntpkey</tt> files have been removed, the program generates a RSA host key file and matching RSA-MD5 certificate file, which is all that is necessary in many cases. The program also generates soft links from the generic names to the respective files. If run again, the program uses the same host key file, but generates a new certificate file and link.</p>
 		<p>The host key is used to encrypt the cookie when required and so must be RSA type. By default, the host key is also the sign key used to encrypt signatures. When necessary, a different sign key can be specified and this can be either RSA or DSA type. By default, the message digest type is MD5, but any combination of sign key type and message digest type supported by the OpenSSL library can be specified, including those using the MD2, MD5, SHA, SHA1, MDC2 and RIPE160 message digest algorithms. However, the scheme specified in the certificate must be compatible with the sign key. Certificates using any digest algorithm are compatible with RSA sign keys; however, only SHA and SHA1 certificates are compatible with DSA sign keys.</p>
 		<p>Private/public key files and certificates are compatible with other OpenSSL applications and very likely other libraries as well. Certificates or certificate requests derived from them should be compatible with extant industry practice, although some users might find the interpretation of X509v3 extension fields somewhat liberal. However, the identification parameter files, although encoded as the other files, are probably not compatible with anything other than Autokey.</p>
 		<p>Running the program as other than root and using the Unix <tt>su</tt> command to assume root may not work properly, since by default the OpenSSL library looks for the random seed file <tt>.rnd</tt> in the user home directory. However, there should be only one <tt>.rnd</tt>, most conveniently in the root directory, so it is convenient to define the <tt>$RANDFILE</tt> environment variable used by the OpenSSL library as the path to <tt>/.rnd</tt>.</p>
diff -up ntp-4.2.2p1/html/ntpd.html.htmldocloc ntp-4.2.2p1/html/ntpd.html
--- ntp-4.2.2p1/html/ntpd.html.htmldocloc	2008-01-17 18:23:31.000000000 +0100
+++ ntp-4.2.2p1/html/ntpd.html	2008-01-17 18:23:31.000000000 +0100
@@ -63,7 +63,7 @@
 		<p>In contexts where a host name is expected, a <tt>-4</tt> qualifier preceding the host name forces DNS resolution to the IPv4 namespace, while a <tt>-6</tt> qualifier forces DNS resolution to the IPv6 namespace.</p>
 		<p>Various internal <tt>ntpd</tt> variables can be displayed and configuration options altered while the <tt>ntpd</tt> is running using the <tt><a href="ntpq.html">ntpq</a></tt> and <tt><a href="ntpdc.html">ntpdc</a></tt> utility programs.</p>
 		<p>When <tt>ntpd</tt> starts it looks at the value of <tt>umask</tt>, and if zero <tt>ntpd</tt> will set the <tt>umask</tt> to <tt>022</tt>.</p>
-		<p>Unless the <tt>-n</tt> or <tt>-d</tt> option is used, <tt>ntpd</tt> changes the current working directory to the root, so options specifing paths need to use absolute path or path relative to the root.</p>
+		<p>Unless the <tt>-n</tt> or <tt>-d</tt> option is used, <tt>ntpd</tt> changes the current working directory to the root directory, so any options or commands specifying paths need to use an absolute path or a path relative to the root.</p>
 		<h4 id="cmd">Command Line Options</h4>
 		<dl>
 			<dt><tt>-4</tt>
@@ -181,6 +181,9 @@
 				<td width="20%"><tt>keysdir</tt></td>
 			</tr>
 		</table>
+		<h4 id="codes">Exit Codes</h4>
+		<p>A non-zero exit code indicates an error. Any error messages are logged to the system log by default.</p>
+		<p>The exit code is 0 only when <tt>ntpd</tt> is terminated by a signal, or when the <tt>-q</tt> option is used and <tt>ntpd</tt> successfully sets the system clock.</p>
 		<hr>
 		<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
 	</body>
diff -up ntp-4.2.2p1/html/authopt.html.htmldocloc ntp-4.2.2p1/html/authopt.html
--- ntp-4.2.2p1/html/authopt.html.htmldocloc	2006-06-26 13:02:10.000000000 +0200
+++ ntp-4.2.2p1/html/authopt.html	2008-01-17 18:23:31.000000000 +0100
@@ -74,7 +74,7 @@
 			<dt><tt>controlkey <i>key</i></tt>
 			<dd>Specifies the key identifier to use with the <a href="ntpq.html"><tt>ntpq</tt></a> utility, which uses the standard protocol defined in RFC-1305. The <tt><i>key</i></tt> argument is the key identifier for a trusted key, where the value can be in the range 1 to 65,534, inclusive.
 			<dt><tt>crypto [cert <i>file</i>] [leap <i>file</i>] [randfile <i>file</i>] [host <i>file</i>] [sign <i>file</i>] [ident <i>scheme</i>] [iffpar <i>file</i>] [gqpar <i>file</i>] [mvpar <i>file</i>] [pw <i>password</i>]</tt>
-			<dd>This command requires the OpenSSL library. It activates public key cryptography, selects the message digest and signature encryption scheme and loads the required private and public values described above. If one or more files are left unspecified, the default names are used as described above. 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 <tt>keysdir</tt> command or default <tt>/usr/local/etc</tt>. Following are the subcommands:
+			<dd>This command requires the OpenSSL library. It activates public key cryptography, selects the message digest and signature encryption scheme and loads the required private and public values described above. If one or more files are left unspecified, the default names are used as described above. 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 <tt>keysdir</tt> command or default <tt>/etc/ntp</tt>. Following are the subcommands:
 				<dl>
 					<dt><tt>cert <i>file</i></tt>
 					<dd>Specifies the location of the required host public certificate file. This overrides the link <tt>ntpkey_cert_<i>hostname</i></tt> in the keys directory.
@@ -103,7 +103,7 @@
 			<dt><tt>keys <i>keyfile</i></tt>
 			<dd>Specifies the complete path and location of the MD5 key file containing the keys and key identifiers used by <tt>ntpd</tt>, <tt>ntpq</tt> and <tt>ntpdc</tt> when operating with symmetric key cryptography. This is the same operation as the <tt>-k </tt>command line option.
 			<dt><tt>keysdir <i>path</i></tt>
-			<dd>This command specifies the default directory path for cryptographic keys, parameters and certificates. The default is <tt>/usr/local/etc/</tt>.
+			<dd>This command specifies the default directory path for cryptographic keys, parameters and certificates. The default is <tt>/etc/ntp</tt>.
 			<dt><tt>requestkey <i>key</i></tt>
 			<dd>Specifies the key identifier to use with the <a href="ntpdc.html"><tt>ntpdc</tt></a> utility program, which uses a proprietary protocol specific to this implementation of <tt>ntpd</tt>. The <tt><i>key</i></tt> argument is a key identifier for the trusted key, where the value can be in the range 1 to 65,534, inclusive.
 			<dt><tt>revoke [<i>logsec</i>]</tt>
@@ -152,4 +152,4 @@
 		<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
 	</body>
 
-</html>
\ No newline at end of file
+</html>
diff -up ntp-4.2.2p1/html/ntpdate.html.htmldocloc ntp-4.2.2p1/html/ntpdate.html
--- ntp-4.2.2p1/html/ntpdate.html.htmldocloc	2008-01-17 18:23:31.000000000 +0100
+++ ntp-4.2.2p1/html/ntpdate.html	2008-01-17 18:23:31.000000000 +0100
@@ -43,7 +43,7 @@
 			<dt><tt>-e <i>authdelay</i></tt>
 			<dd>Specify the processing delay to perform an authentication function as the value <i>authdelay</i>, in seconds and fraction (see <tt>ntpd</tt> for details). This number is usually small enough to be negligible for most purposes, though specifying a value may improve timekeeping on very slow CPU's.
 			<dt><tt>-k <i>keyfile</i></tt>
-			<dd>Specify the path for the authentication key file as the string <i>keyfile</i>. The default is <tt>/etc/ntp.keys</tt>. This file should be in the format described in <tt>ntpd</tt>.
+			<dd>Specify the path for the authentication key file as the string <i>keyfile</i>. The default is <tt>/etc/ntp/keys</tt>. This file should be in the format described in <tt>ntpd</tt>.
 			<dt><tt>-o <i>version</i></tt>
 			<dd>Specify the NTP version for outgoing packets as the integer <i>version</i>, which can be 1 or 2. The default is 4. This allows <tt>ntpdate</tt> to be used with older NTP versions.
 			<dt><tt>-p <i>samples</i></tt>
@@ -65,7 +65,7 @@
 			<i>server_user</i>.
 		</dl>
 		<h4>Files</h4>
-		<tt>/etc/ntp.keys</tt> - encryption keys used by <tt>ntpdate</tt>.
+		<tt>/etc/ntp/keys</tt> - encryption keys used by <tt>ntpdate</tt>.
 		<h4>Bugs</h4>
 		The slew adjustment is actually 50% larger than the measured offset, since this (it is argued) will tend to keep a badly drifting clock more accurate. This is probably not a good idea and may cause a troubling hunt for some values of the kernel variables <tt>tick</tt> and <tt>tickadj</tt>.&nbsp;
 		<hr>