Dies ist eine alte Version des Dokuments!
Ansible - weitere Beispiele: Admin Benutzer verwalten (v2)
Im Eingangskapitel Grundlagen haben wir uns mit der Installation bereits befasst. Mit den Hintergrundinformationen haben wir uns auch schon in den beiden Kapiteln Playbooks und YAML - was ist das? eingehend beschäftigt, sowie erste Erfahrungen mit Playbooks gesammelt.
Mit einer erste grundlegende Version unseres Ansible-Playbooks zum Anlegen, Modifizieren und Löschen unserer Admin-Konten haben wir im letzten Kapitel bereits betrachtet. Dieses Playbook werden wir nun noch etwas verändern und ein paar Prüfroutinen einbauen.
Aufgabenstellung
Oft steht man vor der Herausforderung, Admin-Konten auf unzähligen Zielsystemen anzulegen und wieder zu löschen. So sind im Zuge eines onboarding von neuen Admins jeweils Konten anzulegen und mit Passworten und Schlüsselmaterial zu versorgen. Beim Ausscheiden eines Admins, müssen dessen|ihre Konten samt Passworten und Schlüssel wieder gelöscht werden.
Es soll ja zuweilen Unternehmungen geben, bei denen sich das Personal mehr oder weniger in sehr kurzen Zeitabständen die Klinge in die Hand geben, was das Prozedere dann zusätzlich vom Aufwand her nach oben treibt.
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 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:
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,groups
: Admins müssen zur Rechterweiterung der Gruppewheel
angehören, daher muss der Gruppennamewheel
lauten und darf nicht leer sein,ids
: die UID/GID unserer Admins müssen sich im Bereich von1000 - 5000
bewegen,shell
: die Variable darf nicht leer sein - der Admin soll sich ja schliesslich anmelden können undstate
: letztendlich wird über die Variablestate
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 nurpresent
oderabsent
sein - andere Werte sind schlichtweg unzulässig.
Lösung
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:
$ 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
Wichtig: Aber nicht vergessen die Admin-Inventory-Daten in ein Ansible-.Vault verpacken!
$ ansible-vault encrypt ~/ansible/inventories/production/group_vars/all/admins
Anschliessend kann man direkt zur Ausführung schreiten.
GH-Plugin
https://github.com/splitbrain/dokuwiki-plugin-gh/blob/master/syntax.php
- syntax.php
* @license GPL 2 http://www.gnu.org/licenses/gpl-2.0.html * @author Andreas Gohr <andi@splitbrain.org> */ class syntax_plugin_gh extends DokuWiki_Syntax_Plugin {
GH-Plugin (private Gitlab-Instanz)
https://gitlab.nausch.org/django/example_8b/blob/main/playbooks/ansible_grundconfig_v2.yml
- playbooks/ansible_grundconfig_v2.yml
vars: ansible_working_dir: devel/ansible ansible_config: '/home/{{ admin_user }}/.ansible.cfg' admin_user: "{{ lookup('env','USER') }}" admin_mail: '{{ admin_user }}@nausch.org' vars_prompt: - name: pass_secret prompt: "Enter password for vault-password-store?" - name: pass_secret_2nd prompt: "Retype password for vault-password-store?"