Nginx

Wie man einen eigenen Collabora Server für Nextcloud in Docker und hinter einem Nginx Reverse Proxy korrekt startet

Um innerhalb von Nextcloud so eine Art Google-Docs betreiben zu können, benötigt man zum einen die Nextcloud-Office-App, aber auch einen extra Server (Collabora), der quasi als Backend für das Office dient. Letztendlich handelt es sich da um eine Headless Open-Office Instanz, wenn ich das richtig verstanden habe.

Im besten Fall betreibt man Nextcloud ohnehin auf dem eigenen Server innerhalb von Docker, dann sollte die Kommunikation mit dem Collabora Server kein Problem sein.

Da in meinem Beispiel die Nextcloud Instanz von Hetzner gehosted wird, war es notwendig, dass der Collabora Server über das Internet kontaktiert wird und eben nicht im gleichen Netzwerk hängt. Und da ist die Dokumentation etwas schwammig bzw. einfach falsch. Denn in der Dokumentation, die man so im Netz finden kann, wird gesagt, dass man eine Environment-Variable namens “domain” definieren muss, die dann ein Regex der Nextcloud Domain enthält (damit nur Requests von dieser Domain bearbeitet werden).

Der entsprechende Code wurde aber geändert, sodass mehrere Nextcloud Server auf Collabora zugreifen können. Statt “domain” muss die Environmentvariable “aliasgroup1” heißen und sie enthält die komplette Domain inkl Portangabe (Durch Komma getrennt kann man mehrere URLs übergeben).

Beispiel:

aliasgroup1=https://meine.domain.com:443

In meinem konkreten Beispiel habe ich die Konfiguration, dass auf dem Server für Colabora Docker mit dem allseits bekannten Lets Encrypt Nginx Companion läuft. Das nette an diesem Setup ist, dass man allen weiteren Docker Containern auf diesem Server nur drei Env-Variablen mitgeben muss und schon erstellt und verwaltet das System automatisiert die Lets Encrypt Zertifikate.

In dieser Kombination ist es wichtig, Collabora mitzuteilen, dass es sich nicht um SSL kümmern soll, was man mit der Env-Variable

extra_params=--o:ssl.enable=false --o:ssl.termination=true

erreicht. Ausserdem muss der Collabora Container im privileged Modus laufen!

Mein Setup in Ansible sieht dann letztenlich so aus:

- docker_container:
    name: collabora
    image: collabora/code
    state: started
    detach: yes
    restart_policy: always
    privileged: yes
    expose:
      - 9980
    env:
      aliasgroup1: https://nextcloud.domain.com:443
      VIRTUAL_HOST: office.domain.com
      LETSENCRYPT_HOST: office.domain.com
      VIRTUAL_PORT: "9980"
      LETSENCRYPT_EMAIL: ich@meins.de
      extra_params: "--o:ssl.enable=false --o:ssl.termination=true"

Das Equivalent auf der Console sollte dann so aussehen:

docker run --name=collabora --env=aliasgroup1=https://nextcloud.domain.com:443 --env=VIRTUAL_HOST=office.domain.com --env=LETSENCRYPT_HOST=office.domain.com --env=VIRTUAL_PORT=9980 --env=LETSENCRYPT_EMAIL=ich@meins.de --env='extra_params=--o:ssl.enable=false --o:ssl.termination=true' --privileged --expose=9980 --restart=always --detach=true collabora

Wenn das erledigt ist und der Server läuft, kann man in Nextcloud den Admin Bereich öffnen und dort auf den Punkt “Office” gehen. Hier stellt man den Collabora Server ein und klickt auf Speichern:

Anschließend geht man in Nextcloud auf den “Dateien” Tab und klickt dann oben auf das Plus, um eine neue Datei zu erzeugen:

Anschließend öffnet man das Dokument und sollte nun die Office Oberfläche sehen. Falls eine Fehlermeldung kommt, und man es “später nochmal versuchen soll”, geht auf den Server wo Collabora läuft und schaut in die Logs des Containers.

Wenn ihr da irgendwas von

Terminating connection. Error: No acceptable WOPI hosts found matching the target host [nextcloud.domain.com] in config.

seht, dann habt ihr die Domain in der Environment Variable nicht korrekt übergeben. Überprüft vor allem, ob es sich überhaupt um die gleiche Domain wie in der Fehlermeldung handelt. Diese ist in jedem Fall die korrekte Domain und sollte so auch in der “aliasgroup1” drin stehen!

Nginx Docker Reverse Proxy wirft 404 Fehler ab dem zweiten Request

Als großer Fan von “nackten Servern” auf denen nur Docker Container laufen, nutze ich Nginx als Reverse Proxy – im Speziellen das großartige Setup von jwilder/nginx-proxy in Kombinantion mit dem Let’s Encrypt Addon. Effektiv läuft das Teil passiv mit und schaut nur auf bestimmte Environment-Variablen anderer Docker Container. Sobald es diese sieht, wird automatisch ein Reverse Proxy in Nginx so konfiguriert, dass er diesen Dienst erreichbar macht und gleichzeitig wird noch ein Let’s Encrypt Cert für die entsprechende Domain besorgt und auf dem neuesten Stand gehalten.

Nun hatte ich in einem Setup mit sehr vielen gleichzeitig laufenden Diensten das Problem, dass einer der Dienste immer nur auf den ersten Request erfolgreich geantwortet hat, aber bei jedem weiteren Request nur noch einen 404 geworfen hat. Der Dienst selbst lief, Nginx hat auch keinen Fehler im Log geworfen und ich war etwas ratlos.

Nach ein paar grauen Haaren mehr und dem ein oder anderen versteckten Hinweis auf Google kam ich dann auf des Rätsels Lösung: durch ein fehlerhaftes Deployment lief kurzzeitig ein weiterer Container, der mittels der Environment Variable die gleiche URL für sich beanspruchte. Der Nginx Automatismus machte daraus automatisch einen Load Balancer. Nachdem das fehlerhafte Deployment weg war, wurde der Loadbalancer aber nicht mehr aufgelöst und somit war nur noch einer von beiden Einträgen aktiv. Warum der Nginx dann trotzdem immer wieder auf den nicht vorhandenen Host gehen wollte erschließt sich mir nicht so richtig, aber das war des Problems Lösung.

Also bin ich einfach per docker exec in den Nginx Container und habe die Datei /etc/nginx/conf.d/default editiert:

# server.name.com upstream server.name.com { # CONTAINER_NAME_1 server 123.45.0.67:1234; # CONTAINER_NAME_2 server 123.45.0.78:1234; }

Nachdem ich den Part von CONTAINER_NAME_2 gelöscht hatte, konnte ich mittels

nginx -s reload

die Config von Nginx on the fly neu laden und ab dem Moment lief der Service wieder wie gewohnt.

Nextcloud mit nginx reverse proxy macht endlos reloads

Langer Titel, einfaches Problem.

Ich habe eine Nextcloud Instanz, die lokal läuft und dann mittels Nginx Reverse Proxy aus dem Internet nur per HTTPS erreichbar ist. Nach einem der üblichen Updates endete dieses Setup, welches bis dahin problemlos lief, immer in einer Endlossschleife – aber nur für die Website. Die Nextcloud Sync Clients liefen problemlos weiter.

Mir war also klar, dass es irgendwie mit dem Reverse Proxy zusammenhängen muss. Und so war es dann auch. Nachdem ich folgendes zur Config Datei hinzugefügt hatte, lief es wieder:

'overwritehost'     => 'WWW.MEINE.DOMAIN',
'overwriteprotocol' => 'https',

Das Problem war einfach, dass scheinbar Nextcloud intern auf HTTP gehen wollte, was durch den Auto-Redirect des Nginx auf HTTPS dann für die Endlosschleife gesorgt hatte 🙂

[Quicktip] Nginx Reverse Proxy mit Basic Auth

Nehmen wir an, ihr richtet einen Nginx als reverse Proxy ein und möchtet nun, dass bestimmte Subdomains, die von anderen Servern durchgeschliffen werden, per Basic Auth “geschützt” werden sollen. Dann werdet ihr wahrscheinlich auf das Problem stoßen, dass ihr immer wieder nach dem Basic Auth Login gefragt werdet und der Reverse Proxy nicht korrekt agiert. Die Lösung ist ganz einfach: ihr müsst verhindern, dass die Basic Auth Header weitergereicht werden. Und das geht so:

server {
    listen 80;
    server_name foo.bar.com;
    access_log            /var/log/nginx/foo.access.log;
    location / {
      proxy_set_header        Authorization "";    # <== das ist die wichtige Zeile, die verhindert, dass Basic Auth weiter gereicht wird!
      auth_basic              "Protected";
      auth_basic_user_file    /etc/nginx/basic_auth;
      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;
      proxy_set_header        Host [YOUR_REMOTE_DOMAIN];
      proxy_set_header        Accept-Encoding "";
      proxy_pass              [YOUR_REMOTE_URL];
      proxy_read_timeout      90;
    }
}