network time default, f23

Simo Sorce simo at redhat.com
Mon Aug 31 19:28:31 UTC 2015


On Mon, 2015-08-31 at 15:14 -0400, Stephen Gallagher wrote:
> On Mon, 2015-08-31 at 12:41 -0600, Chris Murphy wrote:
> > On Mon, Aug 31, 2015 at 12:24 PM, Stephen Gallagher <sgallagh at redhat.
> > com> wrote:
> > > No, FreeIPA provides an NTPD server to its clients as the
> > > authoritative source. It has nothing to do with trusting system
> > > time
> > > (kind of the opposite; it's asserting that this system's time is so
> > > authoritative that its clients should use it as the One Truth.
> > 
> > Ahh OK got it. So ignore everything I said.
> > 
> > I suspect that by default a server should be treated as an ntp client
> > rather than as a trusted server. If there's a role that can switch
> > this out and make it easier, great. But I suspect setting up an ntp
> > server requires a bit of esoteric knowledge to make sure this is all
> > configured correctly before it can be reliably the One True Time
> > source.
> > 
> 
> Actually, there's no configuration knowledge needed when running
> FreeIPA. It assumes that the local clock is authoritative and just
> serves that out to any client configured to use the FreeIPA server as
> a domain controller.
> 
> There are important historical reasons for this. Until *very* recently
> (within the last 24 months), Kerberos could not function without the
> KDC and the client having a clock that was kept synchronized to within
> five minutes. This meant that any Kerberos deployment realistically
> needed to have NTP provided by the KDC. So that's why FreeIPA includes
> it.
> 
> In very recent versions of Kerberos (I forget the exact release, but
> I'm pretty sure it was at least krb5 1.11) there's now a new
> capability to maintain a known offset between clients and the KDC
> (which also aids situations where one client might be connected to two
> different KDCs, each with clocks unsynchronized from one another). So
> this has become less of an issue, as long as all of your NTP clients
> are running very new versions of krb5. (Which does not include
> RHEL/CentOS 6 and older)

Server's still need to be synchronized with the KDC though, which is why
FreeIPA will keep serving ntpd by default, as it is an infrastructure
component built principally for "servers".

Keep in mind we do not configure NTPD to advertise itself as stratum 0
or anything, we keep ntpd still pulling the clock from upstream servers.
In this regard FreeIPA's ntpd also acts like a proxy so that less
traffic is sent to upstream ntp servers.

> If you have such clients, then it remains necessary to have SOME sort
> of NTP server in the domain, and having FreeIPA automatically
> configure it just makes sense. Since realistically we have to assume
> that we will have such clients for at least the next six or seven
> years...
> 
> Right now, that means we use the traditional ntpd daemon, because
> that's what upstream FreeIPA is using. This *does* mean that without
> upstream work, even if we ship with timesyncd or chronyd for default
> behavior (pointing at clock.fedoraproject.org), when a domain is
> joined it will swap that out for ntpd anyway. If we have strong
> reasons for why our chosen default is a better solution, we need to
> work with FreeIPA upstream to make that at least an option.

Indeed, patches (or at least tickets with convincing explanations) are
very welcome.

> 
> > If running FreeIPA necessarily implies that the system it's running
> > on
> > is so trusted, then it sounds like a role could optimize this change.
> > 
> > 
> 
> I hope the above explanation made that more clear and you understand
> why it has to be trusted, even if it's wrong :)
> 
> 
> > > > Separately I'm noticing on atomic cloud (F22), that there is
> > > > also no
> > > > network time set. Chrony and ntpd are not installed and
> > > > systemd-timesyncd.service is disabled.  I'd really hate to think
> > > > we
> > > > end up with three completely different ways of syncing time on
> > > > the
> > > > three products.
> > > 
> > > Yes, I concur that we should try to settle on one. That's kind of
> > > why
> > > I was suggesting timesyncd; it seemed most likely to be present on
> > > all
> > > Editions.
> > 
> > After I clicked send and started to write an email for Cloud SIG, I
> > thought, wait the baremetal host should have the correct time, and
> > that should get propagated to the VM or container that Cloud (atomic
> > or otherwise) is running in. So ntp client shouldn't be applicable.
> > 
> 
> Well, it would presumably still be relevant for the hypervisor host,
> which in our perfect world would also be a domain client to minimize
> the necessity for admins to configure this manually. So deciding on an
> appropriate NTP client for domain members still makes sense.
> 
> 
> > 
> > > BTW, is timesyncd == timedated? Because the FESCo ruling was about
> > > timedated. If it's just a name-change, fine. But if it's a new
> > > implementation, we may want a new investigation.
> > 
> > They appear to be different. systemd-timesyncd.service can either be
> > enabled or disabled, where systemd-timedated.service is static. I
> > think this is the daemon that timedatectl talks to (?) regardless of
> > what process is the ntp client.
> > 
> > http://www.freedesktop.org/wiki/Software/systemd/timedated/
> > 
> > 
> 
> 
> I think we need to officially put this on the agenda for tomorrow's
> Server SIG meeting. I don't particularly care what we settle on, so
> long as we pick something.

Ack,
Simo.

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



More information about the server mailing list