Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding the timesync_ntp_allow variable for setuping a server as source server #48

Open
florian0410 opened this issue Sep 20, 2019 · 1 comment

Comments

@florian0410
Copy link

We started to use the role in a private cloud and we are using a single server that connect to externals ntp servers for synchronization while other are offline.

We would like to use it as an NTP server and client at the same time.
From what I read we need to use the configuration allow https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/sect-understanding_chrony_and-its_configuration

We should add a new variable to handle this in timesync/templates/chrony.conf.j2, for example:

timesync_allow_network:
  - ip_net: 127.0.1.0/24

Which would result in the vars like this:

{% if timesync_allow_network is defined %}
{% for value in timesync_allow_network %}
{{ 'allow' if 'ip_net' in value and value['ip_net'] }} {{value['ip_net'] }}
{% endfor %}
{% endif %}

Resulting in in the configuration as follow :

allow 127.0.1.0/24
@mlichvar
Copy link
Collaborator

As currently documented, this role is meant only for configuring NTP clients and/or PTP slaves. It might make sense to extend it into a NTP server, but we need to consider all supported use cases and how it will work with future improvements. For instance, if the role is configured with a single PTP domain, there is no ntpd/chronyd currently running. Should it be started? Or would it be better to rely on a separate "NTP server" role?

PR #46 is a similar issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants