Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- linux:ansible:playbook_example_14 [30.11.2022 20:29. ] – [Aufgabenstellung] django
+++ linux:ansible:playbook_example_14 [09.06.2024 08:14. ] (aktuell) – [Lösung] django
@@ Zeile 1: / Zeile 1: @@
+~~NOCACHE~~
 ====== Ansible - weitere Beispiele: Admin Benutzer verwalten (v2)======
 {{:centos:ansible:ansible_logo.png?nolink&125|Bild: Ansible Logo}} \\ \\
@@ Zeile 13: / Zeile 14: @@
 Möchte ein bestehender Admin sein|ihr Passwort oder Schlüssel ändern, kann dies auch zu einer zeitraubenden Tätigkeit ausarten. Was liegt also näher das Anlegen und Löschen der Konten samt Passwörter und Schlüsselmaterial sowie die Pflege dieser Daten mit Hilfe von Ansible zu automatisieren?
-Die Beschreibung kennen wir schon aus dem ersten Beispiel **[[playbook_example_13|Admin Benutzer verwalten]]** - so weit, so gut. Zusätzlich zu dieser Ausgangssituation wollen wir nun noch sicherstellen, dass die Adminspezifischen Definitionen aus dem Inventory valide sind. Folgende Rahmenbedingungen bei den Eigenschaften eines Admin-Kontos sollen gelten:
+Die Beschreibung kennen wir schon aus dem ersten Beispiel **[[playbook_example_13|Admin Benutzer verwalten]]** - so weit, so gut. Zusätzlich zu dieser Ausgangssituation wollen wir nun noch sicherstellen, dass die Adminspezifischen Definitionen aus dem Inventory valide sind. Folgende Rahmenbedingungen bei den Eigenschaften eines Admin-Kontos sollen gelten: ~~codedoc:xref:anchor_var_def~~
   * **''user''** : Der Admin muss mit Vor und Nachnamen bekannt sein und auch definiert werden, darf also nicht leer sein,
   * **''name''** : der Account-Name des Admins muss definiert werden, darf also nicht leer sein,
@@ Zeile 21: / Zeile 22: @@
   * **''state''** : letztendlich wird über die Variable **''state''** geregelt, ob eine Admin-Konto existierten (**''present''**) darf, oder ob dies ggf. gelöscht werden soll (**''absent''**). Das bedeutet, die Variable im Inventory kann also entweder nur **''present''** oder **''absent''** sein - andere Werte sind schlichtweg unzulässig.
+Zur Prüfung dieser Rahmenbedingungen greifen wir auf das Ansible Modul **[[https://docs.ansible.com/ansible/latest/collections/ansible/builtin/assert_module.html|ansible.builtin.assert]]** zurück und legen uns hierzu eine einen eigenen **[[#anchor_assert|Task]]** in der Rolle an.
+===== Lösung =====
+<WRAP center round tip 80%>
+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/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!
+   $ ansible-vault encrypt ~/ansible/inventories/production/group_vars/all/admins
+</WRAP>
+Anschliessend kann man direkt **[[#script_starten|zur Ausführung schreiten]]**.
+</WRAP>
+==== Vorbereitung - Admindaten im Inventory ====
+Dreh- und Angelpunkt unserer Admin-Verwaltung ist natürlich unser Inventory. Dank unserer Vorbereitungen ins Sachen **[[playbook_example_07|Ansible Vault]]** können wir natürlich gehashte Passwörter und SSH-keys im Inventory vorhalten, da diese dort ja sicher verwahrt vorliegen.
+=== Inventory-Hülle ===
+Wir werden uns also erst einmal unsere Admins im Inventory eine zugehörige Datei anlegen.
+   $ ansible-vault create ~/ansible/inventories/production/group_vars/all/admins
+Dort legen wir als erstes mal eine Hülle für die weitere Bearbeitung an.
+<file c++ admins>linux_admins:
+  - user   : Vorname Nachname
+    name   : User-Name
+    groups : wheel
+    ids    : 1000
+    shell  : /bin/bash
+    state  : present                              # present bzw. absent
+    pwd    : <-- Ergebnis: openssl passwd -6  -->
+    key    : ssh-key
+</file>
+=== gehashtes Passwort ===
+Damit wir keine PLAIN-Text Passworte sondern nun gehashte Passwörter im Inventory stehen haben wollen, denn aus Sicherheitsgründen dürfen nur die Admins selbst deren Passwort kennen und sonst niemand, bitten wir diese uns das gehashte Passwort mit **''openssl''** zu generieren.
+   $  openssl passwd -6
+  Password:
+  Verifying - Password:
+  $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 lassen.
+=== Inventory Daten für unsere Admins ===
+Diese Daten übernehmen wir dann in unser Inventory:
+   $ ansible-vault edit inventories/production/group_vars/all/admins
+<file c++ admins>linux_admins:
+  - user   : Michael Nausch
+    name   : django
+    groups : wheel
+    ids    : 1000
+    shell  : /bin/bash
+    state  : present
+    pwd    : $6$QYCbUeY2/EecXmL4$iA7Q.M457er0F0354573RoPyKcbbPMozx8uFYKMpZLJnz2JIoAlcMxi0o0b1zJywJLECw1fSB2OCdfzc9vOX1
+    key    : ssh-ed25519 AAAAC3N1NTE5A0aTHP001zaC1lZDI1NTE5AAAAINPs/cN40aTu2HTGeHhV7IV1EngqT5 openpgp:0xDAED833F
+  - user   : Christoph Leichi
+    name   : rookie
+    groups : wheel
+    ids    : 1001
+    shell  : /bin/bash
+    state  : present
+    pwd    : $6$n9UE0JVV7T.nzFJOdSY1dHDEsbfY3$0SPNKmewfaQ0z5thaRMrrrI9Uig.nzFJOdSY1erIZbw5yzDqeCg4S2oXa8zn2jEf9KDfjg31
+    key    : ssh-ed25519 AAAAC3NzaqK6Pb38bv0oM9fw0C1lZDI1NTE5AAAAIDo46Pb38bv0oM9fmgM6byylc0815 rookie@nausch.org
+  - user   : Wänä Marschel
+    name   : waenae
+    groups : wheel
+    ids    : 1002
+    shell  : /bin/bash
+    state  : present
+    pwd    : $6$nJVSYV9J17.SY1v0oM9fow8Do46d04m354u3$0SPNKmewfaQ0z5tsafZi3haRMrrrI9Uig.OdSY1e6dHDEsbfY3$rI51ewfaQ0z5th
+    key    : ssh-ed25519 AAAAK6Pb38bv0oM9fw8DoOdSY1er4b38bNzaqK6Pb38bv0oM9fw01erIZbw5yzDqeCC5 waennae@nausch.org
+</file>
+In diesem Beispiel haben wir also drei Admins mit den zugehörigen Daten.
+==== Playbook mit zugehörigen Rollen ====
+Hatten wir das **[[https://gitlab.nausch.org/django/example_14|Gitlab-Paket]]** wie unter dem Abschnitt **[[#loesung|Lösung]]** beschrieben können wir die nächsten Schritte zum Anlegen des Playbooks und der Rolle mit den zugehörigen Tasks, getrost überspringen und gleich zur **[[#ausfuehrung|Ausführung]]** schreiten.
+=== Playbook ===
+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/master/playbooks/admin_updates.yml }}
+=== Rolle und Tasks ===
+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/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/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/master/roles/admins/tasks/variablencheck.yml}}
+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/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/master/roles/admins/tasks/sudoers.yml }}
+===== Ausführung =====
+Mit Hilfe dieses Playbooks können alle erforderlichen Konfigurationsschritte reproduzierbar und beliebig oft abgesetzt werden. Somit können neue Admins hinzugefügt, SSH-Keys und Passwörter ausgerollt bzw. aktualisiert werden und natürlich bestehende Admin-Konten auch bei Bedarf wieder gelöscht werden.
+Folgende Schritte werden also mit Hilfe des Playbooks abgearbeitet:
+  - 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 *****************************************************************************************************************************************************************************************
+vml000137                  : ok=13   changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0</code> Oder ein weiteres Beispiel: <code>TASK [admins : Prüfen ob die Variable state richtig gesetzt wurde.] ********************************************************************************************************************************
+fatal: [vml000137]: FAILED! => {"assertion": "item.state is defined and (item.state == 'present' or item.state == 'absent')", "changed": false, "evaluated_to": false, "msg": "Die Variable item.state ist nicht vorhanden bzw. leer!"}
-==== GH-Plugin ====
+PLAY RECAP *****************************************************************************************************************************************************************************************
-  https://github.com/splitbrain/dokuwiki-plugin-gh/blob/master/syntax.php
+vml000137                  : ok=15   changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0</code>
-{{gh>https://github.com/splitbrain/dokuwiki-plugin-gh/blob/master/syntax.php 5-10}}
+  - Sicherstellen dass die Gruppen für Admin-User existieren.
+  - Sicherstellen dass die Admin-User existieren.
+  - Gruppe entfernen, sofern der User zum Löschen gekennzeichnet ist mit **''absent''** im Inventory/Vault.
+  - SSH-Client-Verzeichnis anlegen
+  - SSH-Key des Admins hinterlegen
+  - SSH-Client-Verzeichnis entfernen, sofern der User zum Löschen gekennzeichnet ist mit **''absent''** im Inventory/Vault.
+  - Der Gruppe **''wheel''** sudo Rechte zuweisen.
-==== GH-Plugin (private Gitlab-Instanz) ====
+Entscheidend für das Anlegen bzw. Löschen eines Admins ist die Array-Variable **''state''**; ist ihr der Wert **''present''** zugewiesen wir der Admin neu angelegt und dessen Schlüssel angelegt. Ist der Wert der Variable aber **''absent''** wir dessen Gruppe und User auf den Zielsystemen entfernt. Nach einem erfolgreichen Playbooklauf können wir dann anschliessend den Admin wieder aus dem Inventory löschen oder eben solange dort stehen lassen, bis dieser wieder z.B. nach einem [[https://de.wikipedia.org/wiki/Sabbatical|Sabbatical]] seinen Dienst antritt.
+Haben wir die Daten in unserem Vault entsprechend aktualisiert können wir, wie im Playbook vermerkt, das Playbook wie gewohnt aufrufen.
+Aufruf via für alles Hosts:
+   $ ansible-playbook playbooks/admin_updates.yml
+bzw. für einzelne Hosts:
+   $ ansible-playbook playbooks/admin_updates.yml --limit <-hostnames->
-  https://gitlab.nausch.org/django/example_8b/blob/main/playbooks/ansible_grundconfig_v2.yml
+Interessiert uns lediglich die erfolgreiche Abarbeitung unseres Playbook-Aufrufs können wir dies z.B. beim Host mit dem Namen **''vml000137''** auch wie folgt erreichen:
+   $ ansible-playbook playbooks/admin_updates.yml --limit vml000137 | sed -n '/PLAY RECAP/,$p'
-{{gh>https://gitlab.nausch.org/django/example_8b/blob/main/playbooks/ansible_grundconfig_v2.yml  10-20}}
+  PLAY RECAP ********************************************************************************************************
+  vml000137                  : ok=29   changed=0    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0
+====== Links ======
+  * **[[detail|zurück zum Kapitel "Ansible - Erweiterte Konfigurationsbeispiele"]] <= **
+  * **=> [[playbook_example_10|weiter zum Kapitel "Ansible Controll Node]]**
+  * **[[start|Zurück zur "Ansible"-Übersicht]]**
+  * **[[wiki:start|Zurück zu >>Projekte und Themenkapitel<<]]**
+  * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**