Das Symptom: drei rote Punkte

Man öffnet eine Tabelle in der eigenen Cloud, alles sieht normal aus — und dann meldet die interne „Server-Prüfung" drei rote Alarme:

• „Dokumente sind nicht wirklich enthalten: fehlende Funktionen oder Namensräume."
• „Langsame Einrichtung der Sandbox, Bind-Mount nicht möglich."
• „Schlechte Proxy-Leistung bei allen Netzwerkanfragen."

Das wirkt nach einem Konfigurationsfehler. Ist es aber nicht. Es ist die Bauart des eingebauten Servers.

Warum der eingebaute Server das gar nicht kann

Viele Cloud-Plattformen liefern einen Office-Server „zum Mitinstallieren" mit — praktisch für den ersten Test. Technisch läuft er aber als kleiner Hilfsprozess innerhalb desselben Containers wie die Cloud-Anwendung und schleust jede Anfrage über ein PHP-Proxy-Skript.

Ein Dokumenten-Editor isoliert jede geöffnete Datei in einer eigenen kleinen Sandbox („Jail"). Dafür braucht er zwei Dinge vom Betriebssystem: eigene Namespaces und die Möglichkeit, Verzeichnisse per Bind-Mount einzuhängen. Beides steht dem eingebetteten Hilfsprozess in einem fremden Container nicht zur Verfügung. Also fällt er auf langsames Kopieren zurück, kann Dateien nicht sauber isolieren — und schickt alles über das Proxy-Skript. Genau das melden die drei roten Punkte.

Die Lösung: ein eigener, dedizierter Server

Die dauerhafte Antwort ist ein eigener Container nur für den Dokumenten-Server, erreichbar unter einer eigenen Subdomain. Ein dedizierter Container darf die nötigen Kernel-Fähigkeiten mitbringen (konkret die Capability zum Anlegen von Geräteknoten), kann seine Sandboxes richtig aufbauen — und es gibt kein Proxy-Skript mehr, weil er ein echter Server im Netz ist.

Das Ergebnis nach dem Umzug:

Der bewusste Rest-Kompromiss

Ein Punkt bleibt gelb: die Sandbox baut sich per Kopieren statt per Bind-Mount auf. Voll grün würde sie erst mit einer sehr weitreichenden Container-Berechtigung (dem Recht, im Container selbst zu mounten). Das schwächt aber die Isolation des Containers spürbar — und steht damit gegen eine Sicherheitslinie, die auf Runtime-Überwachung und harte Container-Grenzen setzt.

Die drei Reverse-Proxy-Fallen

Der Umzug klingt einfach — hinter dem Reverse Proxy warten aber drei Klassiker, an denen wir der Reihe nach hängen blieben:

1. Der Crash-Loop beim Start. Um dem Server das Erzeugen eines selbst-signierten Zertifikats zu ersparen, setzt man gern eine „kein-Zertifikat-erzeugen"-Option. Fatal: Der Server will die Zertifikatsdateien beim Start trotzdem laden — und stürzt endlos ab, weil sie fehlen. Lösung: die Option weglassen, den Server die internen Zertifikate ruhig selbst erzeugen lassen.

2. Der 502 Bad Gateway. Man möchte das Backend gern unverschlüsselt sprechen lassen (TLS macht ja der Proxy). Die entsprechende Server-Option greift je nach Version aber nicht — der Dokumenten-Server bleibt intern auf HTTPS. Spricht der Proxy dann HTTP, bricht die Verbindung ab („empty reply") → 502. Sauberer ist es, den Proxy das Backend per HTTPS ansprechen zu lassen.

3. Der 404 durch einen fehlenden Transport. Weil das interne Zertifikat selbst-signiert ist, muss der Proxy die Zertifikatsprüfung zum Backend überspringen. So ein „Transport" lässt sich über Container-Labels nicht zuverlässig anlegen — der Proxy meldet dann „transport not found" und liefert 404. Die Lösung: den Transport in einer eigenen Konfigurationsdatei definieren und von dort referenzieren.

Browser  ──HTTPS (öffentliches Zertifikat)──▶  Reverse Proxy
                                                    │
                          HTTPS (self-signed, Prüfung übersprungen)
                                                    ▼
                                          Dokumenten-Server :Port

Was man mitnimmt

• „Eingebaut" heißt „für den Anfang". Sobald echte Nutzung dazukommt, gehört ein Dienst in seinen eigenen Container mit den Rechten, die er wirklich braucht.
• Rote Warnungen sind manchmal ehrlich. Nicht jeder Alarm ist ein Bug — manchmal ist er die korrekte Diagnose einer prinzipiellen Grenze.
• Sicherheit ist eine Abwägung, kein Automatismus. Den letzten gelben Punkt „grün zu machen" wäre möglich gewesen — aber der Preis (schwächere Isolation) war es nicht wert. Solche Entscheidungen schreibt man auf, damit sie später nachvollziehbar bleiben.

Self-Hosting heißt: Man versteht seine Dienste bis auf die Ebene, auf der Entscheidungen wehtun. Der Lohn ist eine Cloud, die genau das tut, was man will — und nicht mehr.