Zentraler MegBes-Server – Inventur und Administration
Zentraler MegBes-Server – Inventur und Administration
[Bearbeiten]Zweck und Status
[Bearbeiten]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
[Bearbeiten]| 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
[Bearbeiten]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
[Bearbeiten]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
[Bearbeiten]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
[Bearbeiten]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
[Bearbeiten]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
[Bearbeiten]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`.
Für MongoDB wurde zusätzlich ein logisches Sicherungsverfahren mit `mongodump` eingerichtet. Der erste aktuelle, komprimierte Dump wurde erfolgreich erstellt und mittels Gzip-Test und SHA-256 geprüft. Ein Cronjob erstellt täglich um 02:17 Uhr UTC einen neuen Dump. Details und Wiederherstellungsregeln: MongoDB sichern und wiederherstellen.
Noch offen sind automatische Aufbewahrung, eine externe Kopie außerhalb des Servers und ein praktischer Wiederherstellungstest. Aus der Plesk-Dateiliste lässt sich außerdem nicht ableiten, dass `/home/certs`, `/home/ssl` und alle Containerdefinitionen vollständig gesichert werden.
Wiki-Logo und Persistenz
[Bearbeiten]Das MegBes-Logo aus dem Status-Monitor ist im Wiki eingebunden. Die ausgelieferte Datei und das Quelllogo besitzen dieselbe SHA-256-Prüfsumme. Vor der Änderung wurde `LocalSettings.php` geschützt unter `/home/megbeswiki/config-backups` gesichert.
Logo und persistente Kopie liegen unter `/home/megbeswiki/assets`. Die aktive `LocalSettings.php` und die ausgelieferte Bilddatei befinden sich derzeit jedoch im beschreibbaren Layer des MediaWiki-Containers. Nach einer Neuerstellung des Containers muss die fest definierte Aktion `wiki-logo-install` erneut ausgeführt werden. Langfristig sollten `LocalSettings.php` und Logo als eigene Bind-Mounts in der Containerdefinition verankert werden.
Erste Betriebsbeobachtungen
[Bearbeiten]- 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
[Bearbeiten]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
[Bearbeiten]- 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.