Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- linux:ntp [19.02.2024 13:21. ] – [Manualpage von chronyd] django
+++ linux:ntp [03.07.2024 19:56. ] (aktuell) – [Rolle] django
@@ Zeile 1: / Zeile 1: @@
+{{htmlmetatags>metatag-robots=()
+metatag-keywords=(Ansible,Arch Linux,ntp, chrony, timeserver,stratum,chronyc,chronyd)
+metatag-description=(NTP-Zeitserver mit chrony unter Arch Linux einrichten und nutzen)
+}}
 ====== NTP-Zeitserver mit chrony unter Linux einrichten und nutzen ======
 {{:linux:hourglass.png?nolink&100 |Bild: stilisierte Sanduhr}} Basis für eine zuverlässige Kommunikation zwischen netzwerkbasierten Diensten und Servern ist unter anderem eine exakte Zeitmessung. Nur so kann gewährleistet werden das Systemkomponenten wie z.B. systemd-Timer und Cronjobs zur richtigen Zeit gestartet werden und laufen. Einzelne Systeme können mit Hilfe des **N**etwork **T**ime **P**rotocol kurz **NTP** ihre Systemzeiten mit einem zentralen Zeitserver oder einem Pool von Servern zu synchronisieren. NTP wurde 1985 von David L. Mills entwickelt und wurde als [[https://tools.ietf.org/html/rfc958|RFC 958]] definiert um eine zuverlässige Zeitgabe über Netzwerke mit variabler Paketlaufzeit über das verbindungslose Protokolls **UDP** zu ermöglichen und bekam von der Internet Assigned Numbers Authority den UDP-Ports **123** zugewiesen. Das **RFC958** wurde in den letzten Jahren mehrfach überarbeitet und ergänzt und wurde letztmalig mit **[[https://www.rfc-editor.org/rfc/rfc9109|RFC 9109 - Network Time Protocol Version 4: Port Randomization]]** ergänzt.
@@ Zeile 26: / Zeile 30: @@
 ==== Chrony unter Arch Linux installieren ====
 Bei der Installation des chrony-Paketes verwenden wir unter **[[https://archlinux.org/|Arch Linux]]** den Paketmanager **''pacman''**.
-  - Als User: <code> $ sudo pacman -S chrony -y </code>
+  - Als User: <code> $ sudo pacman -S chrony</code>
-  - Als Nutzer mit Root-Rechten entsprechend: <code> $ sudo pacman -S chrony -y </code>
+  - Als Nutzer mit Root-Rechten entsprechend: <code> # pacman -S chrony</code>
 ===== Paketinhalt =====
@@ Zeile 110: / Zeile 114: @@
 Nach der Installation des **chrony** Paketes finden wir zwei Binärpakete in unserem System.
+   # ll -alF /usr/bin/chrony*
+<code>-rwxr-xr-x 1 root root  88928 Dec 24 08:56 /usr/bin/chronyc*
+-rwxr-xr-x 1 root root 297640 Dec 24 08:56 /usr/bin/chronyd*</code>
 ==== Binary chronyc ====
 **''chronyc''** ist das Commandline-Interface des chrony Daemon. **''chronyc''** ist ein Kommandozeilen-Interface-Programm, mit dem die Leistung des **chronyd** überwacht werden und mit dem man bei Bedarf während der Laufzeit verschiedene Betriebsparameter abändern kann.
@@ Zeile 130: / Zeile 137: @@
 ==== Manualpage von chronyc ====
-Bei Bedarf wirft man einen Blick in besagte Manual-Page (//zum Öffnen der im WIKI abgelegten Man-Page auf die grauen Balken klicken!//) :
+Bei Bedarf wirft man einen Blick in besagte Manual-Page.
-<accordion collapsed="false">
-<panel title="    $ man chronyc">
+     $ man chronyc
+++++ chronyc manpage |
 <code>CHRONYC(1)                                                User manual                                               CHRONYC(1)
@@ Zeile 1538: / Zeile 1546: @@
 chrony 4.5                                                2023-12-05                                                CHRONYC(1)
 </code>
-</panel>
+++++
-</accordion>
 ==== Binary chronyd ====
@@ Zeile 1574: / Zeile 1580: @@
 ==== Manualpage von chronyd ====
-Eine ausführliche Beschreibung des Daemon und seiner Optionen findet man in zugehöriger Manual-Page (//zum Öffnen der im WIKI abgelegten Man-Page auf die grauen Balken klicken!//) :
+Eine ausführliche Beschreibung des Daemon und seiner Optionen findet man in zugehöriger Manual-Page.
     $ man chronyd
@@ Zeile 1772: / Zeile 1778: @@
 ++++
 ===== Dokumentation =====
-Eine ausführliche Onlinedokumentation des Chrony Projekts findet sich auf der entsprechnden Projektseite → https://chrony-project.org/documentation.html Bei der Installation des aktuellen chrony-Paketes z.B. unter Arch Linux finden sich im Verzeichnis **''/usr/share/doc/chrony/''** auch entsprechende FAQs, READMEs, NEWS und Beispiele.
+Eine ausführliche Onlinedokumentation des Chrony Projekts findet sich auf der entsprechenden Projektseite → https://chrony-project.org/documentation.html Bei der Installation des aktuellen chrony-Paketes z.B. unter Arch Linux finden sich im Verzeichnis **''/usr/share/doc/chrony/''** auch entsprechende FAQs, READMEs, NEWS und Beispiele.
    # tree /usr/share/doc/chrony/
 <code>/usr/share/doc/chrony//
@@ Zeile 4582: / Zeile 4588: @@
 # Django : 2024-02-18
-server pool.ntp.org iburst
+pool pool.ntp.org iburst
 #######################################################################
@@ Zeile 4737: / Zeile 4743: @@
 ! allow 192.168/16
 # Django : 2024-02-18
+allow fd00::/10
 allow 10.0.0.0/24
 allow 2003:a:e0d:7603::/64
@@ Zeile 4904: / Zeile 4911: @@
 Die relevanten KOnfigurationsoptionen können wir mit Hilfe von **''grep''** uns auch gerafft anzeigen lassen.
    # grep -Ev '(^%|^$|^#|^!|^;)' /etc/chrony.conf
-<code>server pool.ntp.org iburst
+<code>pool pool.ntp.org iburst
 driftfile /var/lib/chrony/drift
 ntsdumpdir /var/lib/chrony
@@ Zeile 4910: / Zeile 4917: @@
 leapsectz right/UTC
 makestep 1.0 3
+allow fd00::/10
 allow 10.0.0.0/24
 allow 2003:a:e0d:7603::/64
@@ Zeile 4937: / Zeile 4945: @@
    # firewall-cmd --permanent --zone=idmz --add-rich-rule="rule family="ipv6" source address="2003:a:e0d:7603::/64" port protocol="udp" port="123" \
                     destination address="2003:a:e0d:7603:10::110/64" accept"
+  success
+   # firewall-cmd --permanent --zone=idmz --add-rich-rule="rule family="ipv6" source address="fd00::/10" port protocol="udp" port="123" \
+                    destination address="fd00::3:10:0:0:110/64" accept"
   success
@@ Zeile 4950: / Zeile 4964: @@
   success
-Anschliessend können wir den Firewall-Daemon einmal neu laden und anschließend überprüfen, ob die Regeln auch entsprechend unserer Definition, gezogen haben.
+   # firewall-cmd --permanent --zone=idmz --add-rich-rule="rule family="ipv6" source address="fd00::/10" port protocol="udp" port="123" \
+                    destination address="fd00::7:192:168:0:110/64" accept"
+  success
+Anschließend können wir den Firewall-Daemon einmal neu laden und anschließend überprüfen, ob die Regeln auch entsprechend unserer Definition, gezogen haben.
    # firewall-cmd --reload
@@ Zeile 4957: / Zeile 4977: @@
 Werfen wir noch kurz einen Blick in die Zone **''idmz''**:
    # firewall-cmd --zone=idmz --list-rich-rules
-<code>rule family="ipv6" icmp-type name="echo-request" accept
+<code>rule family="ipv6" source address="2003:a:e0d:7603::/64" destination address="2003:a:e0d:7603:10::110/64" port port="123" protocol="udp" accept
-rule family="ipv6" source address="2003:a:e0d:7603::/64" destination address="2003:a:e0d:7603:10::110/64" port port="123" protocol="udp" accept
+rule family="ipv6" source address="fd00::/10" destination address="fd00::3:10:0:0:110/64" port port="123" protocol="udp" accept
-rule family="ipv4" source address="10.0.0.0/24" destination address="10.0.0.110/32" port port="123" protocol="udp" accept</code>
+rule family="ipv6" icmp-type name="echo-request" accept
+rule family="ipv4" source address="10.0.0.0/24" destination address="10.0.0.110/32" port port="123" protocol="udp" accept
+</code>
 Bei Bedarf machen wir das gleiche nun noch mit der Zone **''intra''**:
    # firewall-cmd --zone=intra --list-rich-rules
-<code>rule family="ipv4" source address="10.0.10.0/24" service name="ssh" accept
+<code>rule family="ipv6" source address="2003:a:e0d:7607::/64" destination address="2003:a:e0d:7607:1920:168:0:110/64" port port="123" protocol="udp" accept
-rule family="ipv4" source address="192.168.0.0/24" destination address="192.168.0.110/32" port port="123" protocol="udp" accept
 rule family="ipv6" source address="2003:a:e0d:7607::/64" service name="ssh" accept
-rule family="ipv6" source address="2003:a:e0d:7607::/64" destination address="2003:a:e0d:7607:1920:168:0:110/64" port port="123" protocol="udp" accept</code>
+rule family="ipv6" source address="fd00::/10" destination address="fe10::7:1921:68ff:fe00:110/64" port port="123" protocol="udp" accept
+rule family="ipv4" source address="192.168.0.0/24" destination address="192.168.0.110/32" port port="123" protocol="udp" accept
+rule family="ipv4" source address="10.0.10.0/24" service name="ssh" accept</code>
 ===== Start des Daemon =====
@@ Zeile 5064: / Zeile 5087: @@
 udp        UNCONN      0           0                        [::1]:323                      [::]:*           users:(("chronyd",pid=1865,fd=6)) </code>
-=== Checking chrony Sources ===
+==== Paketfilter - Port Erreichbarkeit ====
+Bevor wir nun von einem unserer Client-Hosts, die zur Synchronisation der Uhrzeit unseren eigenen NTP-Server nutzen, mit Hilfe des Binary **''chronyc''** einzelne Tests durchführen, testen wir noch ob überhaupt der Port **123** auf unserer VM auf der der **chronyd** läuft errechbar ist. Dazu benutzen wir das Programm **''nmap''**.
+Zunächst installieren wir uns besagtes Programm-Paket, sofern es noch nichtv auf unsererm Client-Rechner vorhanden ist. Nachfolgend finden wir die Variante  der Installation unter Arch Linux mit Root-Rechten. Verwenden wir einen User ohne Root-Rechte, stellen wir einfach ein **''sudo''** dem Aufriuuf voran. Bei anderen Distributionen verwenden wir entsprechend den zugehörigen Paketmanager.
+   # pacman -S nmap
+Zunächst testen wir ob wir per **''IPv4''** den **''UDP''**-Port **''123''** (NTP) auf dem Zielhost **''10.0.0.110''**, auf dem unser **''chronyd''** als NTP-Server fungiert, erreichbar ist.
+   # nmap -4 -sU -v -p 123 10.0.0.110
+<code>Starting Nmap 7.94 ( https://nmap.org ) at 2024-02-21 18:33 CET
+Initiating ARP Ping Scan at 18:33
+Scanning 10.0.0.110 [1 port]
+Completed ARP Ping Scan at 18:33, 0.06s elapsed (1 total hosts)
+Initiating Parallel DNS resolution of 1 host. at 18:33
+Completed Parallel DNS resolution of 1 host. at 18:33, 0.00s elapsed
+Initiating UDP Scan at 18:33
+Scanning 10.0.0.110 [1 port]
+Discovered open port 123/udp on 10.0.0.110
+Completed UDP Scan at 18:33, 0.14s elapsed (1 total ports)
+Nmap scan report for 10.0.0.110
+Host is up (0.00044s latency).
+PORT    STATE SERVICE
+/udp open  ntp
+MAC Address: 52:54:00:41:11:01 (QEMU virtual NIC)
+Read data files from: /usr/bin/../share/nmap
+Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds
+           Raw packets sent: 3 (180B) | Rcvd: 2 (104B)</code>
+Soweit so gut, das hat also schon mal geklappt!
+Im nächsten Schritt versuchen wir ob wir Port **''123''** **''UDP''** per **''IPv6''** die **ULA**((**U**nique **L**ocal  **A**ddress)) **''fd00::3:10:0:0:110''** kontaktieren können.
+   # nmap -6 -sU -v -p 123 fd00::3:10:0:0:110
+<code>Starting Nmap 7.94 ( https://nmap.org ) at 2024-02-21 18:38 CET
+Initiating ND Ping Scan at 18:38
+Scanning fd00::3:10:0:0:110 [1 port]
+Completed ND Ping Scan at 18:38, 0.06s elapsed (1 total hosts)
+Initiating Parallel DNS resolution of 1 host. at 18:38
+Completed Parallel DNS resolution of 1 host. at 18:38, 0.00s elapsed
+Initiating UDP Scan at 18:38
+Scanning fd00::3:10:0:0:110 [1 port]
+Discovered open port 123/udp on fd00::3:10:0:0:110
+Completed UDP Scan at 18:38, 0.14s elapsed (1 total ports)
+Nmap scan report for fd00::3:10:0:0:110
+Host is up (0.00052s latency).
+PORT    STATE SERVICE
+/udp open  ntp
+MAC Address: 52:54:00:41:11:01 (QEMU virtual NIC)
+Read data files from: /usr/bin/../share/nmap
+Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds
+           Raw packets sent: 3 (264B) | Rcvd: 2 (168B)</code>
+Auch das wurde entsprechend positiv beschieden **''PORT → 123/udp, STATE → open, SERVICE → ntp''**.
+Zum Schluß testen wir dann noch die Variante mit der **IPv6-Unicast-Adresse** **''2003:a:e0d:7603:10::110''** unseres eignen NTP-Servers.
+   # nmap -6 -sU -v -p 123 2003:a:e0d:7603:10::110
+<code>Starting Nmap 7.94 ( https://nmap.org ) at 2024-02-21 18:41 CET
+Initiating ND Ping Scan at 18:41
+Scanning 2003:a:e0d:7603:10::110 [1 port]
+Completed ND Ping Scan at 18:41, 0.06s elapsed (1 total hosts)
+Initiating Parallel DNS resolution of 1 host. at 18:41
+Completed Parallel DNS resolution of 1 host. at 18:41, 0.00s elapsed
+Initiating UDP Scan at 18:41
+Scanning vml000110.idmz.nausch.org (2003:a:e0d:7603:10::110) [1 port]
+Discovered open port 123/udp on 2003:a:e0d:7603:10::110
+Completed UDP Scan at 18:41, 0.14s elapsed (1 total ports)
+Nmap scan report for vml000110.idmz.nausch.org (2003:a:e0d:7603:10::110)
+Host is up (0.00053s latency).
+PORT    STATE SERVICE
+/udp open  ntp
+MAC Address: 52:54:00:41:11:01 (QEMU virtual NIC)
+Read data files from: /usr/bin/../share/nmap
+Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds
+           Raw packets sent: 3 (264B) | Rcvd: 2 (168B)</code>
+Auch dieser Test war entsprechend erfolgreich! Somit können wir uns nun im Anschluss mit dem Binary **''chronyc''** und dem Testen unseres chrony-Daemon befassen.
+==== Checking chrony Sources ====
 Welche Server vom lokalen Daemon benutzt werden kann mit Hilfe des Befehls **''chronyc sources''** abgefragt werden.
    # chronyc sources
@@ Zeile 5070: / Zeile 5173: @@
 <code>MS Name/IP address         Stratum Poll Reach LastRx Last sample
 ===============================================================================
-^* kronos.mailus.de              3   8   377    91   -106us[ -128us] +/-   57ms</code>
+^* defiant.tlercher.de           2  10   377    91    +59us[ +988us] +/-   10ms</code>
+Mit der Option **''-v''** erhalten wir dazu auch noch Hinweise zu den einzelnen Spaten und deren Werte bzw. Bedeutung:
+   # chronyc sources -v
+<code>
+  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
+ / .- Source state '*' = current best, '+' = combined, '-' = not combined,
+| /             'x' = may be in error, '~' = too variable, '?' = unusable.
+||                                                 .- xxxx [ yyyy ] +/- zzzz
+||      Reachability register (octal) -.           |  xxxx = adjusted offset,
+||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
+||                                \     |          |  zzzz = estimated error.
+||                                 |    |           \
+MS Name/IP address         Stratum Poll Reach LastRx Last sample
+===============================================================================
+^+ time.cnetm.de                 2   6   377     7   +755us[ +755us] +/-   17ms
+^- frank.askja.de                2   6   377     5   -166us[ -166us] +/-   59ms
+^* ntp1.noris.net                2   6   377    72   -154us[ -125us] +/-   12ms
+^+ sv1.ggsrv.de                  2   6   377     5   +284us[ +284us] +/-   15ms
+</code>
 Dieses Beispiel zeigt die Abfrage auf unserem zentralen NTP-Server, den wir gerade eingerichtet haben. Nachfolgendes Beispiel zeigt einen Host, der wiederum unseren eigenen zentralen NTP-Server als Quelle benutzt.
-<code>MS Name/IP address         Stratum Poll Reach LastRx Last sample
+<code>
+  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
+ / .- Source state '*' = current best, '+' = combined, '-' = not combined,
+| /             'x' = may be in error, '~' = too variable, '?' = unusable.
+||                                                 .- xxxx [ yyyy ] +/- zzzz
+||      Reachability register (octal) -.           |  xxxx = adjusted offset,
+||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
+||                                \     |          |  zzzz = estimated error.
+||                                 |    |           \
+MS Name/IP address         Stratum Poll Reach LastRx Last sample
 ===============================================================================
-^* vml000110.idmz.nausch.org     4   6   377    33    +33us[  +15us] +/-   33ms
+^+ fd00::3:10:0:0:110            3   6   377    30    +92us[ +306us] +/-   11ms
-^+ 10.0.0.110                    4   6   377    33    +29us[  +29us] +/-   33ms</code>
+^* vml000110.idmz.nausch.org     3   6   377    24    +86us[ +301us] +/-   11ms
+^+ 10.0.0.110                    3   6   377    30    +87us[ +302us] +/-   11ms</code>
 Die einzelnen Spalten haben folgende Bedeutung:
@@ Zeile 5114: / Zeile 5246: @@
    chronyc> sources -v
-<code>  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
+<code>
+  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
  / .- Source state '*' = current best, '+' = combined, '-' = not combined,
 | /             'x' = may be in error, '~' = too variable, '?' = unusable.
@@ Zeile 5124: / Zeile 5257: @@
 MS Name/IP address         Stratum Poll Reach LastRx Last sample
 ===============================================================================
-^* kronos.mailus.de              3   8   377    47   +135us[ +169us] +/-   37ms
+^+ time.cnetm.de                 2   6   377     7   +755us[ +755us] +/-   17ms
+^- frank.askja.de                2   6   377     5   -166us[ -166us] +/-   59ms
+^* ntp1.noris.net                2   6   377    72   -154us[ -125us] +/-   12ms
+^+ sv1.ggsrv.de                  2   6   377     5   +284us[ +284us] +/-   15ms
 </code>
-=== Checking chrony Source Statistics ===
+==== Checking chrony Source Statistics ====
 Den Status unserer Zeitserverquellen fragen wir mit dem Befehl **chronyc sourcestats** ab.
    # chronyc sourcestats
@@ Zeile 5133: / Zeile 5269: @@
 <code>Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
 ==============================================================================
-kronos.mailus.de           26  16   35m     +0.005      0.141   +697ns   107us</code>
+time.cnetm.de              16  11   782     -0.042      1.299    -35us   292us
+frank.askja.de             16   9   783     +0.281      0.379   +169us    99us
+ntp1.noris.net              6   4   452     -0.529      0.977   -304us    43us
+sv1.ggsrv.de               14   8   784     +0.211      0.264   +434us    70us</code>
+Mit der Option **''-v''** erhalten wir eine Kurzbeschreibung der angezeigten Werte.
+   # chronyc sourcestats -v
+<code>                             .- Number of sample points in measurement set.
+                            /    .- Number of residual runs with same sign.
+                           |    /    .- Length of measurement set (time).
+                           |   |    /      .- Est. clock freq error (ppm).
+                           |   |   |      /           .- Est. error in freq.
+                           |   |   |     |           /         .- Est. offset.
+                           |   |   |     |          |          |   On the -.
+                           |   |   |     |          |          |   samples. \
+                           |   |   |     |          |          |             |
+Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
+==============================================================================
+time.cnetm.de              16  11   782     -0.042      1.299    -37us   292us
+frank.askja.de             16   9   783     +0.281      0.379   +178us    99us
+ntp1.noris.net              6   4   452     -0.529      0.977   -320us    43us
+sv1.ggsrv.de               14   8   784     +0.211      0.264   +440us    70us
+</code>
 Die einzelnen Spalten haben folgende Bedeutung:
@@ Zeile 5169: / Zeile 5327: @@
 Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
 ==============================================================================
-kronos.mailus.de           26  16   35m     +0.005      0.141  +1048ns   107us
+fd00::3:10:0:0:110          6   3   516     +0.712      4.486    +87us   185us
+vml000110.idmz.nausch.org   6   3   389     -0.745      4.072   -107us   109us
+.0.0.110                  6   3   387     +0.011      6.874    +20us   151us
 </code>
-=== Checking chrony Tracking ===
+==== Checking chrony Tracking ====
 Die Anzeige der System Zeit Informationen fragen wir mit dem Befehl **chronyc tracking** ab.
    # chronyc tracking
-<code>Reference ID    : 88F3B185 (kronos.mailus.de)
+<code>Reference ID    : 3E800112 (ntp1.noris.net)
-Stratum         : 4
+Stratum         : 3
-Ref time (UTC)  : Sun Feb 18 18:06:16 2024
+Ref time (UTC)  : Thu Feb 22 12:24:14 2024
-System time     : 0.000038475 seconds fast of NTP time
+System time     : 0.000030264 seconds slow of NTP time
-Last offset     : +0.000023120 seconds
+Last offset     : +0.000049906 seconds
-RMS offset      : 0.000039260 seconds
+RMS offset      : 0.000355495 seconds
-Frequency       : 23.886 ppm fast
+Frequency       : 23.667 ppm fast
-Residual freq   : +0.003 ppm
+Residual freq   : +0.017 ppm
-Skew            : 0.136 ppm
+Skew            : 0.322 ppm
-Root delay      : 0.029358303 seconds
+Root delay      : 0.016084936 seconds
-Root dispersion : 0.018334404 seconds
+Root dispersion : 0.002525240 seconds
-Update interval : 257.0 seconds
+Update interval : 64.5 seconds
 Leap status     : Normal</code>
@@ Zeile 5212: / Zeile 5372: @@
     * **Not synchronized** Zeit konnte noch nicht synchronisiert werden.
-=== Checking chrony Clients ===
+==== Checking chrony Clients ====
 Betreiben wir unseren chrony-Daemon im Server-Mode, können wir uns anzeigen lassen, welcher oder welche Clients sich mit dem Daemon verbunden haben, egal ob via NTP oder zum command/monitoring Port. Hierzu öffnen wir zuerst einmal die chrony-Shell auf unserem Server, auf dem der chrony-Daemon läuft.
    # chronyc -a
@@ Zeile 5230: / Zeile 5390: @@
 <code>Hostname                      NTP   Drop Int IntL Last     Cmd   Drop Int  Last
 ===============================================================================
-:a:e0d:7603:10::210        39      0   6   -    53       0      0   -     -
+fd00::3:10:0:0:210            115      0   7   -    50       0      0   -     -
-_gateway                       39      0   6   -    53       0      0   -     -
+_gateway                      110      0   6   -    50       0      0   -     -
+:a:e0d:7603:10::210        71      0   6   -    42       0      0   -     -
 </code>
@@ Zeile 5245: / Zeile 5406: @@
 ===== Orchestrierung - Installation und Konfiguration des chronyd mit Hilfe von Ansible =====
-Natürlich wird man im Jahr 2024 nicht mehr ernsthaft, manuell Server aufsetzen und betreiben wollen. Vielmehr wird amn auf ein Orchestrierungswerkzeug wie z.B. **[[linux:ansible:start|Ansible]]** zurückgreifen.
+Natürlich wird man im Jahr 2024 nicht mehr ernsthaft, manuell Server aufsetzen und betreiben wollen. Vielmehr wird man auf ein Orchestrierungswerkzeug wie z.B. **[[linux:ansible:start|Ansible]]** zurückgreifen.
 Wir werden uns nun nachfolgend sowohl die Client- wie auch die Server-Installation und -konfiguration genauer betrachten.
 ==== Installation und Client-Konfiguration ====
-Setzen wir einen neue virtuellen Host unter Arch Linux neu auf, oder wollen wir bei einem bestehenden Host die Konfiguration aktualisieren, verwenden wir wie zuvor schon angeschnitten **[[https://www.ansible.com/|Ansible]]** als Orchstrierungswerkzeug. So ist sichergestellt dass zum einen all unsere Hosts entsprechend gleich aufgebaut, konfiguriert und betrieben werden.
+Setzen wir einen neue virtuellen Host unter Arch Linux neu auf, oder wollen wir bei einem bestehenden Host die Konfiguration aktualisieren, verwenden wir wie zuvor schon angeschnitten **[[https://www.ansible.com/|Ansible]]** als Orchestrierungswerkzeug. So ist sichergestellt dass zum einen all unsere Hosts entsprechend gleich aufgebaut, konfiguriert und betrieben werden.
+=== Rolle ===
 Für die Konfiguration unserer Hosts verwenden wir eine eigene Rolle **''chrony_client''**, die wir dann in einem unserer Playbooks später einfach mit aufrufen werden.
    $ tree roles/chrony_client/
@@ Zeile 5267: / Zeile 5429: @@
 ├── templates
 └── vars</code>
+Wie wir sehen ist die Rolle durchaus überschaubar, im Task **''main.yaml''** verweisen wir lediglich auf den eigentlichen Task **''chrony.yml''**.
+   $ vim ~/ansible/roles/chrony_client/tasks/main.yml
+<file yaml roles/chrony_client/tasks/main.yml>---                                     # Playbook/Rolle zur Konfiguration des NTP-Clients
+- include_tasks: chrony.yml             # Chrony Client installieren und konfigurieren.
+  tags: chrony                          #
+...                                     # YML Ende</file>
+Die eigentliche Installation und Konfiguration erfolgt dann im Task **''chrony.yml''**.
+   $ vim ~/ansible/roles/chrony_client/tasks/chrony.yml
+<file yaml roles/chrony_client/tasks/chrony.yml>--- # YAML Start
+    # Chrony Daemon installieren und als Client konfigurieren.
+- name: "Installation des chrony-Daemons."
+  community.general.pacman:
+    name: chrony
+    state: present
+- name: "Checken ob es bereits eine Backupdatei der chrony.conf gibt."
+  ansible.builtin.stat:
+    path: /etc/chrony.conf.orig
+  register: check_chrony_config
+- name: "Sofern bereits eine Backupdatei der chrony.conf existiert, diese rücksichern."
+  ansible.builtin.copy:
+    remote_src: true
+    src: /etc/chrony.conf.orig
+    dest: /etc/chrony.conf
+    owner: root
+    group: root
+    mode: '0644'
+  when: check_chrony_config.stat.exists
+- name: "Backupdatei der chrony.conf Konfigurationsdatei erstellen."
+  ansible.builtin.copy:
+    remote_src: true
+    src: /etc/chrony.conf
+    dest: /etc/chrony.conf.orig
+    owner: root
+    group: root
+    mode: '0644'
+  when: not check_chrony_config.stat.exists
+- name: "Änderungen an der chrony.conf mit blockinfile vornehmen."
+  ansible.builtin.blockinfile:
+    path: /etc/chrony.conf
+    marker: '# {mark} ANSIBLE MANAGED - DO NOT EDIT BLOCK'
+    insertbefore: BOF
+    block: |
+      # Ansible managed configuration file, do not modify manually!
+- name: "Änderungen an der chrony.conf mit lineinfile vornehmen."
+  ansible.builtin.lineinfile:
+    dest: /etc/chrony.conf
+    regexp: '{{ item.from }}'
+    line: '{{ item.to }}'
+    state: present
+    backrefs: false
+  with_items: '{{ chrony_config }}'
+- name: "Sicherstellen, dass der chrony Service reboot(-fest) startet."
+  ansible.builtin.systemd:
+    name: chronyd
+    # state: reloaded
+    enabled: true
+... # YML Ende</file>
+=== Inventory -Variablendefinition ===
+Über die Variable **''chrony_config''** definieren wir nun im Inventory entweder in den Host- oder Group-Variablen welchen NTP-Server bzw. welchen NTP-Pool wir verwenden möchten. In Nachfolgendem Beispiel setzen wir für alle Host der Zone **edmz** als NTP-Server die Host-IP-Adressen **''fd00::3:10:0:0:110''**, **''2003:a:e0d:7603:10::110''** und **''10.0.0.110''**. Ferner setzen wir noch als Empfangs-eMail-Adresse die unseres Hauptadmins, falls chronyd einen Fehler von mehr als 0,5 Sekunden korrigieren muss.
+   $ vim inventories/production/group_vars/edmz/chrony
+<file yaml inventories/production/group_vars/edmz/chrony>chrony_config:
+  - from: 'pool 2.arch.pool.ntp.org iburst'
+    to  : |
+           server fd00::3:10:0:0:110      iburst
+           server 2003:a:e0d:7603:10::110 iburst
+           server 10.0.0.110              iburst
+  - from: '! mailonchange wibble@example.net 0.5'
+    to  : mailonchange django@nausch.org 0.5
+</file>
+=== Playbook ===
+Die definierte Rolle **chrony_client** binden wird dann z.B. in das Playbook für die Installation und Konfiguration des **chrony**-Daemon im **Client-Mode** ein.
+   # vim playbooks/arch_chrony_client.yml
+<file yaml playbooks/arch_chrony_client.yml>---
+# Ansible Playbook zum Konfigurieren des Chrony-Daemon im Client-Modus unter Arch-Linux.
+# Aufruf via $ ansible-playbook playbooks/arch_chrony_client.yml --limit <-VHOSTNAME->, also z.B.:
+#  $ ansible-playbook playbooks/arch_chrony_client.yml --limit vml000210
+# für einen Host aus der Hostgruppe DMZ.
+- name: arch_chrony_client.yml              # Name des Playbooks
+  hosts: idmz:edmz:intra                    # Hostgruppe für die das Playbook gelten soll
+  roles:
+    - role: chrony_client                   # Chrony-Client installieren und konfigurieren
+      tags: chrony_client                   # Tag-Kennzeichnung der definierten Rolle
+...
+</file>
+=== Playbooklauf ===
+Die orchestrierte Variante der Installation und Konfiguration unseres **chrony**-Daemon im **Client-Mode** gestaltet sich ab sofort sehr einfach, brauchen wir doch lediglich die Konfigurationswerte im Inventory zu hinterlegen und zu pflegen und letztendlich das Playbook entsprechend aufzurufen:
+   $ ansible-playbook playbooks/arch_chrony_client.yml --limit vml000210
+<html><pre class="code">
+<font style="color: rgb(0, 0, 0)">[19:32:35] Gathering Facts</font>
+<font style="color: rgb(25, 100, 5)">↳  vml000210 | SUCCESS | 1.81s</font>
+<font style="color: rgb(0, 0, 0)">[19:32:37] chrony_client : include_tasks</font>
+<font style="color: rgb(25, 100, 5)">↳  vml000210 | SUCCESS | 21ms</font>
+<font style="color: rgb(0, 0, 0)">[19:32:37]     ↳ chrony: Installation des chrony-Daemons.</font>
+<font style="color: rgb(25, 100, 5)">↳  vml000210 | SUCCESS | 1.34s</font>
+<font style="color: rgb(0, 0, 0)">[19:32:38]     ↳ chrony: Checken ob es bereits eine Backupdatei der chrony.conf gibt.</font>
+<font style="color: rgb(25, 100, 5)">↳  vml000210 | SUCCESS | 713ms</font>
+<font style="color: rgb(0, 0, 0)">[19:32:39]     ↳ chrony: Sofern bereits eine Backupdatei der chrony.conf existiert, diese rücksichern.</font>
+<font style="color: rgb(196, 160, 0)">↳  vml000210 | CHANGED | 661ms</font>
+<font style="color: rgb(0, 0, 0)">[19:32:40]     ↳ chrony: Backupdatei der chrony.conf Konfigurationsdatei erstellen.</font>
+<font style="color: rgb(43, 100, 164)">vml000210 | SKIPPED | 31ms</font>
+<font style="color: rgb(0, 0, 0)">[19:32:40]     ↳ chrony: Änderungen an der chrony.conf mit blockinfile vornehmen.</font>
+<font style="color: rgb(196, 160, 0)">↳  vml000210 | CHANGED | 616ms</font>
+<font style="color: rgb(0, 0, 0)">[19:32:41]     ↳ chrony: Änderungen an der chrony.conf mit lineinfile vornehmen.</font>
+<font style="color: rgb(196, 160, 0)">↳  vml000210 | CHANGED | 1.18s</font>
+<font style="color: rgb(0, 0, 0)">[19:32:42]     ↳ chrony: Sicherstellen, dass der chrony Service reboot(-fest) startet.</font>
+<font style="color: rgb(25, 100, 5)">↳  vml000210 | SUCCESS | 984ms</font>
+<font style="color: rgb(0, 0, 0)">[19:32:43] system</font>
+<font style="color: rgb(25, 100, 5)">-- Play recap --</font>
+<font style="color: rgb(196, 160, 0)">vml000210                  </font><font style="color: rgb(0, 0, 0)">: </font><font style="color: rgb(25, 100, 5)">ok=8    </font><font style="color: rgb(196, 160, 0)">changed=3    </font>unreachable=0    failed=0    <font style="color: rgb(43, 100, 164)">skipped=1</font>    rescued=0    ignored=0</font>
+</pre>
+</html>
+==== Installation und Chrony-Server-Konfiguration ====
+Damit unsere eigenen neue virtuellen Host unter Arch Linux die Zeit von unserem eigenen NTP-Server holen können werden wir nun im nächsten Konfigurationsbeispiel mit Hilfe von **[[https://www.ansible.com/|Ansible]] chrony** installieren und als NTP-Server konfigurieren.
+=== Rollen ===
+== Chrony ==
+Da sich die Installation und Konfiguration unseres **chrony** im Daemon-Modus lediglich bei den Konfigurationsparametern unterscheidet, können wir die Rolle aus dem vorherigen Beispiel einfach aufgreifen und wiederverwenden!
+   $ tree roles/chrony_client/
+++++ roles/chrony_client/ |
+<code>roles/chrony_client/
+├── defaults
+├── files
+├── handlers
+├── library
+├── lookup_plugins
+├── meta
+├── module_utils
+├── tasks
+│   ├── chrony.yml
+│   └── main.yml
+├── templates
+└── vars</code>
+++++
 Wie wir sehen ist die Rolle durchaus überschaubar, im Task **''main.yaml''** verweisen wir lediglich auf den eigentlichen Task **''chrony-.yml''**.
    $ vim ~/ansible/roles/chrony_client/tasks/main.yml
+++++ roles/chrony_client/tasks/main.yml |
 <file yaml roles/chrony_client/tasks/main.yml>---                                     # Playbook/Rolle zur Konfiguration des NTP-Clients
 - include_tasks: chrony.yml             # Chrony Client installieren und konfigurieren.
   tags: chrony                          #
 ...                                     # YML Ende</file>
+++++
 Die eigentliche Installation und Konfiguration erfolgt dann im Task **''chrony.yml''**.
    $ vim ~/ansible/roles/chrony_client/tasks/chrony.yml
+++++ roles/chrony_client/tasks/chrony.yml |
 <file yaml roles/chrony_client/tasks/chrony.yml>--- # YAML Start
-    # SSH Server Configdatei erzeugen und kopieren.
+    # Chrony Daemon installieren und als Client konfigurieren.
 - name: "Installation des chrony-Daemons."
@@ Zeile 5289: / Zeile 5605: @@
     path: /etc/chrony.conf.orig
   register: check_chrony_config
+- name: "Sofern bereits eine Backupdatei der chrony.conf existiert, diese rücksichern."
+  ansible.builtin.copy:
+    remote_src: true
+    src: /etc/chrony.conf.orig
+    dest: /etc/chrony.conf
+    owner: root
+    group: root
+    mode: '0644'
+  when: check_chrony_config.stat.exists
 - name: "Backupdatei der chrony.conf Konfigurationsdatei erstellen."
@@ Zeile 5324: / Zeile 5650: @@
 ... # YML Ende</file>
+++++
+== Firewalld - Paketfilter ==
+Der eigentliche "große" Unterschied zwischen **Client-** und **Daemon-Mode** bei unserer chrony-Konfiguration ist der Umstand, dass wir auf unserem NTP-Server mit Hilfe des Firewall-Daemon **''firewalld''** noch die Verkehrsbeziehungen freischalten und den Port **''123/UDP''** für die betreffenden Netze freischalten werden.
+Diese Konfiguration lagern wir in einer eigenen Rolle aus, da diese ja bei Hosts, die den chronyd lediglich als Client nutzen nicht benötigt wird.
+Da sich die Installation und Konfiguration unseres **chrony** im Daemon-Modus lediglich bei den Konfigurationsparametern unterscheidet, können wir die Rolle aus dem vorherigen Beispiel einfach aufgreifen und wiederverwenden!
+Für die Konfiguration der Paketfilterregeln unseres NTP-Serversverwenden wir eine eigene Rolle **chrony_firewalld**, die wir dann in einem unserer Playbooks später einfach mit aufrufen werden.
+   $ tree roles/chrony_firewalld/
+<code>roles/chrony_firewalld/
+├── defaults
+├── files
+├── handlers
+├── library
+├── lookup_plugins
+├── meta
+├── module_utils
+├── tasks
+│   ├── config.yml
+│   └── main.yml
+├── templates
+└── vars</code>
+Wie wir sehen ist die Rolle durchaus überschaubar, im Task **''main.yaml''** verweisen wir lediglich auf den eigentlichen Task **''chrony-.yml''**.
+   $ vim ~/ansible/roles/chrony_firewalld/tasks/main.yml
+<file yaml roles/chrony_firewalld/tasks/main.yml>---                                     # Playbook/Rolle zur Konfiguration des firewalld
+- include_tasks: config.yml             # firewall konfigurieren.
+  tags: config                          #
+...                                     # YML Ende
+</file>
+Die eigentliche Konfiguration unserer notwendigen Firewall-Regeln erfolgt dann im Task **''config.yml''**.
+   $ vim ~/ansible/roles/chrony_firewalld/tasks/config.yml
+<file yaml roles/chrony_firewalld/tasks/config.yml>-- # YAML Start
+    # Firewall Daemon Regeln für chrony im Daemon-Mode konfigurieren.
+- name: "Port 123/UDP für IPv4 in der Zone IDMZ freischalten."
+  ansible.posix.firewalld:
+    rich_rule: >
+      rule family=ipv4
+      source address={{ guest_ip4_net_1 }}{{ guest_mask4_1 }}
+      port protocol="udp" port="123"
+      destination address={{ guest_ip4_1 }}/32
+      accept
+    zone: '{{ guest_zone_1 }}'
+    immediate: true
+    permanent: true
+    state: enabled
+- name: "Port 123/UDP für IPv6 (ULA) in der Zone IDMZ freischalten."
+  ansible.posix.firewalld:
+    rich_rule: >
+      rule family=ipv6
+      source address=fd00::/10
+      port protocol="udp" port="123"
+      destination address={{ guest_ip6_ls_1 }}{{ guest_mask6_1 }}
+      accept
+    zone: '{{ guest_zone_1 }}'
+    immediate: true
+    permanent: true
+    state: enabled
+- name: "Port 123/UDP für IPv6 (Global-Scope) in der Zone IDMZ freischalten."
+  ansible.posix.firewalld:
+    rich_rule: >
+      rule family=ipv6
+      source address={{ guest_ip6_net_1 }}{{ guest_mask6_1 }}
+      port protocol="udp" port="123"
+      destination address={{ guest_ip6_gs_1 }}{{ guest_mask6_1 }}
+      accept
+    zone: '{{ guest_zone_1 }}'
+    immediate: true
+    permanent: true
+    state: enabled
+- name: "Port 123/UDP für IPv4 in der Zone INTRA freischalten."
+  ansible.posix.firewalld:
+    rich_rule: >
+      rule family=ipv4
+      source address={{ guest_ip4_net_2 }}{{ guest_mask4_2 }}
+      port protocol="udp" port="123"
+      destination address={{ guest_ip4_2 }}/32
+      accept
+    zone: '{{ guest_zone_2 }}'
+    immediate: true
+    permanent: true
+    state: enabled
+- name: "Port 123/UDP für IPv6 (ULA) in der Zone INTRA freischalten."
+  ansible.posix.firewalld:
+    rich_rule: >
+      rule family=ipv6
+      source address=fd00::/10
+      port protocol="udp" port="123"
+      destination address={{ guest_ip6_ls_2 }}{{ guest_mask6_2 }}
+      accept
+    zone: '{{ guest_zone_2 }}'
+    immediate: true
+    permanent: true
+    state: enabled
+- name: "Port 123/UDP für IPv6 (Global-Scope) in der Zone INTRA freischalten."
+  ansible.posix.firewalld:
+    rich_rule: >
+      rule family=ipv6
+      source address={{ guest_ip6_net_2 }}{{ guest_mask6_2 }}
+      port protocol="udp" port="123"
+      destination address={{ guest_ip6_gs_2 }}{{ guest_mask6_2 }}
+      accept
+    zone: '{{ guest_zone_2 }}'
+    immediate: true
+    permanent: true
+    state: enabled
+- name: "Regeländerungen auf vml000110 neu laden."
+  ansible.builtin.service:
+    name: firewalld
+    state: reloaded
+... # YML Ende</file>
+=== Inventory -Variablendefinition ===
+== chronyd==
+Über die Variable **''chrony_config''** definieren wir nun im Inventory in den Host-Variablen alle Konfigurationsparameter, die wir bei unserem NTP-Server bzw. genauer gesagt bei unserem **chronyd** im **Server-Mode**setzen wollen.
+   $ vim inventories/production/host_vars/vml010110/chrony
+<file yaml inventories/production/host_vars/vml010110/chrony>chrony_config:
+  - from: 'pool 2.arch.pool.ntp.org iburst'
+    to  : pool pool.ntp.org              iburst
+  - from: '! dumpdir /var/lib/chrony'
+    to  : dumpdir /var/lib/chrony
+  - from: '# is unimportant.'
+    to  : |
+          # is unimportant.
+          #
+          # nausch.org :
+          allow fd00::/10
+          allow 10.0.0.0/24
+          allow 2003:a:e0d:7603::/64
+          allow 192.168.0.0/24
+          allow 2003:a:e0d:7607::/64
+  - from: '! local stratum 10'
+    to  : local stratum 3
+  - from: '! logchange 0.5'
+    to  : logchange 0.5
+  - from: '! mailonchange wibble@example.net 0.5'
+    to  : mailonchange django@nausch.org 0.5
+  - from: '! lock_all'
+    to  : lock_all
+</file>
+== firewalld==
+Die Netzwerkspezifischen Definitionen für den Paketfilter holen wir uns aus den Netzwerk-Variablen unseres Hosts selbst.
+   $ vim inventories/production/host_vars/vml010110/kvm_vhost
+<file yaml inventories/production/host_vars/vml010110/kvm_vhost>kvm_base:           "kvm-arch"
+host_dev:           "eth0"
+host_ip:            '{{ guest_ip4_1 }}'
+guest_name:         "vml000110"
+guest_zone:         "idmz"
+guest_domain:       "nausch.org"
+guest_desc:         "Ansible-Test-VM III on new ArchLINUX"
+guest_mate:         "true"
+guest_ram:          8192
+guest_cpu:          4
+guest_imagesize:    30
+guest_imagetype:    "qcow2"
+guest_imagemode:    "compat=1.1"
+guest_source:       "archlinux-2024.01.16-x86_64.iso"
+guest_zone_1:       "idmz"
+guest_bridge_1:     "br3"
+guest_nic_1:        "eth0"
+guest_direction_1:  "idmz_2_intra"
+guest_mac_1:        "52:54:00:41:11:01"
+guest_ip4_net_1:    "10.0.0.0"
+guest_ip4_1:        "10.0.0.110"
+guest_mask4_1:      "/24"
+guest_gw4_1:        "10.0.0.210"
+guest_dns4_1:       "217.237.151.142"
+guest_ip6_ll_1:     "fe80::3:10:ff:fe00:110"
+guest_ip6_ls_1:     "fd00::3:10:0:0:110"
+guest_ip6_gs_1:     "2003:a:e0d:7603:10::110"
+guest_ip6_net_1:    "2003:a:e0d:7603::"
+guest_mask6_1:      "/64"
+guest_gw6_1:        "fd00::3:10:0:0:210"
+guest_dns6_1:       "2003:180:2:a000::53"
+guest_zone_2:       "intra"
+guest_bridge_2:     "br4"
+guest_nic_2:        "eth1"
+guest_direction_2:  "intra_2_idmz"
+guest_mac_2:        "52:54:00:41:11:02"
+guest_ip4_net_2:    "192.168.0.0"
+guest_ip4_2:        "192.168.0.110"
+guest_mask4_2:      "/24"
+guest_gw4_2:        "10.0.0.210"
+guest_dns4_2:       "217.237.151.142"
+guest_ip6_ll_2:     "fe80::7:1921:68ff:fe00:110"
+guest_ip6_ls_2:     "fd00::7:192:168:0:110"
+guest_ip6_gs_2:     "2003:a:e0d:7607:1920:168:0:110"
+guest_ip6_net_2:    "2003:a:e0d:7607::"
+guest_mask6_2:      "/64"
+guest_gw6_2:
+guest_dns6_2:
+</file>
+=== Playbook ===
+Die definierte Rollen **chrony_client** und **chrony_firewalld** binden wird dann z.B. in das Playbook für die Installation und Konfiguration des **chrony**-Daemon im **Server-Mode** ein.
+   # vim playbooks/arch_chrony_server.yml
+<file yaml playbooks/arch_chrony_server.yml>---
+# Ansible Playbook zum Konfigurieren des Chrony-Daemon im Server-Modus unter Arch-Linux.
+# Aufruf via $ ansible-playbook playbooks/arch_chrony_client.yml :
+#  $ ansible-playbook playbooks/arch_chrony_server.yml
+# für einen Host aus der Hostgruppe DMZ.
+- name: arch_chrony_server.yml              # Name des Playbooks
+  hosts: vml010110                          # Hostgruppe für die das Playbook gelten soll
+  roles:
+    - role: chrony_client                   # Chrony-Client installieren und konfigurieren
+      tags: chrony_client                   # Tag-Kennzeichnung der definierten Rolle
+    - role: chrony_firewalld                # Paketfilter-Regeln für Chrony-Server anlegen
+      tags: chrony_firewalld                # Tag-Kennzeichnung der definierten Rolle
+...
+</file>
+=== Playbooklauf ===
+Die orchestrierte Variante der Installation und Konfiguration unseres **chrony**-Daemon im **Server-Mode** gestaltet sich ab sofort sehr einfach, brauchen wir doch lediglich die Konfigurationswerte im Inventory zu hinterlegen und zu pflegen und letztendlich das Playbook entsprechend aufzurufen:
+   $ ansible-playbook playbooks/arch_chrony_server.yml
+<html><pre class="code">
+<font style="color: rgb(0, 0, 0)">[23:10:06] Gathering Facts</font>
+<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 1.79s</font>
+<font style="color: rgb(0, 0, 0)">[23:10:08] chrony_client : include_tasks</font>
+<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 24ms</font>
+<font style="color: rgb(0, 0, 0)">[23:10:08]     ↳ chrony: Installation des chrony-Daemons.</font>
+<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 1.34s</font>
+<font style="color: rgb(0, 0, 0)">[23:10:10]     ↳ chrony: Checken ob es bereits eine Backupdatei der chrony.conf gibt.</font>
+<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 679ms</font>
+<font style="color: rgb(0, 0, 0)">[23:10:10]     ↳ chrony: Sofern bereits eine Backupdatei der chrony.conf existiert, diese rücksichern.</font>
+<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 626ms</font>
+<font style="color: rgb(0, 0, 0)">[23:10:11]     ↳ chrony: Backupdatei der chrony.conf Konfigurationsdatei erstellen.
+<font style="color: rgb(43, 100, 164)">vml010110 | SKIPPED | 36ms</font>
+<font style="color: rgb(0, 0, 0)">[23:10:11]     ↳ chrony: Änderungen an der chrony.conf mit blockinfile vornehmen.</font>
+<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 607ms</font>
+<font style="color: rgb(0, 0, 0)">[23:10:12]     ↳ chrony: Änderungen an der chrony.conf mit lineinfile vornehmen.</font>
+<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 3.97s</font>
+<font style="color: rgb(0, 0, 0)">[23:10:16]     ↳ chrony: Sicherstellen, dass der chrony Service reboot(-fest) startet.</font>
+<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 984ms</font>
+<font style="color: rgb(0, 0, 0)">[23:10:17] chrony_firewalld : include_tasks</font>
+<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 36ms</font>
+<font style="color: rgb(0, 0, 0)">[23:10:17]     ↳ config: Port 123/UDP für IPv4 in der Zone IDMZ freischalten.</font>
+<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 848ms</font>
+<font style="color: rgb(0, 0, 0)">[23:10:17]     ↳ config: Port 123/UDP für IPv6 (ULA) in der Zone IDMZ freischalten.</font>
+<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 7276ms</font>
+<font style="color: rgb(0, 0, 0)">[23:10:18]     ↳ config: Port 123/UDP für IPv6 (Global-Scope) in der Zone IDMZ freischalten.</font>
+<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 697ms</font>
+<font style="color: rgb(0, 0, 0)">[23:10:19]     ↳ config: Port 123/UDP für IPv4 in der Zone INTRA freischalten.</font>
+<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 798ms</font>
+<font style="color: rgb(0, 0, 0)">[23:10:20]     ↳ config: Port 123/UDP für IPv6 (ULA) in der Zone INTRA freischalten.</font>
+<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 774ms</font>
+<font style="color: rgb(0, 0, 0)">[23:10:20]     ↳ config: Port 123/UDP für IPv6 (Global-Scope) in der Zone INTRA freischalten.</font>
+<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 804ms</font>
+<font style="color: rgb(0, 0, 0)">[23:10:21]     ↳ config: Regeländerungen auf vml000110 neu laden.</font>
+<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.02s</font>
+<font style="color: rgb(0, 0, 0)">[23:10:22] system</font>
+<font style="color: rgb(25, 100, 5)">-- Play recap --</font>
+<font style="color: rgb(196, 160, 0)">vml010110                  </font><font style="color: rgb(0, 0, 0)">: </font><font style="color: rgb(25, 100, 5)">ok=16   </font><font style="color: rgb(196, 160, 0)">changed=10   </font>unreachable=0    failed=0    <font style="color: rgb(43, 100, 164)">skipped=1</font>    rescued=0    ignored=0</font>
+</pre>
+</html>
+====== Links ======
+  * Zurück zu **[[wiki:start|Projekte und Themenkapitel]]**
+  * Zurück zu **[[centos:start|LINUX Installation und Konfiguration]]**
+  * Zurück zu **[[linux:ansible:start|Zurück zur "Ansible"-Übersicht"]]**
+  * Zurück zur **[[http://dokuwiki.nausch.org/doku.php/|Startseite]]**