Server on zefanjas.de - Open Source & Education

Zammad sichern und wiederherstellen

Sat, 06 Jul 2019 07:05:58 +0000

Seit einigen Jahren verwenden wir Zammad als Support- bzw. Helpdesk-Software in unserer Schule. Wir sind damit sehr zufrieden, denn Zammad bietet viele Features und ein angenehm zu bedienende Benutzeroberfläche. Vor einiger Zeit mussten wir unseren Server umziehen und somit auch unsere Zammad-Installation. In diesem Artikel möchte ich kurz zeigen, wie man Zammad sichern und wiederherstellen kann.

Zammad sichern

Zammad bietet von Haus aus ein Backup-Skript, welches aber standardmäßig deaktiviert ist. Man kann das Skript dazu benutzen, um regelmäßige Backups anzulegen. Es befindet sich unter /opt/zammad/contrib/backup/. Das Backup-Skript greift auf eine Konfigurationsdatei zu, in der alle wichtigen Einstellungen vorgenommen werden. Diese Datei muss man zuerst umbenennen:

$ mv /opt/zammad/contrib/backup/config.dist /opt/zammad/contrib/backup/config

Anschließend öffnet man die Datei und kann einige wenige Dinge einstellen:

$ nano /opt/zammad/contrib/backup/config

...
BACKUP_DIR='/var/tmp/zammad_backup'
HOLD_DAYS='10'
DEBUG='no'

BACKUP_DIR legt fest, wohin die Backups gespeichert werden sollen. Das Verzeichnis muss existieren! HOLD_DAYS gibt an, wie lange ein bzw. wie viele Backup(s) aufbewahrt werden sollen.

Nun kann man das Backup-Skript ausführen:

$ cd /opt/zammad/contrib/backup
$ ./zammad_backup.sh

Das Skript legt zwei Archive an (Datenbanksicherung und Zammad-Ordner), die sich nun im konfigurieren Backup-Ordner befinden.

Hinweis: Wenn man eine Installation migrieren möchte, ist es sinnvoll, Zammad vorher anzuhalten und erst dann das Backup zu erstellen. Das spielt aber nur bei größeren Installationen eine Rolle.

Zammad wiederherstellen

Wenn man ein Backup auf dem gleichen Host wiederherstellen möchte, kann man das mit dem Wiederherstellungsskript erledigen:

$ cd /opt/zammad/contrib/backup
$ ./zammad_restore.sh

Fertig 🙂

Wenn man allerdings eine Zammad-Installation umziehen möchte (Migration, Neuinstallation), gibt es einige Dinge zu beachten:

Zammad muss installiert sein (inklusive Elasticsearch)
die Zammad-Version sollte gleich oder höher sein (als die vom Backup)
es sollte die gleiche Datenbank verwendet werden (ein Wechsel ist wohl möglich, aber sehr aufwändig, da die Daten abgepasst werden müssen).
Es sollte genügend freier Speicherplatz vorhanden sein (ca. 2x so viel wie die Größe des Backups)

Wenn alle Bedingungen erfüllt sind, muss man zuerst die Konfiguration auf dem Zielsystem aktivieren:

$ mv /opt/zammad/contrib/backup/config.dist /opt/zammad/contrib/backup/config

Danach die Backupdateien in den konfigurierten Backup-Ordner kopieren (mit cp oder wenn man LXD-Container verwendet mit lxc file push/pull) und letztendlich das Wiederherstellungsskript laufen lassen:

$ cd /opt/zammad/contrib/backup
$ ./zammad_restore.sh

Weitere Informationen finden sich in der offiziellen Dokumentation.

Fazit

Zammad bringt einen einfachen Sicherungs- und Wiederherstellungsmechanismus mit, der zuverlässig funktioniert. Wer seine Zammad-Installation nicht anderweitig sichert, kann für das Backup-Skript auch einen Cron-Job einrichten, um regelmäßig ein Backup zu erstellen.

Xen Orchestra installieren und aktualisieren (Vollversion)

Fri, 10 May 2019 12:24:28 +0000

An unserer Schule verwenden wir Citrix Hypervisor (ehemals XenServer){.bar-label.clickable} (bald xcp-ng) für die Virtualisierung unseres Schulservers und anderer Anwendungen. Citrix liefert mit XenCenter ein Verwaltungstool für Windows. Damit kann man bequem alle virtuellen Maschienen verwalten und Einstellungen am Citrix Hypervisor vornehmen. Eine andere Möglichkeit ist Xen Orchestra. Es ist ein webbasiertes Tool, was noch einiges mehr als XenCenter kann. Auf der Website kann man sich eine fertig eingerichtete Appliance herunterladen. Diese ist allerdings von den Features stark eingeschränkt (man hat ca. 2 Wochen Zeit alle Features zu testen). Deshalb möchte ich einen kleinen Tipp weitergeben, wie man Xen Orchestra installieren kann – mit allen Features der Enterprice und Premium Edition.

Xen Orchestra installieren

Xen Orchestra ist eine Open Source Projekt, deshalb kann es sich jeder selbst den Quellcode nehmen und installieren. Die Anleitung dazu findet man in der offiziellen Dokumentation. Auf Github findet man auch ein Installationsskript, welches die Installation automatisch durchführt. Damit kann man Xen Orchestra in wenigen Schritten installieren. Auf einem frischen Ubuntu LTS Server muss man nur die folgenden Befehle ausführen:

$ sudo bash
$ curl https://raw.githubusercontent.com/Jarli01/xenorchestra_installer/master/xo_install.sh | bash

Das war es auch schon 🙂 Xen Orchestra kann man nun unter IP des Servers erreichen. Der Standard-Benutzername ist admin@admin.net, das Password admin.

Xen Orchestra aktualisieren

Wenn man Xen Orchestra fertig eingerichtet hat und sollte man es natürlich aktuell halten, um alle Sicherheitsupdates und neue Features zu bekommen. Eigentlich bringt jede Version einige neue Features mit, welche die Arbeit mit dem XenServer (bzw. xcp-ng) erweitern oder erleichtern. Der Autor des Installationsskript stellt ein weiteres Skript für die Aktualisierungen bereit. Zu finden ist es ebenfalls auf Github.

Das Aktualisierungsskript bietet verschiedene Optionen an. Zum einfachen Aktualisieren reicht der folgende Aufruf:

$ sudo bash
$ sudo curl https://raw.githubusercontent.com/Jarli01/xenorchestra_updater/master/xo-update.sh | bash

Nach wenigen Minuten ist Xen Orchestra wieder auf den aktuellen Stand!

Wer sich unwohl dabei fühlt ein Skript aus dem Netz als root laufen zu lassen, kann sich das Skript natürlich vorher noch genau anschauen, was es macht bzw. nicht macht 🙂

Fazit

Xen Orchestra ist ein tolles Projekt. Unser XenServer lässt sich damit leicht verwalten. Backups sind schnell angelegt (seit neustem auch Backups der Konfiguration von Xen Orchestra) inklusiver Benachrichtigungen (eMail oder nach Slack / Mattermost). Diese beiden Skripts haben uns das Leben sehr erleichtert. Ein großes Dankeschön an Jarli01!

Netzwerkbrücke für LXD Container einrichten

Thu, 07 Feb 2019 14:05:12 +0000

Die meisten unserer Webanwendungen laufen in LXD Containern. Nicht ohne Grund ist LXD für mich eines der wichtigsten Features von Ubuntu Server. Es gibt viele Wege um von außen auf eine Webanwendung in einem LXD Container zuzugreifen. So kann man z.B. einen Reverse Proxy nehmen und darüber die Zugriff auf die Container regeln (hier hatte ich schon mal davon berichtet). Eine andere Möglichkeit ist die Einrichtung einer Netzwerkbrücke, sodass sich die Container im gleichen Netz wie der Containerhost (Ubuntu Server) befinden. In diesem Artikel möchte ich kurz beschreiben, wie man eine Netzwerkbrücke für LXD Container einrichtet.

Netzwerkbrücke für LXD Container

Um eine Netzwerkbrücke unter Ubuntu einzurichten, muss man die bridge-utils installieren:

$ apt install bridge-utils

Danach kann man die Netzwerkbrücke einrichten.

bis Ubuntu 16.04

Bis Ubuntu 16.04 nutzt Ubuntu ifupdown um Einstellungen für die Netzwerkverbindungen festzulegen. Die Konfiguration nimmt man in den Dateien unter /etc/network/ vor. Eine einfache Netzwerkbrücke, um die Container in das Host-Netzwerk zu bekommen, könnte so aussehen:

$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The main Bridge
auto br0
iface br0 inet dhcp
    bridge-ifaces enp4s0
    bridge-ports enp4s0
    up ip link set enp4s0 up

# The primary network interface
iface enp4s0 inet manual

Hier bekommt die Brücke ihre Adresse vom DHCP-Server mitgeteilt. Die reale Netzwerkkarte enp4s0 wird in den manuellen Modus gesetzt und der Brücke zugewiesen.

ab Ubuntu 18.04

Ab Ubuntu 18.04 wird Netplan für die Konfiguration der Netzwerkverbindungen verwendet. Die Konfigurationsdateien befinden sich unter /etc/netplan/. Eine Definition für die Brücke könnte folgendermaßen aussehen:

$ cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    ethernets:
        enp3s0:
            dhcp4: no
    version: 2
    bridges:
        br0:
            dhcp4: no
            addresses:
            - 10.10.10.5/24
            gateway4: 10.10.10.254
            nameservers:
                addresses:
                - 10.10.10.254
            interfaces:
            - enp3s0

Im oberen Teil konfiguriert man die reale Netzwerkkarte (enp3s0) und weißt ihr keine Adresse zu. Danach folgt die Definition der Netzwerkbrücke. Sie wird wie eine statische Netzwerkverbindung eingerichtet und enthält zusätzlich den Punkt interfaces. Dort legt man fest, welche reale Netzwerkkarte „überbrückt“ werden soll. Weitere (komplexere) Beispiele zu Netzwerkbrücken gibt es auf der offiziellen Website.

Nun werden mit dem folgenden Befehl die Änderungen an den Netzwerkeinstellungen angewendet:

$ netplan apply  --debug

Netzwerkbrücke zuweisen

Hat man die Netzwerkbrücke fertig eingerichtet und bekommt sie auch die richtige IP-Adresse, muss man dem LXD Container noch mitteilen, dass er seine IP-Adresse über die Netzwerkbrücke beziehen soll. Das erledigt man mit folgendem Befehl:

$ lxc config device add containername eth0 nic nictype=bridged parent=br0 name=eth0

Mit name=eth0 legt man fest, unter welchen Namen man die Netzwerkkarte im Container findet. Nun kann man im Container eth0 nach Belieben konfigurieren. Ab sofort sollte der Container eine IP-Adresse aus dem Host-Netzwerk bekommen.

Fazit

Eine einfache Netzwerkbrücke lässt sich schnell einrichten und man kann sie ohne Probleme einem Container zuweisen. Andere Benutzer im Netzwerk können so ohne die Einrichtungen eines Reverse-Proxys auf eine Webanwendung zugreifen. Auch komplexere Szenarien sind denkbar (VLANs, mehrere Brücken, um die Container in verschiedene Netz zu bekommen etc.), doch das würde den Rahmen dieses kurzen Artikels sprengen.

HAProxy, Nginx, LXD und Let’s Encrypt

Mon, 01 Jan 2018 04:55:59 +0000

In meinem letzten Beitrag habe ich beschrieben, wie man verschiedene Webserver, die in einem LXD Container laufen, von außen über einen Reverse-Proxy (in unserem Fall HAProxy) erreichbar machen kann. Diese Setup läuft aber nur über HTTP (Port 80) und damit über einen unverschlüsselte Verbindung. Heutzutage ist es unabdingbar, dass man seine Website auch verschlüsselt. Deswegen möchte ich heute das Setup erweitern, sodass die Webserver über eine verschlüsselte Verbindung erreichbar sind. HAProxy wird dabei SSL/TLS Termination Proxy agieren, d.h. wir müssen nur an einer Stelle alle unsere Zertifikate verwalten und nicht auf jedem einzelnen Webserver selbst. Der Vorteil ist, dass den Webservern Arbeit durch den Proxy abgenommen wird, allerdings muss man wissen, dass die Kommunikation zwischen HAProxy und den Webservern unverschlüsselt erfolgt. Dieses private Netz sollte als sicher angesehen werden. In unserem Fall ist das das Subnet von LXD, in dem sich die Container befinden. Folgende Grafik veranschaulicht den Prozess:

Container überprüfen

Zuerst überprüfen wir, ob alle unsere Container laufen und eine IP haben. Das können wir mit dem bekannten lxc list Befehl machen:

$ lxc list
+---------+---------+-----------------------+------+------------+-----------+
|  NAME   |  STATE  |         IPV4          | IPV6 |    TYPE    | SNAPSHOTS |
+---------+---------+-----------------------+------+------------+-----------+
| haproxy | RUNNING | 10.10.10.10 (eth0)    |      | PERSISTENT | 0         |
+---------+---------+-----------------------+------+------------+-----------+
| web1    | RUNNING | 10.10.10.100 (eth0)   |      | PERSISTENT | 0         |
+---------+---------+-----------------------+------+------------+-----------+
| web2    | RUNNING | 10.10.10.200 (eth0)   |      | PERSISTENT | 0         |
+---------+---------+-----------------------+------+------------+-----------+

Alle unsere Container sind online und haben eine IP-Adresse bekommen. Weiterhin sollten die DNS-Einträge unserer beiden Webserver auf die öffentliche IP des Servers zeigen. Dies können wir z.B. mit dem host-Befehl überprüfen:

$ host web2.example.com
web1.example.com has address 1.2.3.4

Weiterleitung für HTTPS einrichten

Bisher wird nur Traffic, der auf Port 80 auf unserem Server ankommt an den HAProxy Container weitergeleitet. Für HTTPS brauchen wir aber noch eine Weiterleitung für Port 443. Diese können wir mit einer ähnlichen iptables Regel einrichten:

$ sudo iptables -t nat -I PREROUTING -i eth0 -p TCP -d server_ip/32 --dport 443 -j DNAT --to-destination haproxy_ip:443

Diese Regel ist nach einem Neustart wieder weg. Um sie dauerhaft einzurichten, kann man z.B. das Paket iptables-persistent installieren.

HAProxy anpassen

Als nächsten müssen wir den HAProxy Konfiguration anpassen. Dazu loggen wir uns als root in dem Container ein:

$ lxc exec haproxy bash

Nun können wir die Konfigurationsdatei (/etc/haproxy/haproxy.cfg) öffnen (im HAProxy-Container) und anpassen.

$ nano /etc/haproxy/haproxy.cfg

Damit unser SSL Setup möglichst sicher ist, fügen wir folgende Zeilen im global Abschnitt hinzu. Ich habe Sie mit dem Mozilla SSL Configuration Generator erzeugt:

global
    ...
    # set default parameters to the modern configuration
    ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
    ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
    ssl-default-server-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
    ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

Im defaults Block fügen wir folgende Zeilen hinzu:

defaults
     ...
     option forwardfor
     option http-server-close
     ...

Nun sind einige Anpassungen im frontend www_frontend Abschnitt notwendig:

frontend www_frontend
    # Http
    bind *:80
    # Https mit Ordner für Certifikate
    bind *:443 ssl crt /etc/haproxy/certs/
    # allen Traffic nach https weiterleiten
    redirect scheme https if !{ ssl_fc }
    # TLS Termination. HAProxy informiert hier unseren Webserver darüber. 
    reqadd X-Forwarded-Proto:\ https

    # Unterscheide zwischen sicheren und unsicheren Requests (wird in den nächsten zwei Zeilen verwendet).
    acl secure dst_port eq 443
    
    # Markiere alle Cookies als sicher, wenn sie über SSL gesendet werden.
    rsprep ^Set-Cookie:\ (.*) Set-Cookie:\ \1;\ Secure if secure
    # Füge den HSTS-Header mit einem maximalen Alter von 1 Jahr hinzu.
    rspadd Strict-Transport-Security:\ max-age=31536000 if secure

In in den Backend Abschnitten müssen wir keine Änderungen vornehmen.

Let’s Encrypt Zertifikate einrichten

Nun brauchen wir für die verschlüsselte Kommunikation noch ein Zertifikat für unsere Webserver. Let’s Encrypt bietet kostenfreie Zertifikate schon seit einigen Jahren an und ab diesem Jahr sogar Wildcard-Zertifikate.

Damit wir die Zertifikate einrichten können, brauchen wir den Let’s Encrypt Client, den wir wie folgt installieren (im HAProxy Container):

$ sudo apt install letsencrypt

Wir generieren ein Zertifikat, welches für alle unsere Domains gültig ist:

$ letsencrypt certonly -d example.com -d web2.example.com

Wenn alles geklappt hat, haben wir nun ein gültiges Zertifikat für unsere beiden Webserver. Jetzt müssen wir nur noch HAProxy die richtigen Zertifikate zur Verfügung stellen. Dazu müssen wir die Certificate Chain und den Private Key zusammenfügen, damit HAProxy etwas damit anfangen kann. Wir legen im ersten Schritt das Zielverzeichnis an und fügen dann die Zertifikate und den Key zusammen:

$ mkdir -p /etc/haproxy/certs/
$ DOMAIN='example.com' sudo -E bash -c 'cat /etc/letsencrypt/live/$DOMAIN/fullchain.pem /etc/letsencrypt/live/$DOMAIN/privkey.pem &gt; /etc/haproxy/certs/$DOMAIN.pem'

Zum Schluss starten wir den HAProxy neu:

$ systemctl restart haproxy

Testen

Wir sind fast am Ziel und möchten unsere Domains noch testen, ob auch alles richtig konfiguriert wurde. Zuerst rufen wir die Seiten in einem Webbrowser auf. Es sollte neben der Adresse ein grünes Schloss erscheinen (im Firefox). Weiterhin sollten wir noch einen SSL Server Test durchführen. Das Ergebnis lässt sich sehen:

Fazit

Mit wenigen Schritten haben wir ein Setup geschaffen, in dem wir mehrere Webseiten nach außen hin erreichbar machen können. Das Ganze lässt sich leicht erweitern und skalieren. Besonders angenehm finde ich die Verwaltung der Zertifikate an einer Stelle und nicht auf jedem Webserver einzeln. LXD und Let’s Encrypt, sowie HAProxy sind für mich eine der großen persönlichen Entdeckungen der letzten zwei Jahre.

Was sind für dich die größten Herausforderung bei der Bereitstellung von Webservern?

Wie man mehrere Webseiten mit Nginx und HAProxy mit LXD hosten kann

Tue, 26 Dec 2017 14:16:50 +0000

LXD und Linuxcontainer sind eine meiner Lieblingstechnologien in Ubuntu. In wenigen Sekunden kann man einen neue virtuelle Maschine in einem Container starten. Wir machen davon in [unserer Schule][1] [stark Gebrauch][2]. Fast alle Webanwendungen laufen in einem solchen Container. So haben wir die einzelnen Anwendungen besser getrennt. Weiterhin kann man sehr schnell einen Snapshot eines Containers machen und vieles mehr. Wenn man nun diese verschiedenen Webseiten öffentlich zugänglich machen möchte, gibt es ein Problem, denn i.d.R. hat man nur eine öffentliche IP zur Verfügung (fest bzw. dynamisch). Eine Lösung wäre, dass die Webanwendungen auf verschiedenen Ports laufen, aber das ist nicht unbedingt benutzerfreundlich. In diesem Beitrag möchte ich zeigen, wie man mehrere Webseiten mit Nginx und HAProxy mit LXD hosten kann.

Voraussetzungen

Wir brauchen:

einen Server (ab Ubuntu 16.04) mit öffentlicher IP
Zugang mit Rootrechten (root / sudo)
eine Domain und Subdomain, die mit je einem DNS A Eintrag auf die öffentliche IP des Servers zeigen

Schritt 1 – Benutzer der lxd – Gruppe hinzufügen

Damit man mit einem Nicht-Root-Benutzer lxd verwalten kann, müssen wir zuerst den Benutzer der Gruppe hinzufügen:

sudo usermod --append --groups lxd username
```

Damit die Änderungen wirksam werden, müssen wir uns einmal _aus- und wieder einloggen_!

### Schritt 2 – lxd konfigurieren

lxd ist in Ubuntu 16.04 vorinstalliert. Falls nicht, können wir es mit

```
sudo snap install lxd
```

nachholen. In LXD gibt es verschiedene Möglichkeiten, wie und wo die Container ihren Speicherplatz haben. Man kann verschiedene Dateisysteme auswählen und entscheiden, ob die Container in einer Datei oder extra Partition bzw. Festplatte gespeichert werden. In diesem Tutorial verwenden wir ZFS für Linux mit einen sogenannten „loop device“. Das installieren wir mit

sudo apt-get install zfsutils-linux
```

Nun können wir mit der Einrichtung von lxd beginnen:

sudo lxd init
```

Es werden verschiedene Fragen gestellt, die man wie folgt beantworten kann (Achtung: Die Netzwerkbrücke nur für IPv4 aktivieren! Das Subnet kann frei gewählt werden)

```
Name of the storage backend to use (dir or zfs) [default=zfs]: zfs
Create a new ZFS pool (yes/no) [default=yes]? <span style="color: yes
Name of the new ZFS pool [default=lxd]: lxd
Would you like to use an existing block device (yes/no) [default=no]? no
Size in GB of the new loop device (1GB minimum) [default=15]: 15
Would you like LXD to be available over the network (yes/no) [default=no]? no
Do you want to configure the LXD bridge (yes/no) [default=yes]? yes
LXD has been successfully configured.
```

Die Netzwerkbrücke ist notwendig, damit jeder Container seine eigene IP bekommt und Zugang zum Internet hat.

 

So, jetzt ist alles eingerichtet und wir können unsere ersten Container erstellen!

### Schritt 3 – Container erstellen

Um unsere Container zu verwalten, brauchen wir den `lxc` Befehl. Diese feine Programm ist sehr einfach zu verwenden und dabei sehr mächtig. Zuerst wollen wir uns mal alle Container anzeigen lassen. Das geht mit `lxc list`:

$ lxc list
+------+-------+------+------+------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------+-------+------+------+------+-----------+
```

Es werden keine Container angezeigt, weil wir ja noch keine erstellt haben.

Für unser Beispiel brauchen wir drei Container: einen für HAProxy und 2 Webserver mit Nginx (oder Apache, wenn das jemand bevorzugt).

Wir werden den Befehl `lxc launch` verwenden, um einen Ubuntu 16.04 (`ubuntu:x`) Container namens `web1` zu erstellen und zu starten. Das `x` in `ubuntu:x` ist eine Abkürzung für den ersten Buchstaben von Xenial, der Codename von Ubuntu 16.04. `ubuntu:` ist der Bezeichner für das vorkonfigurierte Repository von LXD-Images.

Unsere drei Container können wir also mit folgenden Befehlen erstellen:

```
$ lxc launch ubuntu:x web1
$ lxc launch ubuntu:x web2
$ lxc launch ubuntu:x haproxy

```

Wenn man den ersten Container erstellt, wird zuerst das Image heruntergeladen, dass etwas dauern kann. Die anderen beiden Container werden dann sehr schnell erstellt.

Nun können wir mit lxc list schauen, ob unsere Container auch alle da sind:

```
$ lxc list
+---------+---------+-----------------------+------+------------+-----------+
|  NAME   |  STATE  |         IPV4          | IPV6 |    TYPE    | SNAPSHOTS |
+---------+---------+-----------------------+------+------------+-----------+
| haproxy | RUNNING | 10.10.10.10 (eth0)    |      | PERSISTENT | 0         |
+---------+---------+-----------------------+------+------------+-----------+
| web1    | RUNNING | 10.10.10.100 (eth0)   |      | PERSISTENT | 0         |
+---------+---------+-----------------------+------+------------+-----------+
| web2    | RUNNING | 10.10.10.200 (eth0)   |      | PERSISTENT | 0         |
+---------+---------+-----------------------+------+------------+-----------+
```

In dieser Liste sehen wir zuerste den Namen des Containers und seinen Status (RUNNING, STOPPED). Dann die IP Adresse(n) (die hier exemplarisch ist) und der Typ. Zum Schlusso noch die Anzahl der Snapshots / Sicherungspunkte. Die IP-Adressen werden wir gleich brauchen (am besten notieren).

### Schritt 4 – Nginx-Container einrichten

Um eine Verbindung zum Container herzustellen, verwenden wir den Befehl `lxc exec`, der den Namen des Containers und die auszuführenden Befehle enthält.

```
$ lxc exec web1 -- sudo --login --user ubuntu
```

Die Zeichenkette `--` gibt an, dass die Befehlsparameter für lxc dort zu Ende sind, und der Rest der Zeile wird als der auszuführende Befehl innerhalb des Containers übergeben. Der Befehl ist `sudo --login --user ubuntu`, der eine Login-Shell für das vorkonfigurierte Konto `ubuntu` im Container bereitstellt.

> Hinweis: Wenn man eine Verbindung zu den Containern als _root_ herstellen müssen, kann man stattdessen den Befehl `lxc exec web1 -- /bin/bash` verwenden

Nun sind wir in der Konsole des Containers (_ubuntu@web1_) und können nginx installieren:

```
$ sudo apt update
$ sudo apt install nginx
```

Damit wir später besser erkennen auf welchem Webserver wir uns gerade befinden, ändern wir die Standard-Seite des Webservers:

```
$ sudo nano /var/www/html/index.nginx-debian.html
```

Für die Änderung bieten sich der _title_-Tag und die erste Überschrift (_h1_) an:

```
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx on LXD container web1!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx on LXD container web1!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
```

Nachdem wir die Datei an den beiden Stellen geändert haben, können wir mit **Strg+X** und **Y** die Datei speichern. Mit **Strg+D** oder `logout` verlassen wir wieder den Container.

Zurück auf dem Server testen wir, ob der Webserver auch ordnungsgemäß funktioniert. Mit dem folgenden Befehl sollten wir die Willkommenseite sehen, die wir gerade eben angepasst haben:

```
$ curl http://10.10.10.100/
```

Wenn alles geklappt hat, kann der zweite Container nach dem gleichen Muster eingerichtet werden.

### Schritt 5 – HAProxy konfigurieren

Jetzt, da alle beiden Webserver-Container eingerichtet sind, fehlt nur noch der Reverse Proxy. Er ist dafür verantwortlich, dass die Anfragen von außen vom richtigen Container verarbeitet werden. [HAProxy][3] ist ein sehr leistungsstarker Proxy, der auch von Gihub oder Twitter verwendet wird. Die Möglichkeiten sind auch hier wieder sehr vielfältig. Wir werden deshalb nur ein sehr einfaches Setup machen.

Zuerst loggen wir uns wieder in den Container ein und installieren HAProxy:

```
$ lxc exec haproxy -- sudo --login --user ubuntu
$ sudo apt-get update
$ sudo apt-get install haproxy
```

Nun konfigurieren wir HAProxy. Dazu öffnen wir die Datei _**/etc/haproxy/haproxy.conf**_ mit einem Texteditor:

$ sudo nano /etc/haproxy/haproxy.cfg
```

Im Abschnitt `defaults` fügen wir die Optionen _forwardfor_ und _http-server-close_ hinzu.

global
...
defaults
    log global
    mode    http
    option  httplog
    option  dontlognull
    <span class="highlight">option   forwardfor</span>
    <span class="highlight">option   http-server-close</span>
    timeout connect 5000
    timeout client  50000
    timeout server  50000
...
```

#### Frontends

Als nächstes konfigurieren wir das Frontend so, dass es auf unsere beiden Backend-Container zeigt. Wir fügen einen neuen Frontend-Abschnitt mit dem Namen _wwww_frontend_ hinzu, der so aussieht:

```
frontend www_frontend
    bind *:80 # Port 80 (www) an den Container binden

    # Es gibt eine Übereinstimmung sobald das HTTP Host: field einen der Hostnamen enthält (nach dem '-i').
    acl host_web1 hdr(host) -i example.com www.example.com
    acl host_web2 hdr(host) -i web2.example.com

    # Leite die Verbindung zum richtigen Servercluster um, je nach Übereinstimmung.
    use_backend web1_cluster if host_web1
    use_backend web2_cluster if host_web2
```

Die _acl-Befehle_ stimmen mit den Hostnamen der Webserver überein und leiten die Anfragen an den entsprechenden Backend-Abschnitt weiter.

#### Backends

Dann definieren wir zwei neue Backend-Abschnitte, eine für jeden Webserver, und nennen sie _web1_cluster_ bzw. _web2_cluster_. Wir fügen den folgenden Code zur Datei hinzu, um die Backends zu definieren:

```
backend web1_cluster
    balance leastconn
    # Wir setzen den X-Client-IP HTTP-Header. Dies ist nützlich, wenn wir wollen, dass der Webserver die tatsächliche Client-IP kennt.
    http-request set-header X-Client-IP %[src]
    # Dieses Backend, hier "web1" genannt, verweist auf den Container "web1.lxd" (Hostname).
    server web1 web1.lxd:80 check

backend web2_cluster
    balance leastconn
    http-request set-header X-Client-IP %[src]
    server web2 web2.lxd:80 check

```

Die _balance_-Option bezeichnet die Load-Balancing-Strategie. In diesem Fall entscheiden wir uns für die geringste Anzahl von Verbindungen. Die Option _http-request_ setzt einen HTTP-Header mit der realen Web-Client-IP. Wenn wir diesen Header nicht setzen würden, würde der Webserver die HAProxy-IP-Adresse als Quell-IP für alle Verbindungen aufzeichnen, was die Analyse der Herkunft des Datenverkehrs erschwert. Die Server-Option spezifiziert einen beliebigen Namen für den Server (web1), gefolgt von Hostname und Port des Servers.

LXD stellt einen DNS-Server für die Container zur Verfügung, so dass web1.lxd sich auf die mit dem web1-Container verknüpfte IP auflöst. Die anderen Container haben eigene Hostnamen, wie z.B. web2.lxd und haproxy.lxd.

Der c_heck_-Parameter weist HAPRoxy an, auf dem Webserver Überprüfungen durchzuführen, um sicherzustellen, dass er verfügbar ist.

Um zu testen, ob die Konfiguration gültig ist, führen Sie den folgenden Befehl aus:

```
$ haproxy -f /etc/haproxy/haproxy.cfg -c
Configuration file is valid
```

Nun müssen wir noch den HAProxy neu laden:

```
$ sudo systemctl reload haproxy

```

Damit sind wir im HAProxy-Container fertig und können uns wieder mit **Strg+D** bzw. **logout** abmelden.

Wir haben HAProxy so konfiguriert, dass es als Reverse-Proxy fungiert, der alle Verbindungen, die es auf Port 80 empfängt, an den entsprechenden Webserver in den beiden anderen Containern weiterleitet. Testen wir, ob es Haproxy tatsächlich gelingt, die Anfragen an den richtigen Web-Container weiterzuleiten. Dazu führen wir den folgenden Befehl aus:

```
$ curl --verbose --header 'Host: web2.example.com' http://10.10.10.10
```

Dies stellt eine Anfrage an HAProxy und setzt einen HTTP-Host-Header, den HAProxy verwenden soll, um die Verbindung zum entsprechenden Webserver umzuleiten.

Als Ausgabe sollten wir nun die Standarseite des Nginx-Servers vom web2-Container erhalten!

HAProxy hat die Anfrage richtig verstanden und an den web2-Container weitergeleitet. Dort zeigt der Webserver der Standard-Indexseite an, die wir zuvor bearbeitet haben, und zeigt den Text auf dem LXD-Container web2 an.

### Schritt 6 – Eingehende Verbindungen an den HAProxy weiterleiten

Zum Schluss müssen wir noch dafür sorgen, dass alle externen Anfragen auf Port 80 an HAProxy weitergeleitet werden, damit die Welt auf unsere Websites zugreifen kann.

HAProxy haben wir in einem Container installiert und ist standardmäßig aus dem Internet nicht erreichbar. Um dies zu lösen, erstellen wir eine iptables-Regel, um Verbindungen weiterzuleiten.

Der Befehl iptables benötigt zwei IP-Adressen: die öffentliche IP-Adresse des Servers (server\_ip) und die private IP-Adresse des Haproxy-Containers (haproxy\_ip), die man mit dem Befehl `lxc list` erhält.

Führen Sie diesen Befehl aus, um die Regel zu erstellen:

```
$ sudo iptables -t nat -I PREROUTING -i eth0 -p TCP -d server_ip/32 --dport 80 -j DNAT --to-destination haproxy_ip:80
```

Um diesen iptables-Befehl zu speichern, damit er nach einem Neustart erneut angewendet wird, installieren wir das Paket _iptables-persistent_:

```
$ sudo apt-get install iptables-persistent
```

Bei der Installation des Pakets werden wir aufgefordert, die aktuellen iptables-Regeln zu speichern. Akzeptieren und speichern wir alle aktuellen iptables-Regeln.

### Schritt 7 – Zugriff von außen testen

Wenn wir die beiden Domains (DNS A Eintrag) eingerichtet haben, sollten wir in der Lage sein, sich mit Ihrem Webbrowser mit jeder Website zu verbinden. Alternativ und nur zum lokalem Test können wir auch einen Eintrag in der **_/etc/hosts_** Datei machen:

```
server_IP example.com
server_IP web2.example.com
```

Um zu testen, ob die beiden Webserver tatsächlich über das Internet erreichbar sind, greifen wir von einem lokalen Computer aus mit einem Browser auf unsere beiden Domains zu (example.com bzw. web2.example.com). In beiden Fällen sollten wir nun die entsprechende Standardseite des Webservers sehen!

### Fazit

Wir haben zwei Websites eingerichtet, jede in einem eigenen Container, wobei HAProxy den Datenverkehr steuert. Diesen Prozess können wir wiederholen, um viele weitere Websites zu konfigurieren, die jeweils auf einen eigenen Container beschränkt sind.

So könnten wir z.B. auch MySQL in einem neuen Container hinzufügen und dann ein CMS wie WordPress installieren, um eine Website zu starten. Weiterhin könnten wir  diese Vorgehensweise auch verwenden, um ältere Softwareversionen zu unterstützen. Zum Beispiel, wenn eine Installation eines CMS eine ältere Version von Software wie PHP5 erfordert, dann können wir Ubuntu 14.04 in den Container installieren (`lxc launch ubuntu:t`), anstatt zu versuchen, die Paketmanager-Versionen, die auf Ubuntu 16.04 verfügbar sind, herabzusetzen.

Schließlich bietet LXD die Möglichkeit, Snapshots des vollen Zustands von Containern zu machen, was die Erstellung von Backups und das Zurückrollen von Containern zu einem späteren Zeitpunkt vereinfacht. Darüber hinaus, wenn wir LXD auf zwei verschiedenen Servern installieren, dann ist es möglich, diese miteinander zu verbinden und Container zwischen Servern über das Internet zu migrieren. Doch darüber berichte ich vielleicht ein andern mal…

**Update:** [Als nächsten Schritt sollte man das Setup noch mit SSL sicherer machen.][4]


  Setzt du LXD ein und welche Erfahrungen hast du bisher gemacht?


 [1]: https://zefanjas.de/5-grossartige-open-source-programme-die-wir-in-unserer-schule-einsetzen/
 [2]: https://zefanjas.de/open-source-in-der-schul-it-teil-2/
 [3]: http://www.haproxy.org/
 [4]: https://zefanjas.de/haproxy-nginx-lxd-und-lets-encrypt/

Petitions-Server geht in die Knie ;)

Tue, 05 May 2009 13:54:09 +0000

Zur Zeit läuft ja eine Online-Petition mit dem Titel „Keine Indizierung und Sperrung von Internetseiten“. Wer die Petition noch nicht unterzeichnet hat, ist aufgefordert, das jetzt noch nachzuholen!

Der Server scheint dem Ansturm nicht ganz gewachsen zu sein (20000 Unterschriften in 2 Tagen):