Version 5 (modified by 7 years ago) ( diff ) | ,
---|
NTP
The download URL is http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/snapshots/ntp-stable/2006/02/ntp-stable-4.2.0a-20060224.tar.gz
NTPD privsep
Installing ntpd to drop to non-root -
If you have libacl and libattr installed, you can configure NTP with:
--enable-linuxcaps
Then add an ntpd user:
groupadd ntpd && useradd -c 'ntpd PrivSep' -d /var/lib/ntpd -g ntpd \ -s /bin/false ntpd && install -v -m710 -g ntpd -d /var/lib/ntpd
Install the blfs bootscript, and modify /etc/rc.d/init.d/ntp with this:
loadproc /usr/sbin/ntpd --configfile=/etc/ntpd.conf \ --jaildir=/var/lib/ntpd --logfile=/var/log/ntpd.log \ --pidfile=/var/run/ntpd.pid --user=ntpd:ntpd \ --no-load-opts
To give the ntpd user minimal privileges create a tmpfs just big enough for the drift file:
install -d -m 0000 /var/lib/ntpd/drift
And add this to /etc/fstab, and replace the gid with ntpd's group id:
tmpfs /var/lib/ntpd/drift tmpfs size=9k,nosuid,noexec,nodev,mode=1770,gid=1003,nr_inodes=2,nr_blocks=2 0 0
Fixes if synchronisation fails following frequent suspend to RAM
On one of my machines, ntp had lost synchronisation. I initially blamed the tsc clocksource in a particular kernel version, and recommended changing it back to acpi_pm.
From the initial version of this section:
On one of my machines, in one kernel release, I lost synchronisation and the log showed:
frequency error 1726 PPM exceeds tolerance 500 PPM
Google found a not-too-old link to redhat [https://access.redhat.com/solutions/35640] which suggested checking the available drivers with
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
and assuming that acpi_pm is available, temporarily changing to it with
echo acpi_pm >/sys/devices/system/clocksource/clocksource0/current_clocksource
and seeing if that helps. If useful, it can forced by adding
clocksource=acpi_pm
to the bootargs in grub.
A better fix (sysvinit)
I forgot about the problem, until one day when I discovered that my desktop clock was 5 minutes slow. In the end, this appears to be related to frequent suspend to RAM, sometimes for a few days. In early versions of pm-utils (which is what I use for s2ram) there was a script to fix up ntpd - but that was removed long ago, in the belief that the clock would only drift for a maximum of 64 seconds realtime (not drift *by* 64 seconds!) and then ntpd would start to sync it. For systemd the preferred methods are apparently different. Anyway,I've now added the following script as /usr/lib/pm-utils/sleep.d/48ntpd (mode 755) and things seem to work - using 'ntpq -p' I can sometimes see offsets of several hundred milliseconds (and increasing!) even when the box has sync'd to my local server, but it seems to stay accurate to within a second, and eventually syncs to a few milliseconds.
#!/bin/sh # stop ntpd on suspend, fix and start fresh on wakeup . "${PM_FUNCTIONS}" case $1 in suspend) /etc/rc.d/init.d/ntpd stop ;; resume) /usr/sbin/ntpd -gq /etc/rc.d/init.d/ntpd start *) exit 0 ;; esac exit 0
When the clock is too far away from the correct time
If ntpd bails out because the clock is too far from the correct time, try stopping ntpd, then use
ntpd -gq
to let it sync, and then restart ntpd. According to the man page, -g can be used multiple times if the clock is far adrift.