OpenCloud mit externem Reverse Proxy, Collabora und Virenschutz

Einleitung

Opencloud ist eine relativ neue Filesharing und Kollaborationslösung, die insbesondere schlanker und schneller als Nextcloud sein soll. Ich nehme keinen Vergleich zwischen Nextcloud und OpenCloud vor und führe vor allem keine Performance-Messungen durch. Hier beschreibe ich, wie ich Opencloud für mich installiert und konfiguriert habe. Die offizielle Administrations-Dokumentation ist schon sehr gut gemacht und umfassend. Ich wollte aber OpenCloud lokal hosten und über einen extern gehosteten Proxy und einen VPN-Tunnel von außen zugänglich machen. Dabei sollten auch der Virenschutz und die Kollaborationssoftware Collabora funktionieren. Und bis ich das meinen Vorstellungen entsprechend zum Laufen gebracht habe, musste ich doch etwas recherchieren und ausprobieren. Darum halte ich das Ergebnis hier fest.

Voraussetzungen

Man nehme:

1. Einen (lokalen) Server mit Debian oder Ubuntu sowie Docker
2. Einen (virtuellen) Server, der aus dem Internet erreichar ist mit dem Nginx Proxy Manager
3. Eine (Sub-)Domain, die aus dem Internet erreichbar ist und darunter die (Sub-)Subdomains
   • collabora.domain.tld
   • wopiserver.domain.tld
4. Entsprechende DNS-A-Records, damit diese Subdomains auf die IP-Adresse des Servers im Internet auflösen
5. Ein funktionierendes VPN, indem sich NPM und der OpenCloud-Server gegenseitig finden

Da ich die Einrichtung von virtuellen Servern und die Basisinstallation von Linux bereits mehrfach beschrieben habe, wiederhole ich das hier nicht. Die Installation von Docker habe ich hier und die des Nginx Proxy Managers (NPM) hier beschrieben. Die Einrichtung des VPN mit Wireguard habe ich hier beschrieben.

Klonen und Anpassen der Docker-Dateien

Zunächst lade ich die benötigten Dateien herunter

git clone https://github.com/opencloud-eu/opencloud-compose.git

Dabei wird ein Verzeichnis namens "opencloud-compose" erstellt, in dem sich die Unterverzeichnisse und Konfigurationsdateien befinden, die für OpenCloud benötigt werden. Ich wechsele daher zunächst in den entstandenen Unterordner

cd opencloud-compose

und erstelle die wichtigste Konfigurationsdatei ".env". Hierbei handelt es sich um eine versteckte Datei (das bewirkt der vorangestellte Punkt). Darin werden alle wichtigen Umgebungsvariablen für OpenCloud definiert. Diese Datei wird als Kopie der Vorlage erstellt:

cp .env.example .env

und dann angepasst:

nano .env

Hier suche (Strg+w) ich den Parameter "INSECURE" und ändere ihn von "true" nach "false" ab. Außerdem suche ich den Parameter "OC_DOMAIN" und trage hier die (Sub)Domain ein, die ich für OpenCloud vorgesehen habe. Damit ich mich später an der Admin-Oberfläche anmelden kann, suche ich nach dem Parameter "INITIAL_ADMIN_PASSWORD" und gebe hier ein Passwort ein, dass ich mir merken kann und dass aber auch einigermaßen sicher ist. Weil ich aus möglicherweise nachvollziehbaren Gründen möchte, dass die OpenCloud künftig auch nach einem Neustart des Rechners noch ihre Daten hat, also nicht alle Dokumente, User, Einstellungen usw. flüchtig sind, definiere ich persistente Volumes für die Ordner config und data. Ich suche also nach den Parametern "OC_CONFIG_DIR" und "OC_DATA_DIR" und trage dort feste Pfade ein. In meinem Beispiel:

-OC_CONFIG_DIR=/home/andreas/opencloud/data
-OC_DATA_DIR=/home/andreas/opencloud/config

Die Standardsprache stelle ich auch gleich ein, wo ich schon einmal hier bin. Dazu suche ich den Parameter "DEFAULT_LANGUAGE" und trage dort "de" ein. Ich kann, wenn ich möchte, noch unter COLLABORA_ADMIN_USER und COLLABORA_ADMIN_PASSWORD Credentials eingeben, mit denen ich mich dann künftig unter der URL https://[collabora-subdomain]/browser/dist/admin/admin.html an der Adminoberfläche von Collabora anmelden könnte. Das ist aber für den Betrieb der Opencloud zunächst nicht relevant.

Nun muss ich noch meine Subdomains eintragen:

COLLABORA_DOMAIN=collabora.[domain]
WOPISERVER_DOMAIN=wopiserver.[domain]

Wichtig ist noch, den Parameter COLLABORA_SSL_ENABLE anzupassen. Das System soll ja über einen Reverse Proxy angesprochen werden, wobei sich die einzelnen Container innerhalb des Docker-Netzwerks sehen (sollen). Daher ist hier der Parameter

COLLABORA_SSL_ENABLE=false

zu setzen. Nach diesen Anpassungen speichere ich die Datei und schließe den Editor nano (Strg+o und Strg+x). Nun muss ich die Datei external-proxy/opencloud.yml anpassen.

nano external-proxy/opencloud.yml

und entferne die IP-Adresse "127.0.0.1" ersatzlos, damit der Port nach außen geöffnet wird.

services:
  opencloud:
      environment:
        # bind to all interfaces
        PROXY_HTTP_ADDR: "0.0.0.0:9200"
      ports:
        # expose the opencloud server on localhost
        - "127.0.0.1:9200:9200"

Nachdem ich auch das gespeicher habe (strg+o, strg+x), öffne ich die Datei external-proxy/collabora.yml und füge am Ende ein:

cap_add:
      - MKNOD
      - SYS_CHROOT
      - FOWNER

SYS_CHROOT erlaubt dem Container, den Befehl chroot (Change Root) zu benutzen. Aus Sicherheitsgründen sperrt Collabora jede geöffnete Datei in ein eigenes, isoliertes Mini-Dateisystem (ein sogenanntes "Jail"). Damit ein Prozess sein eigenes Wurzelverzeichnis ändern kann, benötigt er dieses Recht. Ohne dies könnte ein Fehler in einem Dokument theoretisch den ganzen Collabora-Container gefährden.

MKNOD erlaubt dem Prozess, "Device Nodes" zu erstellen. Innerhalb der oben genannten "Jails" muss Collabora oft grundlegende Systemgeräte simulieren (wie /dev/null oder /dev/random), damit die LibreOffice-Instanz im Hintergrund stabil läuft. Ohne MKNOD kann Collabora diese virtuellen Geräte innerhalb der Isolation nicht anlegen.

FOWNER erlaubt einem Prozess, Dateiberechtigungen (UID/GID) zu ignorieren oder zu ändern, auch wenn er nicht der Besitzer der Datei ist. Collabora jongliert mit Dateien, die vom oCIS-Nutzer kommen, aber im Container von einem internen cool-User verarbeitet werden. Damit Collabora die Berechtigungen im isolierten Bereich so setzen kann, dass LibreOffice darauf zugreifen darf, muss es die "Besitzer-Prüfung" des Kernels kurzzeitig übersteuern können.

Einrichtung der Proxy Hosts auf dem NPM

Ich habe für die Domains oc.kernke.koeln, collabora.kernke.koeln und wopiserver.kernke.koeln DNS-Einstellungen vorgenommen (A-Records), die auf die IP-Adresse meines vServers verweisen, auf dem ich den Nginx Proxy Manager (NPM) betreibe. Auf der Weboberfläche des NPM, die ich nur aus dem VPN heraus erreiche, richte ich unter Proxy Hosts drei neue Proxy Hosts ein und zwar für die oben genannten Subdomains

1. oc.kernke.koeln
2. collabora.kernke.koeln
3. wopiserver.kernke.koeln

(Sub)Domain für Opencloud

Für die Subdomain oc... trage ich unter Details die Subdomain ein. Unter "Scheme" wähle ich "http" (nicht https!) aus und trage unter "Forward Hostname/IP" die IP-Adresse ein, die der OpenCloud-Server, der sich in meinem lokalen Netzwerk befindet, im VPN hat. Port ist 9200. Außerdem wähle ich "Websocket Support" aus, damit später die Kommunikation zwischen OpenCloud, Collabora und Wopiserver funktioniert.

Unter der Registerkarte SSL wähle ich aus "Request a new SSL Certificate with Let's Encrypt". Ich hake die Optionen "Force SSL" und "HSTS Enabled" an, prüfe, dass ich auch eine korrekte eMail-Adresse hinterlegt habe, damit ich über Aktionen hinsichtlich des Zertifikats informiert werde und stimme den Nutzungsbedingungen von Let's Encrypt, die ich natürlich aufmerksam gelesen habe ;-), zu. Der Parameter "Force SSL" erzwingt die Nutzung von SSL-Verschlüsselung, wirkt also als Redirect, wenn die Domain per http angesprochen würde. Mit HSTS Enabled werden Webbrowser angehalten, den Zugriff immer nur über HTTPS zu erlauben.

Unter "Advanced" trage ich ein:

# Diese Werte ergänzen den Standard-Block von NPM
client_max_body_size 0;
proxy_read_timeout 600s;
proxy_send_timeout 600s;
# Sicherstellen, dass die Protokoll-Weitergabe stimmt (verhindert Redirect-Loops)
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
# Optional für oCIS/WebDAV Performance
proxy_request_buffering off;
proxy_buffering off;

Diese Parameter werden in den Kommentaren dazu ja erläutert.

Subdomains für Collabora und wopiserver

Hier gehe ich fast genauso vor. Ich lege jeweils einen neuen Proxy Host an und trage zunächst unter Details die Subdomain für Collabora, in meinem Fall also "collabora.kernke.koeln" bzw. für den wopiserver "wopiserver.kernke.koeln" ein und wähle "Websockets Support" aus. Unter SSL wähle ich wieder aus, dass ich ein neues SSL-Zertifikat von Let's Encrypt haben möchte. Hier hake ich nun an "Force SSL", "HSTS Enabled" und "HTTP/2 Support" an. HTTP/2 ist eine modernere, binäre Art der Datenübertragung. Im Gegensatz zum alten HTTP/1.1 kann es viele Dateien (Bilder, Skripte, Dokumententeile) gleichzeitig über eine einzige Verbindung laden (Multiplexing). Das führt insbesondere bei der Nutzung von Collabora zu einer erheblichen Beschleunigung. (Danke Gemini für die Erläuterungen).

Unter Advanced trage ich für diese beiden Proxy Hosts noch ein:

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

damit die Vertrauensstellung zwischen dem Browser der Nutzenden, dem Proxy und den Backend-Containern funktioniert. Ohne diese Parameter würden die Container nicht zusammenarbeiten und insbesondere Collabora würde nicht funktionieren.

Wenn ich das mit "Save" bestätige, dann wird (hoffentlich) jeweils ein neues Let's Encrypt Zertifikat bezogen und mit der Subdomain verbunden. Die Subdomains verweisen ja auf meinen Proxy Server und der routet durch den VPN-Tunnel auf den Server im lokalen Netzwerk durch.

Virenschutz

Im Ordner opencloud-compose befindet sich ein Verzeichnis antivirus und darin eine Datei clamav.yml. Diese öffne ich mit dem Editor nano zum Bearbeiten (hier gehe ich davon aus, dass ich mich mit dem SSH-Prompt aktuell in dem Pfad ~/opencloud-compose befinde).

nano antivirus/clamav.yml

Hier füge ich zunächst unter "environment" ein:

STORAGE_USERS_DATA_GATEWAY_INSECURE: "true"

Wenn ClamAV eine hochgeladene oder bearbeitete Datei ohne das INSECURE-Flag anfordert, bekommt er ein 401 Unauthorized. ClamAV sagt dann nichts, und oCIS wartet ewig. Mit dem Flag darf ClamAV die Datei über die interne IP/URL http://opencloud:9200/data einfach abgreifen.

Dann öffne ich wieder die Datei .env im Verzeichnis opencloud-compose und suche dort den Parameter START_ADDITIONAL_SERVICES="". Diesen ergänze ich wie folgt:

START_ADDITIONAL_SERVICES="antivirus"

Container starten

Um nun OpenCloud mit allen gewünschten Diensten zu starten, müssen die Container

1. weboffice/collabora.yml
2. search/tika.yml
3. radicale/radicale.yml
4. antivirus/clamav.yml
5. external-proxy/opencloud-exposed.yml
6. external-proxy/collabora-exposed.yml

gestartet werden. Auf den Container radicale könnte ich verzichten, wenn ich keine Kalenderfunktionalität brauche. Den Start der Container könnte ich mit dem umständlichen Befehl

docker compose -f docker-compose.yml -f weboffice/collabora.yml -f search/tika.yml -f radicale/radicale.yml -f antivirus/clamav.yml -f external-proxy/opencloud-exposed.yml -f external-proxy/collabora-exposed.yml up -d

machen. Aber ich bin ja ITler, also nutze ich ein Skript dafür. Ich erstelle mit

nano start-cloud.sh

eine neue Datei und füge ein:

docker compose -f docker-compose.yml \
  -f weboffice/collabora.yml \
  -f search/tika.yml \
  -f radicale/radicale.yml \
  -f antivirus/clamav.yml \
  -f external-proxy/opencloud-exposed.yml \
  -f external-proxy/collabora-exposed.yml \
  up -d

Diese mache ich mit

chmod +x start-cloud.sh

ausführbar. Nun und später kann ich sie mit

./start-cloud.sh

ausführen und damit die Container, die ich benötige, einfach am Stück starten.

Nutzung der Cloud

Nun kann ich mich mit dem zuvor ausgewählten Admin-Account und -Passwort anmelden, Gruppen, Nutzer, Spaces anlegen usw. Das wird hier kein Tutorial für die Nutzung von OpenCloud. Daher ist hier nun Schluss.