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.

echo "deb http://download.proxmox.com/debian jessie pve-no-subscription" >> /etc/apt/sources.list
wget -O - http://download.proxmox.com/debian/key.asc | apt-key add -
apt-get update
apt-get upgrade
apt-get dist-upgrade
uname -a
reboot

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

apt-get install proxmox-ve ssh postfix ksm-control-daemon open-iscsi systemd-sysv mailutils

Nach einem erneuten Reboot zeigte ein uname -a nun

Linux hostname 4.4.59-1-pve #1 SMP PVE 4.4.59-87 (Tue, 25 Apr 2017 09:01:58 +0200) x86_64 GNU/Linux

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

78.78.78.82

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

78.78.78.86
78.78.78.90

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

auto lo
iface lo inet loopback
iface lo inet6 loopback

# ETH0
auto eth0
iface eth0 inet static
  address 78.78.78.82 # Server Basis IP
  netmask 255.255.255.255 # Netzmaske neu gesetzt
  gateway  78.78.78.65 # wird von Hetzner mitgeteilt
  pointopoint 78.78.78.65 # PTP auf das Gateway

# VMBR0

auto vmbr0
iface vmbr0 inet static
  address 78.78.78.82 # Server Basis IP
  netmask 255.255.255.255 # Netzmaske neu gesetzt
  bridge_ports none
  bridge_stp off
  bridge_fd 0
    up ip route add 78.78.78.86/32 dev vmbr0 # erste VM mit erster Zusatz-IP
    up ip route add 78.78.78.90/32 dev vmbr0 # zweite VM mit zweiter Zusatz-IP

# IPv6 Config 

iface eth0 inet6 static
        address  121:121:121:121::2
        netmask  128
        gateway  fe80::1
        up ip -6 route add default via fe80::1 dev eth0
        up sysctl -p

iface vmbr0 inet6 static
        address 121:121:121:121::2
        netmask 64

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 

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
net.ipv6.conf.all.forwarding=1

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

78.78.78.86/32

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

78.78.78.82

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

lxc-attach -n 100

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

auto vmbr1
iface vmbr1 inet static
        address  10.16.1.0
        netmask  255.255.0.0
        bridge_ports none
        bridge_stp off
        bridge_fd 0

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:

ProxyRequests Off
   <Proxy *>
    Order allow,deny
    Allow from all
  </Proxy>
ProxyPass /pydio http://pydio/
ProxyPassReverse /pydio http://pydio/

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

[Pydio]
Host sub.domain.tld
Alias pydio.sub.domain.tld
AllowExternalHTTPS yes
URL sub.domain.tld/pydio
RedirectExternalHTTP https://sub.domain.tld/pydio

4. Die beteiligten Dienste neu starten:

ldfirewall restart
update_pound_config -r
/etc/init.d/apache2 restart

Ein

host pydio

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

links2 http://pydio
links2 https://pydio # weniger relevant, s.U.

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.