timesync
timesync copied to clipboard
chrony.conf ubuntu crash
The timesync role places the chrony.conf into /etc for each OS. Ubuntu (DEBIAN) expects the config in the /etc/chrony/ directory. Should be handled inside /tasks/main.yml as os specific variable.
- name: Generate chrony.conf file
template:
src: chrony.conf.j2
dest: /etc/chrony.conf
backup: true
mode: 0644
notify: restart {{ 'chronyd' if timesync_mode == 1 else 'timemaster' }}
when:
- timesync_mode != 2
- timesync_ntp_provider == 'chrony'
- "'chrony' in ansible_facts.packages"
The directory should be set in a file in vars/
- we have a Debian file - https://github.com/linux-system-roles/timesync/blob/master/vars/Debian.yml - is it different than Ubuntu?
Ubuntu expects the chrony.conf as describe above in a different directory. The Path is hardcoded in the main.yml see template copy process I quoted above. Would be great if we could introduce an option to change the target path for the template within the debian vars file as you mentioned.
Rather than add a "one-off" setting specifically for Ubuntu to tasks/main.yml, I would like to refactor the code to handle this case better:
- refactor tasks/set_vars.yml to use this method https://github.com/redhat-cop/automation-good-practices/tree/main/roles#platform-specific-variables instead of the "first found" method
- this will allow use to consolidate all of the various
vars/Platform_Ver.yml
intovars/Platform.yml
- add a new var
timesync_chrony_config_path
- in vars/RedHat.yml this will be/etc/chrony.conf
- vars/Debian.yml will use/etc/chrony/chrony.conf
(I believe os_family Debian includes Ubuntu - if not, then add a vars/Ubuntu.yml) - use
timesync_chrony_config_path
for https://github.com/redhat-cop/automation-good-practices/tree/main/roles#platform-specific-variables
We can then use this same approach for /etc/ntp.conf, /etc/ptp4l.conf, /etc/sysconfig/phc2sys, /etc/sysconfig/network, and any other platform differences.
One problem is that even though the code "supports" Debian, Ubuntu, etc., we have no CI testing on anything except RedHat os_family platforms, so we would have no way of knowing if the refactoring introduced any regressions.
I have made a PR addressing the location #187 as the role didn't crash on Debian, but the configuration wasn't effectuated after running the role :sweat_smile:
That should fix this issue as well, as Ubuntu should match with os_family
.