Die Installation von Collabora (CODE) in nextCloud hinter einem HTTPS-Apache-Proxy verläuft ohne Zicken. Einfach die Anleitung nachturnen und es funktioniert. Aber es funktioniert zäh und das auch bei 32GB RAM auf einem (etwas in die Jahre geratenen aber durchaus noch webtauglichen) Dell Poweredge T710 mit zwei Xeon Prozessoren. Zumindest im Vergleich zu einem OnlyOffice (OO).
OnlyOffice bringt viel mehr Funktionen mit, lässt sich flutschiger bedienen und sieht darüber hinaus auch noch schicker aus. Im Vergleich dazu fällt Collabora sehr weit zurück: zähe, zickige und schnarchige Bedienung und gerade mal ein paar Basisfunktionen an Bord. Hat man einmal mit OO gespielt, will man nicht mehr zu CODE zurück. Dafür würde ich sogar hinnehmen, dass OO alles ins OOXML Format konvertieren will.
Jedoch: OnlyOffice in ownCloud hinter einem HTTPS-Apache-Proxy warf sich mir mit weitaus mehr Problemen bei der Installation in den Weg als CODE. Aktuell habe ich noch nicht alle im Griff – es funktioniert erst im Prinzip. Und zwar hiermit:
docker pull onlyoffice/documentserver
Die Virtualhost für den Apache anpassen:
<VirtualHost *:443>
ServerName onlyoffice.domain.tld:443
SSLEngine on
ServerSignature On
SSLHonorCipherOrder on
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
SSLCertificateFile /etc/letsencrypt/live/onlyoffice.domain.tld/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/onlyoffice.domain.tld/privkey.pem
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/access.log combined
ErrorLog ${APACHE_LOG_DIR}/error.log
# Just in case - see below
SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off
# contra mixed content warnings
RequestHeader set X-Forwarded-Proto "https"
# basic proxy settings
ProxyRequests off
ProxyPass / http://127.0.0.3:9090/
<Location />
ProxyPassReverse /
</Location>
</VirtualHost>
Den OO Container starten:
docker run -i -t -d -p 127.0.0.3:9090:80 --restart always onlyoffice/documentserver
die ownCloud App für OO installieren und die Kiste läuft. Im Prinzip.
Textverarbeitung funktioniert.
Präsentationssoftware funktioniert.
Tabellenkalkulation funktioniert.
Aber: Es funktioniert eben nur im Prinzip.
Denn man muss damit leben, dass einem der Firefox weiterhin in der Debug-Console Meldungen entgegen wirft:
Firefox kann keine Verbindung zu dem Server unter wss://onlyoffice.domain.tld/2017-02-17-15-53/doc/271488117372/c/493/1niaepga/websocket aufbauen. sockjs.min.js:3:4835
Ich fummel mir hier nun seit Tagen einen ab, um diese Meldungen los zu werden. In der VHost Konfiguration des Apachen oben sind ja noch Reste davon zu sehen.
Für diese Versuche startete ich den docker container so, dass dessen Port 443 zum Wirt auf Port 9091 weiter gereicht wird
docker run -i -t -d -p 127.0.0.3:9090:80 -p 127.0.0.3:9091:443 onlyoffice/documentserver
und stellte dann Versuche in der VHost Config des Apachen nach dem Schema (!)
ProxyPassMatch "/(.*)/websocket" wss://127.0.0.3:9091/$1/websocket
an. Erfolglos. Auch meine Versuche mit ProxyPass, ProxyPassReverse oder ReWrite Regeln scheiterten bisher.
Ich glaube, ich habe nun alle Anleitungen und Tutorials rund um Websockets mit HTTPs und Apache Proxy durch – ich fahr da noch immer vor die Wand. Und vor allem: Ich hab keine blassen Dunst, was ich eigentlich genau verzocke.
Drängen tut das Problem nicht. Ich roll weder OO noch CODE zum aktuellen Zeitpunkt aus. Denn ich vertraue weder dem auf einer eigenen Subdomain laufende OO Documentserver noch dem CODE Container. Zwar können Besucher theoretisch nur in den docker container reinfummeln und wohl nicht aus diesem oder dem Apache Proxy ausbrechen, aber schon dass finde ich irritierend.
Schlimmer ist vielmehr, dass ich den Websocket nicht an den Apache HTTPS Proxy so dran bekomme, dass der Firefox endlich Ruhe gibt. Falls da einer ne Idee hat … ich hab ein offenes Ohr. Vielleicht ist ja was dabei, was ich noch nicht probiert habe.
