chrony: make default pools optional

[shaunco]

Summary

• remove the hardcoded resinio.pool.ntp.org pools from chrony.conf
• generate default pools at runtime unless ntpServers is "null", keeping defaults and custom lists in separate chrony source files
• document the three ntpServers behaviours in README.md

Fixes #3680

Change-type: patch

Contributor checklist

• Changes have been tested
  • Covered in automated test suite
  • Manual test case recorded
• Change-type present on at least one commit
• Signed-off-by is present
• The PR complies with the Open Embedded Commit Patch Message Guidelines

Reviewer Guidelines

• When submitting a review, please pick:
  • 'Approve' if this change would be acceptable in the codebase (even if there are minor or cosmetic tweaks that could be improved).
  • 'Request Changes' if this change would not be acceptable in our codebase (e.g. bugs, changes that will make development harder in future, security/performance issues, etc).
  • 'Comment' if you don't feel you have enough information to decide either way (e.g. if you have major questions, or you don't understand the context of the change sufficiently to fully review yourself, but want to make a comment)

[github-actions]

A repository maintainer needs to approve these workflow run(s).

To approve, maintainers can either:

• Submit an approval review on this pull request, OR

• Submit a review comment starting with /deploy

Then re-run the failed job(s) via the Checks tab above.

Reviews must be on the specific commit SHA of the workflow run to be considered.

[github-actions]

A repository maintainer needs to approve these workflow run(s).

To approve, maintainers can either:

• Submit an approval review on this pull request, OR

• Submit a review comment starting with /deploy

Then re-run the failed job(s) via the Checks tab above.

Reviews must be on the specific commit SHA of the workflow run to be considered.

[github-actions]

A repository maintainer needs to approve these workflow run(s).

To approve, maintainers can either:

• Submit an approval review on this pull request, OR

• Submit a review comment starting with /deploy

Then re-run the failed job(s) via the Checks tab above.

Reviews must be on the specific commit SHA of the workflow run to be considered.

[github-actions]

A repository maintainer needs to approve these workflow run(s).

To approve, maintainers can either:

• Submit an approval review on this pull request, OR

• Submit a review comment starting with /deploy

Then re-run the failed job(s) via the Checks tab above.

Reviews must be on the specific commit SHA of the workflow run to be considered.

[flowzone-app]

A repository maintainer needs to approve these workflow run(s).

To approve, maintainers can either:

• Submit an approval review on this pull request, OR

• Submit a review comment starting with /deploy

Then re-run the failed job(s) via the Checks tab above.

Reviews must be on the specific commit SHA of the workflow run to be considered.

[ycardaillac]

Hi @shaunco, thanks for your contribution, we are currently working on it here: #3783
I've cherry picked your commit and I'm working mostly on the tests for now, but we might change the behavior a little bit, discussions are happening internally.

[shaunco]

Thanks @ycardaillac!

[Timple]

Please do not go this route.

Can you please give access to the full chrony.conf file?
That would solve #3680 as well as #1526

edit: and #3005

[alexgg]

hey @Timple thanks for your comment. Allowing applications to directly access hostOS configuration is not how the current product is designed to work. HostOS configuration is performed either via config.json at installation time, or via the supervisor.

It's a conscious design decision that trades off reproducibility, maintenance and security versus flexibility. It also allows to maintain a good automated OS tests coverage without the exponential increase of configuration changes.

#1526 is a good example. Providing access to chrony.conf would allow applications to implement the feature eventually, but every user would need to implement this and Balena would need to implicitly support them. Except that is already possible, applications just need to stop the hostOS chrony and run their own, clearly separating the hostOS and application responsibilities.

The approach we would take instead is to provide the needed hostOS configuration via the supervisor, properly test the feature works, add an automated test to make sure it does not break, and then release it. So it becomes a known to work, production ready supported feature.

Why do you say this change will not address #3680 and #3005?
After this change you can either:

• Not define ntpServers and use default pools
• Set ntpServers as null and use only DHCP provided servers
• Set ntpServers to a list of servers and use only those.

[Timple]

Thank you for your comment. I was not saying it was not solving those.
I was merely indicating that a different approach could solve all issues.

In a new project we have at the moment it's really undesired to do a makestep. Yet that is the default config and cannot be undone.
In yet another project we are supposed to act as a timeserver as well. This is easily done by adding:

# Allow other clients to query chrony for time
allow
# Serve time immediately even before syncing with upstream (stratum 10 when unsynchronized)
local stratum 10

to the configuration.

That, in combination with the GPS source (of a different project) leads me to the suggestion:

Please give full control of the chrony configuration.

Of course the implementation is debatable. But you are shifting the line bit-by-bit at the moment:

• First Default chrony
• Then Custom NTP servers
• Then Allow dhcp server
• Then dhcp servers without default ntp servers
• ...

This is a bit whack-a-mole with approximately a two-year interval. Perhaps we can go directly to N and allow fine-grained acces somehow?

[alexgg]

hi @Timple would stopping the hostOS chronyd via dbus and running the NTP server in the application won't work? That gives a production tested time sync until application start, and then the application can take over with a custom chrony configuration.

[Timple]

Yes that works. That is exactly how we do it now:
https://github.com/nobleo/balena-chrony

But it feels kind of hacky and a lot of work for just modifying a config file. And we needed hacks like these to get it robust: nobleo/balena-chrony#7 and nobleo/balena-chrony#9