Version vom 7. August 2026, 12:57 Uhr

Zentraler MegBes-Server – Inventur und Administration

Zweck und Status

Diese Seite dokumentiert den geprüften Istzustand, das Berechtigungsmodell und das Inventurverfahren des zentralen MegBes-Servers. Sie ist die technische Grundlage für Wartung, Fehlerdiagnose und das spätere Anlegen neuer Kundencontainer.

Stand der Bestandsaufnahme: 7. August 2026. System, Container, Mounts, Hostbindungen, Plesk-Proxy-Zuordnungen, Firewall-Grundzustand und vorhandene Plesk-Sicherungen wurden ausschließlich lesend aufgenommen. MongoDB-Authentisierung, Herkunft der Containerdefinitionen und ein praktischer Wiederherstellungstest bleiben offen. Vorläufige Beobachtungen sind ausdrücklich als solche gekennzeichnet.

Serverbasis

Merkmal	Geprüfter Stand
Hosting	IONOS-Server mit Plesk
Betriebssystem	Ubuntu 24.04.4 LTS, x86_64
Plesk	Plesk Obsidian 18.0.79.5
Container-Laufzeit	Docker 29.7.2
Arbeitsspeicher	15,55 GiB für die Container verfügbar
Massenspeicher	464 GiB gesamt, rund 22 GiB belegt; zum Prüfzeitpunkt kein Kapazitätsengpass
Swap	nicht eingerichtet
Laufzeit des Hosts	rund 94 Tage zum Prüfzeitpunkt
Docker-Netzwerke	Standardnetzwerke `bridge`, `host` und `none`; keine benannten projektspezifischen Netzwerke
Docker-Volumes	Keine benannten Volumes; persistente Daten werden voraussichtlich über Bind-Mounts bereitgestellt und müssen noch geprüft werden

Die öffentliche IP-Adresse, Zugangsdaten und weiteren sicherheitsrelevanten Verbindungsdaten werden nicht auf dieser Seite veröffentlicht. Sie liegen in der geschützten System- beziehungsweise Passwortdokumentation.

Berechtigungsmodell für Administration

Für automatisierte Prüfung und unterstützte Administration existiert der eigene Serverbenutzer `clawtronics` mit separatem ED25519-Schlüssel.

Der Benutzer:

besitzt keine Mitgliedschaft in der Gruppe `docker`,
besitzt keinen pauschalen Root- oder sudo-Zugang,
darf nur ausdrücklich freigegebene, root-eigene Hilfsskripte ohne Passwort ausführen,
kann die freigegebenen Skripte selbst nicht verändern,
erhält neue Rechte stufenweise und nur für einen dokumentierten Betriebszweck.

Der aktuelle Read-only-Befehl `/usr/local/sbin/megbes-discovery` liefert ausschließlich Plesk-Version, Container, Images, Docker-Netzwerke, Docker-Volumes und eine momentane Ressourcenübersicht. Containeränderungen, `docker exec`, Datenbankzugriffe und Dateisystemänderungen sind nicht freigegeben.

Die Gruppe `docker` wird nicht vergeben, da deren Mitgliedschaft praktisch Root-Rechte ermöglicht. Erweiterungen werden als eng begrenzte, root-eigene Hilfsskripte umgesetzt.

Aktueller Containerbestand

Zum Prüfzeitpunkt liefen 13 Container ohne sichtbare Neustartschleife.

Container	Image beziehungsweise Release	Hostbindung	Aufgabe
`megbes-status`	`tinetronics/megbes-status:AUGUST-2026-2-RELEASE`	alle IPv4-Schnittstellen, Port 9990	zentraler Status-Monitor
`megbes-external-tine`	`MARCH-2026-1-RELEASE`	alle IPv4-Schnittstellen, Port 32770	Kundenprojekt Tine
`megbes-external-limes`	`MARCH-2026-1-RELEASE`	alle IPv4-Schnittstellen, Port 32780	Kundenprojekt Limes
`megbes-external-gkp`	`MARCH-2026-1-RELEASE`	alle IPv4-Schnittstellen, Port 32769	Kundenprojekt GKP
`megbes-external-bayam`	`MARCH-2026-1-RELEASE`	nur localhost, Port 32768	Kundenprojekt BayAM
`megbes-external-miqua`	`MARCH-2026-1-RELEASE`	alle IPv4-Schnittstellen, Port 32779	Kundenprojekt MiQua
`megbes-external-messe`	`MARCH-2026-1-RELEASE`	alle IPv4- und IPv6-Schnittstellen, Port 32771	Kundenprojekt Messe
`megbes-external-hon`	`MARCH-2026-1-RELEASE`	nur localhost, Port 9997	Kundenprojekt HoN
`mediawiki`	`mediawiki:latest`	nur localhost, Port 49155	internes MegBes-Wiki
`mongodb`	`mongo:7.0.12`	alle IPv4-Schnittstellen, Port 49154	zentrale MongoDB
`megbes-external-nowalux`	`MARCH-2026-1-RELEASE`	alle IPv4-Schnittstellen, Port 34615	Kundenprojekt NowaLux
`megbes-external-miquaguide`	`MARCH-2026-1-RELEASE`	alle IPv4- und IPv6-Schnittstellen, Port 32774	Kundenprojekt MiQua Guide
`megbes-external-gse`	`MARCH-2026-1-RELEASE`	alle IPv4-Schnittstellen, Port 32805	Kundenprojekt GSE

Die Hostbindung zeigt, an welchen Schnittstellen Docker lauscht. Sie beweist allein noch keine Erreichbarkeit aus dem Internet; dafür müssen zusätzlich Plesk-, Firewall- und Providerregeln geprüft werden.

Containerbetrieb und Mounts

Alle Container verwenden die Restart-Policy `unless-stopped`. Kein Container besitzt einen Docker-Healthcheck. Die angezeigten Speicherlimits entsprechen jeweils dem gesamten Hostspeicher; damit sind keine individuellen Container-Speichergrenzen erkennbar.

Die persistenten beziehungsweise extern bereitgestellten Daten werden über beschreibbare Bind-Mounts eingebunden:

Bereich	Hostpfad	Containerpfad	Bemerkung
allgemeine Schlüsselablage	`/home/ssl`	`/opt/app/key`	bei Status-Monitor und mehreren External-Containern eingebunden
allgemeine Zertifikate	`/home/certs`	`/opt/app/certs`	beim Status-Monitor eingebunden
projektspezifische Zertifikate	`/home/certs/<projekt>`	`/opt/app/certs`	bei Tine, Limes, BayAM, MiQua, Messe, HoN, MiQua Guide und GSE
MediaWiki-Daten	`/home/megbeswiki`	`/var/www/data`	enthält die persistente Wiki-Konfiguration und -Daten
MongoDB-Daten	`/root/mdb/data`	`/data/db`	produktive Datenablage
MongoDB-Konfiguration	`/root/mdb/config`	`/data/configdb`	Konfigurationsdatenbank

Alle ermittelten Mounts sind mit Schreibrecht eingebunden. Für reine Zertifikats- und Schlüsselablagen ist später zu prüfen, ob ein Read-only-Mount genügt. Eine solche Änderung darf erst nach Prüfung der Anwendung und mit Rückkehrweg erfolgen.

Netzwerk und externe Erreichbarkeit

UFW ist auf dem Host inaktiv. `nftables` enthält von Docker erzeugte NAT- und Filterregeln sowie Fail2ban-Regeln. Zusätzlich muss eine vorgelagerte Provider- oder Plesk-Firewall wirken, da nicht alle lokal gebundenen Ports von außen erreichbar waren.

Ein externer TCP-Verbindungstest am 7. August 2026 ergab:

Port beziehungsweise Gruppe	Ergebnis
22, 80 und 443	öffentlich erreichbar; erwartete SSH- und Webdienste
9990	öffentlich direkt erreichbar; Status-Monitor zusätzlich zum Domainzugriff exponiert
9997 und 32768	nicht öffentlich erreichbar und lokal an `127.0.0.1` gebunden
32769, 32770, 32771, 32774, 32779, 32780, 32805 und 34615	trotz Bindung an alle Schnittstellen beim Test nicht öffentlich erreichbar
49154	MongoDB trotz Bindung an alle IPv4-Schnittstellen beim Test nicht öffentlich erreichbar
49155	MediaWiki nicht öffentlich direkt erreichbar und lokal an `127.0.0.1` gebunden

Die externe Nichterreichbarkeit ist eine Momentaufnahme und ersetzt keine bewusst dokumentierte Firewallregel. Empfohlen ist, Reverse-Proxy-Ziele grundsätzlich an `127.0.0.1` zu binden, sofern kein direkter Zugriff erforderlich ist. Besonders Port 9990 und die MongoDB-Bindung sind vor einer Änderung zunächst gegen den betrieblichen Zweck und die Plesk-Konfiguration zu prüfen.

Plesk-Domains und Reverse Proxy

Plesk verwaltet die Domains beziehungsweise Subdomains `bayam`, `gkp`, `hon`, `limes`, `megbes.de`, `messe`, `miqua`, `miquaguide`, `nowalux`, `status`, `tine`, `vserver` und `wiki` unter `megbes.de`.

Die nginx-Konfigurationen leiten die projektbezogenen Domains auf die jeweiligen Docker-Hostports weiter. Die Ziele sind derzeit überwiegend als `0.0.0.0:<port>` eingetragen. Funktional ist das möglich; als klareres internes Proxyziel sollte bei einer späteren Bereinigung `127.0.0.1:<port>` zusammen mit einer lokalen Containerbindung geprüft werden. Generierte Plesk-Konfigurationen dürfen nicht direkt und dauerhaft bearbeitet werden; Änderungen erfolgen über die zuständige Plesk-Einstellung beziehungsweise zusätzliche Konfiguration.

Sicherungsstand

Im Plesk-Sicherungsverzeichnis liegen tägliche inkrementelle Sicherungen mit erfolgreichen Statusmarkern bis einschließlich 7. August 2026. Erfasst sind Plesk-Systembestandteile sowie die Domains `gkp.megbes.de`, `hon.megbes.de`, `megbes.de`, `nowalux.megbes.de`, `status.megbes.de`, `vserver.megbes.de` und `wiki.megbes.de`.

Aus der Dateiliste lässt sich noch nicht ableiten, dass `/root/mdb/data`, `/root/mdb/config`, `/home/certs`, `/home/ssl` und alle Containerdefinitionen vollständig und konsistent gesichert werden. Insbesondere die MongoDB benötigt ein anwendungsgeeignetes Backupverfahren; eine reine Dateikopie im laufenden Betrieb ist nicht automatisch konsistent. Ablageziel, Aufbewahrungsdauer und ein praktischer Wiederherstellungstest bleiben zu dokumentieren.

Erste Betriebsbeobachtungen

Alle 13 Container liefen zum Prüfzeitpunkt seit rund sechs Stunden.
Die momentane CPU- und Speicherauslastung war unauffällig.
Der Status-Monitor nutzt den derzeit bekannten aktuellen Release `AUGUST-2026-2-RELEASE`.
Die zehn Kundencontainer von `megbes-external` verwenden `MARCH-2026-1-RELEASE`, obwohl das Image `AUGUST-2026-1-RELEASE` lokal vorhanden ist. Daraus folgt kein automatischer Updateauftrag; Freigabe, Kompatibilität und Rückkehrweg sind projektweise zu prüfen.
MediaWiki sowie BayAM und HoN sind nur an localhost gebunden.
Die Bindung von MongoDB an alle IPv4-Schnittstellen ist sicherheitsrelevant. Der Port war extern nicht erreichbar; Authentisierung, vorgelagerte Filterregel und tatsächlicher Verwendungszweck bleiben dennoch zu prüfen.
Mehrere MegBes-Ports sind an alle Schnittstellen gebunden, waren beim externen Test mit Ausnahme von Port 9990 jedoch nicht erreichbar. Ob die Bindungen erforderlich sind oder Plesk als lokaler Reverse Proxy genügt, wird projektweise geprüft.

Inventurplan

Die folgenden Punkte werden ausschließlich lesend aufgenommen, bevor Betriebsänderungen erfolgen:

Eigentümer, Rechte und Sicherungsumfang der ermittelten Datenpfade
Herkunft und reproduzierbare Definition der Container
Zertifikatszuordnungen und Erneuerungsverfahren
MongoDB-Authentisierung und Netzwerkbindung, ohne Geheimwerte auszugeben
konsistentes Backup der MongoDB- und MediaWiki-Daten
Aufbewahrungsdauer und praktischer Wiederherstellungstest
Logwachstum und Logrotation der Container
standardisierter Ablauf für Update, Rollback und neuen Kundencontainer

Regeln für Änderungen

Vor jeder Änderung werden betroffene Container, Konfiguration, Mounts, Ports und aktueller Image-Stand gesichert beziehungsweise dokumentiert.
Geheimwerte werden weder in Befehlsausgaben noch im Wiki gespeichert.
Ein Container wird nur mit bekanntem Rückkehrweg ersetzt.
Datenbank- und Volume-Änderungen erfolgen erst nach geprüfter Sicherung.
Neustarts, Updates und neue Kundencontainer benötigen einen ausdrücklichen Auftrag.
Nach Änderungen werden Anwendung, Logs, Status-Monitor und mindestens ein kontrollierter Projektablauf geprüft.

Siehe auch Megbes-external unter Plesk und Wartung, Backups und Fehlerdiagnose.

@@ Zeile 4: / Zeile 4: @@
 Diese Seite dokumentiert den geprüften Istzustand, das Berechtigungsmodell und das Inventurverfahren des zentralen MegBes-Servers. Sie ist die technische Grundlage für Wartung, Fehlerdiagnose und das spätere Anlegen neuer Kundencontainer.
-'''Stand der Bestandsaufnahme: 7. August 2026.''' Die erste Übersicht ist geprüft; Mounts, Firewall, Plesk-Proxy-Zuordnungen, Backups und Wiederherstellungswege werden noch vertieft inventarisiert. Vorläufige Beobachtungen sind ausdrücklich als solche gekennzeichnet.
+'''Stand der Bestandsaufnahme: 7. August 2026.''' System, Container, Mounts, Hostbindungen, Plesk-Proxy-Zuordnungen, Firewall-Grundzustand und vorhandene Plesk-Sicherungen wurden ausschließlich lesend aufgenommen. MongoDB-Authentisierung, Herkunft der Containerdefinitionen und ein praktischer Wiederherstellungstest bleiben offen. Vorläufige Beobachtungen sind ausdrücklich als solche gekennzeichnet.
 == Serverbasis ==
@@ Zeile 19: / Zeile 19: @@
 |-
 | Arbeitsspeicher || 15,55 GiB für die Container verfügbar
+|-
+| Massenspeicher || 464 GiB gesamt, rund 22 GiB belegt; zum Prüfzeitpunkt kein Kapazitätsengpass
+|-
+| Swap || nicht eingerichtet
+|-
+| Laufzeit des Hosts || rund 94 Tage zum Prüfzeitpunkt
 |-
 | Docker-Netzwerke || Standardnetzwerke `bridge`, `host` und `none`; keine benannten projektspezifischen Netzwerke
@@ Zeile 76: / Zeile 82: @@
 Die Hostbindung zeigt, an welchen Schnittstellen Docker lauscht. Sie beweist allein noch keine Erreichbarkeit aus dem Internet; dafür müssen zusätzlich Plesk-, Firewall- und Providerregeln geprüft werden.
+== Containerbetrieb und Mounts ==
+Alle Container verwenden die Restart-Policy `unless-stopped`. Kein Container besitzt einen Docker-Healthcheck. Die angezeigten Speicherlimits entsprechen jeweils dem gesamten Hostspeicher; damit sind keine individuellen Container-Speichergrenzen erkennbar.
+Die persistenten beziehungsweise extern bereitgestellten Daten werden über beschreibbare Bind-Mounts eingebunden:
+{| class="wikitable"
+! Bereich !! Hostpfad !! Containerpfad !! Bemerkung
+|-
+| allgemeine Schlüsselablage || `/home/ssl` || `/opt/app/key` || bei Status-Monitor und mehreren External-Containern eingebunden
+|-
+| allgemeine Zertifikate || `/home/certs` || `/opt/app/certs` || beim Status-Monitor eingebunden
+|-
+| projektspezifische Zertifikate || `/home/certs/<projekt>` || `/opt/app/certs` || bei Tine, Limes, BayAM, MiQua, Messe, HoN, MiQua Guide und GSE
+|-
+| MediaWiki-Daten || `/home/megbeswiki` || `/var/www/data` || enthält die persistente Wiki-Konfiguration und -Daten
+|-
+| MongoDB-Daten || `/root/mdb/data` || `/data/db` || produktive Datenablage
+|-
+| MongoDB-Konfiguration || `/root/mdb/config` || `/data/configdb` || Konfigurationsdatenbank
+|}
+Alle ermittelten Mounts sind mit Schreibrecht eingebunden. Für reine Zertifikats- und Schlüsselablagen ist später zu prüfen, ob ein Read-only-Mount genügt. Eine solche Änderung darf erst nach Prüfung der Anwendung und mit Rückkehrweg erfolgen.
+== Netzwerk und externe Erreichbarkeit ==
+UFW ist auf dem Host inaktiv. `nftables` enthält von Docker erzeugte NAT- und Filterregeln sowie Fail2ban-Regeln. Zusätzlich muss eine vorgelagerte Provider- oder Plesk-Firewall wirken, da nicht alle lokal gebundenen Ports von außen erreichbar waren.
+Ein externer TCP-Verbindungstest am 7. August 2026 ergab:
+{| class="wikitable"
+! Port beziehungsweise Gruppe !! Ergebnis
+|-
+| 22, 80 und 443 || öffentlich erreichbar; erwartete SSH- und Webdienste
+|-
+| 9990 || öffentlich direkt erreichbar; Status-Monitor zusätzlich zum Domainzugriff exponiert
+|-
+| 9997 und 32768 || nicht öffentlich erreichbar und lokal an `127.0.0.1` gebunden
+|-
+| 32769, 32770, 32771, 32774, 32779, 32780, 32805 und 34615 || trotz Bindung an alle Schnittstellen beim Test nicht öffentlich erreichbar
+|-
+| 49154 || MongoDB trotz Bindung an alle IPv4-Schnittstellen beim Test nicht öffentlich erreichbar
+|-
+| 49155 || MediaWiki nicht öffentlich direkt erreichbar und lokal an `127.0.0.1` gebunden
+|}
+Die externe Nichterreichbarkeit ist eine Momentaufnahme und ersetzt keine bewusst dokumentierte Firewallregel. Empfohlen ist, Reverse-Proxy-Ziele grundsätzlich an `127.0.0.1` zu binden, sofern kein direkter Zugriff erforderlich ist. Besonders Port 9990 und die MongoDB-Bindung sind vor einer Änderung zunächst gegen den betrieblichen Zweck und die Plesk-Konfiguration zu prüfen.
+== Plesk-Domains und Reverse Proxy ==
+Plesk verwaltet die Domains beziehungsweise Subdomains `bayam`, `gkp`, `hon`, `limes`, `megbes.de`, `messe`, `miqua`, `miquaguide`, `nowalux`, `status`, `tine`, `vserver` und `wiki` unter `megbes.de`.
+Die nginx-Konfigurationen leiten die projektbezogenen Domains auf die jeweiligen Docker-Hostports weiter. Die Ziele sind derzeit überwiegend als `0.0.0.0:<port>` eingetragen. Funktional ist das möglich; als klareres internes Proxyziel sollte bei einer späteren Bereinigung `127.0.0.1:<port>` zusammen mit einer lokalen Containerbindung geprüft werden. Generierte Plesk-Konfigurationen dürfen nicht direkt und dauerhaft bearbeitet werden; Änderungen erfolgen über die zuständige Plesk-Einstellung beziehungsweise zusätzliche Konfiguration.
+== Sicherungsstand ==
+Im Plesk-Sicherungsverzeichnis liegen tägliche inkrementelle Sicherungen mit erfolgreichen Statusmarkern bis einschließlich 7. August 2026. Erfasst sind Plesk-Systembestandteile sowie die Domains `gkp.megbes.de`, `hon.megbes.de`, `megbes.de`, `nowalux.megbes.de`, `status.megbes.de`, `vserver.megbes.de` und `wiki.megbes.de`.
+Aus der Dateiliste lässt sich noch nicht ableiten, dass `/root/mdb/data`, `/root/mdb/config`, `/home/certs`, `/home/ssl` und alle Containerdefinitionen vollständig und konsistent gesichert werden. Insbesondere die MongoDB benötigt ein anwendungsgeeignetes Backupverfahren; eine reine Dateikopie im laufenden Betrieb ist nicht automatisch konsistent. Ablageziel, Aufbewahrungsdauer und ein praktischer Wiederherstellungstest bleiben zu dokumentieren.
 == Erste Betriebsbeobachtungen ==
@@ Zeile 83: / Zeile 145: @@
 * Die zehn Kundencontainer von `megbes-external` verwenden `MARCH-2026-1-RELEASE`, obwohl das Image `AUGUST-2026-1-RELEASE` lokal vorhanden ist. Daraus folgt kein automatischer Updateauftrag; Freigabe, Kompatibilität und Rückkehrweg sind projektweise zu prüfen.
 * MediaWiki sowie BayAM und HoN sind nur an localhost gebunden.
-* Die Bindung von MongoDB an alle IPv4-Schnittstellen ist sicherheitsrelevant und muss gegen Firewall, Authentisierung und tatsächlichen Verwendungszweck geprüft werden.
+* Die Bindung von MongoDB an alle IPv4-Schnittstellen ist sicherheitsrelevant. Der Port war extern nicht erreichbar; Authentisierung, vorgelagerte Filterregel und tatsächlicher Verwendungszweck bleiben dennoch zu prüfen.
-* Mehrere MegBes-Ports sind an alle Schnittstellen gebunden. Ob dies erforderlich ist oder Plesk als lokaler Reverse Proxy genügt, wird projektweise geprüft.
+* Mehrere MegBes-Ports sind an alle Schnittstellen gebunden, waren beim externen Test mit Ausnahme von Port 9990 jedoch nicht erreichbar. Ob die Bindungen erforderlich sind oder Plesk als lokaler Reverse Proxy genügt, wird projektweise geprüft.
 == Inventurplan ==
 Die folgenden Punkte werden ausschließlich lesend aufgenommen, bevor Betriebsänderungen erfolgen:
-# Container-Mounts, Datenpfade und Eigentümer
+# Eigentümer, Rechte und Sicherungsumfang der ermittelten Datenpfade
-# Restart-Policies, Healthchecks und Ressourcenbegrenzungen
+# Herkunft und reproduzierbare Definition der Container
-# Plesk-Domains, Reverse-Proxy-Ziele und Zertifikatszuordnungen
+# Zertifikatszuordnungen und Erneuerungsverfahren
-# Host-Firewall und tatsächlich öffentlich erreichbare Ports
 # MongoDB-Authentisierung und Netzwerkbindung, ohne Geheimwerte auszugeben
-# Ablage und Sicherung der MongoDB- und MediaWiki-Daten
+# konsistentes Backup der MongoDB- und MediaWiki-Daten
-# Backup-Zeitpläne, Aufbewahrung und vorhandene Wiederherstellungstests
+# Aufbewahrungsdauer und praktischer Wiederherstellungstest
-# freier Speicherplatz, Logwachstum und Docker-Datennutzung
+# Logwachstum und Logrotation der Container
-# Herkunft und Startparameter jedes Containers
 # standardisierter Ablauf für Update, Rollback und neuen Kundencontainer