Zu einer Cloud, die was auf sich hält, gehört doch ein „echtes“ Office-Programm zum gemeinsamen Arbeiten, oder? Also habe ich seit ein paar Wochen den Plan, „Collabora“ zu implementieren.
Der Vorteil, entstandene Dateien offline speichern zu können, macht die Anwendung gegenüber Etherpad attraktiv. Außerdem ist ein quasi „echtes“ Officeprogramm natürlich deutlich vielfältiger zu nutzen. Und: von überall aus auf ein LibreOffice zugreifen zu können, ist schon sehr komfortabel.
Also gesagt…und getan wie bei den meisten anderen Implementierungen: nachdem ein paar Stolpersteine aus dem Weg geräumt waren, läuft die Sache.

Collabora vs. Onlyoffice + Systemvoraussetzungen

Zu allererst wollte natürlich geklärt sein, welches Tool es denn werden darf. Immerhin  integriert Nextcloud selbst das MS-favorisierende OnlyOffice in seinen Hub und nicht das LibreOffice Derivat Collabora. Die Entscheidung fiel im Vorbeigehen. Zum einen bin ich Anti-Fan von MS, zum anderen: wenn schon, denn schon. Als Open Source Version von OpenOffice ist Libre sowieso schon auf allen Studiorechnern. Also bekommt auch die Cloud diese Office-Variante übergeholfen.

Jetzt noch kurz zu den harten Fakten. Hier sind die Basics, auf denen die Installation stattfindet: Nextcloud 18.03 // Ubuntu 18.0.4 // Docker 19.03.6 // Apache 2.4.29 // Certbot // Router: 1x dynDNS

Von Anleitung zu Anleitung zu Anleitung

Natürlich gab es wieder sehr viele zur Auswahl. Und alle lasen sich wie üblich gar nicht schlimm. Die Favoriten waren:

_die offizielle Anleitung aus der Nextcloud_Doku; sie ist aktuell
_eine andere vom Nextcloud-Forum, die hilfreich war
_mal wieder leicht verständlich, daher super: Bitblokes – allerdings nur für http
_Decatec für eine echte sichere Implementierung auf ngix
_die, an die ich mich überwiegend gehalten habe: xprog

Einblicke in Docker

Da Docker anscheinend gerad angesagt ist, wollte ich natürlich nicht kneifen und installierte einfach mal den Kontainer-Virtualisierer. Auf den ersten Blick sah die Sache recht harmlos aus. Die eigenständige Schnittstelle im Einsatz zu sehen, schindete aber doch Eindruck. Mir schwante, dass das eine größere Sache war. Ein paar Grundlagen und Befehle für´s Handling zu wissen, war sicher nicht verkehrt. Collabora CODE ließ sich unkompliziert reinladen.

Von der Subdomain über den Apachen zur Nextcloud

Nun gab´s einen kleinen Break. Eine eigene Subdomain wollte beim Internetprovider erstellt sein – darunter macht die Collabora-Instanz es nicht. Mit frischer beim Provider verschlüsselter Subdomain in petto, ging´s jetzt an die Konfiguration des Apachen. So weit, so gut. Bisher lief alles nach Plan. Der Apache war laut Check sogar aktiv und irgendwie schien alles in Ordung. Beim Versuch die Collabora-Instanz in Nextcloud zu öffnen, zeigte sich allerdings: nichts war in OK. Die Cloud konnte den Server nicht finden. Im Copy/Paste-Stil den Anleitungen folgen, hatte sich spätestens jetzt erledigt.

Certbot

Die erste Vermutung war, dass ein Zertifikatsproblem vorlag. Die Subdomain war ja via Provider verschlüsselt und die Cloud-Domain direkt im Ubuntu. Ich machte mich mit der Zertifizierung von Let’s Encrypt vertrauter und spielte damit etwas rum. Das zeitigte zwischendurch fiese Folgen.
Firefox erklärte: Das Zertifikat ist echter Schrott. Der Browser versuchte gar nicht erst die Seite zu öffnen. So ein Mist! An die gesamte Cloud war kein Rankommen. Ich hatte die beiden Domains in einem Zertifikat zusammenlegen wollen und aus Versehen eine von beiden daraus gelöscht. Im Trail & Error-Verfahren lernte ich mit Certbot umgehen. Mit dem Ergebnis: die Cloud war wieder zugänglich, der Collabora-Server glänzte aber leider immer noch durch Abwesenheit.

dynDNS: keine (Sub-)domain sondern CNAME-Record

Also zurück auf Start: es hieß überall Collabora brauche eine Extradomain – besser Subdomain. Irgendwie schwante mir, dass in diesem Fall etwas nicht passte. Wie sollte die Collabora-Instanz auf eine Subdomain bei meinem Internetprovider zugreifen können, wenn der Router sie eigentlich gar nicht ins Internet ließ? Sie hatte keine Freigabe. Die war auch nicht möglich, weil der Router nur einen dynDNS-Service anlegen konnte.
Den entscheidenden Tipp zur Problemlösung lieferte die Seite von Decatec. Eine „echte“ Subdomain war gar nicht notwendig. Vielmehr war ein CNAME Record gefragt. Der Domain des dynamischen DNS musste ein zweiter Domainname (CNAME) zugeordnet werden. Den erstellte ich also beim Provider. Automatisch stieg die Konzentration. Immerhin wurde mir nahegelegt: falls irgendwas nicht mehr funktionieren sollte nach meinem Eingriff, sei ich schön selbst dafür verantwortlich, oh je. Aber voilá: Alles lief weiter; und der Apache zeigte bei Url-Eingabe endlich seine Leitseite. Leider half auch das der Instanz nur eingeschränkt. Nextcloud beharrte darauf, dass der Server nicht zu finden sei.

die Sache mit dem kleinen „s“

Ubuntu erklärte: „Bind:…..failed, port already allocated. Und es blieb stur bei seiner Meinung. Nach langwierigem Rumgesuche, war diese Fehlerbehebung mal wieder „bedauerlich“ simpel. Ich hatte die Seite auf https und Port 443 in der Webserver-Konfiguration gesetzt. Das spiegelte sich aber leider nicht in der Url-Eingabe der Nextcloud wider, dort stand immer noch http. Tja, was so ein unausfälliges „s“ alles verursachen kann.

Anyway: Endlich prangte der grüne Button auf der Nextcloud-Seite. Der Server war bereit.

Und sonst so:

Falls jemand die Instanz lediglich im internen LAN-Netz zugänglich machen möchte. Hacksenwerk hat auch das Problem gelöst.