[src/trunk]: src/external/bsd/ntp/bin PR/55710: Kimmo Suominen: Delete manual...

[christos <christos%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/e3e3c9222c49
branches:  trunk
changeset: 955750:e3e3c9222c49
user:      christos <christos%NetBSD.org@localhost>
date:      Sat Oct 10 14:25:21 2020 +0000

description:
PR/55710: Kimmo Suominen: Delete manual pages so that they get copy from the
imported, already generated ones.

diffstat:

 external/bsd/ntp/bin/ntp-keygen/ntp-keygen.8 |  1223 -----------
 external/bsd/ntp/bin/ntpd/ntp.conf.5         |  2814 --------------------------
 external/bsd/ntp/bin/ntpd/ntp.keys.5         |   170 -
 external/bsd/ntp/bin/ntpd/ntpd.8             |   908 --------
 external/bsd/ntp/bin/ntpdc/ntpdc.8           |   809 -------
 external/bsd/ntp/bin/ntpq/ntpq.8             |  1055 ---------
 external/bsd/ntp/bin/sntp/sntp.1             |   317 --
 7 files changed, 0 insertions(+), 7296 deletions(-)

diffs (truncated from 7324 to 300 lines):

diff -r 3d5eade353f3 -r e3e3c9222c49 external/bsd/ntp/bin/ntp-keygen/ntp-keygen.8
--- a/external/bsd/ntp/bin/ntp-keygen/ntp-keygen.8      Sat Oct 10 14:23:48 2020 +0000
+++ /dev/null   Thu Jan 01 00:00:00 1970 +0000
@@ -1,1223 +0,0 @@
-.Dd March 3 2020
-.Dt NTP_KEYGEN 8 User Commands
-.Os
-.\"  EDIT THIS FILE WITH CAUTION  (ntp-keygen-opts.mdoc)
-.\"
-.\"  It has been AutoGen-ed  March  3, 2020 at 05:41:30 PM by AutoGen 5.18.5
-.\"  From the definitions    ntp-keygen-opts.def
-.\"  and the template file   agmdoc-cmd.tpl
-.Sh NAME
-.Nm ntp-keygen
-.Nd Create a NTP host key
-.Sh SYNOPSIS
-.Nm
-.\" Mixture of short (flag) options and long options
-.Op Fl flags
-.Op Fl flag Op Ar value
-.Op Fl \-option\-name Ns Oo Oo Ns "=| " Oc Ns Ar value Oc
-.Pp
-All arguments must be options.
-.Pp
-.Sh DESCRIPTION
-This program generates cryptographic data files used by the NTPv4
-authentication and identification schemes.
-It can generate message digest keys used in symmetric key cryptography and,
-if the OpenSSL software library has been installed, it can generate host keys,
-signing keys, certificates, and identity keys and parameters used in Autokey
-public key cryptography.
-These files are used for cookie encryption,
-digital signature, and challenge/response identification algorithms
-compatible with the Internet standard security infrastructure.
-.Pp
-The message digest symmetric keys file is generated in a format
-compatible with NTPv3.
-All other files are in PEM\-encoded printable ASCII format,
-so they can be embedded as MIME attachments in email to other sites
-and certificate authorities.
-By default, files are not encrypted.
-.Pp
-When used to generate message digest symmetric keys, the program
-produces a file containing ten pseudo\-random printable ASCII strings
-suitable for the MD5 message digest algorithm included in the
-distribution.
-If the OpenSSL library is installed, it produces an additional ten
-hex\-encoded random bit strings suitable for SHA1, AES\-128\-CMAC, and
-other message digest algorithms.
-The message digest symmetric keys file must be distributed and stored
-using secure means beyond the scope of NTP itself.
-Besides the keys used for ordinary NTP associations, additional keys
-can be defined as passwords for the
-.Xr ntpq 8
-and
-.Xr ntpdc 8
-utility programs.
-.Pp
-The remaining generated files are compatible with other OpenSSL
-applications and other Public Key Infrastructure (PKI) resources.
-Certificates generated by this program are compatible with extant
-industry practice, although some users might find the interpretation of
-X509v3 extension fields somewhat liberal.
-However, the identity keys are probably not compatible with anything
-other than Autokey.
-.Pp
-Some files used by this program are encrypted using a private password.
-The
-.Fl p
-option specifies the read password for local encrypted files and the
-.Fl q
-option the write password for encrypted files sent to remote sites.
-If no password is specified, the host name returned by the Unix
-.Xr hostname 1
-command, normally the DNS name of the host, is used as the the default read
-password, for convenience.
-The
-.Nm
-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.
-.Pp
-The
-.Cm pw
-option of the
-.Ic crypto
-.Xr ntpd 8
-configuration command specifies the read
-password for previously encrypted local files.
-This must match the local read password used by this program.
-If not specified, the host name is used.
-Thus, if files are generated by this program without an explicit password,
-they can be read back by
-.Xr ntpd 8
-without specifying an explicit password but only on the same host.
-If the write password used for encryption is specified as the host name,
-these files can be read by that host with no explicit password.
-.Pp
-Normally, encrypted files for each host are generated by that host and
-used only by that host, although exceptions exist as noted later on
-this page.
-The symmetric keys file, normally called
-.Pa ntp.keys ,
-is usually installed in
-.Pa /etc .
-Other files and links are usually installed in
-.Pa /usr/local/etc ,
-which is normally in a shared filesystem in
-NFS\-mounted networks and cannot be changed by shared clients.
-In these cases, NFS clients can specify the files in another
-directory such as
-.Pa /etc
-using the
-.Ic keysdir
-.Xr ntpd 8
-configuration file command.
-.Pp
-This program directs commentary and error messages to the standard
-error stream
-.Pa stderr
-and remote files to the standard output stream
-.Pa stdout
-where they can be piped to other applications or redirected to files.
-The names used for generated files and links all begin with the
-string
-.Pa ntpkey\&*
-and include the file type, generating host and filestamp,
-as described in the
-.Sx "Cryptographic Data Files"
-section below.
-.Ss Running the Program
-The safest way to run the
-.Nm
-program is logged in directly as root.
-The recommended procedure is change to the
-.Ar keys
-directory, usually
-.Pa /usr/local/etc ,
-then run the program.
-.Pp
-To test and gain experience with Autokey concepts, log in as root and
-change to the
-.Ar keys
-directory, usually
-.Pa /usr/local/etc .
-When run for the first time, or if all files with names beginning with
-.Pa ntpkey\&*
-have been removed, use the
-.Nm
-command without arguments to generate a default
-.Cm RSA
-host key and matching
-.Cm RSA\-MD5
-certificate file with expiration date one year hence,
-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 without options, the program uses the
-existing keys and parameters and generates a new certificate file with
-new expiration date one year hence, and soft link.
-.Pp
-The host key is used to encrypt the cookie when required and so must be
-.Cm 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
-.Cm RSA
-or
-.Cm DSA
-type.
-By default, the message digest type is
-.Cm MD5 ,
-but any combination
-of sign key type and message digest type supported by the OpenSSL library
-can be specified, including those using the
-.Cm AES128CMAC , MD2 , MD5 , MDC2 , SHA , SHA1
-and
-.Cm 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
-.Cm RSA
-sign keys;
-however, only
-.Cm SHA
-and
-.Cm SHA1
-certificates are compatible with
-.Cm DSA
-sign keys.
-.Pp
-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.
-.Pp
-Running the program as other than root and using the Unix
-.Xr su 1
-command
-to assume root may not work properly, since by default the OpenSSL library
-looks for the random seed file
-.Pa .rnd
-in the user home directory.
-However, there should be only one
-.Pa .rnd ,
-most conveniently
-in the root directory, so it is convenient to define the
-.Ev RANDFILE
-environment variable used by the OpenSSL library as the path to
-.Pa .rnd .
-.Pp
-Installing the keys as root might not work in NFS\-mounted
-shared file systems, as NFS clients may not be able to write
-to the shared keys directory, even as root.
-In this case, NFS clients can specify the files in another
-directory such as
-.Pa /etc
-using the
-.Ic keysdir
-.Xr ntpd 8
-configuration file command.
-There is no need for one client to read the keys and certificates
-of other clients or servers, as these data are obtained automatically
-by the Autokey protocol.
-.Pp
-Ordinarily, cryptographic files are generated by the host that uses them,
-but it is possible for a trusted agent (TA) to generate these files
-for other hosts; however, in such cases files should always be encrypted.
-The subject name and trusted name default to the hostname
-of the host generating the files, but can be changed by command line options.
-It is convenient to designate the owner name and trusted name
-as the subject and issuer fields, respectively, of the certificate.
-The owner name is also used for the host and sign key files,
-while the trusted name is used for the identity files.
-.Pp
-All files are installed by default in the keys directory
-.Pa /usr/local/etc ,
-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.
-.Pp
-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
-.Ar hostname
-and
-.Ar filestamp
-file name extensions, the files for an NTP server and
-dependent clients can all be installed in the same shared directory.
-.Pp
-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,
-.Xr ntpd 8
-follows it to the file name to extract the
-.Ar filestamp .
-If a link is not present,
-.Xr ntpd 8
-extracts the
-.Ar filestamp
-from the file itself.
-This allows clients to verify that the file and generation times
-are always current.
-The
-.Nm
-program uses the same
-.Ar filestamp
-extension for all files generated
-at one time, so each generation is distinct and can be readily
-recognized in monitoring data.
-.Pp
-Run the command on as many hosts as necessary.
-Designate one of them as the trusted host (TH) using
-.Nm
-with the
-.Fl T
-option and configure it to synchronize from reliable Internet servers.
-Then configure the other hosts to synchronize to the TH directly or
-indirectly.