Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
linux:kea [19.10.2024 14:39. ] – [Rolle] djangolinux:kea [14.03.2025 13:17. ] (aktuell) – [Ergebniskontrolle] django
Zeile 7: Zeile 7:
  
 |< 100% 5% 8% 12% 12% 12% 12% 12% >| |< 100% 5% 8% 12% 12% 12% 12% 12% >|
-^  Subnetz \\ (ID)  ^  Subnetz \\ (Use)  ^ Subnetz Prefix\\ (global Unicast)  ^ Host\\ -       ^ IPv4\\ -         ^ Link-Local-Scope\\ -                ^ Unique-Local-Scope\\  (ULA)          ^ Global-Scope\\ (GUA)             ^ +^  Subnetz \\ (ID)  ^  Subnetz \\ (Use)  ^ Subnetz Prefix\\ (global Unicast)  ^ Host\\ -       ^ IPv4\\ -         ^ Link-Local-Scope\\ (LLA)            ^ Unique-Local-Scope\\  (ULA)          ^ Global-Scope\\ (GUA)             ^ 
-|  **7**            |  Intra             | 2003:a:e0d:760**7**::/64                          |                  |                                                                          |                                  | +|  **7**            |  Intra             | 2003:a:bcd:123**4**::/64                          |                  |                                                                          |                                  | 
-|                                      |                                    | //pml010073//  | ''10.0.10.73''   | ''fe80::e9a6::bb03:1544:b0000/64''  | ''fdb6:cb48:9d77:0:10:0:10:073/64''  | ''2003:a:e0d:7607:10:0:10:73''   | +|                                      |                                    | //pml010073//  | ''10.0.10.73''   | ''fe80::e9a6::bb03:1544:b0000/64''  | ''fd00:dead:beef:0:10:0:10:073/64''  | ''2003:a:bcd:1234:10:0:10:73''   | 
-|                                      |                                    | //pml010102//  | ''10.0.10.102''  | ''fe80::10:ff:fe10:102''            | ''fdb6:cb48:9d77:0:10:0:10:102/64''  | ''2003:a:e0d:7607:10:0:10:102'' +|                                      |                                    | //pml010102//  | ''10.0.10.102''  | ''fe80::10:ff:fe10:102''            | ''fdb6:dead:beef:0:10:0:10:102/64''  | ''2003:a:bcd:1234:10:0:10:102'' 
-|                                      |                                    | //vml010110//  | ''10.0.10.110''  | ''fe80::10:ff:fe10:110''            | ''fdb6:cb48:9d77:0:10:0:10:110/64''  | ''2003:a:e0d:7607:10:0:10:110''  |+|                                      |                                    | //vml010110//  | ''10.0.10.110''  | ''fe80::10:ff:fe10:110''            | ''fdb6:dead:beef:0:10:0:10:110/64''  | ''2003:a:bcd:1234:10:0:10:110''  |
  
  
Zeile 1152: Zeile 1152:
 ==== Grund-Konfiguration ==== ==== Grund-Konfiguration ====
 === Firewall/Paketfilter - firewalld === === Firewall/Paketfilter - firewalld ===
-Bevor wir nun unseren **Kea-DHCP-Daemon** Konfigurieren und starten müssen wir natürlich sicherstellen, dass auf dem betreffendem Host auch die Kommunikationsbeziehungen entsprechend erlaubt sind.  +Bevor wir nun unseren **Kea-DHCP-Daemon** konfigurieren und starten müssen wir natürlich sicherstellen, dass auf dem betreffendem Host auch die Kommunikationsbeziehungen entsprechend erlaubt sind.  
  
 Wie auch schon früher bei **CentOS** ab Release **7** bzw. den nachfolgenden Relaese-Kandidaten **Stream von RHEL** nutzen wir auch unter **Arch Linux** den dynamischen **[[https://firewalld.org/|firewalld]]** Service. Ein grosser Vorteil der dynamischen Paketfilterregeln ist unter anderem, dass zur Aktivierung der neuen Firewall-Regel(n) nicht der Daemon durchgestartet werden muss und somit alle aktiven Verbindungen kurz getrennt werden. Sondern unsere Änderungen können **//on-the-fly//** aktiviert oder auch wieder deaktiviert werden. Wie auch schon früher bei **CentOS** ab Release **7** bzw. den nachfolgenden Relaese-Kandidaten **Stream von RHEL** nutzen wir auch unter **Arch Linux** den dynamischen **[[https://firewalld.org/|firewalld]]** Service. Ein grosser Vorteil der dynamischen Paketfilterregeln ist unter anderem, dass zur Aktivierung der neuen Firewall-Regel(n) nicht der Daemon durchgestartet werden muss und somit alle aktiven Verbindungen kurz getrennt werden. Sondern unsere Änderungen können **//on-the-fly//** aktiviert oder auch wieder deaktiviert werden.
Zeile 1180: Zeile 1180:
 Werfen wir noch kurz einen Blick in die Zone **''intra''**: Werfen wir noch kurz einen Blick in die Zone **''intra''**:
    
-   # firewall-cmd --zone=intra --list-services+<code> # firewall-cmd --zone=intra --list-services</code>
  
   dhcp dhcpv6   dhcp dhcpv6
Zeile 3080: Zeile 3080:
 Der ungeduldigen Leser kann auch direkt zur Tat schreiten und das manuelle Anlegen der Inventory-Hülle, des Playbooks und der zugehörigen Rolle überspringen und diese Aufgaben mit folgendem Befehl sozusagen auf einem Rutsch erledigen: Der ungeduldigen Leser kann auch direkt zur Tat schreiten und das manuelle Anlegen der Inventory-Hülle, des Playbooks und der zugehörigen Rolle überspringen und diese Aufgaben mit folgendem Befehl sozusagen auf einem Rutsch erledigen:
  
-<code> $ mkdir -p ~/devel/ansible ; wget https://gitlab.nausch.org/django/example_kea/-/archive/main/example_kea-main.tar.gz -O - | tar -xz --strip-components=1 -C ~/devel/ansible</code>+<code> $ mkdir -p ~/devel/ansible ; wget https://gitlab.nausch.org/django/example_kea/-/archive/main/example_kea-main.tar.gz 
 +         -O - | tar -xz --strip-components=1 -C ~/devel/ansible</code>
  
 Nach Anpassung der Daten im Inventory kann man anschliessend direkt **[[#ausfuehrung_-_playbooklauf|zur Ausführung schreiten]]**. Nach Anpassung der Daten im Inventory kann man anschliessend direkt **[[#ausfuehrung_-_playbooklauf|zur Ausführung schreiten]]**.
Zeile 3129: Zeile 3130:
  
 Die beiden Beispiel-Hosts aus der Gruppe|Zone **''intra''** in diesem Inventory symbolisieren folgende unterschiedlichen Knoten.  Die beiden Beispiel-Hosts aus der Gruppe|Zone **''intra''** in diesem Inventory symbolisieren folgende unterschiedlichen Knoten. 
-  * Der Host **''pnc010007''** steht exeplarisch für einen Client im Intranet. In dessen Inventory-File **''inventories/production/host_vars/pnc010007''** sind die ihn beschreibenden Datein enthalten.+  * Der Host **''pnc010007''** steht exemplarisch für einen Client im Intranet. In dessen Inventory-File **''inventories/production/host_vars/pnc010007''** sind die ihn beschreibenden Dateien enthalten.
   * Der Host **''vml010110''** ist in diesem Beispiel unser Server, der die Verbindung zwischen der Zone **''intra''** und der Aussenwelt herstellt. Auf diesem Konten läuft bereits ein **[[linux:ntp|Chrony Timeserver|]]** wie auch eine Firewall auf Basis von **[[https://firewalld.org/|firewalld]]** der eine Zonendefinition **''intra''** besitzt, die die Regeln für diese Zone beinhalten. Sowohl Timeserver wie auch Firewall werden in diesem Beispiel hier nur erwähnt, da in dem Playbook bzw.genauer gesagt im Inventory darauf referenziert wird.    * Der Host **''vml010110''** ist in diesem Beispiel unser Server, der die Verbindung zwischen der Zone **''intra''** und der Aussenwelt herstellt. Auf diesem Konten läuft bereits ein **[[linux:ntp|Chrony Timeserver|]]** wie auch eine Firewall auf Basis von **[[https://firewalld.org/|firewalld]]** der eine Zonendefinition **''intra''** besitzt, die die Regeln für diese Zone beinhalten. Sowohl Timeserver wie auch Firewall werden in diesem Beispiel hier nur erwähnt, da in dem Playbook bzw.genauer gesagt im Inventory darauf referenziert wird. 
  
Zeile 3168: Zeile 3169:
  
 === Playbook === === Playbook ===
-Unser Playbook zum Installieren und Konfigurieren der beiden Kea-Daemon **kea-dhcp4** und **kea-dhcp6**, ist wie imer schlank, unscheinbar und unspektakulär, beinhaltet aber Hinweise zur Aufgabe und wie es aufzurufen ist.+Unser Playbook zum Installieren und Konfigurieren der beiden Kea-Daemon **kea-dhcp4** und **kea-dhcp6**, ist wie immer schlank, unscheinbar und unspektakulär, beinhaltet aber Hinweise zur Aufgabe und wie es aufzurufen ist.
    $ vim playbooks/kea_dhcp.yml    $ vim playbooks/kea_dhcp.yml
 ++++ playbooks/kea_dhcp.yml | ++++ playbooks/kea_dhcp.yml |
Zeile 3177: Zeile 3178:
  
 === Rolle === === Rolle ===
-Für die Konfiguration der **kea**-Daemon verwenden wir eine eigene Rolle **''kea_dhcp''**, die wir bei unserem zuvor angelegten Playbooks später einfach mit aufrufen werden. hierzu kopieren wir uns zunächst die Mustervorlage **''common''**.+Für die Konfiguration der **kea**-Daemon verwenden wir eine eigene Rolle **''kea_dhcp''**, die wir bei unserem zuvor angelegten Playbooks später einfach mit aufrufen werden. Hierzu kopieren wir uns zunächst die Mustervorlage **''common''**.
    $ cp -avr roles/common/ roles/kea_dhcp    $ cp -avr roles/common/ roles/kea_dhcp
  
Zeile 3273: Zeile 3274:
 ++++ ++++
  
-Sollte bei der Abarbeitung des Playbook eine oder beide Konfigurationsdateien **''kea-dhcp4.conf''** und **''kea-dhcp6.conf''** verändert werden, ist natürlich hierbei ein Restart der betreffenden Kea-Daemon notwenig. Hierzu verwenden wir die **[[https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_handlers.html|Ansible Playbook Handlers]]**. Diese Handler werden in den beiden Tasks zur Erstellung der Kea-Konfigurationsdateien mit Hilfe eines **handler**-Calls aufgerufen, sofern sich die Datei verändert hat. +Sollte bei der Abarbeitung des Playbook eine oder beide Konfigurationsdateien **''kea-dhcp4.conf''** und **''kea-dhcp6.conf''** verändert werden, ist natürlich hierbei ein Restart der betreffenden Kea-Daemon notwendig. Hierzu verwenden wir die **[[https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_handlers.html|Ansible Playbook Handlers]]**. Diese Handler werden in den beiden Tasks zur Erstellung der Kea-Konfigurationsdateien mit Hilfe eines **handler**-Calls aufgerufen, sofern sich die Datei verändert hat. 
  
 Zu guter Letzt brauchen wir noch eine Konfiguration der Aufgaben die bei einem **''notify''** abgearbeitet werden sollen. Zu guter Letzt brauchen wir noch eine Konfiguration der Aufgaben die bei einem **''notify''** abgearbeitet werden sollen.
Zeile 3299: Zeile 3300:
  
 === Ausführung - Playbooklauf === === Ausführung - Playbooklauf ===
-Die orchestrierte Variante der Installation und Konfiguration unseres **radvd**-Daemon 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:  +Die orchestrierte Variante der Installation und Konfiguration unserer **kea**-Daemon 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, wenn z.B. ein Client im Intranet hinzugefügt, entfernt oder ausgetauscht wird:  
-   $ ansible-playbook playbooks/arch_radvd.yml+   $ ansible-playbook playbooks/kea_dhcp.yml
  
 <html><pre class="code"> <html><pre class="code">
-<font style="color: rgb(0, 0, 0)">[22:15:26] Gathering Facts</font> +<font style="color: rgb(0, 0, 0)">[16:43:13] Gathering Facts</font> 
-<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 1.98s</font> +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 2.19s</font> 
-<font style="color: rgb(0, 0, 0)">[22:15:28radvd : Installation und Konfiguration des Router Advertisement Daemon radvd.</font>+<font style="color: rgb(0, 0, 0)">[16:43:15] kea-dhcp Installation des Kea DHCP-Servers.</font> 
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 7ms</font> 
 +<font style="color: rgb(0, 0, 0)">[16:43:15    ↳ vorbereitung: Vorhandenes System aktualisieren.</font> 
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 2.45s</font> 
 +<font style="color: rgb(0, 0, 0)">[16:43:17]     ↳ vorbereitung: Installation der benötigten kea Pakete.</font> 
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 1.63s</font> 
 +<font style="color: rgb(0, 0, 0)">[16:43:19] kea-dhcp : Konfiguration des Kea DHCP4-Servers.</font>
 <font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 12ms</font> <font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 12ms</font>
-<font style="color: rgb(0, 0, 0)">[22:15:28]     ↳ installInstallation des Router Advertisement Daemon radvd.</font> +<font style="color: rgb(0, 0, 0)">[16:43:19]     ↳ dhcp4Checken ob es bereits eine Backupdatei der kea-dhcp4.conf gibt.</font> 
-<font style="color: rgb(1961600)">↳  vml010110 | CHANGED | 3.14s</font> +<font style="color: rgb(251005)">↳  vml010110 | SUCCESS 609ms</font> 
-<font style="color: rgb(0, 0, 0)">[22:15:31]     ↳ install: Checken ob es bereits eine Backupdatei der radvd.conf gibt.</font> +<font style="color: rgb(0, 0, 0)">[16:43:19]     ↳ dhcp4: Backupdatei der Konfigurationsdatei kea-dhcp4.conf erstellen.</font> 
-<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 654ms</font> +<font style="color: rgb(3, 99, 84)">vml010110 | SKIPPED | 9ms</font> 
-<font style="color: rgb(0, 0, 0)">[22:15:32]     ↳ install: Backupdatei der radvd.conf Konfigurationsdatei erstellen.</font> +<font style="color: rgb(0, 0, 0)">[16:43:20]     ↳ dhcp4: Individuelle Konfigurationsdatei kea-dhcp4.conf erzeugen und kopieren.</font> 
-<font style="color: rgb(1961600)">↳  vml010110 | CHANGED 705s</font> +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 1.19s</font> 
-<font style="color: rgb(0, 0, 0)">[22:15:32]     ↳ installGenerieren und kopieren der radvd Konfigurationsdatei /etc/radvd.conf</font> +<font style="color: rgb(0, 0, 0)">[16:43:21]     ↳ dhcp4: Sicherstellen, dass der kea-dhcp4 Daemon reboot(-fest) startet.</font> 
-<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.13s</font> +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 918ms<font> 
-<font style="color: rgb(0, 0, 0)">[22:15:34radvd : Konfiguration des firewalld für den Router Advertisement Daemon radvd.</font> +<font style="color: rgb(0, 0, 0)">[16:43:22] kea-dhcp Konfiguration des Kea DHCP6-Servers.</font> 
-<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 17ms</font> +<font style="colorrgb(25, 100, 5)">↳  vml010110 | SUCCESS | 10ms<font> 
-<font style="color: rgb(0, 0, 0)">[22:15:34]     ↳ firewalld: Sicherstellen, dass der Firewall-Daemon reboot(-fest) starten.</font> +<font style="color: rgb(0, 0, 0)">[16:43:22]     ↳ dhcp6: Checken ob es bereits eine Backupdatei der kea-dhcp6.conf gibt.</font> 
-<font style="color: rgb(1961600)">↳  vml010110 | CHANGED 1.40s</font> +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 524ms<font> 
-<font style="color: rgb(0, 0, 0)">[22:15:35]     ↳ firewalld: Service basierte Rules je Zone definieren.</font> +<font style="color: rgb(0, 0, 0)">[16:43:22]     ↳ dhcp6: Backupdatei der Konfigurationsdatei kea-dhcp6.conf erstellen.</font> 
-<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 872ms</font> +<font style="color: rgb(39984)">vml010110 | SKIPPED 14ms<font> 
-<font style="color: rgb(0, 0, 0)">[22:15:36]     ↳ firewalld: Zum Schluss den aktuellen permanenten Regelsatz final neu laden.</font> +<font style="color: rgb(0, 0, 0)">[16:43:22]     ↳ dhcp6Individuelle Konfigurationsdatei kea-dhcp6.conf erzeugen und kopieren.</font> 
-<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 928ms</font> +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.31s<font> 
-<font style="color: rgb(0, 0, 0)">[22:15:37] system</font>+<font style="color: rgb(0, 0, 0)">[16:43:24]     ↳ dhcp6: Sicherstellen, dass der kea-dhcp4 Daemon reboot(-fest) startet.</font> 
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 826ms</font> 
 +<font style="color: rgb(0, 0, 0)">[16:43:24kea-dhcp : Konfiguration der firewalld-Regeln für beide Kea Daemons.</font> 
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 27ms</font> 
 +<font style="color: rgb(0, 0, 0)">[16:43:24]     ↳ firewalld: Konfiguration der firewalld Regeln in Zone_1 für die Kea-Daemon.</font> 
 +<font style="color: rgb(251005)">↳  vml010110 | SUCCESS 5.09s</font> 
 +<font style="color: rgb(0, 0, 0)">[16:43:30]     ↳ firewalld: Konfiguration der firewalld Regeln in Zone_2 für die Kea-Daemon./font> 
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 5.12s</font> 
 +<font style="color: rgb(0, 0, 0)">[16:43:35]     ↳ firewalld: Zum Schluss den aktuellen permanenten Regelsatz final neu laden.</font> 
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 918ms</font> 
 +<font style="color: rgb(25, 100, 5)">triggering handler | kea-dhcp : Restart dhcp6</font> 
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.76s</font> 
 +<font style="color: rgb(0, 0, 0)">[16:43:36] system</font>
 <font style="color: rgb(25, 100, 5)">-- Play recap --</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=10   </font><font style="color: rgb(196, 160, 0)">changed=   </font>unreachable=0    failed=0    skipped=   rescued=0    ignored=0</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=17   </font><font style="color: rgb(196, 160, 0)">changed=   </font>unreachable=0    failed=0    <font style="color: rgb(3, 99, 84)">skipped=2</font>    <font style="color: rgb(0, 0, 0)">rescued=0    ignored=0</font>
 </pre> </pre>
 </html> </html>
  
-/* +==== Ergebniskontrolle ==== 
-[15:40:36] Gathering Facts +Ob die Konfigurationsdateien valide erstellt und auch von den Kea-Daemons erfolgreich geladen worden sind, kontrollieren wir zum Beispiel auf dem Zielhost mit einem Blick in die betreffenden Konfigurationsdateien, mit Hilfe der Option **''-t''** beim jeweiligen kea-binarys, oder mit Hilfe der **''status''**-Abfrage des betreffenden Kea-Daemons
-↳  vml010110 | SUCCESS | 3.43s +  * **kea-dhcp4** <code> # bat /etc/kea/kea-dhcp4.conf</code><code> # kea-dhcp4 -t /etc/kea/kea-dhcp4.conf</code><code> # systemctl status kea-dhcp4</code> 
-[15:40:40] radvd : Prüfen ob die Variablen für GUA und ULA valide Werte haben. +  * **kea-dhcp6** <code> # bat /etc/kea/kea-dhcp6.conf</code><code> # kea-dhcp6 -t /etc/kea/kea-dhcp6.conf</code><code> # systemctl status kea-dhcp6</code> 
-↳  vml010110 | SUCCESS | 12ms + 
-[15:40:40]     ↳ variablencheck: Prüfen ob die Variable radvd_gua_mode gesetzt wurde. +====== Links ====== 
-↳  vml010110 | SUCCESS | 34ms +  * **[[linux:ansible:detail|zurück zum Kapitel "Ansible - Erweiterte Konfigurationsbeispiele"]] <= ** 
-[15:40:40]     ↳ variablencheck: Prüfen ob die Variable radvd_ula_mode gesetzt wurde. +  * **=> [[linux:dhcpd|weiter zum Kapitel "DNS Server für IPv4|6 unter Arch Linux einrichten und nutzen"]] <= ** 
-↳  vml010110 | SUCCESS | 34ms +  * **[[linux:start#ansible|Zurück zur "Ansible"-Übersicht]]** 
-[15:40:40]     ↳ variablencheck: Prüfen ob die beiden Variable raddv_gua_mode und radvd_ula_mode = noone sind+  * **[[wiki:start|Zurück zu >>Projekte und Themenkapitel<<]]** 
-vml010110 | SKIPPED | 19ms +  * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**
-[15:40:40] radvd : Installation und Konfiguration des Router Advertisement Daemon radvd+
-↳  vml010110 | SUCCESS | 13ms +
-[15:40:40]     ↳ install: Installation des Router Advertisement Daemon radvd. +
-↳  vml010110 | SUCCESS | 4.12s +
-[15:40:44]     ↳ install: Checken ob es bereits eine Backupdatei der radvd.conf gibt. +
-↳  vml010110 | SUCCESS | 765ms +
-[15:40:45]     ↳ install: Backupdatei der radvd.conf Konfigurationsdatei erstellen. +
-vml010110 | SKIPPED | 18ms +
-[15:40:45]     ↳ install: GUA _oder_ ULA: Generieren und kopieren der radvd Konfigurationsdatei /etc/radvd.conf +
-vml010110 | SKIPPED | 17ms +
-[15:40:45]     ↳ install: GUA _und_ ULA: Generieren und kopieren der radvd Konfigurationsdatei /etc/radvd.conf +
-↳  vml010110 | CHANGED | 1.30s +
-[15:40:46    ↳ install: Restart des radvd zur Aktivierung der Konfiguration. +
-↳  vml010110 | CHANGED | 1.08s +
-[15:40:47] radvd : Konfiguration des firewalld für den Router Advertisement Daemon radvd. +
-↳  vml010110 SUCCESS | 16ms +
-[15:40:47    ↳ firewalld: Sicherstellen, dass der Firewall-Daemon reboot(-fest) starten. +
-↳  vml010110 | CHANGED | 1.12s +
-[15:40:48    ↳ firewalld: Service basierte Rules je Zone definieren +
-↳  vml010110 | SUCCESS | 874ms +
-[15:40:49    ↳ firewalld: Zum Schluss den aktuellen permanenten Regelsatz final neu laden. +
-↳  vml010110 | CHANGED | 852ms +
-[15:40:50] system +
--- Play recap -- +
-vml010110                  : ok=13   changed=4    unreachable=0    failed=0    skipped=3    rescued=0    ignored=0    +
-✔ ~/devel/ansible [main|✚ 1+
  
-*/ 
-FIXME 
  • linux/kea.1729348785.txt.gz
  • Zuletzt geändert: 19.10.2024 14:39.
  • von django