Dies ist eine alte Version des Dokuments!


Ansible - weitere Beispiele: Admin Benutzer verwalten (v2)

Bild: Ansible Logo

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.

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. :-x

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 Gruppe wheel angehören, daher muss der Gruppenname wheel lauten und darf nicht leer sein,
  • ids : die UID/GID unserer Admins müssen sich im Bereich von 1000 - 5000 bewegen,
  • shell : die Variable darf nicht leer sein - der Admin soll sich ja schliesslich anmelden können und
  • 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.
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
{
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?"
Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
  • linux/ansible/playbook_example_14.1669840175.txt.gz
  • Zuletzt geändert: 30.11.2022 20:29.
  • von django