Zentraler MegBes-Server – Inventur und Administration: Unterschied zwischen den Versionen

(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)

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:

|-

| 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`.

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 ==

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 ==

Zeile 83:

Zeile 152:

* 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

@@ 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`.
+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 ==
+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 ==
@@ Zeile 83: / Zeile 152: @@
 * 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