network time default, f23

Simo Sorce simo at redhat.com
Tue Sep 1 14:42:00 UTC 2015


On Tue, 2015-09-01 at 11:26 +0200, Miroslav Lichvar wrote:
> On Mon, Aug 31, 2015 at 12:48:37PM -0600, Chris Murphy wrote:
> > On Mon, Aug 31, 2015 at 12:32 PM, Tomasz Torcz <tomek at pipebreaker.pl> wrote:
> > 
> > >   IMO FreeIPA should be changed to install use chrony as server,
> > > as chrony is default since few Fedora releases.
> > 
> > The pluses of chrony as an ntp client for Workstation are fairly
> > clear. I don't know if there are significant advantages to chrony as
> > an ntp server over ntpd.
> 
> Well, an NTP server is just an NTP client that is listening on port
> 123 and is willing to tell other hosts what time it currently thinks
> it is. There is not much to it. A better NTP client should be also a
> better NTP server. There are some server-specific differences between
> chronyd and ntpd, but probably nothing so important that it would
> decide what is a better default NTP server. See the "NTP server"
> section here
> 
> http://chrony.tuxfamily.org/comparison.html
> 
> chronyd doesn't implement server rate limiting (yet). It's not a high
> priority. It may sound like a useful feature, but it often actually
> increases the network traffic, because clients that send too many
> requests are often the ones that will quickly send another request
> when there is no reply from the server or it's told to reduce its
> polling rate.

Just FYI, the reason we chose ntpd and stuck top it is that we
eventually want to support MS-SNTP signing (for compatibility with
windows clients/samba). We haven't done that yet because when we did
work on the component it was still an external patch (IIRC) even for
ntpd, but signing time is something we'd really want to do.

Note that having an implementation of Network Time Security to which we
can feed certificates (for the server) would also be a very good thing,
sadly none of the clients/servers support it yet apparently.

HTH,
Simo.

> > >   Those are two different things. Timesyncd is simple SNTP client (plus
> > > time restoration over reboot, for things without RTC).
> > 
> > Is an exception needed for ARM where it's more common to find no RTC?
> > That is, on ARM, have a different ntp client by default? Or is it
> > possible to detect the lack of an RTC, and that causes chronyd/ntpd to
> > be disabled, and timesyncd to be enabled?
> 
> With the -s option chronyd does restore time from the driftfile as a
> fallback on machines without RTC, but should that be a responsibility
> of the NTP client? I think there may be better places to do that.
> 
> On Debian, for instance, there is a separate fake-hwclock service, no
> need to have an NTP client installed. Some systems support a fixrtc
> option on the kernel command line to set the system time in initramfs
> to the last mount time of the root filesystem.
> 


-- 
Simo Sorce * Red Hat, Inc * New York



More information about the server mailing list