Home aktualisiert

Home.md

@@ -1,18 +1,18 @@
-### Grundlagen / Überblick
+## Grundlagen / Überblick
 
 Die Motivation für die Plattform war und ist initial der Betrieb einer Community-Lösung auf der Basis von HumHub. Um diese auf einer belastbaren Architektur aufzubauen, die skalierbar und auch für ergänzende Zwecke ausbaufähig ist, wurde die Entscheidung getroffen, die eine professionelle und clusterfähige Virtualisierung auf der Basis von Proxmox ve zu verwenden. Dafür ist mindestens ein Hardware-Server (bare metal) erforderlich. Spätere Erweiterungen können durch Hinzufügen von Hardware-Servern in einem Proxmox ve Cluster skaliert werden. Die folgende Dokumentation beschreibt den Aufbau dieser Lösung und den Entwicklungsstand in der ersten Stufe, mit einem Proxmox ve Server.
 
-### Hardware-Server (bare metal)
+## Hardware-Server (bare metal)
 Der erste „echte“ Server ist ein gemieteter Server im deutschen Rechenzentrum von Hetzner, mit 16x AMD Ryzen 7 3700X 8-Core Processor, 64 GB RAM und zwei 1TB NVMe-Festplatten, die als Software-RAID 1 nach Hetzner-Standard verbunden sind. Die Bezeichnung bei Proxmox ve für so einen Server ist „Node“. Darauf installiert ist zunächst ein Debian 12 Basis-System im Hetzner-Standard gewesen. Auf diesem wurde Proxmox ve 8, nach den Standards für dieses Vorgehen von den Entwicklern von Proxmox ve durchgeführt. Hinzu kamen einige Optimierungen für den Betrieb bei Hetzner und einige Verbesserungen aus Erfahrungen von bestehenden Installationen. Es wurde so wenig wie möglich am Proxmox-Standard verändert, um spätere Updates nicht zu erschweren. Alle Optimierungen sind „updatestabil“.
 
-## Optimierung KSM-Sharing
+### Optimierung KSM-Sharing
 Zu den Optimierungen gehören, ein aktiviertes KSM-Sharing, um Inhalte im RAM sehr effizient zu nutzen, wenn dieser später überwiegend gefüllt ist. Dieser Dienst erkennt gleiche Inhalte im RAM, übergreifend über alle virtuellen Server und fügt sie zusammen. Besonders beim Betrieb von ähnlichen VMs, z.B. mit gleichen Betriebssystemen, spart dies in der Praxis sehr viel teuren RAM auf dem Proxmox-Node (Host = Bare Metal) ein. Grundsätzlich ist dies ein Standard von Proxmox ve und wird auch im Dashboard angezeigt. Bei der Installationsvariante zunächst Debian 12 als Basis zu verwenden und danach Proxmox ve auf diesem nachträglich zu installieren, führt bisher allerdings dazu, dass der Dienst nicht installiert und aktiviert wird. Deshalb braucht es an dieser Stelle eine manuelle Ergänzung.
 
-## Optimierung Netzwerk
+### Optimierung Netzwerk
 Das nach Hetzner-Standard vorinstallierte Debian 12 hat eine für Proxmox ve nicht ausreichende Netzwerkkonfiguration. Um direkt für die Zukunft passende Vorkonfigurationen zu haben, wurden bereits vorkonfigurierte Bridges, mit den Bezeichnungen vmbr0, vmbr1 und vmbr2 angelegt. Die vmbr0 ist das Ausgangsnetzwerk von dem jeweiligen Proxmox-Node und wird auch  bei VMs für die Netzwerkkarte verwendet, wenn eine öffentliche IP-Adresse vom Node „mitgenutzt“ werden soll. Wichtig sei hier zu erwähnen, dass solche VMs auf dem Node gebunden sind, also deren öffentliche IP-Adressen bei einem Umzug auf einen anderen Node nicht funktionieren würden. Dafür ist bereits die vmbr2 vorbereitet. Diese kann genutzt werden, wenn ein oder mehrere Proxmox-Nodes an einen vSwitch von Hetzner angebunden werden UND für diesen vSwitch öffentliche IP-Adressen gebucht werden. Dann ist es möglich über diese Bridge die öffentlichen IP-Adressen für die VMs zu verwenden, die durch die Anbindung an mehrere Proxmox-Nodes auch beim Verschieben von VMs zwischen Proxmox-Nodes erhalten bleiben. Interessant wird dieses Feature bei einem möglichen späteren Cluster-Betrieb von mehreren Proxmox-Nodes im gleichen Rechnezentrum oder zumindest innerhalb von Hetzner, wo die vSwitches verwendet werden können. Die vmbr1 ist so eingerichtet, dass sie ein isoliertes internes Netzwerk mit lokalen IP-Adressen innerhalb von 10.10.10.x/24 ermöglicht. So können VMs untereinander kommunizieren, ohne öffentliche IP-Adressen zu benötigen und ohne vom Internet aus zugänglich sein zu müssen. Besonders interessant ist diese Technik, beim Einsatz von Reverse Proxies. Diese können zwei virtuelle Netzerkkarten haben. Eine bedient das interne Netzwerk und die anderen Netzwerkkarte ist auf einer Bridge, auf der öffentliche IP-Adressen für den Reverse Proxy „geschaltet“ wurden. So kann der Reverse Proxy mit entsprechender Absicherung durch die Firewall alle Anfragen öffentlich annehmen und an die internen VMs mit den Webserver durchleiten. Dies spart öffentliche IP-Adressen und sichert die internen Webserver besser ab, weil diese nur auf Port 80 intern und nur vom Reverse Proxy angesprochen werden.
 Das Setup für die Netzwerkkonfiguration wurde direkt über die Konfiguration in /etc/network/interfaces vom Proxmox-Node gemacht. Die von Proxmox ve bereitgestellte GUI, kann diese Einstellungen überwiegend auch umsetzen und zum gleichen Ziel führen. Allerdings hat es sich in der Vergangenheit bewährt, diese sauber direkt in der Konfigurationsdatei zu editieren. Dies ist aber mit Vorsicht zu machen und nur zu empfehlen, wenn der Server noch nicht produktiv genutzt wird. Eine Unaufmerksamkeit in dieser Konfiguration kann dazu führen, dass der Proxmox-Node nicht mehr über das Internet erreichbar ist, was, neben einer Downtime, aufwendiger zu beheben ist, weil dafür das Rescure System von Hetzner gebraucht wird. Deshalb hier die Empfehlung, diese einmal initial sauber zu erstellen und danach Änderungen sehr gut zu überlegen. Im laufenden Betrieb könnte es sicherer sein, die Proxmox-GUI dafür zu verwenden, weil diese zumindest Syntax-Fehler vermeidet. Trotz der manuellen Anlage der Konfiguration, sieht dies in der GUI so aus und kann dort nachvollzogen werden:
 
-## Optimierung Firewall
+### Optimierung Firewall
 Die Firewall in Proxmox ve hat drei Ebenen:
     • Datacenter-Firewall
     • Node-Firewall
@@ -24,28 +24,28 @@ So sehen die Einstellungen der Datacenter-Firewall aus, bevor diese aktiviert wi
 
 Es ist zu empfehlen dauerhaft keine weiteren Ports zu öffnen.
 
-## Optimierung fail2ban und Härtung
+### Optimierung fail2ban und Härtung
 Es ist nicht zu vermeiden, dass auf einem Proxmox-Node im Rechenzentrum, die administrativen Ports 22 für SSH und 8006, für die Proxmox-GUI aus dem Internet erreichbar sind. Diese Ports müssen offen bleiben. Neben guten Passwörtern für die GUI und der Empfehlung root-Logins sowohl über SSH, als auch über die GUI abzuschalten, ist eine 2 Faktor Authentifizierung für die GUI zu empfehlen. Unabhängig davon, sollte für SSH und für die Weboberfläche auf Port 8006 ein aktives fail2ban hinterlegt sein, um Angriffsversuche mit vielen (falschen) Passworteingaben durch Sperrung der IP-Adressen, die dies versuchen zu erschweren und diese möglichst längerfristig zu blockieren. Für SSH liefert fail2ban entsprechende Regeln und Suchfilter in den Logs mit. Diese müssen nur aktiviert werden und ggf. die Sperrzeit auf höhere, aber angemessene Werte erhöht werden. Für Port 8006 müssen eigene Filter hinterlegt und getestet werden. Dies wurde bei diesem Setup gemacht. Bedeutet allerdings auch, dass Admins, die zu oft unkonzentriert falsche Passwörter eingeben, ggf. längere Zeit gesperrt sind, auf dem Internetzugang, mit dem die Login-Versuche unternommen wurden. Dies behebt sich selber, nach der hinterlegten Sperrzeit oder erfordert einen Eingriff durch einen nicht gesperrten Admin.
 
 ### Virtuelle Server (VMs)
 Zur Realisierung des HumHub-Betriebs werden folgende virtuellen Server eingesetzt:
 
-## humhub-vm
+### humhub-vm
 Dies ist der Webserver, mit einem klassischen LAMP-Setup, optimiert für HumHub. Das Betriebssystem ist ein Debian. Als Datenbank wird MariaDB verwendet und PHP ist als PHP-FPM realisiert. Der Webserver ist im internen Netzwerk erreichbar und kommuniziert auf Port 80. Ein direkter Zugriff auf diese VM über das Internet ist aus Sicherheitsgründen und zur Ressourcen-Schonung (Public IPs) nicht möglich, sofern keine Tunnel angelegt werden. Dies ist die VM für das produktive HumHub. Eine Verbindung über das Internet ist nur über den rProxy möglich, womit HumHub öffentlich aufgerufen wird.
 
-**rProxy**
+###rProxy
 Diese VM ist der Reverse Proxy. Die VM hat zwei Netzwerkkarten. Auf der einen Netzwerkkarte, benutzt die VM öffentliche IP-Adressen für IPv4 und IPv6. Auf der anderen Netzwerkkarte hat die VM eine interne IP-Adresse und kann die internen VMs im internen Netzwerk erreichen. Als Software für den die Einrichtung der einzelnen Domains und Dienste, wird der Nginx-Proxy-Manager verwendet, der wiederum in Docker Compose realisiert ist. Die VM selber basiert auf Debian und hat eine entsprechende Standard-Installation mit Docker und Docker Compose, auf Basis der Standard-Repositories von Docker für Debian. Der Nginx-Reverse-Proxy-Manager erzeugt und aktualisiert automatisiert die Lets Encrypt Zertifikate, um vom Internet aus einen verschlüsselten Zugriff über https auf HumHub zu ermöglichen. Intern werden alle Anfragen an die eigentliche Webserver-VM mit HumHub durchgeleitet. Der rProxy kann nahezu beliebig viele Domains und Subdomains an die hinterliegenden Webserver durchleiten und ist damit zukünftig ausbaufähig. Temporär kann die VM des rProxy auch genutzt werden, um z.B. interne Ports aus dem Internet direkt erreichbar zu machen. Lediglich die Ports 80 und 443 sind reserviert. Um interne Dienste auf beliebige Ports und die öffentlichen IP-Adressen, des rProxy zu tunneln, eignen sich SSH-Tunnel im internen Netzwerk. Zu beachten ist hierbei, dass die Firewall des rProxy diese Ports ebenfalls öffnen muss. Wichtig: Solche Lösungen sollten nur temporär genutzt werden. Werden Dienste dauerhaft direkt vom Internet aus zugänglich gemacht, sind entsprechende Sicherheitsthemen alle durchzugehen.
 
-**humhub-test**
+###humhub-test
 Diese VM ist ebenfalls eine nahezu baugleicher Webserver, wie das produktive HumHub und ist für Testzwecke gedacht, die im produktiven HumHub nur schwer oder mit zu großem Risiko möglich wären. Eine Verbindung über das Internet ist nur über den rProxy möglich, womit HumHub öffentlich aufgerufen wird, genau wie bei dem produktiven HumHub. Eine entsprechend andere Subdomain ist dafür notwendig und führt im rProxy zu der Entscheidung, wohin die Anfragen intern weitergeleitet werden.
 
-**debian-desktop**
+###debian-desktop
 Diese VM ist eine Hilfs- und Wartungs-VM. Der Sinn dieser VM ist, dass dort ein vollständiger Desktop und Tools für die Administration installiert sind. Der Desktop kann über die Proxmox ve GUI bedient werden. Die Netzwerkkarte ist an das interne Netzwerk angebunden. Außerdem ist ein Internetzugriff, wie bei einer Workstation möglich. Über diese VM können alle Arbeiten an Internen Systemen gemacht werden und sie hilft auch, um z.B. Dateien von außerhalb per Download in das interne Netzwerk zu holen, wie z.B. Installationspakete für HumHub, Datenbank-Dumps usw.. Ein Zugriff auf diesen Desktop außerhalb der Proxmox-GUI wäre nur möglich, wenn Tunnel auf öffentliche IP-Adressen eingerichtet werden, wodurch sich dieser Desktop in einer relativ sicheren Umgebung befindet. Dennoch ist dies ein Expertentool, weil z.B. über den dort installierten Browser beliebige Dateien in das interne Netzwerk geholt werden können. Dieser ist somit mit der nötigen Vorsicht von erfahrenen Administratoren zu bedienen, wie die anderen Komponenten auch. Selbstverständlich gibt es andere Möglichkeiten das interne Netzwerk erreichbar zu machen. Dieser Desktop bietet allerdings einen schnellen spontanen Zugriff, ohne Extra-Tools z.B. auf dem eigenen Computer installieren zu müssen oder z.B. SSH-Keys hinterlegen zu müssen. Sollten Entwickler im internen Netzwerk umfangreiche Arbeiten durchführen wollen, kann die im Standard fehlende Copy & Paste Funktion und andere Einschränkungen ggf. behindern. Dafür kann sich initial ein Mehraufwand z.B. für die Einrichtung von temporären SSH-Tunneln lohnen.
 
-**Weitere virtuelle Maschinen**
+###Weitere virtuelle Maschinen
 Die skalierbare Plattform auf Basis von Proxmox ve eignet sich sehr gut, um weitere Services zu hosten, aber auch, um temporäre Test-VMs zu erstellen, die bei der Entwicklung helfen. Deshalb sind weitere VMs vorhanden und können sich dynamisch ändern. Aktuell nicht benötigte VMs können einfach abgeschaltet werden und dauerhaft nicht mehr benötigte VMs, werden gelöscht:
 
-**VM-IDs**
+###VM-IDs
 Im Standard schlägt Promox ve die interne ID beim Erstellen einer VM vor. Diese beginnt im Standard bei 100 und jede weitere VM wird um einen Zähler erhöht. Ist die VM einmal angelegt, ist diese ID fix, bis die VM gelöscht wird. Soll sie nachträglich geändert werden, gibt es noch die Möglichkeit die VM zu klonen und den Klon mit der Wunsch-ID zu versehen. Anschließend wird die ursprüngliche VM mit der unerwünschten ID gelöscht. Dieser Vorgang kann je nach hinterlegten virtuellen Festplatten aufwendig sein. Deshalb sollte sich die ID, wenn sie nicht Standard sein soll, gut überlegt werden. In diesem Setup sind die IDs als Hilfestellung mit den jeweils internen IP-Adressen identisch. IDs dürfen nur Zahlen und müssen eindeutig sein. Hier bedeutet die ID 1010106, dass die VM die interne IP-Adresse 10.10.10.6 hat. Weil Punkte bei IDs nicht erlaubt sind, wurden sie weggelassen. Natürlich sind IDs nicht dafür gedacht, um IP-Adressen abzubilden. Dies ist nur eine kleine Hilfestellung, in diesem Setup und muss so nicht gemacht werden.
 
 ### Backup-Server