Schlagwort-Archive: lxc

Proxmox mit LXC bei Hetzner

Xen? KVM? LXC? Oder gar systemd-nspawn? In der Schule drehen wir uns bezüglich der Virtualisierungsbasis für unsere Cloud hübsch im Kreis. Aktuell neige ich LXC zu, musste aber bei meinen ersten Gehversuchen einige Schläge einstecken: Restricted Container zickten, Debian Jessie Container auf Ubuntu 16.04 als Wirt ebenfalls, das Netzwerk-Setup war fummelig und die Namensauflösung in den Containern selbst immer wieder „einfach weg“ …

Also das schlechte Wetter heute mal sinnvoll genutzt und einen ganz anderen Weg beschritten: nicht wie sonst per Shell gearbeitet, sondern heute mal per Oberfläche gefummelt und mir Proxmox näher angesehen. Geht flott und funktioniert zügig. Hier eine kurze Doku.

Im Hetzner installimage das aktuelle Debian auswählen – hier: Jessie. Setup durchführen, Updates installieren, neu booten und dann an die Arbeit.

Hinweis für die Partitionierung: Die LXC-VMs werden später unter /var – genauer: /var/lib/vz/images – liegen.

Ich habe mir dann „die volle Packung Proxmox“ installiert:

Nach einem erneuten Reboot zeigte ein uname -a nun

Also frisch in Proxmox unter https://server.domain:8006 mit dem PAM Account für root angemeldet und dort eine neue VMBR0 angelegt, die erst einmal unkonfiguriert blieb.

Reboot. Proxmox übernimmt sonst die Änderungen nicht.

Dann das restlichen Netzwerk-Setup von Hand erledigt.

Die Basis-IP des Server war

Dazu kamen zwei über den Robot zusätzlich bestellte IPs

Es ergab sich damit für /etc/network/interfaces diese Konfiguration:

Für jede weitere IP, die im vorliegenden Fall noch kommen mag, muss man für die VMBR0 eine Zeile ergänzen. Ich denke, das Schema ist nachvollziehbar. Die restliche IP-Konfiguration läuft über Proxmox direkt (siehe unten).

Es folgt die Anpassung von /etc/sysctl.conf

Reboot.

Und ab jetzt geht es klickend in Proxmox weiter. Zuerst zieht man sich die benötigten Templates (hier: für Ubuntu und Debian). Dann legt ein Klick auf das entsprechende Icon die erste VM als LXC an. Der erste Container erhält als IP im hier vorliegenden Fall

und für seine Gateway-Adresse die Basis-IP des Servers:

Der Rest – also die Ressourcenzuteilung usw – war für die Testmaschinen dann eine Geschmacksfrage.

Die Verwaltung (Softwareinstallation etc.) der einzelnen VMs nahm ich lieber direkt auf dem Wirt vor. Da reagiert die Shell einfach zügiger als jedes Frontend. Ein

bindet den zuerst erzeugten LXC an die Rootshell.

Ein internes Netzwerk, über das die VMs untereinander sprechen können, ist auch schnell eingerichtet: Auf dem Host oder auch über Proxmox in die /etc/network/interfaces

Reboot und in Proxmox dann der jeweiligen Maschine eine neue Netzwerkkarte (eth1) geben, die an die vmbr1 gebunden wird, passende IP und Netzmaske setzen – voila.

Erste Messungen mit iperf geben so um die 55 Gbit/sec.

Erstes Ergebnis:

  • Netzwerksetup, Einrichtung, Verwaltung laufen rund und zügig ab
  • Die Templates für Proxmox kommen ziemlich „dick“ mit Software ausgestattet daher. So würde ich diese ungern als Basis für eigene VMs nutzen

Pydio auf LD-Server über HTTPS

Pydio wird vom LD-Server in einem LXC Container als Virtuallisierungsschicht mitgeliefert. Nur dumm, dass die gesamte Konfiguration des LD-Servers immer über Subdomains läuft, was den Einsatz eines günstigen Zertifikats für nur eine Domain unmöglich macht, will man nicht auf self-signed zurückgreifen. Self-signed verbietet sich jedoch im schulischen Umfeld für die Dienste, die alle nutzen können sollten, weil man so die LuL und SuS dazu erzieht, Zertifikatswarnungen nicht ernst zu nehmen. Meine Lösung verwendet nun einen Apache Reverse Proxy [1], um die interne Pydio Domain extern in einem Unterverzeichnis der SSL-verschlüsselbaren Schuldomain einzublenden. Damit das klappt, müssen der Reverse Proxy Pound des LD-Servers mit dem Reverse Proxy Apache und dem NGinx im LXC-Container in Reihe geschaltet werden. Das geht so:

1. Kontrollieren ob der Symlink auf /etc/apache2/sites-available/pydio in /etc/apache2/sites-enabled weg ist (die Konfiguration findet an anderer Stelle statt).

2. In der /etc/apache2/sites-enabled/000-default die folgenden Einträge in den Abschnitt für VirtualHost * und auch in den Abschnitt für VirtualHost *:443 vornehmen:

3. In der /etc/logodidact/service.conf Pydio für die Domain, die man schon mit SSL versorgt, einschalten:

4. Die beteiligten Dienste neu starten:

Ein

auf dem LD-Server muss eine Antwort liefern, sonst braucht man nicht weiterforschen, sondern muss die DNS Probleme in den Griff bekommen. Auch ein

sollte Ergebnisse liefern – mindestens eine Zeile HTML Code sollte zu sehen sein, mehr schafft links2 nicht, weil es kein JavaScript kann.

Der Aufruf von Pydio funktioniert dann reibungslos, wenn man den „trailing slash“ im URI zu Pydio nicht vergisst. Ohne diesen sieht man nur ein leeres Fenster. Alle Links für die Kolleg/innen und Schüler/innen sollten also so aussehen:

https://sub.domain.tld/pydio/

Jetzt funktioniert das Setup durchgehend ohne Zertifikatswarnungen und zumindest bis zum internen Reverse Proxy Pound auch verschlüsselt.

Wie und ob Pound dann dem Apache Reverse Proxy (als Übersetzer zwischen Internet und virtueller Pydio Maschine m LXC Container) die Daten verschlüsselt weiterreicht habe ich nicht geprüft. Ich vermute aber, auf Grund der Konfiguration, dass dem nicht so ist. Das sollte aber kein Problem darstellen, da an diesen Datenstrom nur root direkt auf dem Server rankommt.

Zu empfehlen ist eine Konfiguration von Pydio durch den Benutzer admin. Auf Pydio ist dieser mit den nötigen Rechten ausgestattet, weil der LXC Container über LDAP am LD-Server hängt. Hier sollte man alles abschalten was geht – vor allem die Funktionen zum unbegrenzten Teilen per Link und ohne Passwort. Denn: LD stellt Pydio extrem offen zur Verfügung. So offen, dass man aus Urheberrechts- und Datenschutzsicht Einschränkungen vornehmen muss, will man seine Schule und Schüler nicht ausliefern.

Weiter ist die Pydio Installation auch komplett veraltet (Version 5.0.4 – aktuell ist 6). Damit muss man wohl leben bei dieser Schulserverlösung. Deren Marketingabteilung wird das Konzept sicherlich als „bewährte Software“ verticken. Auf den bekannteren Exploit-DBs fand ich aktuell aber nichts, was Skript-Kiddies auf die Schnelle gegen Pydio einsetzen könnten.