Ansible mit Rocky - Versionsgeschichte

Thomas.will: /* Erster Test */

2026-07-09T13:36:50Z

Erster Test

2026-07-09T13:10:12Z

Installation des Control Node

2026-07-09T13:08:23Z

Ansible auf Rocky Linux

2026-07-05T10:15:28Z

2026-07-05T10:07:21Z

tasks/main.yml

2026-07-05T10:06:18Z

handlers/main.yml

2026-07-05T10:01:49Z

tasks/main.yml

2026-07-05T09:51:04Z

Playbook: DMZ ausrollen

2026-07-05T09:49:28Z

Rolle: SSH-Härtung

2026-07-05T09:42:15Z

Playbooks

← Nächstältere Version		Version vom 9. Juli 2026, 13:36 Uhr
Zeile 59:		Zeile 59:
	}		}

−	~~;Verbindungsuser prüfen – muss kit sein, nicht root. Damit lässt sich schnell verifizieren, dass ansible_user aus dem Inventory tatsächlich greift.~~
−	* ansible dmz -m command -a "whoami"

	;sudo-Rechte prüfen – mit -b (become) sollte root erscheinen. Das bestätigt, dass ansible_become und das passwortlose sudo auf den Zielsystemen korrekt zusammenspielen.		;sudo-Rechte prüfen – mit -b (become) sollte root erscheinen. Das bestätigt, dass ansible_become und das passwortlose sudo auf den Zielsystemen korrekt zusammenspielen.

@@ Zeile 13: / Zeile 13: @@
 = Installation des Control Node =
-;Ansible wird ausschließlich auf client.it2XX.int installiert. Die Managed Nodes brauchen keine Ansible-Installation, nur SSH und Python – das ist der Kern des agentenlosen Modells.
+;Ansible wird ausschließlich auf desktop.it2XX.int installiert. Die Managed Nodes brauchen keine Ansible-Installation, nur SSH und Python – das ist der Kern des agentenlosen Modells.
 * sudo dnf install -y ansible

@@ Zeile 3: / Zeile 3: @@
 Ansible ist ein agentenloser Automatisierungsdienst: Es wird nur auf dem '''Control Node''' installiert, die verwalteten Maschinen ("Managed Nodes") brauchen lediglich SSH-Zugang und Python – kein Agent, kein zusätzlicher Dienst. Das unterscheidet Ansible von Werkzeugen wie Puppet oder Chef, die einen dauerhaft laufenden Agenten auf jedem Zielsystem voraussetzen.
-Im Labor übernimmt '''client.it2XX.int''' die Rolle des Control Node und verwaltet von dort aus die DMZ-Server (''fw'', ''ns'', ''www''; ''ldap'' und der Container folgen später als eigene Gruppe). Gearbeitet wird durchgehend als unprivilegierter User '''kit''' – root-Login ist auf allen Systemen deaktiviert, privilegierte Aktionen laufen über ''sudo''.
+Im Labor übernimmt '''desktop.it2XX.int''' die Rolle des Control Node und verwaltet von dort aus die DMZ-Server (''fw'', ''ns'', ''www''; ''ldap'' und der Container folgen später als eigene Gruppe). Gearbeitet wird durchgehend als unprivilegierter User '''kit''' – root-Login ist auf allen Systemen deaktiviert, privilegierte Aktionen laufen über ''sudo''.
 == Voraussetzungen ==

@@ Zeile 163: / Zeile 163: @@
      enabled: true
      state: started
 </syntaxhighlight>

@@ Zeile 206: / Zeile 206: @@
      name: sssd
      state: restarted
 </syntaxhighlight>

@@ Zeile 128: / Zeile 128: @@
 * vi ~/ansible/roles/sssd/tasks/main.yml
 <syntaxhighlight lang="yaml">
 - name: Pakete installieren
    dnf:
@@ Zeile 147: / Zeile 146: @@
    notify: sssd neu starten
-- name: sudoers-Eintrag in nsswitch.conf setzen
+- name: authselect konfigurieren
    lineinfile:
-     path: /etc/nsswitch.conf
+     path: /etc/authselect/user-nsswitch.conf
      regexp: '^sudoers:'
      line: 'sudoers:    files sss'
      state: present
+   notify: authselect anwenden
 - name: oddjobd starten

@@ Zeile 232: / Zeile 232: @@
    roles:
      - { role: sssd, tags: ['sssd'] }
-    - { role: ssh-hardening, tags: ['ssh-hardening'] }
+   </syntaxhighlight>
 ;Zuerst nur SSSD ausrollen und testen
 * ansible-playbook ~/ansible/dmz.yml --tags sssd
 ;Dry-run – zeigt was sich ändern würde, ohne es anzuwenden

@@ Zeile 221: / Zeile 221: @@
 ;Für den produktiven Einsatz: Passwort niemals im Klartext in defaults/main.yml – stattdessen mit ansible-vault verschlüsseln
 * ansible-vault encrypt_string '123Start$' --name 'ldap_password'
 = Playbook: DMZ ausrollen =

@@ Zeile 77: / Zeile 77: @@
 ;Ein Playbook ist eine YAML-Datei, die Tasks in fester Reihenfolge auf einer Zielgruppe ausführt
 ;Einfaches Beispiel – Paket installieren und eine harmlose Testdatei anlegen, läuft dank ansible_become automatisch mit sudo. Nichts hiervon verändert bestehende Konfiguration.
-* vi ~/ansible/htop.yml
+* vi ~/ansible/test.yml
 <syntaxhighlight lang="yaml">
 ---