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-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
