83 lines
11 KiB
HTML
83 lines
11 KiB
HTML
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||
|
|
|
||
|
|
<html>
|
||
|
|
|
||
|
|
<head>
|
||
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org">
|
||
|
|
<title>Building and Installing the Distribution</title>
|
||
|
|
<link href="scripts/style.css" type="text/css" rel="stylesheet">
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<body>
|
||
|
|
<h3>Building and Installing the Distribution</h3>
|
||
|
|
<img src="pic/beaver.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
|
||
|
|
<p>For putting out compiler fires.</p>
|
||
|
|
<p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="99">03:06 AM</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="270">Monday, October 13, 2003</csobj></p>
|
||
|
|
<br clear="left">
|
||
|
|
<h4>Related Links</h4>
|
||
|
|
<script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
|
||
|
|
<h4>Table of Contents</h4>
|
||
|
|
<ul>
|
||
|
|
<li class="inline"><a href="#build">Building and Installing the Distribution</a>
|
||
|
|
<li class="inline"><a href="#unix">Building and Installing under Unix</a>
|
||
|
|
<li class="inline"><a href="#comp">Compilation</a>
|
||
|
|
<li class="inline"><a href="#install">Installation</a>
|
||
|
|
<li class="inline"><a href="#config">Configuration</a>
|
||
|
|
<li class="inline"><a href="#prob">If You Have Problems</a>
|
||
|
|
<li class="inline"><a href="#win">Building and Installing under Windows NT</a>
|
||
|
|
</ul>
|
||
|
|
<hr>
|
||
|
|
<h4 id="build">Building and Installing the Distribution</h4>
|
||
|
|
<p>As a practical matter, every computer architecture and operating system version seems to be different than any other. The device drivers may be different, the input/output system may be idiosyncratic and the libraries may have different semantics. It is not possible in a software distribution such as this one to support every individual system with a common set of binaries, even with the same system but different versions. Therefore, it is necessary to individually configure the software build for each system and version, both at compile time and at run time. In almost all cases, these procedures are completely automatic and all the newbie user need do is type "configure", "make" and "install" in that order and the autoconfigure system does the rest. There are some exceptions, as noted below and on the <a href="hints.html">Hints and Kinks</a> page.</p>
|
||
|
|
<p>If available, the OpenSSL library from <a href="http://www.openssl.org">http://www.openssl.org</a> is used to support public key cryptography. The library must be built and installed prior to building NTPv4. The procedures for doing that are included in the OpenSSL documentation. The library is found during the normal NTPv4 configure phase and the interface routines compiled automatically. Only the <tt>libcrypto.a</tt> library and associated header files are used. If the library is not available or disabled, this step is not required.</p>
|
||
|
|
<h4 id="unix">Building and Installing under Unix</h4>
|
||
|
|
<p>Make sure that you have all necessary tools for building executables. These tools include <tt>cc/gcc, make, awk, sed, tr, sh, grep, egrep</tt> and a few others. Not all of these tools exist in the standard distribution of modern Unix versions (compilers are likely to be an add-on product). If this is the case, consider using the GNU tools and <tt>gcc</tt> compiler. For a successful build, all of these tools should be accessible via the current path.</p>
|
||
|
|
<p>The first thing to do is uncompress the distribution and extract the source tree. In the distribution base directory use the <tt>./configure</tt> command to perform an automatic configuration procedure. This command inspects the hardware and software environment and tests for the presence of system header files and the contents of these files to determine if certain features are present. When one or more of these features are present, the code is compiled to use them; if not, no special code is compiled. However, even if the code is compiled to use these features, the code does a special test at run time to see if one or more are actually present and avoids using them if not present. In such cases a warning message is sent to the system log, but the daemon should still work properly.</p>
|
||
|
|
<p>The default build normally includes the debugging code, which can be useful in diagnosing problems found in initial test, and all reference clock drivers known to work with each machine and operating system. Unless memory space is at a premium, this is a sensible strategy and greatly simplifies debugging and support. If you need to delete either the debugging code or one or all reference clock drivers to save space, see the <a href="config.html">Configuration Options</a> page.</p>
|
||
|
|
<p>If your site supports multiple architectures and uses NFS to share files, you can use a single source tree to compile executables for all architectures. While running on a target architecture machine and in the distribution base directory create a subdirectory using a command like <tt>mkdir A.`config.guess`</tt>, which will create an architecture-specific directory with name peculiar to the architecture and operating system. Then change to this directory and emit a <tt>../configure</tt> command. The remaining steps are the same whether building in the base directory or in the subdirectory.</p>
|
||
|
|
<h4 id="comp">Compilation</h4>
|
||
|
|
<p>Use the <tt>make</tt> command to compile all source modules, construct the libraries and link the distribution. Expect few or no warnings using <tt>cc</tt> and a moderate level of warnings using <tt>gcc</tt>. Note: On some Unix platforms <tt>gcc</tt> may show quite a few complaints about system header files and type inconsistencies, especially with pointer variables. This is usually the case when the system header files are not up to ANSI standards or <tt>gcc </tt>expectations, when <tt>gcc</tt> is not installed properly, or when operating system updates and patches are applied and <tt>gcc</tt> is not reinstalled. While the autoconfigure process is quite thorough, the Unix programming cultures of the various workstation makers still remain idiosyncratic.</p>
|
||
|
|
<h4 id="install">Installation</h4>
|
||
|
|
<p>As root, use the <tt>make install</tt> command to install the binaries in the destination directory. Most commonly, these programs are installed in <tt>/usr/local/bin</tt>, but this can be overridden during configuration. You must of course have write permission on the install in the destination directory. This includes the following programs:</p>
|
||
|
|
<ul>
|
||
|
|
<li><a href="ntpd.html"><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a>
|
||
|
|
<li><a href="ntpq.html"><tt>ntpq</tt> - standard NTP query program</a>
|
||
|
|
<li><a href="ntpdc.html"><tt>ntpdc</tt> - special NTP query program</a>
|
||
|
|
<li><a href="ntpdate.html"><tt>ntpdate</tt> - set the date and time via NTP</a>
|
||
|
|
<li><a href="ntptrace.html"><tt>ntptrace</tt> - trace a chain of NTP servers back to the primary source</a>
|
||
|
|
</ul>
|
||
|
|
<p>If the precision time kernel modifications are present, the following program is installed:</p>
|
||
|
|
<ul>
|
||
|
|
<li><a href="ntptime.html"><tt>ntptime</tt> - read kernel time variables</a>
|
||
|
|
</ul>
|
||
|
|
<p>If the public key authentication functions are present, the following program is installed:</p>
|
||
|
|
<ul>
|
||
|
|
<li><a href="keygen.html"><tt>ntp-keygen</tt> - generate public and private keys</a>
|
||
|
|
</ul>
|
||
|
|
<p>In some systems that include the capability to edit kernel variables, the following program is installed:</p>
|
||
|
|
<ul>
|
||
|
|
<li><a href="tickadj.html"><tt>tickadj</tt> - set time-related kernel variables</a>
|
||
|
|
</ul>
|
||
|
|
<p>Cryptographic support, both symmetric and public key, requires one or more key files, commonly installed in <tt>/usr/local/etc</tt>. Public key cryptography requires a random seed file, usually called <tt>.rnd</tt>, installed in a dark place such as the root directory or <tt>/etc</tt>. Directions for generating keys is on the <a href="authopt.html">Authentication Options</a> page.</p>
|
||
|
|
<h4 id="config">Configuration</h4>
|
||
|
|
<p>You are now ready to configure the daemon and start it. You will need to create a NTP configuration file <tt>ntp.conf</tt> and a cryptographic key file <tt>ntp.keys</tt>. The latter file is necessary only for remote configuration support, if needed. Newbies should see the <a href="quick.html">Quick Start</a> page for orientation. Seasoned veterans can start with the <a href="ntpd.html"><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a> page and move on to the specific configuration option pages from there. A tutorial on NTP subnet design and configuration options is in the <a href="notes.html">Notes on Configuring NTP and Setting up a NTP Subnet</a> page.</p>
|
||
|
|
<h4 id="prob">If You Have Problems</h4>
|
||
|
|
<p>If you have problems peculiar to the particular hardware and software environment (e.g. operating system-specific issues), browse the <a href="hints.html">Hints and Kinks</a> page. For other problems a tutorial on debugging technique is in the <a href="debug.html">NTP Debugging Technique</a> page. As always, the first line of general assistance is the NTP web site <a href="http://www.ntp.org">www.ntp.org</a> and the FAQ resident there. Requests for assistance of a general nature and of interest to other timekeepers should be sent to the NTP newsgroup comp.protocols.time.ntp. Bug reports of a specific nature should be sent to <a href="mailto:bugs@mail.ntp.org">bugs@ntp.org</a>. Bug reports of a specific nature on features implemented by the programmer corps mentioned in the <a href="copyright.html">Copyright</a> page should be sent directly to the implementor listed in that page, with copy to bugs@ntp.org.</p>
|
||
|
|
<p>Please include the version of the source distribution (e.g., ntp-4.0.70a) in your bug report, as well as billboards from the relevant utility programs and debug trace, if available. Please include the output of <tt>config.guess</tt> in your bug report. It will look something like:</p>
|
||
|
|
<p><tt>pdp11-dec-fuzzos3.4</tt></p>
|
||
|
|
<h4>Additional <tt>make</tt> commands</h4>
|
||
|
|
<dl>
|
||
|
|
<dt><tt>make clean</tt>
|
||
|
|
<dd>Cleans out object files, programs and temporary files.
|
||
|
|
<dt><tt>make distclean</tt>
|
||
|
|
<dd>Does the work of <tt>clean</tt>, but cleans out all directories in preparation for a new distribution release.
|
||
|
|
<dt><tt>make dist</tt>
|
||
|
|
<dd>Does the work of <tt>make distclean</tt>, but constructs compressed tar files for distribution. You must have GNU automake to perform this function.
|
||
|
|
</dl>
|
||
|
|
<h4 id="win">Building and Installing under Windows NT</h4>
|
||
|
|
<p>See <tt><a href="hints/winnt.html">hints/winnt.htm</a></tt> for directions to compile the sources and install the executables.</p>
|
||
|
|
<hr>
|
||
|
|
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
|
||
|
|
</body>
|
||
|
|
|
||
|
|
</html>
|