Resolving of hosts specified the allow/deny directive is intentionally required to work on start. Maybe it should be mentioned in the man page.

While theoretically the allow/deny directives could be delayed for name resolving, I'm not sure if it makes much sense. If the address of the NTP client is expected to change over time (i.e. it needs to be specified as a hostname), the client would be allowed access only until the next change of its address and chronyd would need to be restarted. In such case it would be better to periodically run a script and use the allow/deny commands of chronyc.

Also, it's not clear to what should it do if the name resolves to multiple addresses. What if it's used in a deny command blacklisting a client and there is an allow directive for a subnet in which the client is? The client would be allowed access until the resolving succeeds.

It seems the original reason for this bug report is that the allow directive was thought to be needed for NTP sources (like ntpd requires with the restrict directive), but that's not actually necessary.

(In reply to Miroslav Lichvar from comment #2)
> Resolving of hosts specified the allow/deny directive is intentionally
> required to work on start. Maybe it should be mentioned in the man page.

This should also mention that chrony has to be started strictly *after* the network has been brough up, as otherwise DNS resolution might not work.

> While theoretically the allow/deny directives could be delayed for name
> resolving, I'm not sure if it makes much sense. If the address of the NTP
> client is expected to change over time (i.e. it needs to be specified as a
> hostname), the client would be allowed access only until the next change of
> its address and chronyd would need to be restarted. In such case it would be
> better to periodically run a script and use the allow/deny commands of
> chronyc.

But doesn't this render the hostname version of allow/deny useless? If my hostname ←→ IP mapping never changes, I can also just enter the IP address in chrony.conf and forget about all the DNS resolution pain.

> It seems the original reason for this bug report is that the allow directive
> was thought to be needed for NTP sources (like ntpd requires with the
> restrict directive), but that's not actually necessary.

It's not needed, true. But the main point of the BZ was: chrony fails to start if it is started before I have a working network but want to use allow/deny with names.

(In reply to Evgeni Golov from comment #3)
> This should also mention that chrony has to be started strictly *after* the
> network has been brough up, as otherwise DNS resolution might not work.

Right.

Generally, we want to start chronyd early in the boot process, so it can restore the frequency of the clock from the driftfile, set the clock from the RTC (with the -s option), or set the clock from a reference clock (e.g. GPS), even if the network is not up.

There are other interesting problems with name resolving. If chronyd waited for working DNS, it might lock with DNSSEC it it's waiting for chronyd to set the clock.

> But doesn't this render the hostname version of allow/deny useless? If my
> hostname ←→ IP mapping never changes, I can also just enter the IP address
> in chrony.conf and forget about all the DNS resolution pain.

I agree the hostname form of the directive is not very useful. I don't remember any other reports about this. If it was implemented again, it would probably make sense to not support hostnames at all. Now, I think it needs to be preserved for compatibility.

(In reply to Evgeni Golov from comment #3)
> (In reply to Miroslav Lichvar from comment #2)
> > Resolving of hosts specified the allow/deny directive is intentionally
> > required to work on start. Maybe it should be mentioned in the man page.
> 
> This should also mention that chrony has to be started strictly *after* the
> network has been brough up, as otherwise DNS resolution might not work.

This is now upstream:

http://chrony.tuxfamily.org/doc/devel/chrony.conf.html#allow

The improved documentation will be included in chrony rebase (bug #1387223).

the abovementioned page has this relevant part:

"The directive allows a hostname to be specified instead of an IP address, but the name must be resolvable when chronyd is started (i.e. chronyd needs to be started when the network is already up and DNS is working)."

just to be sure, do I get it right that nothing changed in the startup process (as described in the bug reproducer), the whole 'fix' is just docs change as suggested in #c6?

(In reply to Karel Volný from comment #8)
> just to be sure, do I get it right that nothing changed in the startup
> process (as described in the bug reproducer), the whole 'fix' is just docs
> change as suggested in #c6?

Yes, this is just a documentation improvement. The default ordering of the chronyd service doesn't change.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:1908