Server Installation/Ansible: Unterschied zwischen den Versionen

Aus Opennet
Wechseln zu: Navigation, Suche
(local-dns-resolver)
(Ablauf)
Zeile 357: Zeile 357:
 
=== Ablauf ===
 
=== Ablauf ===
 
# Installation der IRCd Software
 
# Installation der IRCd Software
 +
# Firewall anpassen

Version vom 27. Oktober 2019, 05:49 Uhr

Inhaltsverzeichnis

Überblick

ansible ist eine Konfigurationsmanagement-Software basierend auf Python. Es benötigt für die Client-Konfiguration lediglich eine ssh-Verbindung. Auf der Client-Seite ist python-minimal und ansonsten keine spezifische Software erforderlich.

Innerhalb von Opennet setzen wir ansible für die Konfiguration der UGW-Server ein.

Die Konfigurationsverwaltung wird durch clonen unseres ansible-Repositories und lokale Ausführung auf dem eigenen Rechner angewandt.


Vorbereitung

Die folgenden Schritte sind auszuführen, um die Ansible Konfigurationsverwaltung auf einen oder mehrere Hosts anzuwenden.

  1. Paket auf einem persönlichen Linux/Unix Host installieren (Bsp. Debian, Installation erfordert root-Rechte): sudo apt install ansible
  2. git Repository auschecken: git clone --recursive https://dev.opennet-initiative.de/git/on_ansible (siehe Opennet DEV)
  3. den eigenen SSH Schlüssel auf den zu konfigurierenden Servern autorisieren (lassen)

Verzeichnisstruktur

Im ansible-Verzeichnis gibt es mehrere Dateien und Unterverzeichnisse.

Globale Struktur

hosts
Diese Datei enthält das sogenannte Inventory von ansible.
Hier werden alle Hosts aufgeführt, sowie Gruppen zugeordnet.
playbook-*.yml
Ein Playbook enthält Variablendefinitionen, sowie eine Liste von Aufgaben/Zuständen, die auf bestimmte Hosts angewandt werden sollen.
Der Dateiname einer playbook-Datei spielt keine Rolle - die Playbooks werden ausschließlich manuell ausgeführt.
host_vars/
Für jeden Host kann hier eine gleichnamige Datei (HOSTNAME.yml) abgelegt werden, die Host-spezifische Einstellungen (vor allem: IPs und Interface-Namen) enthält.
roles/
Eine Rolle ist in ansible eine Zusammenstellung von Konfigurationen, die auf gewisse Hosts angewandt werden sollen.
Beispielsweise können alle notwendigen Einstellungen für den Betrieb eines DNS-Servers in einer eigenen Rolle zusammengefasst werden.

Rollen-spezifische Struktur

Unterhalb jedes roles-Unterverzeichnis ist die folgende Struktur üblich:

defaults/main.yml
Variablen, die innerhalb dieser Rolle für alle Hosts gelten sollen. Sie können durch Host-spezifische Variablen überschrieben werden.
handlers/main.yml
Im Anschluss an die Änderungen von Dateien müssen unter Umständen Dienste neugestartet werden. Diese Handler werden nur bei tatsächlichen Änderungen ausgeführt.
files/
Per Konvention werden in diesem Verzeichnis zu kopierende Dateien abgelegt. Das copy-Modul verwendet diesen Pfad automatisch als Präfix für relative Pfadangaben.
templates/
Per Konvention werden in diesem Verzeichnis Dateien abgelegt, die Template-Platzhalter enthalten. Das template-Modul verwendet diesen Pfad automatisch als Präfix für relative Pfadangaben.
tasks/
Per Konvention beinhaltet die Datei main.yml in diesem Verzeichnis include-Direktiven zum Einbinden weiterer Dateien in diesem Unterverzeichnis.
Die task-Dateien enthalten die Beschreibungen von herzustellenden Konfigurationen (vorhandene Pakete, Dateien, usw.).

Variablen

Host-spezifische, Rollen-spezifische oder globale Variablen können an verschiedenen Stellen mit unterschiedlicher Priorität definiert werden (siehe ansible-Dokumentation).

Globale Variablen
hosts-Datei in der [all:vars]-Sektion
Rollen-spezifische Variablen für alle Hosts
roles/*/defaults/
Host-spezifische Variablen
host_vars/

Übliche Aufgaben

  • alle Konfigurationen anwenden: ansible-playbook playbook-ugw-servers.yml
  • einen einzigen Server konfigurieren: ansible-playbook playbook-ugw-servers.yml --limit HOSTNAME.on-i.de
  • auf anwendbare Änderungen prüfen ohne sie auszuführen: ansible-playbook playbook-ugw-servers.yml --limit HOSTNAME.on-i.de --check
  • Informationen (inkl. interner Variablen) eines Hosts anzeigen: ansible -m setup HOSTNAME.on-i.de
  • Dokumentation zu einem ansible-Modul anzeigen: ansible-doc synchronize
  • Vorbereitung eines neuen verwalteten Hosts
    • den Hostnamen in die hosts-Datei eintragen
    • eine Datei für den Host unter host_vars/ erstellen (basierend auf der Kopie einer vorhandenen Host-Datei)

Anwendungspolicy

Folgende Abfolge von Schritten ist für eine sichere Verwendung des Werkzeugs Konfigurationverwaltung zu empfehlen:

  1. kleinschrittige Änderungen vornehmen
  2. Änderungen im ersten Versuch nur auf einen einzigen Host anwenden (z.B. ansible-playbook .... --limit HOSTNAME)
    • idealerweise beim ersten Versuch mit den zusätzlichen Optionen --check --diff (keine Änderungen; Unterschiede anzeigen)
  3. die Ausgabe des ansible-Playbook-Laufs sorgfältig auf erwartete und unerwartete Änderungen prüfen
  4. die Wirksamkeit der Änderungen auf dem Host prüfen (funktionieren die Dienste noch?)
  5. Änderungen auf alle Hosts anwenden
  6. Wirksamkeit und Funktionsfähigkeit der Dienste prüfen
  7. Änderungen via git committen

Im Falle von Firewall-Einstellungen (typischerweise via ferm) ist es empfehlenswert, vor der Ansible-Verteilung diese auf einem Beispiel-Host probeweise anzuwenden:

  1. ferm-Konfiguration anpassen
  2. die neuen Regeln erproben; bei fehlender Bestätigung per Tasteneingabe werden die vorherigen Regeln wieder hergestellt:
 ferm -i /etc/ferm/ferm.conf
  1. während der interaktiven ferm-Initialisierung (Vorgabe: 30 Sekunden) prüfen, ob immer noch der Aufbau einer neuen ssh-Verbindung zum Host möglich ist
  2. nach erfolgreichem Test die neuen Regeln via Ansible verteilen

Rollen-Details

basic-server

Diese Rolle ist für alle opennet-Server geeignet.


Ablauf

  1. Verteilung der ssh-Schlüssel von Administratoren und Maschinen-Accounts (z.B. Backup)
  2. grundlegende Firewall-Konfiguration mit ferm
  3. munin-Node installieren
  4. automatische Aktualisierung der Opennet-CA-Widerrufslisten
  5. Änderungsverfolgung einrichten
  6. Mailrelay konfigurieren
  7. Opennet APT Repository hinzufügen

Typische Aufgaben

Neuen Admin / ssh-Schlüssel hinzufügen:

  • die Schlüssel befinden sich unter files/public_keys
  • falls es bereits einen alten (zu entsorgenden Schlüssel gibt): verschiebe ihn von admins nach obsolete (dabei eine Jahreszahl zum Dateinamen hinzufügen)
  • den neuen Schlüssel unter admins hinzufügen (der Dateiname sollte den Besitzer/Ansprechpartner klar erkennbar machen)

olsr

Konfiguration eines OLSR Knoten. Dazu gehört neben der Konfiguration auch Policy-Routing um sicherzustellen, dass Anfragen/Weiterleitungen aus nicht-olsr-Schnittstellen auf demselben Interface beantwortet werden.

Ablauf

  1. olsrd installieren und konfigurieren
  2. Policy-Routing konfigurieren (Routing-Tabelle anlegen, zusätzliche Routing-Regeln beim Booten erzeugen)
  3. ferm/firewall-Regeln: Markierung von eingehenden Paketen aus nicht-olsr-Schnittstellen (für die obigen Regeln)

ugw-server

Diese Rolle verwenden wir für die neuen UGW-Server seit 2015 (Server/erina, Server/subaru und Server/megumi).

TODO: Zertifikate erzeugen (Schlüssel und Zertifikat müssen aktuell per Hand erzeugt und auf den Server übertragen werden)


Ablauf

  1. Netzwerk-Konfiguration
  2. DNS-Server (bzw. Zonen-Slave)
  3. ugw-spezifsiche Firewall-Details
  4. OpenVPN (Konfiguration, Skripte, Zertifikate)
  5. OpenVPN-Statusseite (z.B. https://erina.opennet-initiative.de/vpnstatus)
  6. opennet-spezifische Munin-Plugins für UGW-Server
  7. Dateien für Download-Tests erzeugen

python-module

Übertrage ein paar opennet-spezifische Python-Module auf die Hosts, die für die UGW-Rolle erforderlich sind.

Ablauf

  1. Module kopieren
  2. Abhängigkeiten installieren

Nameserver-Slave

Diese Rolle konfiguriert auf einem Server alle relevanten Details für einen DNS-Slave, der dem Hidden-Primary-Server auf Server/heartofgold folgt.

Ablauf

  1. Bind installieren
  2. geheimen DNS-Key von Server/heartofgold abholen
  3. Bind konfigurieren (inkl. DNS-Key)
  4. Firewall-Regel für tcp-Zugriff auf bind hinzufügen (für Zonen-Transfer)
  5. Resolv.conf auf lokalen Bind zeigen lassen

Nameserver-Resolver

Diese Rolle konfiguriert eine lokale dnsmasq-Instanz, die die Auflösung der nicht-öffentlichen Opennet-Domain (".on") ermöglicht.

Ablauf

  • dnsmasq installieren
  • lokale DNS-Resolver in dnsmasq konfigurieren
  • resolv.conf auf lokale dnsmasq-Instanz verweisen

Domain-Proxy

Konfiguriere einen öffentlich erreichbaren Server als Domain-Proxy.

Ablauf

  1. Abhängigkeiten installieren
  2. Parse- und Aktualisierungsskript übertragen, Cron-Job einrichten
  3. apache2-Konfiguration anpassen
  4. slt-Konfiguration anpassen
  5. minimalistische Status-Website zusammenstellen (Log + erzeugte Konfigurationen)

letsencrypt

Diese Rolle ist für alle opennet-Server geeignet.

Ablauf

  1. Paket dehydrated installieren
  2. cronjob und renew-Hook (für Dienste-Restart nach Zertifikatserneuerung) einrichten
  3. Liste der Zertifikatsdomains übertragen (/etc/dehydrated/domains.txt)
  4. falls apache2 auf dem Ziel-Host installiert ist: Paket dehydrated-apache2 installieren
  5. falls nginx installiert ist: eine nginx-Domain-Konfigurationsdatei übertragen (acme-Mapping und https-Redirect für die konfigurierten Zertifikatsdomains)

Typische Aufgaben

letsencrypt-Domains einem Host zuordnen:

  • siehe roles/letsencrypt/info.txt

Einen weiteren renew-Dienst-Trigger (z.B. für postfix) hinzufügen:

  • siehe roles/letsencrypt/files/dehydrated-hook

Ggf. muss die License Variable beim ersten Aufruf manuell gesetzt werden:

virtualization-server

Diese Rolle vereinfacht die Verwaltung von VMs auf einem Virtualisierungsserver.

Nach der ersten Anwendung dieser Rolle sind wahrscheinlich einmalig Anpassungen an der Konfiguration des Virtualiserungsservers vorzunehmen.

Anschließend ist das Skript vhost-admin auf dem Virtualisierungsserver verwendbar.

Konfiguration

  • virtualization_storage: entweder lvm (Standard) oder file

Ablauf

  1. Pakete rund um KVM-basierte Virtualisierung installieren
  2. unser Skript vhost-admin.sh für die Verwaltung von VMs übertragen
  3. libvirt-Template für die Erzeugung neuer VMs übertragen

backup-storage

Diese Rolle konfiguriert einen Host als Speicherort für Backups. Der Host wird nächtlich via rsnapshot die Dateisysteme aller konfigurierten zu sichernden Hosts kopieren. Allgemeine Hinweise zum Betrieb unter Opennet Backup

Ein verschlüsselter Datenträger wird (optional) unterstützt:

  • Skript zum vereinfachten Mounten des Crypto-Containers (z.B. nach einem reboot)
  • einblenden eines Warnhinweis nach dem Login (mit Verweis auf das obige Skript), falls das Backup-Datenverzeichnis nicht gemountet ist

Typische Aufgaben

Zu sichernden Host hinzufügen

  • Eintrag in roles/backup-storage/defaults/main.yml hinzufügen
    • mit dem dort verwendenteten Hostnamen sollte der Backup-Server den zu sichernden Host per ssh erreichen können
  • ansible-Rolle backup-storage anwenden

Zu sichernden Host entfernen

  • Eintrag aus roles/backup-storage/defaults/main.yml entfernen
  • Nachbereinigung auf dem zu sichernden Host:
    • /usr/local/bin/rrsync löschen
    • ssh-Schlüssel der Backup-Server aus /root/.ssh/authorized_keys entfernen (Schlüssel-Kommentare beginnen mit backup-; zu Beginn der Zeile findet sich ein command=...-Eintrag)

Backup-Server hinzufügen

  • zusätzlichen Server-Namen in dem Server-Playbook (playbook-servers.yml) unter der 'backup-storage-Rolle eintragen
  • ansible-Playbook auf den Backup-Server anwenden
  • Nacharbeiten auf dem neuen Backup-Server:
    • den öffentlichen Teil des ssh-Schlüssels für die rsync-Verbindungen (/root/.ssh/backup-storage_rsa.pub) zur Backup-Schlüsselliste hinzufügen (roles/backup-storage/tasks/source-hosts.yml)
      • anschließend erneut die Rolle anwenden
    • Datenverzeichnis (backup_storage_rsnapshot_directory) vorbereiten:
      • unverschlüsselt: einfacher Eintrag in der fstab
      • verschlüsselt: Container anlegen, Dateisystem erzeugen, Passwort verteilen (an andere Admins), Eintrag in /etc/crypttab anlegen

Konfiguration

  • backup_storage_source_hosts: typischerweise werden alle konfigurierten Hosts gesichert (siehe roles/backup-storage/defaults/main.yml); je Backup-Storage kann jedoch auch eine reduzierte Auswahl von Hosts definiert werden
  • backup_storage_rsnapshot_directory: Zielverzeichnis für die rsnapshot-Backups; es muss per Hand angelegt werden (idealerweise: basierend auf einem verschlüsselten Datenträger)
  • backup_storage_crypto_device: (optional) Device für verschlüsselte Sicherung der Backups

Ablauf

  1. rsnapshot installieren
  • Crypto-Skript kopieren (falls backup_storage_crypto_device gesetzt ist)
  • öffentliche Schlüssel der ssh-Server der zu sichernden Hosts in die Backup-Storage-Hosts importieren
  • öffentlichen Teil der backup-storage-Schlüssel der Backup-Storage-Hosts in den authorized-Key-Schlüsselbund des root-Accounts der zu sichernden Hosts importieren (mit Beschränkung auf die Ausführung von "rrsync" - einem read-only-Wrapper um "rsync --server")

Apt-Repository

Konfiguriere einen Server als Apt Repository‎ für Opennet interne Verteilung von DEB-Paketen.

Ablauf

  1. Apt Repository Benutzer anlegen, mit Homeverzeichnis
  2. SSH Public Keys kopieren für SSH/SCP Zugang zu Apt Repository (relevant für Opennet DEV Gruppe)
  3. GPG Key erstellen und Public Key veröffentlichen (noch unvollständig implementiert, Stand 12/2017)
  4. Software installieren (mini-dinstall, dput), Repository Verzeichnisse anlegen und notwendige Sign-Scripte ablegen

Anschließend muss das Repository-Verzeichnis über eine Webserver erreichbar gemacht werden. Dies ist außerhalb von Ansible zu erledigen.

Ggf. muss bei älteren Debian Installationen (Jessie und früher) die das Apt Repository verwenden sollen der Apt Key manuell hinzugefügt werden:

apt-key add /etc/apt/trusted.gpg.d/opennet-apt-key.asc

apache2-server

Konfiguration einfacher apache2-basierter Webseiten mit Opennet-typischer Konfiguration:

  • Domains
  • Zertifikate
  • Logging
  • Header
  • optionale https-Umleitung
  • optionale PHP Unterstützung

Ablauf

  1. Paketinstallation
  2. Erzeugen einer Webseiten-Konfiguration
  3. Firewall-Regeln: Ports 80 und 443 erlauben
  4. Sicherheitskonfiguration erzeugen
  5. PHP Installation

media-mirror

Bereitstellung eines Freifunk Media CDN Servers zur Ablage und Auslieferung von Media Dateien für das media.freifunk.net Projekt. Basiert auf Mirrorbits. Wird mit der Rolle Apache-Server kombiniert.

Ablauf

  1. Media-Server Gruppe und Benutzer anlegen, als System
  2. Rsync installieren, konfigurieren und im Daemon-Mode starten
  3. Firewall-Regeln: Port 873 (tcp) erlauben

mitgliedsantrag

Diese Rolle installiert den Opennet Web-Mitgliedsantrag.

Ablauf

  • Installiert notwendige Software
  • Installiert Mitgliedsantrag Debian Paket

mitgliederverwaltung

Konfiguriere ein MoinMoin Wiki so, dass es die Daten der Mitgliederverwaltung übernehmen kann.

Ablauf

  • python-moinmoin installieren
  • diverse Verzeichnisse vorbereiten
  • manuell müssen jetzt die Daten des alten MoinMoin ins neue kopiert werden

wireguard-server

Konfiguriere einen Server als ‎Wireguard VPN Instanz.

Ablauf

  1. Debian Apt Repository 'unstable' hinzufügen und mit Pinning versehen (noch notwendig, Stand 01/2019)
  2. Wireguard installieren (derzeit noch aus 'unstable')
  3. Wireguard konfigurieren incl. Erzeugung Keys
  4. Firewall anpassen

mediawiki

Konfiguriere einen Server als MediaWiki Instanz.

Ablauf

  1. notwendige Software installieren
  2. Datenbank einrichten und automatisches Backup aktivieren
  3. MediaWiki Erweiterungen installieren und aktivieren
  4. Konfigurationen (bzw. Vorlagen) übertragen

opennetca

Konfiguriere einen Server als Opennet CA Instanz.

Ablauf

  1. notwendige Software installieren
  2. CA incl. Webinterfaces einrichten
  3. Cronjobs anlegen

homematic

Konfiguriere einen Server als Opennet Homematic Instanz.

Ablauf

  1. Anlegen der Nutzer und Verzeichnisse
  2. Kopieren der Skripte und Dateien

opennetdev-master

Konfiguriere einen Server als Opennet DEV Instanz.

Ablauf

  1. Installation und Konfiguration von Trac (siehe Server Installation/trac)
  2. Installation von Gitolite (siehe Server Installation/gitolite)
  3. Installation und Konfiguration von Git incl. Webinterface / öffentlicher Repo-Zugang
  4. Installation und Konfiguration von Buildbot im Master-Modus

opennetdev-slave

Konfiguriere einen Server als Opennet DEV Slave Instanz.

Ablauf

  1. Bereitstellung des Opennet DEV Download Dienstes
  2. Installation und Konfiguration von Buildbot im Slave/Worker-Modus

irc-server

Konfiguriere einen Server als Opennet IRC Instanz.

Ablauf

  1. Installation der IRCd Software
  2. Firewall anpassen
Meine Werkzeuge
Namensräume

Varianten
Aktionen
Start
Opennet
Kommunikation
Karten
Werkzeuge