Platform chrony configuration intolerant of user modified config

[fifofonix]

Describe the bug

Prior to this FCOS version it was possible to configure a custom NTP server via ignition by writing to /etc/sysconfig/chronyd. Note machines previously commissioned with this ignition snippet upgrade fine to this testing version. This issue occurs also on latest next.

    - path: /etc/sysconfig/chronyd
      mode: 0644
      overwrite: true
      contents:
        inline: |
          OPTIONS="'server ntp.server.acme.edu'
          "

It is not clear to me what the simple way should be to configure a custom ntp server. If there is a simple more canonical way than above I'm open to adopting it instead.

Reproduction steps

1. Commission a new machine for the specified testing stream version with ignition snippet provided.
2. Chronyd.service fails to start.

Expected behavior

1. Chronyd.service should start normally.

Actual behavior

Chrony.service fails:

Could not parse server directive at line 1

This seems to be because a FCOS chronyd config is now created (this attempts to merge in the ignition-specified options but fails on quoting issues, yielding something like:

OPTIONS=''server ntp.server.acme.edu'
 -f /run/coreos/platform-chrony.conf'

System details

• vSphere & AWS

Butane or Ignition config

No response

Additional information

Manually amending the auto-generated /run/coreos/sysconfig-chrony to below results in a happy chronyd.

OPTIONS="'server ntp.nyp.org'
 '-f /run/coreos/platform-chrony.conf'
"

[fifofonix]

Output of sudo journalctl -u coreos-platform-chrony-config.service is:

Mar 28 10:53:42 t-xxx-g1-1 systemd[1]: Starting coreos-platform-chrony-config.service - CoreOS Configure Chrony Based On The Platform...
Mar 28 10:53:42 t-xxx-g1-1 coreos-platform-chrony-config[1361]: coreos-platform-chrony-config: Updated chrony to use aws configuration /run/coreos/platform-chrony.conf
Mar 28 10:53:42 t-xxx-g1-1 systemd[1]: Finished coreos-platform-chrony-config.service - CoreOS Configure Chrony Based On The Platform.
Mar 28 10:57:15 t-xxx-g1-1 systemd[1]: coreos-platform-chrony-config.service: Deactivated successfully.
Mar 28 10:57:15 t-xxx-g1-1 systemd[1]: Stopped coreos-platform-chrony-config.service - CoreOS Configure Chrony Based On The Platform.

[jlebon]

Thanks for the details!

    - path: /etc/sysconfig/chronyd
      mode: 0644
      overwrite: true
      contents:
        inline: |
         OPTIONS="'server ntp.server.acme.edu'
         "

Interesting, I wouldn't have thought this worked. But indeed, the synopsys in chronyd(8) is:

chronyd [OPTION]... [DIRECTIVE]...

And the systemd service just does a pure string substitution:

EnvironmentFile=-/etc/sysconfig/chronyd
ExecStart=/usr/sbin/chronyd $OPTIONS

I could be wrong, but I think the intention with /etc/sysconfig/chronyd was more for specifying option flags rather than overriding the directives from /etc/chrony.conf. (And if you actually want to change the chrony configuration, you'd directly modify /etc/chrony.conf instead; unfortunately there is no /etc/chrony.conf.d/ by default.)

That said, if we want the new code in coreos/fedora-coreos-config#2271 to be tolerant of this, probably the simplest would be to not do anything if /etc/sysconfig/chronyd was modified (i.e. applying the same diff check we currently do for /etc/chrony.conf). In such cases, we consider the chrony configuration as owned by the user.

[dustymabe]

That said, if we want the new code in coreos/fedora-coreos-config#2271 to be tolerant of this, probably the simplest would be to not do anything if /etc/sysconfig/chronyd was modified (i.e. applying the same diff check we currently do for /etc/chrony.conf). In such cases, we consider the chrony configuration as owned by the user.

yeah. Feels a bit like if you'd want to sepcify your own server and stuff you'd supply your own chrony.conf, but I agree the simplest is probably just say if the user changes anything then let them own it.

[dustymabe]

PR for the proposed change: coreos/fedora-coreos-config#2333

[fifofonix]

Tested successfully on newly provisioned node using testing-devel AMI.

[dustymabe]

The fix for this went into next stream release 38.20230402.1.0. Please try out the new release and report issues.

[dustymabe]

The fix for this went into testing stream release 37.20230401.2.0. Please try out the new release and report issues.

[dustymabe]

The fix for this went into stable stream release 37.20230401.3.0.