Schlagwort-Archive: chrony

RHEL System Roles: timesync

In diesem dritten Teil meiner Serie über RHEL System Roles nutze ich die Rolle timesync, um die NTP-Pool-Zone de.pool.ntp.org für meine Hosts zu konfigurieren.

Ich möchte mit diesem Artikel zeigen, wie einfach die Nutzung der RHEL System Roles ist, um eine Gruppe von RHEL-Servern zu konfigurieren. Dabei muss ich mich nicht um Details wie die Frage kümmern, ob auf meinen Zielhosts ntpd oder chronyd für die Zeitsynchronisierung genutzt wird. Diese Aufgabe löst die Ansible-Rolle für mich.

Bevor ich fortfahre, habe ich eine Warnung: Diese Rolle ersetzt die Konfiguration auf den Zielsystemen. Alle zuvor dort getroffenen Einstellungen werden verloren gehen.

Man muss sich also entscheiden, ob man die Zeitsynchronisation komplett über diese Rolle steuern möchte oder gar nicht.

Voraussetzungen

Auf dem Ansible-Controller müssen die Pakete ansible-core und rhel-system-roles installiert sein.

Das Playbook

Ich möchte mehrere NTP-Server konfigurieren. Für diesen Anwendungsfall liefert die Rolle timesync bereits ein Beispiel mit, welches ich mittels Copy-Paste-and-Modify in mein Playbook übernehme.

[root@ansible-ctrl ]# cp /usr/share/doc/rhel-system-roles/timesync/example-multiple-ntp-servers-playbook.yml ansible/use_de_ntp_servers.yml

Das Playbook sieht nach der Anpassung wie folgt aus:

- hosts: all
  vars:
    timesync_ntp_servers:
      - hostname: 0.de.pool.ntp.org
        iburst: yes
      - hostname: 1.de.pool.ntp.org
        iburst: yes
      - hostname: 2.de.pool.ntp.org
        iburst: yes
      - hostname: 3.de.pool.ntp.org
        iburst: yes
  roles:
    - rhel-system-roles.timesync

Testlauf in Labor-Umgebung

Um zu sehen, wie die Datei /etc/chrony.conf vor und nach dem Playbook-Lauf aussieht, lasse ich das Playbook zuerst mit den Optionen -C (aktiviert Check-Mode) und -D (zeigt die Änderungen an) laufen. So kann ich vorab prüfen, welche Änderungen vorgenommen werden, bevor es ernst wird. Die Ausgabe ist über 500 Zeilen lang. Ich habe sie auf Gist gepostet und hier eingebunden. Wer sich für die Ausgabe nicht interessiert, kann direkt zur Zusammenfassung springen.

Anschließend habe ich das Playbook ohne die Optionen -C und -D ausgeführt und meine Hosts wie gewünscht konfiguriert.

Zusammenfassung

Mit der RHEL System Role timesync kann die Zeitsynchronisation verschiedener RHEL-Releases schnell und einfach konfiguriert werden, ohne Kenntnis über die konkrete Implementierung auf den Zielsystemen zu besitzen.

Gleichzeitig kann ein Blick in die Struktur der Rolle und den Inhalt der dazugehörigen Dateien Aufschluss darüber geben, wie Ansible-Rollen für mehrere RHEL-Major-Releases erstellt werden können. Man kann dies für die Erstellung eigener Rollen mit ein wenig Transferleistung wiederverwenden.

  1. Red Hat Enterprise Linux (RHEL) System Roles {en}
  2. Ansible Documentation: Role Directory Structure {en}
  3. Red Hat Software and Download Center {en}
  4. Die Vorteile einer Red Hat Subskription
  5. RHEL System Roles: selinux
  6. RHEL System Roles: sshd
  7. RHEL System Roles: firewall

Ansible kontrolliert /etc/chrony.conf

Damit neue Linux-VMs die richtige Zeit finden, habe ich mir eine kleine Ansible-Rolle namens chrony erstellt, welche ich im Folgenden vorstellen möchte.

# tree chrony/
chrony/
├── handlers
│   └── main.yml
├── tasks
│   └── main.yml
└── templates
    └── chrony.conf.j2

Die Rolle kommt sehr minimalistisch daher und umfasst nur die zwingend erforderlichen Verzeichnisse und Dateien. Sie ähnelt sehr stark der Rolle resolv.conf, welche ich bereits in diesem Beitrag beschrieben habe.

tasks/main.yml

---
- name: make sure chronyd is installed
  yum:
    name: chrony
    state: latest
    update_cache: yes

- name: deploy chrony.conf template
  template:
    src: /data/ansible/roles/chrony/templates/chrony.conf.j2
    dest: /etc/chrony.conf
    owner: root
    group: root
    mode: 0644
    backup: yes
  notify:
  - restart chronyd

Im ersten Task nutze ich das Modul yum, um sicherzustellen, dass das chrony-Paket auch installiert ist, um dieses im zweiten Schritt zu konfigurieren.

Der zweite Task nutzt das Modul template, um aus der Datei unter roles/chrony/templates/chrony.conf.j2 die Zielkonfiguration in der Datei /etc/chrony.conf auf dem Zielsystem zu erstellen. Aktuell enthält mein Template statischen Text und ich hätte genauso gut das Modul copy nutzen können, um diese Datei auf das Zielsystem zu bringen. Ich verwende jedoch das template-Modul, um mir die Möglichkeit offen zu halten, durch Verwendung von Variablen den Inhalt dynamisch erstellen zu lassen.

Am Ende des zweiten Tasks wird ein Handler namens ‚restart chronyd‘ aufgerufen. Die Funktionsweise von Handlern habe ich bereits in DNS-Konfiguration mit Ansible beschrieben. Bitte lest für weitere Informationen dort nach.