Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- linux:bind [27.01.2026 14:30. ] – [Ergebniskontrolle] django
+++ linux:bind [01.02.2026 17:36. ] (aktuell) – [Rolle] django
@@ Zeile 5608: / Zeile 5608: @@
          -O - | tar -xz --strip-components=1 -C ~/devel/ansible</code>
-Nach Anpassung der Daten im **[[#vorbereitung_-_server-_daten_im_inventory|Inventory]** kann man anschliessend direkt **[[#ausfuehrung_-_playbooklauf|zur Ausführung schreiten]]**.
+Nach Anpassung der Daten im **[[#vorbereitung_-_server-_daten_im_inventory|Inventory]]** kann man anschließend direkt **[[#ausfuehrung_-_playbooklauf|zur Ausführung schreiten]]**.
 </WRAP>
@@ Zeile 5651: / Zeile 5651: @@
 ++++
-Die für deb **ISC Bind-Daemon** relevanten Konfigurationsparameter legen wir in der Inventrory-Datei **''inventories/production/host_vars/vml000110/bind''** ab.
+Die für deb **ISC Bind-Daemon** relevanten Konfigurationsparameter legen wir in der Inventory-Datei **''inventories/production/host_vars/vml000110/bind''** ab.
    $ vim inventories/production/host_vars/vml000110/bind
 ++++ inventories/production/host_vars/vml000110/bind |
@@ Zeile 5709: / Zeile 5709: @@
 === Rolle ===
-Für die Konfiguration der **ISC BIND**-Daemon verwenden wir eine eigene Rolle **''bind''**, die wir bei unserem zuvor angelegten Playbooks später einfach mit aufrufen werden. Hierzu kopieren wir uns zunächst die **[[linux:ansible:playbook_example_08|Mustervorlage]]** **''common''**, welche wir bei der initialen Ansible-Einrichtung angelegt hatten.
+Für die Konfiguration des **ISC BIND**-Daemon verwenden wir eine eigene Rolle **''bind''**, die wir bei unserem zuvor angelegten Playbooks später einfach mit aufrufen werden. Hierzu kopieren wir uns zunächst die **[[linux:ansible:playbook_example_08|Mustervorlage]]** **''common''**, welche wir bei der initialen Ansible-Einrichtung angelegt hatten.
    $ cp -avr roles/common/ roles/bind
@@ Zeile 5783: / Zeile 5783: @@
 Das Anlegen der Zonefiles erfolgt dann mit Hilfe des Task-Gruppe mit dem tag **''zonefiles''** mit den Daten aus dem Inventory konfiguriert.
 <WRAP center round important 60%>
-Damit wir uns nicht die Finger brechen bzw. wund tippen speziell bei den Reverse-IPv6-Adressen delegieren wir solch stupide und fehleranfällige Arbeiten an Ansible. Zur Konvertierung der IPv6-Adressen ist hierzu das Paket netaddr notwendig, das wir bei Bedarf mit Hilfe des Paketmanagers auf unserem Linux-Ansible-Kontrollnode/-Workstation noch installieren:
+Damit wir uns nicht die Finger brechen bzw. wund tippen speziell bei den Reverse-IPv6-Adressen delegieren wir solch stupide und fehleranfällige Arbeiten an Ansible. Zur Konvertierung der IPv6-Adressen ist hierzu das Paket python-netaddr notwendig, das wir bei Bedarf mit Hilfe des Paketmanagers auf unserem Linux-Ansible-Kontrollnode/-Workstation noch installieren:
-<code> $ sudo pacman -S netaddr</code>.
+<code> $ sudo pacman -S python-netaddr</code>.
 </WRAP>
@@ Zeile 6057: / Zeile 6057: @@
 </pre>
 </html>
+\\
 <WRAP center round tip 80%>
 In diesem Beispiel haben wir nach nicht einmal **70 Sekunden** einen voll funktionsfähigen DNSSEC-fähigen Namserver für vier Domains mit sehr umfangreichen **20 Zonefiles** mit bis zu **800 Zeilen** in einem Zone-File, die nun wirklich niemand mehr manuell pflegen will. Die automatisierte Erstellung dieser Zonefiles aus den Daten des Inventories hat unscheinbare Vorteile. Man hat sauber formatierte Zonefiles mit aktuellen Daten und die Fehleranfälligkeit durch manuelles Editieren ist auf ein Mindestmaß begrenzt und es gibt auch keine unterschiedlichen Meinungen mehr im Admin-Team ob nun so ein Zonefile mit TABs oder SPACEes formatiert werden soll! ;)