Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- linux:ansible:playbook_example_14 [29.05.2023 16:32. ] – django
+++ linux:ansible:playbook_example_14 [09.06.2024 08:14. ] (aktuell) – [Lösung] django
@@ Zeile 29: / Zeile 29: @@
 Der ungeduldigen Leser kann auch direkt zur Tat schreiten und das manuelle Anlegen der Inventory-Hülle, des Playbooks und der zugehörigen Rollen überspringen und diese Aufgaben mit folgendem Befehl sozusagen auf einem Rutsch erledigen:
-<code> $ mkdir ~/ansible ; wget https://gitlab.nausch.org/django/example_14/-/archive/main/example_14-main.tar.gz -O - | tar -xz --strip-components=1 -C ~/ansible</code>
+<code> $ mkdir ~/ansible ; wget https://gitlab.nausch.org/django/example_14/-/archive/master/example_14-main.tar.gz -O - | tar -xz --strip-components=1 -C ~/ansible</code>
 <WRAP center round alert 100%>
-**Wichtig**: Aber nicht vergessen die Admin-Inventory-Daten in ein Ansible-.Vault verpacken!
+**Wichtig**: Aber nicht vergessen die Admin-Inventory-Daten in ein Ansible-Vault verpacken!
    $ ansible-vault encrypt ~/ansible/inventories/production/group_vars/all/admins
 </WRAP>
@@ Zeile 64: / Zeile 64: @@
   $6$n9UE0JVV7T.nzFJOdSY1dHDEsbfY3$0SPNKmewfaQ0z5thaRMrrrI9Uig.nzFJOdSY1erIZbw5yzDqeCg4S2oXa8zn2jEf9KDfjg31
-Ferner benötigen wir noch den SSH-Publickey den wir uns ebenso wie das gerade erstellte gehashte Passwort von unseren Admins auf einem sicheren Kommunikationsweg zukommen.
+Ferner benötigen wir noch den SSH-Publickey, den wir uns ebenso wie das gerade erstellte gehashte Passwort von unseren Admins auf einem sicheren Kommunikationsweg zukommen lassen.
 === Inventory Daten für unsere Admins ===
@@ Zeile 105: / Zeile 105: @@
 Das Playbook an sich ist relativ unspektakulär, wird doch nur die zugehörige Rolle eingebunden, wie wir hier sehen.
    $ vim ~/ansible/playbooks/admin_updates.yml
-{{gh> https://gitlab.nausch.org/django/example_14/-/blob/main/playbooks/admin_updates.yml }}
+{{gh> https://gitlab.nausch.org/django/example_14/-/blob/master/playbooks/admin_updates.yml }}
 === Rolle und Tasks ===
-Bevor wir unsere Rolle **''admins''** anlegen, kopieren wir noch kurz das Vorlageverzeichnis **''common''**, welches wir bei der Erstkonfiguration von Ansible, wie im Kapitel **[[playbook_example_08|Ansible mit Hilfe von Ansible einrichten]]** beschrieben, bereits angelegt hatten.
+Bevor wir unsere Rolle **''admins''** anlegen, kopieren wir noch kurz das Vorlagenverzeichnis **''common''**, welches wir bei der Erstkonfiguration von Ansible, wie im Kapitel **[[playbook_example_08|Ansible mit Hilfe von Ansible einrichten]]** beschrieben, bereits angelegt hatten.
    $ cp -avr ~/ansible/roles/common/ ~/ansible/roles/admins
 Nun legen wir unseren Main-Task an.
    $ vim ~/ansible/roles/admins/tasks/main.yml
-{{gh> https://gitlab.nausch.org/django/example_14/-/blob/main/playbooks/admin_updates.yml }}
+{{gh> https://gitlab.nausch.org/django/example_14/-/blob/master/roles/admins/tasks/main.yml }}
 Was nun noch fehlt sind die jeweiligen Tasks mit den Teilaufgaben. Zunächst definieren wir einen Task mit Hilfe dessen sichergestellt wird, dass die Gruppe **''wheel''** existiert, die später den Admins zugewiesen wird.
    $ vim ~/ansible/roles/admins/tasks/admingroup.yml
-{{gh> https://gitlab.nausch.org/django/example_14/-/blob/main/roles/admins/tasks/admingroup.yml }} ~~codedoc:xref:anchor_assert~~ Bevor wir nun wie im ersten **[[playbook_example_13|Beispiel]]** mit dem Task **''useranlage''** die jeweilige(n) Admin-Gruppe(n) und User pflegen, werden wir erst einmal die Variablen aus dem Inventory einer Prüfung unterziehen und stellen somit sicher, ob die zuvor definierten Rahmenbedingungen auch zutreffen. Hierzu Nutzen wir das [[https://docs.ansible.com/ansible/latest/collections/ansible/builtin/assert_module.html|ansible.builtin.assert Modul]].
+{{gh> https://gitlab.nausch.org/django/example_14/-/blob/master/roles/admins/tasks/admingroup.yml }} ~~codedoc:xref:anchor_assert~~ Bevor wir nun wie im ersten **[[playbook_example_13|Beispiel]]** mit dem Task **''useranlage''** die jeweilige(n) Admin-Gruppe(n) und User pflegen, werden wir erst einmal die Variablen aus dem Inventory einer Prüfung unterziehen und stellen somit sicher, ob die zuvor definierten Rahmenbedingungen auch zutreffen. Hierzu Nutzen wir das [[https://docs.ansible.com/ansible/latest/collections/ansible/builtin/assert_module.html|ansible.builtin.assert Modul]].
    $ vim ~/ansible/roles/admins/tasks/variablencheck.yml
-{{gh> https://gitlab.nausch.org/django/example_14/-/blob/main/roles/admins/tasks/variablencheck.yml }}
+{{gh> https://gitlab.nausch.org/django/example_14/-/blob/master/roles/admins/tasks/variablencheck.yml}}
-Anschließend definieren wir den Task an, mit Hilfe dessen die jeweilige(n) Admin-Gruppe(n) und User gepflegt werden.
+Anschliessend definieren wir den Task an, mit Hilfe dessen die jeweilige(n) Admin-Gruppe(n) und User gepflegt werden.
    $ vim ~/ansible/roles/admins/tasks/useranlage.yml
-{{gh> https://gitlab.nausch.org/django/example_14/-/blob/main/roles/admins/tasks/useranlage.yml }}
+{{gh> https://gitlab.nausch.org/django/example_14/-/blob/master/roles/admins/tasks/useranlage.yml }}
 Zu guter Letzt legen wir noch den Task an, damit die Admins, die Mitglied der Gruppe **''wheels''** sind, auch sudo-Rechte erlangen können.
    $ vim ~/ansible/roles/admins/tasks/sudoers.yml
-{{gh> https://gitlab.nausch.org/django/example_14/-/blob/main/roles/admins/tasks/sudoers.yml }}
+{{gh> https://gitlab.nausch.org/django/example_14/-/blob/master/roles/admins/tasks/sudoers.yml }}
 ===== Ausführung =====
@@ Zeile 135: / Zeile 136: @@
   - Sicherstellen dass die Gruppe **''wheel''** existiert.
   - Überprüfen, ob die Variablen aus dem Inventory entsprechend der **[[#anchor_var_def|Vorgaben]]** gesetzt und gültig sind. Falls nicht wird ein expliziter Fehlerhinweis ausgegeben und die Ausführung des Playbooks beendet. \\ Beispiel: <code>TASK [admins : Prüfen ob die UID richtig gesetzt wurde.] *******************************************************************************************************************************************
 fatal: [vml000137]: FAILED! => {"assertion": "item.ids is defined and item.ids < 5001", "changed": false, "evaluated_to": false, "msg": "Die Variable item.ids ist nicht vorhanden bzw. falsch gesetzt!"}
 PLAY RECAP *****************************************************************************************************************************************************************************************