On Mon, Aug 31, 2015 at 12:24 PM, Stephen Gallagher <sgallagh(a)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
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.
> Separately I'm noticing on atomic cloud (F22), that there is
> 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
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.
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.