F20 Self Contained Change: Remove deprecated calls of using ntpdate in favor of ntpd

Paul Wouters pwouters at redhat.com
Wed Jul 17 13:23:44 UTC 2013


On Wed, 17 Jul 2013, Chris Adams wrote:

> Once upon a time, Jaroslav Reznik <jreznik at redhat.com> said:
>> ntpdate is slowly being depricated. STIG enhancements for RHEL 6 penalize
>> systems that make use of ntpdate. Also documentation from the NSA Hardening
>> Guidelines as well as CIS Hardening documentation recommends disabling the use
>> of ntpd as a full-time daemon.

> The NTP project has been trying to deprecate ntpdate for a long time
> now,

As long as ntpd does not allow "jumps" in time, ntpdate will be needed
to correct large offsets to real time. There is a very good reason
ntpdate is present in startup scripts before ntpd is started.

Additionally, with systems without a realtime clock, like the raspberry
pi, we have a new problem where we need to obtain the time from an
external source. That might seem easy, but with DNSSEC, we might not be
able to resolve pool.ntp.org without first having a time estimate that's
accurate to about 1 hour.

I have been thinking about how to solve that properly. One idea is to
use DNS and ignoring the time in the RRSIG records, getting a bunch of
DNSSEC queries from various TLDs and the root, using that to estimate
time, then trying to enable DNSSEC and resolve pool.ntp.org.

Another alternative could be to use something like tlsdate, which
obtains time from HTTPS servers, but then we would need to use wellknown
servers and rely on the CA PKI. Also, tlsdate really needs a security
review.

Finally, for an easy fix for rebooting raspberry pi and co, I would
really like to save the timestamp and load it on reboot, similar to the
ranseed file.

Paul


More information about the devel mailing list