Short version: network time is not enabled in a default installation of Fedora 23 Server, using Fedora-Server-netinst-i386-23_Beta_TC1.iso.
- Is this intended? - What is the user expected to do? It's not obvious.
Long version:
chrony is not installed, meanwhile it's installed and the default on workstation. Right off the bat it's confusing that server and workstation will use different services for time synchronization.
ntp and ntpdate are installed, but both are disabled, and I don't even know what ntpdate is.
systemd-timedated.service is masked. systemd-timesyncd.service is disabled.
dbus-org.freedesktop.timedate1.service is enabled, which apparently just points to timedatex.service
Based on searching the journal, nothing is looking out to an ntp server to set the date and time correctly. If I set the hardware clock wrong (by a year) in firmware setup, it never gets corrected.
# timedatectl Local time: Fri 2013-08-30 23:32:34 MDT Universal time: Sat 2013-08-31 05:32:34 UTC RTC time: Sat 2013-08-31 05:32:34 Time zone: America/Denver (MDT, -0600) Network time on: no NTP synchronized: no RTC in local TZ: no
# systemctl enable ntpd # systemctl start ntpd
Fixes this, but it seems like something should be enabled by default.
On Sat, Aug 29, 2015 at 03:21:59PM -0600, Chris Murphy wrote:
chrony is not installed, meanwhile it's installed and the default on workstation. Right off the bat it's confusing that server and workstation will use different services for time synchronization.
IIRC there was a similar problem in F22. chrony was added to the server-product group in comps, but that's not the case in the F23 comps.
ntp and ntpdate are installed, but both are disabled, and I don't even know what ntpdate is.
ntp seems to be installed as a freeipa dependency. It's not enabled by default. There was some discussion that the ipa-*-install scripts will support chrony as an NTP client and server, but that didn't seem to happen yet.
# timedatectl Local time: Fri 2013-08-30 23:32:34 MDT Universal time: Sat 2013-08-31 05:32:34 UTC RTC time: Sat 2013-08-31 05:32:34 Time zone: America/Denver (MDT, -0600) Network time on: no NTP synchronized: no RTC in local TZ: no
# systemctl enable ntpd # systemctl start ntpd
Fixes this, but it seems like something should be enabled by default.
If you want to just enable a (S)NTP client, "timedatectl set-ntp true" should work in all four combinations of chrony and ntp packeges being installed or not installed.
On Mon, 2015-08-31 at 12:10 +0200, Miroslav Lichvar wrote:
On Sat, Aug 29, 2015 at 03:21:59PM -0600, Chris Murphy wrote:
chrony is not installed, meanwhile it's installed and the default on workstation. Right off the bat it's confusing that server and workstation will use different services for time synchronization.
IIRC there was a similar problem in F22. chrony was added to the server-product group in comps, but that's not the case in the F23 comps.
ntp and ntpdate are installed, but both are disabled, and I don't even know what ntpdate is.
ntp seems to be installed as a freeipa dependency. It's not enabled by default. There was some discussion that the ipa-*-install scripts will support chrony as an NTP client and server, but that didn't seem to happen yet.
# timedatectl Local time: Fri 2013-08-30 23:32:34 MDT Universal time: Sat 2013-08-31 05:32:34 UTC RTC time: Sat 2013-08-31 05:32:34 Time zone: America/Denver (MDT, -0600) Network time on: no NTP synchronized: no RTC in local TZ: no
# systemctl enable ntpd # systemctl start ntpd
Fixes this, but it seems like something should be enabled by default.
If you want to just enable a (S)NTP client, "timedatectl set-ntp true" should work in all four combinations of chrony and ntp packeges being installed or not installed.
I'm looking into this right now. I think what we want to do is to ship with systemd-timesyncd.service enabled by default, but I'm running some tests to figure out if this will cause issues with installing FreeIPA (since it doesn't explicitly know to check for this case and disable it when enabling ntpd).
If it works cleanly, we should probably turn this on in our presets. If it doesn't, we'll have three choices.
1) Leave NTP disabled by default until FreeIPA fixes this. 2) Enable timesyncd and add documentation to FreeIPA to tell people to make sure to disable it manually before installing FreeIPA. 3) Do choice 2) above and handle this situation in rolekit deployments of FreeIPA (which is fairly simple, since we're already plumbed for it)
On Mon, 2015-08-31 at 09:11 -0400, Stephen Gallagher wrote:
On Mon, 2015-08-31 at 12:10 +0200, Miroslav Lichvar wrote:
On Sat, Aug 29, 2015 at 03:21:59PM -0600, Chris Murphy wrote:
chrony is not installed, meanwhile it's installed and the default on workstation. Right off the bat it's confusing that server and workstation will use different services for time synchronization.
IIRC there was a similar problem in F22. chrony was added to the server-product group in comps, but that's not the case in the F23 comps.
ntp and ntpdate are installed, but both are disabled, and I don't even know what ntpdate is.
ntp seems to be installed as a freeipa dependency. It's not enabled by default. There was some discussion that the ipa-*-install scripts will support chrony as an NTP client and server, but that didn't seem to happen yet.
# timedatectl Local time: Fri 2013-08-30 23:32:34 MDT Universal time: Sat 2013-08-31 05:32:34 UTC RTC time: Sat 2013-08-31 05:32:34 Time zone: America/Denver (MDT, -0600) Network time on: no NTP synchronized: no RTC in local TZ: no
# systemctl enable ntpd # systemctl start ntpd
Fixes this, but it seems like something should be enabled by default.
If you want to just enable a (S)NTP client, "timedatectl set-ntp true" should work in all four combinations of chrony and ntp packeges being installed or not installed.
I'm looking into this right now. I think what we want to do is to ship with systemd-timesyncd.service enabled by default, but I'm running some tests to figure out if this will cause issues with installing FreeIPA (since it doesn't explicitly know to check for this case and disable it when enabling ntpd).
If it works cleanly, we should probably turn this on in our presets.
Good news! It turns out that ipa-server-install does indeed stop-and- disable systemd-timesyncd. So I'm going to just go ahead and submit a pull-request to get that enabled in Fedora Server.
On Mon, Aug 31, 2015 at 11:02:21AM -0400, Stephen Gallagher wrote:
On Mon, 2015-08-31 at 09:11 -0400, Stephen Gallagher wrote:
I'm looking into this right now. I think what we want to do is to ship with systemd-timesyncd.service enabled by default, but I'm running some tests to figure out if this will cause issues with installing FreeIPA (since it doesn't explicitly know to check for this case and disable it when enabling ntpd).
If it works cleanly, we should probably turn this on in our presets.
Good news! It turns out that ipa-server-install does indeed stop-and- disable systemd-timesyncd. So I'm going to just go ahead and submit a pull-request to get that enabled in Fedora Server.
I'm not sure if enabling timesyncd is a good idea. It's just an SNTP client and not a particularly good one. There would likely be a regression in the timekeeping reliability, performance and there would possibly be even some security implications as a client willing to step the clock at any time is apparently useful in some MITM attacks. Also, it's not integrated with NetworkManager, so it doesn't know about servers from DHCP.
Why not install chrony as before? To save disk space? I may be biased, but I think it's currently by far the best NTP client there is.
2015-08-31 18:09 GMT+02:00 Miroslav Lichvar mlichvar@redhat.com:
Why not install chrony as before? To save disk space? I may be biased, but I think it's currently by far the best NTP client there is.
From a testing perspective it is awkward to use chrony by default but have
one of the flagship roles switch to ntpd instead. Of course, “awkward” is not a show-stopper. Mirek
On Mon, Aug 31, 2015 at 12:05 PM, Miloslav Trmac mitr@redhat.com wrote:
2015-08-31 18:09 GMT+02:00 Miroslav Lichvar mlichvar@redhat.com:
Why not install chrony as before? To save disk space? I may be biased, but I think it's currently by far the best NTP client there is.
From a testing perspective it is awkward to use chrony by default but have one of the flagship roles switch to ntpd instead. Of course, “awkward” is not a show-stopper.
OK I'm kinda ignorant here, when I strace timedatectl, it doesn't enlighten me on how any program is able to get time in a way that doesn't depend on the ntp client; it seems to me it's rather archaic for a program to depend on a particular piece of plumbing setting the time. It's not actually getting the time from that particular ntp client. All that program should care about is getting the time, and should trust the time reported is correct.
What it sounds like is FreeIPA by default mistrusts system time, until it checks for the presence and enabled state of ntpd in order to trust system time. Is this some throwback to a time when system time couldn't be trusted?
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.
On Mon, Aug 31, 2015 at 12:21 PM, Chris Murphy lists@colorremedies.com wrote:
Separately I'm noticing on atomic cloud (F22), that there is also no network time set.
Nevermind I know why...
On Mon, 2015-08-31 at 12:21 -0600, Chris Murphy wrote:
On Mon, Aug 31, 2015 at 12:05 PM, Miloslav Trmac mitr@redhat.com wrote:
2015-08-31 18:09 GMT+02:00 Miroslav Lichvar mlichvar@redhat.com:
Why not install chrony as before? To save disk space? I may be biased, but I think it's currently by far the best NTP client there is.
From a testing perspective it is awkward to use chrony by default but have one of the flagship roles switch to ntpd instead. Of course, “awkward” is not a show-stopper.
OK I'm kinda ignorant here, when I strace timedatectl, it doesn't enlighten me on how any program is able to get time in a way that doesn't depend on the ntp client; it seems to me it's rather archaic for a program to depend on a particular piece of plumbing setting the time. It's not actually getting the time from that particular ntp client. All that program should care about is getting the time, and should trust the time reported is correct.
What it sounds like is FreeIPA by default mistrusts system time, until it checks for the presence and enabled state of ntpd in order to trust system time. Is this some throwback to a time when system time couldn't be trusted?
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.
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.
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.
On Mon, Aug 31, 2015 at 02:24:39PM -0400, Stephen Gallagher wrote:
What it sounds like is FreeIPA by default mistrusts system time, until it checks for the presence and enabled state of ntpd in order to trust system time. Is this some throwback to a time when system time couldn't be trusted?
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.
IMO FreeIPA should be changed to install use chrony as server, as chrony is default since few Fedora releases.
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.
I'd rather see chrony; it is small and provides full NTP sync.
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.
Those are two different things. Timesyncd is simple SNTP client (plus time restoration over reboot, for things without RTC). Timedated is providing an API + utility to set system timezone and time and to toggle external time sync. There are two implementation of timedated: – systemd's on, this only toggles timesyncd as synchronisation mechanism – timedatex, which can toggle arbitrary NTP daemon
2015-08-31 20:32 GMT+02:00 Tomasz Torcz tomek@pipebreaker.pl:
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.
Those are two different things. Timesyncd is simple SNTP client (plus time restoration over reboot, for things without RTC). Timedated is providing an API + utility to set system timezone and time and to toggle external time sync. There are two implementation of timedated: – systemd's on, this only toggles timesyncd as synchronisation mechanism – timedatex, which can toggle arbitrary NTP daemon
Yeah, and the FESCo ticket was answering the question whether it replacing systemd-timedated with timedatex was safe (probably the first instance of two packages fighting over a D-Bus service name) and desirable (for Fedora to keep using a full NTP client, overriding systemd-timedated’s bait-and-switch from supporting the major NTP daemons to only supporting timesyncd). Mirek
On Mon, Aug 31, 2015 at 12:32 PM, Tomasz Torcz tomek@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.
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?
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@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.
Starting with chrony being smaller, comprehensible codebase; there is a list of advantages at https://fedoraproject.org/wiki/Features/ChronyDefaultNTP I think Miroslav can provide much more advocacy for Chrony :)
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?
Let's not forget what we are talking about and let's not loose perspective. We are talking about servers. Anything lacking RTC is not serious enough to be a server, it's just not worth our time. Timesyncd is more like simple program for embedded uses.
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@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.
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.
Am 01.09.2015 um 11:26 schrieb Miroslav Lichvar:
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.
it's a matter of security in case of amplification attacks to third parties since NTP is UDP like DNS and so *not* low priority
On Tue, Sep 01, 2015 at 01:01:44PM +0200, Reindl Harald wrote:
Am 01.09.2015 um 11:26 schrieb Miroslav Lichvar:
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.
it's a matter of security in case of amplification attacks to third parties since NTP is UDP like DNS and so *not* low priority
With the NTP client/server packet modes (as specified by the NTP RFC) no amplification should be possible. The response is never larger than the request. What you are probably referring to are the mode 6 (control) and mode 7 (private) packets, which are supported by ntpd to allow monitoring and configuration. They do allow traffic amplification, but are disabled in our default config for remote addresses.
chronyd ignores mode 6 and mode 7 packets. It has its own command and monitoring protocol, which allowed some amplification in the past, but has been fixed to always keep the amplification ratio <= 1.0. In any case, it's running on a separate port (323) and by default accepts only packets from localhost.
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@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.
On Tue, Sep 01, 2015 at 10:42:00AM -0400, Simo Sorce wrote:
On Tue, 2015-09-01 at 11:26 +0200, Miroslav Lichvar wrote: 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.
If you need the MS-SNTP support, I can work on that. From what I saw it shouldn't be very difficult to implement.
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.
The NTS specification is still a work in progress.
On Tue, 2015-09-01 at 16:57 +0200, Miroslav Lichvar wrote:
On Tue, Sep 01, 2015 at 10:42:00AM -0400, Simo Sorce wrote:
On Tue, 2015-09-01 at 11:26 +0200, Miroslav Lichvar wrote: 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.
If you need the MS-SNTP support, I can work on that. From what I saw it shouldn't be very difficult to implement.
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.
The NTS specification is still a work in progress.
Indeed, and it would be nice if we could have Kerberos based keys used for signatures as well, I am not really fond of the NTP server distributing yet another set of keys ...
Simo.
On Mon, Aug 31, 2015 at 12:24 PM, Stephen Gallagher sgallagh@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.
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 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.
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/
On Mon, 2015-08-31 at 12:41 -0600, Chris Murphy wrote:
On Mon, Aug 31, 2015 at 12:24 PM, Stephen Gallagher <sgallagh@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.
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.
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@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.
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.
On Mon, Aug 31, 2015 at 03:28:31PM -0400, Simo Sorce wrote:
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.
It seems the ipa-server-install script configures ntpd with the LOCAL driver, so it can serve time even when it's not synchronized. That can be done with chronyd too (using the local stratum directive).
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.
I found a ticket for the client part. Should I file one for the server? https://fedorahosted.org/freeipa/ticket/4669
BTW, there was recently a request to add an option to use servers from DNS SRV records (#1234406) and that is implemented in the latest chrony packages.
If it doesn't work for you or other things are needed before FreeIPA can fully support chronyd as an NTP server and client, please let me know.
2015-08-31 15:11 GMT+02:00 Stephen Gallagher sgallagh@redhat.com:
I'm looking into this right now. I think what we want to do is to ship with systemd-timesyncd.service enabled by default
Miroslav says (and FESCo agreed in https://fedorahosted.org/fesco/ticket/1394 ) that the SNTP is not the best default.
(I have basically no expertise in this; I can’t now say whether this means that timesyncd should not be default or that the information in the FESCo ticket is outdated and timesyncd is now OK. Either way, something should be changed.) Mirek
On Sat, 2015-08-29 at 15:21 -0600, Chris Murphy wrote:
Short version: network time is not enabled in a default installation of Fedora 23 Server, using Fedora-Server-netinst-i386- 23_Beta_TC1.iso.
- Is this intended?
- What is the user expected to do? It's not obvious.
Long version:
chrony is not installed, meanwhile it's installed and the default on workstation. Right off the bat it's confusing that server and workstation will use different services for time synchronization.
ntp and ntpdate are installed, but both are disabled, and I don't even know what ntpdate is.
systemd-timedated.service is masked. systemd-timesyncd.service is disabled.
dbus-org.freedesktop.timedate1.service is enabled, which apparently just points to timedatex.service
Based on searching the journal, nothing is looking out to an ntp server to set the date and time correctly. If I set the hardware clock wrong (by a year) in firmware setup, it never gets corrected.
# timedatectl Local time: Fri 2013-08-30 23:32:34 MDT Universal time: Sat 2013-08-31 05:32:34 UTC RTC time: Sat 2013-08-31 05:32:34 Time zone: America/Denver (MDT, -0600) Network time on: no NTP synchronized: no RTC in local TZ: no
# systemctl enable ntpd # systemctl start ntpd
Fixes this, but it seems like something should be enabled by default.
During today's Server SIG meeting, we agreed that we should have a time-synchronization service enabled by default and that it will be chrony.
I've pushed https://git.fedorahosted.org/cgit/comps.git/commit/?id=0b75 52671709a898c05b76eb47323cfb5700cc05 upstream to comps, so the Fedora 23 Beta and Final will carry this as a mandatory component.
server@lists.fedoraproject.org