Bug 1986039

(In reply to Chris Adams from comment #0)
> When anaconda gets NTP servers from DHCP, it overrides the default pool
> config in chrony.conf with the DHCP-provided servers. This differs from the
> behavior of the installed OS, which does not edit chrony.conf (it keeps the
> pool servers and adds the DHCP-provided servers dynamically).
I think the motivation for this might be corporate networks that only allow self-hosted NTP servers that
they also provide to hosts via DHCP.  All other NTP servers are blocked at the corporate firewall.

IIRC the motivation is kerberos and other security technologies that are depndent on precise time synchronization
that an attacker acting as man in the middle for the default pool could influence.

I guess if the default pool stayed in place then the host would still try to use it, only for the requests to be blocked
anyway, before switching to the network provided NTP servers.

> 
> The result is that installing on a network with DHCP-provided NTP servers
> means you _only_ get those servers configured, removing the pool servers
> from the config. It looks like anaconda is maybe treating DHCP-provided
> servers the same as kickstart-configured servers, which IMHO is not correct.
> 
> This is especially problematic when you are installing servers on one
> network and then shipping them elsewhere.
> 
> Right now, I work around this in my kickstarts by configuring anaconda to
> disable NTP and then manually adding it back, but that shouldn't be needed.
> At a minimum, maybe add a flag to the timesource kickstart config to disable
> this behavior.
I think that could be the way forward - keep the current behavior and create a new options, say "--keep-defaults", that could be used if you want to the default as well as DHCP provided NTP servers.

I looked around and couldn't find the current behavior documented, so nobody should be depending on it (especially for security). Having unique behavior from anaconda is at best confusing. IMHO the default should be as close to the same in all circumstances; anaconda's default should be the same as an installed system (add DHCP-provided NTP servers dynamically without touching the config on disk).

This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

The undocumented behavior is still an issue in rawhide - any chance of fixing this?

This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle.
Changing version to 37.

So the only current work-around for this is to use "timezone --nontp" (and then separately install/enable chronyd) in a kickstart file... but now I see that the --nontp option is deprecated in RHEL 9.1? This really needs to be fixed; since this is undocumented behavior, it should be removed, or it should be documented with an opt-out (or really, an opt-in).

This undocumented, non-intuitive, and inconsistent behavior is still present in Fedora 38's anaconda. There's no real excuse for saying it's needed by people using Kerberos or such, as they are configuring time servers if needed anyway (FreeIPA's client install does this by default for example). The installer really should NOT be editing config files based on information not provided by who/what is installing it (either interactive install or kickstart) but from the network (as far as I can tell, this is the only DHCP-provided information that is then hard-coded in the installed system).

This behavior leads to real broken installs - we found a bunch of systems that were built on a dedicated install network (where the DHCP server config happened to include the NTP server, because it was copied from other networks) but then deployed elsewhere had bad clocks, which caused all kinds of problems.

Hello Chris,

I understand your point, however, this functionality was implemented to Anaconda on request in bug 862755 . And it was implemented even before (already part of RHEL 6.3 which is year 2012). This is usual issue of Anaconda because of its history.

As noted above this functionality is a long time requested behavior from Anaconda and we can't just change this long time used default because we could break a lot of installations.

One of the reasoning was:
- this may render NTP unusable in environments where NTP traffic is only allowed within internal network



What we can do, is to somehow provide an option to people to turn off this feature (UI, boot options?) but we should avoid changing the defaults. Would that be fine with you? Although, I have say that we don't have a capacity near term future to implement something like this and we would have to discuss the impact first.

Looking at BZ 862755, it seems to request different behavior than was actually implemented.

The requested behavior is the DHCP-provided servers are prepended in a chooser in firstboot, while the actual behavior is that they are exclusively used (the pool servers are removed by anaconda). Also, I think this may have been done before the DHCP-provided servers were used by NTP in a normal boot (ntpd then, chrony now), so is not needed anymore.

The note that "this may render NTP unusable in environments where NTP traffic is only allowed within internal network" is actually wrong now, given the behavior of an installed system automatically using DHCP-provided servers. Having pool servers in the config (in other words, not having anaconda rewrite the config at all) would work just fine. The DHCP-provided servers would be added with the include from /run; having theoretically unreachable pool servers listed would not break anything (chronyd would just not use them). Also, the current behavior breaks expectations of using DHCP-provided servers in the installed system, as changing the DHCP server config to provide a different server would not stop installed clients from continuing to try to use the old server.

The problem is that the current setup DOES render NTP unusable in environments where systems may be installed on one network and used anywhere else. For me, this is servers built on a dedicated VLAN, but it also breaks notebooks where the OS is installed on a network with DHCP-provided servers and then used anywhere else. Disabling the current behavior of rewriting /etc/chrony.conf would not render NTP unusable anywhere (since DHCP-provided servers are automatically used by the installed system already, without replacing pool servers).

It would seem that the only people who would want the current behavior might be those that don't want to use pool servers for security; depending on undocumented anaconda behavior for that level of security seems broken anyway (they should be explicitly writing chrony.conf to operate in their desired fashion and/or blocking access to external NTP servers at the network).

Also, somewhat oddly, the anaconda behavior is trying to be "smart" and NOT even necessarily using the DHCP-provided servers. DHCP provides an IP address, but anaconda then uses a reverse DNS lookup to get a name, and then writes that name to chrony.conf. If you're going to say "we're going to hard-code the DHCP-provided servers in the installed config" (which I still say is wrong), then you should just use the servers as provided by DHCP, i.e. IP addresses. Just because an IP has a reverse to a hostname at install doesn't mean that hostname will resolve (and to the same IP) later. In my case, DHCP is providing both an IPv4 and an IPv6 NTP server address, both "local" (RFC1918 IPv4 and ULA IPv6). anaconda (using just the IPv4 I think?) turned that into a hostname, but the hostname also resolves to a public (but changing) IPv6 address, so on boot the installed system chose the public IPv6 address.

This sounds interesting. Thanks for the info.

We don't have capacity for this change right now and we need to do more discovery about the impact. However, the output would be better user experience and less support for us as a side benefit. Will try to take a look on this later.