1 / 20
Jul 2021

Hallo, wie schon im Titel steht, habe ich Probleme mit der installation vom Collabora Server (selbst-gehostet).

Erstmal möchte ich mich für mein unwissen entschuldigen, aber ich komme wirklich nicht weiter.

Ich habe eine Nextcloud, und würde deshalb gerne einen Dokumente-Server hosten, um kollaborativ an Dokumeten arbeiten zu können. Ich habe NGO Lizenzen für Collabora von egroupware bekommen. Mit der E-Mail der Bestellbestätigung kamen auch gleich Anweisungen, wie man den Collabora-Server installiert, und die Lizenzen. Hier die Anweisungen aus der E-Mail:

Anleitung Collabora in der EGroupware Eigeninstallation:

1. Collabora Paket auf dem Host installieren:

apt/yum/zypper install egroupware-collabora-key

2. URL des EGroupware & Collabora Server herausfinden. Wenn die Installation von innen und außen erreichbar ist, MUSS die URL die gleiche sein, sprich man muss die externe verwenden. Wenn EGroupware https verwendet, MUSS auch die Collabora URL https verwenden. 
Da Collabora in einem Container läuft und der äußere Webserver, den auch die EGroupware verwendet, in den Container proxied, ist die Collabora URL nur Protokoll und Servername, z.B. 

https://egw.meine-firma.de

EPL: die URL einfach unter Admin >> Collabora >> Konfiguration der Anwendung eintragen

CE: das folgende SQL ausführen ( mit der obigen URL ersetzen)

REPLACE INTO egw_config (config_appname,config_name,config_value) VALUES ("collabora","server","");

Nach der Änderung muss direkt in der Datenbank für die CE der Instanzcache gelöscht werden: 
Admin >> Cache löschen und Hooks registrieren.

Nach dem Speichern der Collabora Konfiguration sollte diese anzeigen, dass der Server erreichbar ist UND der anonymous Benutzer existiert. Danach kann bereits ohne einen Support Key, mit Wasserzeichen in der Anzeige getestet werden.

3. Eintragen des Support Keys erfolgt über die bereits erwähnte Collabora Konfiguration. Dabei muss der Inhalt der collabora.key Datei in das Feld Support-key eingetragen werden. Die Datei selbst kann im Moment noch nicht hochgeladen werden. Danach sollte der Collabora Container automatisch neu starten.

Schritt eins habe ich relativ einfach hinbekommen. Ich habe das Paket installiert, und versucht mit schritt zwei weiterzumachen. Jetzt meine ersten Fragen: Wie finde ich die URL heraus? Welche URL? Die von der Nextcloud?

Auf GitHub habe ich auch Anweisungen für die Eigeninstallation gefunden, allerdings soll man dort ein Skript ausführen das nach einem Benutzernamen und einem Passwort für download.egroupware.org1 verlangt, was ich beides ebenfalls nicht habe.

Ist das ein Dead-End? Habe ich etwas falsch verstanden? Muss ich den Collabora Server mithilfe von den Paketen von egroupware installieren, oder kann ich ihn auch so installieren?

Danke schonmal im vorraus.

  • created

    Jul '21
  • last reply

    Jul '21
  • 19

    replies

  • 2.7k

    views

  • 4

    users

  • 7

    links

Hallo Kishima,

dein Egroupware Server sollte ja mit einer URL erreichbar sein - wie rufst du die Oberfläche von Egroupware auf? Das wäre die URL die hier gemeint ist.

Es kommt ein wenig darauf an wie der Egroupware Server aufgestellt ist, wenn er im Internet steht und z.B. über die URL https://egw.kishima.com/2 für dich erreichbar ist - dann wäre das die korrekte URL. Steht er in der Firma und ist nur von intern erreichbar, dann lautet die URL entsprechend anders.

Wichtig ist dass wenn der Server von intern und extern durch die gleiche URL erreichbar ist!

Das SQL führst du übrigens dann mit /etc/egroupware-docker/mysql.sh aus.

Ich hoffe das hilft dir ein wenig weiter.
Schöne Grüße
Manfred

Hallo grufo, danke für deine Antwort.

Das bedeuted ich brauche einen Egroupware Server? Ich habe einen Linux root server, ich dachte ich könnte dort einfach den Collabora Server installieren, und ihn mit den gekauften Lizenen laufen lassen.

Grüße
Kishima

Du postest im Egroupware Forum - daher gehe ich davon aus dass es dir darum geht einen Egroupware Server mit Collabora zu betreiben!? Dafür braucht man gewöhnlich auch einen Egroupware Server - ja. :slight_smile:

Wenn es dir darum geht Nextcloud und Collabora gemeinsam zu betreiben und Egroupware nicht auf deiner Agenda steht dann würde ich mich an eine der zahlreichen Anleitungen halten die man zu dem Thema findet, eine google Suche liefert massenweise Treffer.

Auf dem Root-Server kannst du im Grunde alles laufen lassen - Collabora, Nextcloud, Egroupware!

Hallo Ralf,

danke für deine Antwort. Ich bein jetzt soweit, dass der Collabora-Server läuft und von der Nextcloud erreichbar ist. In der Mail steht, dass ich den Support-key (wenn man ein Dokument mit der Nextcloud öffne ist dort auch ein Wasserzeichen) in der Collabora-Konfiguration eintragen soll. Ich nehme an, dass damit die Konfiguration aus der Egroupware-Software gemeint ist. Wo trage ich den Key ein, wenn ich die Software nicht habe (in der Nextcloud gibt es kein Feld dafür)?

Grüße
Kishima

Die Konfiguration von Collabora Online müsste liegen in:
grafik

In EGroupware kann man den key in ein Maskefeld eintragen und das wird dann in diese Konfig geschrieben.
Ich vermute mal, genau das müsstest du manuell in die Konfig schreiben (und Collabora neu starten?).
Steht am Ende
<support_key></support_key>
?
Dann pack den kompletten Key dazwischen.

Stefan

Okay, also ich habe mit Ralf gestern das egroupware-collabora-key Paket installiert. Dann lief der collabora-key container im Docker, und wir haben in der loolwsd.xml Datei den support key eingetragen.

Gestern hat dann nur noch ein SSL-Zertifikat gefehlt, damit der Server auch über SSL erreichbar ist. Das Zertifikat habe ich heute bekommen, aber der Server war immer noch nicht erreichbar, bzw. wenn man die Seite mein.collabora.server/hosting/discovery aufgerufen hat, bekam man einen 500 Proxy Error.

Ich ging deshalb davon aus, dass es am collabora-key container liegen muss und habe mit dem Befehl docker run -t -d -p 127.0.0.1:9980:9980 -e "domain=meine.nextcloud.de" --name my-collabora --restart always quay.io/egroupware/collabora-key:stable einen “eigenen” container gestartet.

Der container lief, und man konnte ihn über die Nextcloud erreichen. Dokumente konnte man auch öffnen, allerdings war dann dort das Wasserzeichen unsupported support key is missing. Ich habe dann folgendermaßen die loolwsd.xml aus dem my-collabora container kopiert: docker cp my-collabora:/etc/loolwsd/loolwsd.xml .. Danach habe ich, wie Stefan beschrieben hat, den support key eingetragen, die Datei wieder zurückkopiert: docker cp loolwsd.xml my-collabora:/etc/loolwsd/loolwsd.xml, und den container neugestartet.

Ab dem Punkt war der Server nicht mehr erreichbar. Darum habe ich das support-key Feld wieder entfernt, und die Datei wieder in den container kopiert, und neugestartet. Immer noch nicht erreichbar.

Testweise habe ich dann den container gelöscht docker container rm my-collabora und ihn mit den gleichen Parametern wie oben nochmal gestartet, was bedeutet, dass der support key fehlt.

Screenshot 2021-07-10 at 15-43-33 Einstellungen - Storage Share

Das kommt mir sehr komisch vor. Ich habe ja nicht so viel Ahnung, aber den support_key einzutragen zerstört ihm Prinzip den ganzen Container? Zumindest den my-collabora container, ich weiß nicht wie der collabora-key container gestartet wird, aber ich nehme aufgrund meiner Beobachtungen an, dass das Problem ein ähnliches, oder sogar das gleiche ist.

Ist mir ein Fehler unterlaufen? Warum läuft das nicht? hat überhaupt schonmal jemand versucht eine licensed Collabora Online version in Nextcloud zu integrieren (im Internet steht immer nur was zu collabora/code, auch wenn man explizit nach Collabora Online mit Lizenz sucht findet man nichts)?

Bekommen… Und dann?

Wie sieht den deine Konstellation überhaupt aus?
Vserver?
Reverse-Proxy (Apache / nginx)?
Netzwerk? (Zeig mal docker ps -a)

Wenn der Container läuft und dieser nicht erreichbar ist (von wo auch immer), braucht es nun mehr Informationen. So etwas ist individuell (kaputt).

Was läuft noch auf dem Server? Ist das erreichbar (per https)?

Stefan

Hallo Stefan, danke für deine Antwort.

Zertifikate habe ich mit certbot --apache bekommen, also Reverse-Proxy Apache. Der Server ist per https erreichbar, und es läuft nichts weiter drauf.

Die Nextcloud ist bereitgestellt von Hetzner, und der Server auf dem Collabora läuft ist auch von Hetzner. Die Nextcloud ist quasi stand-alone und den Server für Collabora haben wir extra gebucht.

docker ps -a:

CONTAINER ID   IMAGE                                     COMMAND                  CREATED        STATUS                     PORTS                      NAMES
0e186916a7e2   quay.io/egroupware/collabora-key:stable   "/bin/sh -c 'bash st…"   2 hours ago    Up 2 hours                 127.0.0.1:9980->9980/tcp   my-collabora
c9926a962525   quay.io/egroupware/collabora-key:stable   "/bin/sh -c 'bash st…"   29 hours ago   Exited (137) 2 hours ago                              collabora-key

Hier ist auch die collabora.conf Datei für Apache. Das ist eine Template von Nextcloud:

<VirtualHost *:443>
ServerName office.nextcloud.com:443

# SSL configuration, you may want to take the easy route instead and use Lets Encrypt!
SSLEngine on
SSLCertificateFile /path/to/signed_certificate
SSLCertificateChainFile /path/to/intermediate_certificate
SSLCertificateKeyFile /path/to/private/key
SSLProtocol             all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
SSLHonorCipherOrder     on

# Encoded slashes need to be allowed
AllowEncodedSlashes NoDecode

# Container uses a unique non-signed certificate
SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off

# keep the host
ProxyPreserveHost On

# static html, js, images, etc. served from loolwsd
# loleaflet is the client part of LibreOffice Online
ProxyPass           /loleaflet https://127.0.0.1:9980/loleaflet retry=0
ProxyPassReverse    /loleaflet https://127.0.0.1:9980/loleaflet

# WOPI discovery URL
ProxyPass           /hosting/discovery https://127.0.0.1:9980/hosting/discovery retry=0
ProxyPassReverse    /hosting/discovery https://127.0.0.1:9980/hosting/discovery

# Main websocket
ProxyPassMatch "/lool/(.*)/ws$" wss://127.0.0.1:9980/lool/$1/ws nocanon

# Admin Console websocket
ProxyPass   /lool/adminws wss://127.0.0.1:9980/lool/adminws

# Download as, Fullscreen presentation and Image upload operations
ProxyPass           /lool https://127.0.0.1:9980/lool
ProxyPassReverse    /lool https://127.0.0.1:9980/lool

# Endpoint with information about availability of various features
ProxyPass           /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities retry=0
ProxyPassReverse    /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities

# Not part of the template
# Include egroupware-collabora-key conf file
Include /etc/egroupware-collabora-key/apache.conf

</VirtualHost>

Den ServerName habe ich natürlich ersetzt, und die SSLCertificateFiles wurden automatisch von certbot konfiguriert.
Grüße
Kishima

Ich denke beide Apache Konfigurationen können sich nur stören, dh. entweder die von Nextcloud oder die (includierte) von uns.

Wenn Du Dich am Montag morgen nochmal meldest können wir nochmal zusammen drauf schauen.

Ralf

Ich habe gestern nochmal wie du gesagt hast eine meiner Domains mit einem CNAME DNS-Entry auf den Server umgeleitet, und dafür ein https Zertifikat mit cerbot --apache erstellt, und dementsprechend auch den ServerName in der collabora.conf geändert. Das Zertifikat läuft, und der Server ist in der Nextcloud erreichbar. Über die Domain kann man auch /hosting/discovery und /hosting/capabilities erreichen.

Die Seite in der Nextcloud ist immer noch weiß, was kann ich da jetzt noch machen? Wenn man mit docker run den collabora/code Server startet, muss man als env variable die Domain der Nextcloud angeben, also -e "meine\\.nextcloud\\.de". Könnte es daran liegen?

Kishima

Ja, die wird auch bei EGroupware automatisch in die loolwsd.xml eingetragen.

Sprich Du musst die /var/lib/egroupware/default/loolwsd/loolwsd.yml bearbeiten und die Domain dort eintragen:

Und danach den Container neu starten: docker restart collabora-key

Ralf

Okay, danke. Das hat schonmal geholfen. Das Collabora Interface lädt jetzt, bleibt aber in der Initialisierung hängen, und sagt: SecurityError: The operation is insecure.

Die Nextcloud URL habe ich folgendermaßen eingetragen:

<wopi ...>
    <host desc="Nextcloud hostname">meine\.nextloud\.de</host>
    ...
</wopi>

Was jetzt?

Kishima

Ups :slight_smile:

Danke, da hab ich zu schnell getippt.
Der Error bleibt leider bestehen…

Mit https:\/\/meine\.nextcloud\.de habe ich es auch versucht, ändert aber nichts.

Tut mir leid das sich das alles so hinzieht…

Kishima

Mittwoch bis Freitag hatte ich leider auch keine Zeit. Der SecurityError ist jetzt weg, aber das Interface lädt immer noch nicht, es sei denn man erlaubt mixed-content für die Seite, und auch dann landet man in einer “Initialisierungs-Schleife” und das Dokument lädt nicht.

Ich denke mal, dass das alles mit HTTP und HTTPS zusammenhängt. Soweit ich das verstanden habe, will die Nextcloud alles über HTTPS machen. Ist das Problem, dass der Collabora Server intern über HTTP kommuniziert?

Können wir morgen Früh nochmal telefonieren?

Kishima

Problem war, das in der loolwsd.xml die externe SSL-Terminierung durch den Proxy / Webserver auf dem Host nicht eingetragenen war. Deswegen hat Collabora an Nextcloud unsichere http-URLs gemeldet und der Browser hat sich geweigert Collabora im IFrame anzuzeigen:

    <ssl desc="SSL settings">
        <enable type="bool" desc="Controls whether SSL encryption between browser and loolwsd is enabled (do not disable for production deployment). If default is false, must first be compiled with SSL support to enable." default="true">false</enable>
        <termination desc="Connection via proxy where loolwsd acts as working via https, but actually uses http." type="bool" default="true">true</termination>

EGroupware kümmert sich um diese Dinge automatisch :slight_smile:

@Kishima: bitte Thema als gelöst markieren

Ralf