network time default, f23

[Stephen Gallagher]

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)

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.


> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20150831/0646df0b/attachment-0001.sig>