Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
linux:ansible:playbook_example_14 [01.12.2022 20:00. ] – [Ausführung] django | linux:ansible:playbook_example_14 [09.06.2024 08:14. ] (aktuell) – [Lösung] django |
---|
| ~~NOCACHE~~ |
====== Ansible - weitere Beispiele: Admin Benutzer verwalten (v2)====== | ====== Ansible - weitere Beispiele: Admin Benutzer verwalten (v2)====== |
{{:centos:ansible:ansible_logo.png?nolink&125|Bild: Ansible Logo}} \\ \\ | {{:centos:ansible:ansible_logo.png?nolink&125|Bild: Ansible Logo}} \\ \\ |
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: | 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%> | <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 | $ ansible-vault encrypt ~/ansible/inventories/production/group_vars/all/admins |
</WRAP> | </WRAP> |
| |
=== gehashtes Passwort === | === 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. | 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 | $ openssl passwd -6 |
Password: | Password: |
$6$n9UE0JVV7T.nzFJOdSY1dHDEsbfY3$0SPNKmewfaQ0z5thaRMrrrI9Uig.nzFJOdSY1erIZbw5yzDqeCg4S2oXa8zn2jEf9KDfjg31 | $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 === | === Inventory Daten für unsere Admins === |
pwd : $6$n9UE0JVV7T.nzFJOdSY1dHDEsbfY3$0SPNKmewfaQ0z5thaRMrrrI9Uig.nzFJOdSY1erIZbw5yzDqeCg4S2oXa8zn2jEf9KDfjg31 | pwd : $6$n9UE0JVV7T.nzFJOdSY1dHDEsbfY3$0SPNKmewfaQ0z5thaRMrrrI9Uig.nzFJOdSY1erIZbw5yzDqeCg4S2oXa8zn2jEf9KDfjg31 |
key : ssh-ed25519 AAAAC3NzaqK6Pb38bv0oM9fw0C1lZDI1NTE5AAAAIDo46Pb38bv0oM9fmgM6byylc0815 rookie@nausch.org | key : ssh-ed25519 AAAAC3NzaqK6Pb38bv0oM9fw0C1lZDI1NTE5AAAAIDo46Pb38bv0oM9fmgM6byylc0815 rookie@nausch.org |
- user : Oliver Gewinnbringer | - user : Wänä Marschel |
name : oliver | name : waenae |
groups : wheel | groups : wheel |
ids : 1002 | ids : 1002 |
shell : /bin/bash | shell : /bin/bash |
state : present | state : present |
pwd : $6$nJVSYV9J17.SY1v0oM9fow8Do46dHDEsbfY3$0SPNKmewfaQ0z5tsafZi3haRMrrrI9Uig.OdSY1e6dHDEsbfY3$rI51ewfaQ0z5th | pwd : $6$nJVSYV9J17.SY1v0oM9fow8Do46d04m354u3$0SPNKmewfaQ0z5tsafZi3haRMrrrI9Uig.OdSY1e6dHDEsbfY3$rI51ewfaQ0z5th |
key : ssh-ed25519 AAAAK6Pb38bv0oM9fw8DoOdSY1er4b38bNzaqK6Pb38bv0oM9fw01erIZbw5yzDqeCC5 oliver@nausch.org | key : ssh-ed25519 AAAAK6Pb38bv0oM9fw8DoOdSY1er4b38bNzaqK6Pb38bv0oM9fw01erIZbw5yzDqeCC5 waennae@nausch.org |
</file> | </file> |
In diesem Beispiel haben wir also drei Admins mit den zugehörigen Daten. | In diesem Beispiel haben wir also drei Admins mit den zugehörigen Daten. |
Das Playbook an sich ist relativ unspektakulär, wird doch nur die zugehörige Rolle eingebunden, wie wir hier sehen. | 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 | $ 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 === | === 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 | $ cp -avr ~/ansible/roles/common/ ~/ansible/roles/admins |
| |
Nun legen wir unseren Main-Task an. | Nun legen wir unseren Main-Task an. |
$ vim ~/ansible/roles/admins/tasks/main.yml }} | $ 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. | 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 | $ 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 | $ 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 | $ 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. | 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 | $ 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 ===== | ===== Ausführung ===== |
- Sicherstellen dass die Gruppe **''wheel''** existiert. | - 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.] ******************************************************************************************************************************************* | - Ü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!"} | 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 ***************************************************************************************************************************************************************************************** | PLAY RECAP ***************************************************************************************************************************************************************************************** |
vml000137 : ok=29 changed=0 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0 | 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]]** |