Re: [chrony-dev] Adding a "fallback" option to "server" and friends

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Tue, Dec 07, 2021 at 03:51:39PM +0100, Reinhard Max wrote:
> I am wondering if it would make sense to add a flag to the "server"
> directive that acts like kind of the reverse of "prefer". It could be named
> "fallback", but I am open for better suggestions.
> 
> Entries marked with this new flag would be ignored (and maybe even hidden
> from the list of sources) as long as there are other sources available that
> do not have this flag.

The prefer option is used in the source selection algorithm, in a
later stage where the sources considered good for synchronization
(i.e. not falsetickers, good distance, etc) are trimmed down to one or
more sources that will be combined and actually update the clock.

If the fallback option was just an inverse of prefer, the sources
would still be polled and visible.

> This would allow vendor preconfigurations to stay in the background while
> there are locally configured sources, but act as a fallback if there is no
> local configuration or the locally configured servers are not reachable.

The confdir and sourcedir directives accept multiple directories.
For example, packages can have default configuration in
/usr/lib/chrony, which will be used only when the corresponding file
in /etc/chrony doesn't exist.

As for falling back when servers are unreachable, I'm not sure if that
would be a good idea. It makes it less obvious what is going on. There
could be security implications. If the user specified an authenticated
NTP server, a MITM attacker could block the communication with the
server in order to make it appear unreachable and force the client to
switch to an unauthenticated fallback server.

> Of course similar behavior could be accieved by using the "prefer" flag in
> all local configurations, but not in the preconfigurations, but this would
> require every user and every script to cooperate, whereas a new flag with
> lower priority that is kind of reserved for vendors would not interfer with
> existing practice and scripts.

Yes, this is a problem. I don't see a good solution. There are
different approaches, but all seem to have some disadvantages.
Traditionally there was a single chrony.conf file. That allows the
user and configuration tools to see everything at once, but it's not
easy to make modifications (e.g. by adding files to a directory). With
multiple files (possibly in different directories) it is easier to
extend the configuration, but it's difficult to override specific
parts (e.g. replace all servers with different servers).

As a downstream maintainer, I'm sticking to the single-file approach,
at least for now.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.