wiki/Technik/Netzinfrastruktur/Supernodes/Ansible Automatisierung.page

---
format: markdown
categories: Netz-Infrastruktur, Backbone, Supernodes
title: Server-Automatisierung
...

# Automatisierung der Konfiguration von Supernodes/Gateways und anderer Server (als Link in ff@home einfuegen!)

## Aufbau und Konfiguration 1) Steuerungsrechner 2) Repository 3) Zielrechner  

## 1) Steuerungsrechner  

Der Steuerungsrechner (Control Host) hält die Konfigurationen der Zielrechner (target hosts) und die Ansible Playbooks zur Anpassung der Zielrechner vor. 

Ein Steuerungsrechner wird mit Python3 und Ansible in einer virtuellen venv-Umgebung verwendet:  

    ansible [core 2.19.3]  
    config file = /home/m-an/git/snng-roles-l2tp/ansible.cfg  
    configured module search path = ['/home/m-an/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']  
    ansible python module location = /home/m-an/git/venv/lib/python3.12/site-packages/ansible  
    ansible collection location = /home/m-an/.ansible/collections:/usr/share/ansible/collections  
    executable location = /home/m-an/git/venv/bin/ansible  
    python version = 3.12.3 (main, Nov  6 2025, 13:44:16) [GCC 13.3.0] (/home/m-an/git/venv/bin/python3)  
    jinja version = 3.1.6  
    pyyaml version = 6.0.3 (with libyaml v0.2.5)  

Die Ansibleversion des Steuerungsrechners ausserhalb der venv-Umgebung kann sich wegen Systemupdates unterscheiden:  

    ansible [core 2.19.4]  
    config file = /home/m-an/git/snng-roles-l2tp/ansible.cfg  
    configured module search path = ['/home/m-an/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']  
    ansible python module location = /usr/lib/python3/dist-packages/ansible  
    ansible collection location = /home/m-an/.ansible/collections:/usr/share/ansible/collections  
    executable location = /usr/bin/ansible  
    python version = 3.12.3 (main, Nov  6 2025, 13:44:16) [GCC 13.3.0] (/usr/bin/python3)  
    jinja version = 3.1.2  
    pyyaml version = 6.0.1 (with libyaml v0.2.5)  

Diese Unterschiede können zu Konflikten bei der Playbookausführung führen, deshalb sollten während der Erstellung eines Playbooks weder die Ansible- noch die Pythonversion  verändert werden.   

## Python venv-Umgebung erstellen  

✅ 1. Benötigte Pakete installieren

Unter Debian heißt das Paket für virtuelle Umgebungen meist python3-venv:

    $ sudo apt update
    $ sudo apt install python3-venv

✅ 2. Virtuelle Umgebung erstellen

Wechsle mit cd xyz in den gewünschten Projektordner und führe aus:

    ~/git/xyz $ python3 -m venv venv

Dadurch entsteht ein Verzeichnis venv/, das unabhängig vom hostsystem die nötigen Python-Pakete enthält.

✅ 3. venv aktivieren  

    ~/git/xyz $ source venv/bin/activate

Du erkennst die aktivierte venv an der (venv)-Präfix in der Shell.

✅ 4. Pakete installieren

Jetzt nutzt pip die isolierte Umgebung:  

    (venv)~/git/xyz $ pip install <paketname>

oder zum Beispiel:  

    (venv)~/git/xyz $ pip install ansible

um genau in diese venv-Umgebung ansible zu installieren.

✅ 5. venv wieder deaktivieren, (venv) erscheint nicht mehr im Prompt:  

    (venv)~/git/xyz $ deactivate
    ~/git/xyz $


## 2) Aufbau des Repository

Das Repository ist unter gogs.ffdo.de im Verzeichnis snng-roles-l2tp zu finden. Dieses Repository ist geforkt von ffdo-infrastruktur/ffdo-ansible-l2tp.  

Das komplette Playbook zur Erstellung eines Gateways/Supernodes heisst ng-gateway.yml, über Tags können daraus einzelne Playbooks isoliert ausgeführt werden.  
Alle Playbooks werden als root ausgeführt, eine Anmeldung auf den Zielrechnern als root ist grundsätzlich ausgeschlossen und für User nur über ssh möglich. 
Dafür müssen für jeden User, der das Playbook ausführen soll, der publickey auf die Zielrechner kopiert werden.
Das Passwort für die privelage-escalation, also für sudo ist abgeschaltet. Ein Aufruf für den Server snng-dus03 lautet dann:

    (venv)$ ansible-playbook -b ng-gateway.yml -v -l snng-dus03 -u <username>

oder mit einem Tag, um nur ein oder mehrere Teile des Playbooks auszuführen:  

    (venv)$ ansible-playbook -b ng-gateway.yml -v -l snng-dus03 --tags "<tagname>" -u <username> 
 
Die anderen dort vorhandenen Playbooks dienen zu Testzwecken.  



## Umgang mit dem Repository und mit git

Wenn nur wenige Personen im Repo arbeiten, ist es sinnvoll, vor jedem Arbeitstreffen ein git pull durchzuführen und nach Abschluss der Arbeiten ein git push.
Damit werden Forks und evtl. notwendige --rebase vermieden. 


## 3) Zielrechner  

Ein Zielrechner oder eine Ziel-VM müssen folgende Elemente als Rohzustand enthalten, damit sie per ansible konfiguriert werden können:  
- ein aktuelles Debian-Betriebssystem mit python3    
- eine ip, also einen Netzzugang  
- einen ssh-Zugang für die Personen, die von ihrem Steuerungsrechner aus Playbooks auf dem Zielrechnmer ausführen möchten    
- ansible selbst ist **nicht** erforderlich


## historischer Stand

Es gab Ansätze eine Community (Supernodes + Map Server) in Ansible zu beschreiben. Das Playbook kann 
[hier](https://github.com/dereulenspiegel/ffdo-ansible) Stand: 09.12.25 gefunden werden.  
Auf Basis dieses Playbook wurden einige Rollen
als eigenständige Rollen ausgegliedert und in eigene Repositories abgespalten

* [Alfred](https://github.com/dereulenspiegel/ansible-alfred) Stand: 09.12.25  
* [Alfred-json](https://github.com/dereulenspiegel/ansible-alfred-json) -"-
* [fastd](https://github.com/dereulenspiegel/ansible-fastd) -"-

Diese Rollen können eigenständig benutzt werden und sollten keine bzw. wenige Abhängigkeiten zu anderen Rollen haben. 
Diese Rollen werden auch im oben genannten Playbook wiederverwendet.  

Inzwischen werden die Repos des Freifunk Dortmund unter git.ffdo.de gehostet und dort über git (siehe oben) bearbeitet.