Zum Inhalt springen

Server Installation/Ansible

Aus Opennet
Version vom 7. Mai 2017, 12:16 Uhr von Lars (Diskussion | Beiträge) (Rolle "virtualization-server" dokumentiert)

Ü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 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.

| warning = #b22222 solid;background-color: #ffdddd;"> | caution = #f28500 solid;background-color: #ffffaa;"> | approval = #00ff00 solid;background-color: #deffde;"> | proposal = #9932cc solid;background-color: #e4d8ff;"> | detail = #f4c430 solid;background-color: #fbfbfb;"> | protection = #bba solid;background-color: #fbfbfb;"> | notice | #default = #1e90ff solid;background-color: #fbfbfb;"> }} {{#switch: | blank | none =

| #default =

}}

{{#if: | {{#ifeq:|none 

 |
| }} }}
{{ 
 #switch:
 | left =
| #default = 
 }}
 {{#if:
 | {{{image}}}
 | [[Image:{{#switch:warning
   | danger     = Ambox warning pn.svg
   | warning    = Ambox warning pn.svg
   | caution    = Ambox important.svg
   | approval   = Thumb_up_icon.svg
   | proposal   = Ambox warning purple.svg
   | detail     = Ambox style.png
   | protection = Ambox protection.png
   | notice          
   | #default   = Information icon4.svg
   }} | {{#switch: 
     | left = 20x20px 
     | #default = 40x40px 
     }} ]]
 }}{{#switch:
 | left =
| #default =
}}		 Konfigurationsverwaltung ist ein mächtiges Werkzeug, das durch unbedachte Nutzung großflächigen Schaden/Ausfälle produzieren kann. Siehe unseren Leitfaden für eine vorsichtige Nutzung. {{#switch: 
   | left = {{{imageright}}}
| #default =
{{{imageright}}}
}}


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-get install ansible
  2. git Repository auschecken: git clone 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.

| warning = #b22222 solid;background-color: #ffdddd;"> | caution = #f28500 solid;background-color: #ffffaa;"> | approval = #00ff00 solid;background-color: #deffde;"> | proposal = #9932cc solid;background-color: #e4d8ff;"> | detail = #f4c430 solid;background-color: #fbfbfb;"> | protection = #bba solid;background-color: #fbfbfb;"> | notice | #default = #1e90ff solid;background-color: #fbfbfb;"> }} {{#switch: | blank | none =

| #default =

}}

{{#if: | {{#ifeq:|none 

 |
| }} }}
{{ 
 #switch:
 | left =
| #default = 
 }}
 {{#if:
 | {{{image}}}
 | [[Image:{{#switch:notice
   | danger     = Ambox warning pn.svg
   | warning    = Ambox warning pn.svg
   | caution    = Ambox important.svg
   | approval   = Thumb_up_icon.svg
   | proposal   = Ambox warning purple.svg
   | detail     = Ambox style.png
   | protection = Ambox protection.png
   | notice          
   | #default   = Information icon4.svg
   }} | {{#switch: 
     | left = 20x20px 
     | #default = 40x40px 
     }} ]]
 }}{{#switch:
 | left =
| #default =
}}		 Nach der ersten Anwendung wird eventuell das olsr-Routing durch die firewall-Regeln blockiert. Stelle also sicher, dass der Host auch ohne OLSR erreichbar ist. Erst die darauffolgende Rolle olsr-node öffnet die olsr-Ports. {{#switch: 
   | left = {{{imageright}}}
| #default =
{{{imageright}}}
}}


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

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-node

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

Ablauf

  1. olsr 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)

| warning = #b22222 solid;background-color: #ffdddd;"> | caution = #f28500 solid;background-color: #ffffaa;"> | approval = #00ff00 solid;background-color: #deffde;"> | proposal = #9932cc solid;background-color: #e4d8ff;"> | detail = #f4c430 solid;background-color: #fbfbfb;"> | protection = #bba solid;background-color: #fbfbfb;"> | notice | #default = #1e90ff solid;background-color: #fbfbfb;"> }} {{#switch: | blank | none =

| #default =

}}

{{#if: | {{#ifeq:|none 

 |
| }} }}
{{ 
 #switch:
 | left =
| #default = 
 }}
 {{#if:
 | {{{image}}}
 | [[Image:{{#switch:notice
   | danger     = Ambox warning pn.svg
   | warning    = Ambox warning pn.svg
   | caution    = Ambox important.svg
   | approval   = Thumb_up_icon.svg
   | proposal   = Ambox warning purple.svg
   | detail     = Ambox style.png
   | protection = Ambox protection.png
   | notice          
   | #default   = Information icon4.svg
   }} | {{#switch: 
     | left = 20x20px 
     | #default = 40x40px 
     }} ]]
 }}{{#switch:
 | left =
| #default =
}}		 Wähle einen geeigneten Zeitpunkt für die Anwendung dieser Konfiguration aus. Vor allem die Änderung der openvpn-Konfiguration führt zu einer kurzzeitigen Trennung aller Clients. {{#switch: 
   | left = {{{imageright}}}
| #default =
{{{imageright}}}
}}


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. http://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

DNS-Slave-Server

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

Domain-Proxy

Konfiguriere einen öffentlich erreichbaren Server als Domain-Proxy.

Ablauf

  1. Abhängigkeiten installieren
  2. Parse- und Aktualisierungsskript übertragen, Cron-Job einrichten
  3. nginx-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:

  • in einer ansible-Host-Variable festlegen, beispielsweise host_vars/yurika.on:
  letsencrypt_certificates:
  - {primary: api.opennet-initiative.de, other: api.on-i.de}
  - {primary: map.opennet-initiative.de, other: map.on-i.de}

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

  • siehe roles/letsencrypt/files/dehydrated-hook

virtualization-server

Diese Rolle vereinfacht die Verwaltung von VMs auf einem Virtualisierungsserver.

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
Abgerufen von „https://docs.opennet-initiative.de/index.php?title=Server_Installation/Ansible&oldid=30677“