Collabora: loolswd.xml konsolidieren / Dokumentberarbeitung startet nicht

[Rüdiger Kupper]

Gleiches Spiel wie letztes Mal: ein Update des Collabora-Servers hat ein neues xml-Config-File gebracht, dass sich nicht auf die Schnelle mit dem alten vergleichen lässt. Ich habe das alte File stehen lassen, das neue äüsste jetzt als .dpkg-new im Verzeichnis liegen.
Todo: die Dateien mit einem XML-Differ vergleichen und konsolidieren.

[Rüdiger Kupper]

Wow, aber das Update hat sich gelohnt! Collabora läuft jetzt auch im Handy-Browser (jedenfalls auf meinem Ubuntu-Touch-Handy). Bislang sind die Seiten immer abgestürzt.
Das ist wirklich extrem nützlich, man kann nun vom Handy aus seine Office-Dokumente an der Schule bearbeiten!

[Rüdiger Kupper]

So, beim heutigen Update haben die Entwickler alle Files von „loolwsd“ nach „coolwsd“ umbenannt. Vielen Dank, jetzt läuft der Dienst erst mal nicht mehr.

-> Collabora läuft grade nicht, falls jemand fragt.
Muss die Config von Hand portieren.

[Rüdiger Kupper]

Mannomann, die Reverse-Proxy-Config muss offenbar auch angepasst werden. Siehe:
​https://sdk.collaboraonline.com/docs/installation/Proxy_settings.html

[Rüdiger Kupper]

Habe die Config auf dem collabora-Server und auf dem Apache angepasst. Trotzdem kein Erfolg. Man erhält nur die Fehlermeldung "The requested URL was not found on this server."
Bin leider grade etwas aufgeschmissen …

[bau]

Das muss auf dem apache eingerichtet werden, da dort der "ordner" hinter der URL korrekt weitergelietet werden muss.

[Rüdiger Kupper]

Ja, auf beiden Rechnern (apache und collabora) musste die Apache-Config angepasst werden. Was ich nicht beachtet hatte war, dass die Configdatei auf den beiden Rechnern verschieden heißt, weil sie auf dem apache-Rechner für SSL formuliert sein muss und lokal auf dem collabora-Rechner ohne SSL. Das habe ich jetzt gemacht und jetzt kommen die Anfragen offensichtlich auch auf dem collabora-Rechner an.

Der derzeitige Zustand, wenn man ein Dokument anklickt ist:

• man erhält das Collabora-Fenster mit dem grauen Hintergrund (das kommt vom collabora-Server, ist also schon mal gut)
• es erscheint kurz eine Fehlermeldung, die man nicht lesen kann
• dann erscheint das "hüpfende Collabora-Logo" mit einem Fortschrittsbalken, der bei 0% feststeht

Ich interpretiere das so, dass der Collabora-Server nicht auf die Datei zugreifen kann (die muss er ja von NC holen). Wo es da nun wieder hängt, ist unklar.

[Rüdiger Kupper]

Nach dem Anklicken findet man eine Kopie der Datei auf dem collabora-Server. Die Dateiübertragung funktioniert also, daran scheint es nicht zu liegen. Doch warum startet die Bearbeitung dann nicht?
In den Logs habe ich noch nichts gefunden, außer den üblichen Meldungen zu misslungenen Mounts, die aber laut Forum unkritisch sind und die es auch zuvor schon gab.

@bau

Vielleicht schauen wir die Konfiguration mal zusammen an, vielleicht hast Du eine Idee?

[Rüdiger Kupper]

Die Fehlermeldung, die nur ganz kurz erscheint, heißt dennoch:

"Es konnte keine Verbindung zu Ihrem Dokument hergestellt werden. Bitte versuchen Sie es erneut."

Also klappt das Herüberkopieren zum collabora-Rechner, doch dann kann nicht darauf zugegriffen werden(?).

[bau]

Hast du die Collabora-Einstellungen auf dem Next-Cloud-Server kontrolliert - da musste man doch im Web-Frontend irgendwas einstellen?

[Rüdiger Kupper]

Sort trägt man nur den Namen des Collabora-Hosts ein und der hat sich nicht geändert. Dort ist auch der grüne Haken mit der Bestätigung "Server ist erreichbar". Beim Anklicken eines Dokuments wird der Server ja auch kontaktiert und das Dokument dorthin hochgeladen. Nur das Starten des Libreoffice-Prozesses mit diesem Dokument hängt dann offenbar fest.
Wie sieht es mit den "Websockets" aus, die in der Apache-Config weitergeleitet werden. Muss man da irgendwo etwas freigeben, wenn der Pfad sich geändert hat?

Hier ist die neue Apache-Config auf dem apache-Rechner:

<IfModule mod_ssl.c>
SSLStaplingCache shmcb:/var/run/apache2/stapling_cache(128000)
<VirtualHost *:443>
  ServerName collabora.kg-fds.de
  DocumentRoot /var/www/collabora

  Options -Indexes

  ErrorLog "/var/log/apache2/collabora_error"
  # 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
  # browser is the client part of Collabora Online
  ProxyPass           /browser http://10.16.112.20:9980/browser retry=0
  ProxyPassReverse    /browser http://10.16.112.20:9980/browser

  # WOPI discovery URL
  ProxyPass           /hosting/discovery http://10.16.112.20:9980/hosting/discovery retry=0
  ProxyPassReverse    /hosting/discovery http://10.16.112.20:9980/hosting/discovery

  # Capabilities
  ProxyPass           /hosting/capabilities http://10.16.112.20:9980/hosting/capabilities retry=0
  ProxyPassReverse    /hosting/capabilities http://10.16.112.20:9980/hosting/capabilities

  # Main websocket
  ProxyPassMatch "/cool/(.*)/ws$" ws://10.16.112.20:9980/cool/$1/ws nocanon

  # Admin Console websocket
  ProxyPass   /cool/adminws ws://10.16.112.20:9980/cool/adminws

  # Download as, Fullscreen presentation and Image upload operations
  ProxyPass           /cool http://10.16.112.20:9980/cool
  ProxyPassReverse    /cool http://10.16.112.20:9980/cool
  # Compatibility with integrations that use the /lool/convert-to endpoint
  ProxyPass           /lool https://10.16.112.20:9980/cool
  ProxyPassReverse    /lool https://10.16.112.20:9980/cool
  
SSLCertificateFile /etc/letsencrypt/live/collabora.kg-fds.de/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/collabora.kg-fds.de/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
Header always set Strict-Transport-Security "max-age=31536000"
SSLUseStapling on
</VirtualHost>
</IfModule>

Und hier auf dem collabora-Server:

# Apache2 reverse proxy configuration for Collabora Online
# Internet <-- SSL --> Reverse Proxy <-- No SSL --> coolwsd
# Make sure that you enable the following Apache2 modules: proxy, proxy_wstunnel, and proxy_http.
# Create a virtual host for Collabora Online and include this configuration file.

  Options -Indexes

  # Encoded slashes need to be allowed
  AllowEncodedSlashes NoDecode

  # keep the host
  ProxyPreserveHost On

  # static html, js, images, etc. served from coolwsd
  # browser is the client part of Collabora Online
  ProxyPass           /browser http://127.0.0.1:9980/browser retry=0
  ProxyPassReverse    /browser http://127.0.0.1:9980/browser

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

  # Capabilities
  ProxyPass           /hosting/capabilities http://127.0.0.1:9980/hosting/capabilities retry=0
  ProxyPassReverse    /hosting/capabilities http://127.0.0.1:9980/hosting/capabilities

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

  # Admin Console websocket
  ProxyPass   /cool/adminws ws://127.0.0.1:9980/cool/adminws

  # Download as, Fullscreen presentation and Image upload operations
  ProxyPass           /cool http://127.0.0.1:9980/cool
  ProxyPassReverse    /cool http://127.0.0.1:9980/cool
  # Compatibility with integrations that use the /lool/convert-to endpoint
  ProxyPass           /lool http://127.0.0.1:9980/cool
  ProxyPassReverse    /lool http://127.0.0.1:9980/cool

[Rüdiger Kupper]

In der Musterkonfiguration hier
​https://sdk.collaboraonline.com/docs/installation/Proxy_settings.html
steht an einer Stelle "wss://" statt "ws://". (Interessanter Weise gerade in der Version *ohne* SSL(?)) Bei uns steht überall "ws://". Das war aber vorher auch schon so …

[Rüdiger Kupper]

Da das Websocket zum collabora-Rechner hin geöffnet wird und diese Verbindung unverschlüsselt ist, ist es wohl richtig, dass dort "ws://" steht

[bau]

Eigentlich haben wir hinter dem Frontend keine Secure-Verbindungen mehr, das ist ja auch unnötig.

[Rüdiger Kupper]

Ja, und zuvor lief es ja auch mit dieser Config.

Wir könnten ausprobieren, den Container priviligiert zu machen. Dann würden immerhin die bind mounts funktionieren, die jetzt nicht klappen. Aber auch das war ja vorher schon so und Collabora verlinkt oder kopiert stattdessen. Die Umgebungen, in denen die Prozesse laufen sollen, finde ich auch, die wurden also eingerichtet. (Jedes Dokument bekommt sein eigenes Libreoffice in einer chroot-Umgebung mit einem kompletten Dateibaum.)

Nur irgrn etwas verhindert, dass der Libreooffice-Prozess dann auch startet.

[Rüdiger Kupper]

Ich habe die Collabora-App in NC erst mal deaktiviert, damit die Kollegen nicht vor dem dysfunktionalen Fenster sitzen, wenn sie ein Dokument anklicken. Die Dokumente werden beim Anklicken jetzt wie andere Dateien auch heruntergeladen.

[Rüdiger Kupper]

Hier gibt es eine informative Diskussion zu den Container-bedingten Fehlermeldungen im NC-Log:
​https://github.com/CollaboraOnline/online/issues/779
Da geht es zwar um Docker, doch das Problem ist das selbe: ein unpriviligierter Docker-Container darf keine Mounts ausführen, genau wir unser unpriviligierter LXC-Container. Startet man den Docker-Container prviligiert, so sind die Fehlermeldungen weg und der Dokumentzugriff arbeitet effizienter.

Unten auf der Seite gibt es eine kurze Enschätzung des Entwicklers zu Vor- und Nachteilen eines priviligierten Containers. Ich würde sagen, wir verwandeln unseren Container mal in einen priviligierten und schauen, ob sich dadurch zufällig auch an unserem Startproblem etwas ändert.

[bau]

Sehr gute Idee!

[Rüdiger Kupper]

Nur hat es ja zuvor mit der alten Collabora-Version auch im unpriviligierten Container funktioniert. Ich habe also sehr wenig Hoffnung, das das unser Problem löst.

[Rüdiger Kupper]

Seit ein paar Tagen läuft der Collabora-Server im priviligierten Container. (Umstellung ging reibungslos: in ProxMox-Interface ein Backup der Maschine auf die lokale Platte machen, Backup wiederherstellen und dabei das Häkchen bei "unpriviligiert" rausnehmen. Der alte Container wird gelöscht und als priviligierter Container wiederhergestellt.)
Leider hat das das Startproblem, wie erwartet, nicht gelöst. Die vielen Fehlermeldungen aus dem Log sind nun aber verschwunden, weil der Server jetzt bind-Mounts machen kann.
Dadurch ist wenigstens das Log besser lesbar. Und es sieht so aus, als ob der Libreoffice-Prozess schlicht und einfach kurz nach dem Start mit SIGABRT abschmiert. Das Signal könnte aus dem Prozess selbst oder einer Bibliothek stammen:

​https://stackoverflow.com/questions/3413166/when-does-a-process-get-sigabrt-signal-6

SIGABRT is commonly used by libc and other libraries to abort the program in case of critical errors. For example, glibc sends an SIGABRT in case of a detected double-free or other heap corruptions.

Im Collabora-Bugtracker steht aber nichts zu einem solchen Fehler, das ist verdächtig.

[Rüdiger Kupper]

Ah, endlich sind im Bugtracker zwei Issues aufgetaucht, die exakt unser Problem beschreiben: Ebenfalls nach Update von Version 6.4 und ebenfalls der SIGABRT-Fehler. Wir sind also nicht allein.
​https://github.com/CollaboraOnline/online/issues/3910

[Rüdiger Kupper]

Ah, Collabora läuft endlich wieder! Einem Mitstreiter im Ticket, der genau das selbe Problem hatte, fiel auf, dass nach dem Update auf die neue Version keine Üokalisieringspakete installiert waren. Nach Installation der deutschen Lokalisierung ist der Crash verschwunden:

# apt install collaboraoffice-dict-da collaboraofficebasis-de
# systemctl restart coolwsd

Ein Hoch auf die Community! Keine Ahnung, wie er darauf kam.

Das heißt auch, dass meine sonstigen Anpassungen für den Schritt con lool nach cool richtig waren. Damit kann ich moch nun endüich um das ursprüngliche Anüiegen dieses Tickets kümmern (coolwsd.xml mit dem alten loolwsd.xml vergleichen, siehe ganz oben.)

Beobachtung: das neue Collaboraoffice 21.06 hat die Ribbons wie MS Office. In Desktop-Libreoffice sind die eine Option, man hat aber die Wahl. Hier offenbar nicht. Soweit ich lese sollen sie aber mit dem nächsten großen Update von NC auf v23 wieder verschwunden sein.

@tabletteam

das neue Collabora hat auch ein ganz brauchbares Mobil-Layout. Könnt ihr das mal auf den Tablets testen?

[bau]

Prima - herzlichen Glückwunsch!
Leider mal wieder Dinge, die die Welt nicht wirklich braucht!

[Rüdiger Kupper]

Replying to bau:

Leider mal wieder Dinge, die die Welt nicht wirklich braucht!

Ja, mit den Ribbons konnte ich ich nie anfreunden, zumal sie genau an der falschen Stelle sind (sie nehmen vertikalen Patz weg, der auf modernen Monitoren ja besonders knapp ist. Seitliche Ribbons wären irgendwie geschickter.) Es gibt aber wohl auch viele Nutzer, die sich damit von MS kommend wohler fühlen.

Interessanter Weise hab ich gelernt, dass man im Desktop-Libreoffice tatsächlich zwischen vielen verschiedenen Menüarten wählen kann, auch verschiedenen Ribbon-Typen (Menü: Ansicht->Benutzeroberfläche). In Collabora habe ich keine Einstellung dafür gefunden. Aber wie gesagt, in NC 23 ist Collabora enger integriert und heißt dann „Nextcloud Office“. Und da haben sie sich als Design wieder für die guten alten Textmenüs entschieden.

[Rüdiger Kupper]

Replying to kup:

das neue Collabora hat auch ein ganz brauchbares Mobil-Layout. Könnt ihr das mal auf den Tablets testen?

Habe verschiedenen Browser auf dem Tablet getestet, Ergebnis:

• in Safari ist der runde Knopf rechts unten, den man klicken muss, um ein Dokument zu bearbeiten, weiterhin teilweise außerhalb des Bildes, so dass man nur den oberen Rand sieht. Leider nur mit dem Stift zu erreichen.
• Chrome: Hier ist der Knopf gar nicht zu sehen! (vermutlich unterhalb des Bildrands)
• Firefox: Der Knopf ist genau an der richtigen Stelle.
• Brave: ebenfalls
• Opera: ebenfalls

Das ist interessant, weil Brave und Opera beide auf Chromium beruhen…

Ich dachte, die Zeit der Browser-Inkompatibilitäten wäre allmählich vorbei?

[Rüdiger Kupper]

Hier steht jetzt auch beschrieben, was ich mühsam selbst rausgefunden habe:
​https://docs.nextcloud.com/server/stable/admin_manual/office/migration.html

Todo

einmal durchgehen und schauen, ob ich alles richtig gemacht habe.

[Rüdiger Kupper]

Collabora-Container läuft nun auf proxmoxls4 (priviligiert). OS upgegradet auf Ubuntu 22.04, Collabora 23.0.5.
Umzug auf dedizierten Host vorgesehenö

[Rüdiger Kupper]

Konsolidierung von looswd.xml/coolswd.xml steht weiterhin an.

[Rüdiger Kupper]

Erledigt. Meld ist ein gutes Tool zum Mergen der alten und neuen Config. Dazu halt die xml-Dateien auf einen Desktoprechner kopieren, dort mit Meld mergen und das Ergebnis zurückkopieren.