Ehrenamtsplattform/EP
0
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Home aktualisiert

jere 2025-06-27 16:56:45 +02:00
parent 8f5f294c64
commit c9a562aaa7
1 changed files with 5 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

10
Home.md

@ -5,14 +5,14 @@ Die Motivation für die Plattform war und ist initial der Betrieb einer Communit
### 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“. 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. 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 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: 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: Die Firewall in Proxmox ve hat drei Ebenen:
• Datacenter-Firewall • Datacenter-Firewall
• Node-Firewall • Node-Firewall
@ -24,13 +24,13 @@ So sehen die Einstellungen der Datacenter-Firewall aus, bevor diese aktiviert wi
Es ist zu empfehlen dauerhaft keine weiteren Ports zu öffnen. 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. 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) ### Virtuelle Server (VMs)
Zur Realisierung des HumHub-Betriebs werden folgende virtuellen Server eingesetzt: 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. 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**