NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38. See InstallingNTPDev for discussion of this topic.
ntp-4.2.8p15 was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
4. Installing NTP
NTP may be installed from the original source code, released by the NTP Project
(which was originally from the University of Delaware starting in the 1980s, and was moved to Network Time Foundation
in 2011) , or through pre-packaged or pre-compiled versions which may be available from your Operating System vendor/aggregator/distributor.
The instructions shown below for specific operating systems are presented as a courtesy and may not be up to date. These instructions presume that you have properly configured that operating systems package management infrastructure. Users are advised to consult their their operating system documentation for current installation instructions.
4.1. The NTP Project Reference Implementation Distribution
Users attempting to install NTP from source code should have some experience compiling software on UNIX or a Unix-like operating system.
The following software is used when installing NTP source code:
- A C compiler
make (note that on some platforms, building outside of the main source directory requires GNU make.)
libcap (note: needed for linux only if you wish to enable linux capabilities to drop root privileges and chroot ntpd)
4.1.1. Installing an
ntp.org software release, and Getting Support
- Download and unpack a tarball from SoftwareDownloads or The NTP Project Download Page
- Read and follow the directions in the
- See ConfiguringNTP for information about how to configure NTP
- Add the
init scripts, etc., to make NTP start at boot time
If you have any questions or problems installing NTP, the following resources are available:
- Community (free) support options:
- Support is available thru Network Time Foundation:
4.2. Debian GNU/Linux
4.2.1. NTP Pool Client
apt-get install ntp
4.2.2. Custom Configuration
apt-get install ntp
/etc/ntp.conf (see ConfiguringNTP)
- Create any required symlinks for your ref-clock if you are using one
make install clean
/etc/ntp.conf (see ConfiguringNTP)
- Create any required symlinks for your ref-clock (if you are using one)
4.6. Microsoft Windows
- Instructions for installing on Windows
- Read the next section about PPS signals on Windows
4.6.1. Using PPS signals on Windows
There are two options to get PPS signals on the DCD pin of a serial line connected to NTPD:
- The venerated 'serialpps.sys' driver in combination with 'serialpps-ppsapi-provider.dll'. This is covered in 1.) above.
- The newer 'loopback-ppsapi-provider.dll' that comes with the sources of NTP for Windows.
'serialpps.sys' is a replacement for 'serial.sys', the UART driver for Windows. This one used to work for all on-board and ISA-board based UARTs, but since these days there are no more ISA slots and cards, the driver is restricted to the UARTS on the motherboard, which seem also to vanishing over time.
To work around this there has been something in NTPD that was known (alas, not widely known) as the 'PPS hack': Since NTPD had to monitor the serial line for what WIndows calls COMM events anyway, it also checked for level changes of the DCD line and used the time stamp of this change to supplant the receive time stamp for the next line of text
. (E.g. the next NMEA record.) This works in user mode and needs no special driver, and it works for every serial interface known to Windows, but it gives reliable results only under tight constraints. (Having more than one NMEA record in the output cycle and selecting not the first after the PPS pulse completely defeats this!)
So 'loopback-ppsapi-provider.dll' came into existence as a means to get around the limitations of 'serialpps.sys' without requiring a kernel mode driver. A kernel mode driver can (but not necessarily will) provide time stamps with less jitter than any user mode application, but 'loopback-ppsapi-provider.dll' seems to do a very decent job here. In case you wonder about the name: This provider loops back into NTPD to tap into information already there.
So how to set this up? There are two environment variables involved, and since NTPD is meant to be run as Windows service, these must be SYSTEM
PPSAPI_DLLS is a ';'-separated list of file names that should be tried in sequence to provide a PPS API for a device. For maximum interoperability between different versions of Windows the files should be given with absolute path, using standard Windows conventions. (That is, use '\' as path separator.)
PPSAPI_HACK should be a boolean value (Yes/No/True/False/0/1) or unset and controls the the PPS-hack operation. (Who would have guessed?)
When it comes to controlling the PPS hack, there is some dependency between those two settings. The decision is based on the principle of least surprise:
- If neither
PPSAPI_HACK is set in the environment, the PPS hack works as it has always done.
- If only
PPSAPI_DLLS is set (and not empty) it disables the PPS hack, assuming that a better way of handling PPS signals is provided. (The interaction between the PPS API and the PPS hack is somewhat tricky. It's better to avoid this area where dragons are roaming unless you feel really adventurous.)
- The environment variable
PPSAPI_HACK takes precedence over
PPSAPI_DLLS: if it is set to Y[es], T[rue] or 1 it enables the PPS hack independently of any setting of
PPSAPI_DLLS; any other value disables the PPS hack unconditionally.
So the cleanest setting that does not require kernel mode support is to have the following in your system environment: