Im Dezember 2022 hatten wir das Thema schon einmal. Ich bin irgendwo darüber gestolpert, das man in der Konfiguration einen deepl.com API Zugriff konfigurieren kann. Das hörte sich spannend an und das musste man mal eben testen. Es wurde eine längere Sitzung an der Konsole...
Ich hatte erfolgreich den eingebauten CODE-Server eingerichtet. Funktionierte so weit auch alles. Aber, dann sucht mal bei diesem AppImage die Konfigurationsdatei coolwsd.xml
Spannend. Ich hatte dann was gefunden.
/tmp/appimage_extracted_6d5bcc2f7e5aa310409d897a20c65ea4/etc/coolwsd/coolwsd.xml
Da ließ sich aber leider auch nichts einstellen, wenn man den PHP neustartete, wurde das AppImage wohl neu ausgepackt(?) und alles war wieder wie vorher. Ich wollte mich jetzt auch nicht intensiver mit AppImages beschäftigen, als musste mal eben wieder ein Collabora Server her.
Die Informationen zu CODE findet man hier. Die Installation ist hier beschrieben.
Nachdem ich jetzt alles installiert hatte, wollte ich den Dienst coolwsd starten.
systemctl start coolwsd.service
Aber, der Dienst crashte andauernd. Ich musste dann etwas tiefer einsteigen und schauen, wo es klemmte. Also, als erstes den SystemD-Dienst anschauen. Erst mal suchen....
/lib/systemd/system/coolwsd.service
[Unit]
Description=Collabora Online WebSocket Daemon
After=network.target
[Service]
EnvironmentFile=-/etc/sysconfig/coolwsd
ExecStart=/usr/bin/coolwsd --version --o:sys_template_path=/opt/cool/systemplate --o:child_root>
KillSignal=SIGINT
TimeoutStopSec=120
User=cool
KillMode=control-group
Restart=always
LimitNOFILE=infinity:infinity
ProtectSystem=strict
ReadWritePaths=/opt/cool /var/log
ProtectHome=yes
PrivateTmp=yes
ProtectControlGroups=yes
CapabilityBoundingSet=CAP_FOWNER CAP_CHOWN CAP_MKNOD CAP_SYS_CHROOT CAP_SYS_ADMIN
[Install]
WantedBy=multi-user.target
Ok, was gab es hier interessantes? Der Dienst wurde mit dem User cool gestartet. Es gab ihn auch.
cool:x:102:109::/opt/cool:/usr/sbin/nologin
Ich hatte zwischenzeitlich versucht den Dienst als root zu starten. Wenn man den Aufruf um folgenden Parameter ergänzt, geht das auch.
--disable-cool-user-checking
Don't check whether coolwsd is running under
the user 'cool'. NOTE: This is insecure, use
only when you know what you are doing!
Ok, nun wusste ich, das etwas mit den Rechten nicht stimmen musste. Also mal nachgeschaut.
/opt/cool
/etc/coolwsd
Diese beiden Verzeichnisse hatten was mit dem Dienst zu tuen. Beide standen auf
root:root
so das ich erst mal die Rechte änderte.
chown -R cool:cool /opt/cool
chown -R cool:cool /etc/coolwsd
Danach ein Neustart des Dienstes und siehe da, diesmal blieb er am leben. Ok, ich hatte auch noch ein Problem, aber dazu später mehr. Der Dienst läuft jetzt erst mal 
Ich muss davon ausgehen, das das Installationsscript einen Fehler enthält. Ärgerlich.
Ich habe mir also von Letsencrypt die Zertifikate geholt und diese als Pfad in die Konfiguration von CODE eingegeben.
Findet man unter
/etc/coolwsd/coolwsd.xml
Dringender Rat, legt Euch vorher eine Kopie an! Ok, hier also der Teil aus der Konfiguration.
<ssl desc="SSL settings">
<!-- switches from https:// + wss:// to http:// + ws:// -->
<enable type="bool" desc="Controls whether SSL encryption between coolwsd and the network is enabled (do not disable for production deployment). If default is false, must first be compiled with SSL support to enable." default="true">true</enable>
<!-- SSL off-load can be done in a proxy, if so disable SSL, and enable termination below in production -->
<termination desc="Connection via proxy where coolwsd acts as working via https, but actually uses http." type="bool" default="true">false</termination>
<cert_file_path desc="Path to the cert file" relative="false">/etc/coolwsd/nginx/fullchain.pem</cert_file_path>
<key_file_path desc="Path to the key file" relative="false">/etc/coolwsd/nginx/privkey.pem</key_file_path>
<ca_file_path desc="Path to the ca file" relative="false"/>
<cipher_list desc="List of OpenSSL ciphers to accept" default="ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH"></cipher_list>
<hpkp desc="Enable HTTP Public key pinning" enable="false" report_only="false">
<max_age desc="HPKP's max-age directive - time in seconds browser should remember the pins" enable="true">1000</max_age>
<report_uri desc="HPKP's report-uri directive - pin validation failure are reported at this URL" enable="false"></report_uri>
<pins desc="Base64 encoded SPKI fingerprints of keys to be pinned">
<pin></pin>
</pins>
</hpkp>
<sts desc="Strict-Transport-Security settings, per rfc6797. Subdomains are always included.">
<enabled desc="Whether or not Strict-Transport-Security is enabled. Enable only when ready for production. Cannot be disabled without resetting the browsers." type="bool" default="false">false</enabled>
<max_age desc="Strict-Transport-Security max-age directive, in seconds. 0 is allowed; please see rfc6797 for details. Defaults to 1 year." type="int" default="31536000">31536000</max_age>
</sts>
</ssl>
Da stand vorher
/etc/letsencrypte/live/<DOMAIN>
Das gibt aber wieder Zugriffsprobleme für den User cool. Da ich das Problem schon von meinem REST-Server kenne, habe ich die Zertifikate nach /etc/coolwsd/nginx kopiert. Danach funktionierte das wie erwartet. Das ist natürlich unschön.
Der Crontab für den certbot muss so aussehen.
# m h dom mon dow command
0 12 1 * * certbot renew --pre-hook "service nginx stop" --post-hook "chown -R cool:cool /etc/letsencrypt/>/ && service nginx start"
Und jetzt können oben in die Konfiguration auch die richtigen Pfaden rein.
/etc/letsencrypt/live/<DOMAIN>/
Was war noch wichtig?
<proto type="string" default="all" desc="Protocol to use IPv4, IPv6 or all for both">all</proto>
<listen type="string" default="any" desc="Listen address that coolwsd binds to. Can be 'any' or 'loopback'.">any</listen>
Der Server hat IPv4 & IPv6.
<host desc="The IPv4 private 192.168 block as plain IPv4 dotted decimal addresses."><IPv4-Addy></host>
<host desc="The IPv4 private 192.168 block as plain IPv4 dotted decimal addresses."><IPv6-Addy></host>
Hier die beiden IP-Adressen des Nextcloud Servers rein.
<deepl desc="DeepL API settings for translation service">
<enabled desc="If true, shows translate option as a menu entry in the compact view and as an icon in the tabbed view." type="bool" default="false">true</enabled>
<api_url desc="URL for the API" type="string" default="">https://api-free.deepl.com/v2/translate</api_url>
<auth_key desc="Auth Key generated by your account" type="string" default=""><API-KEY hier rein!></auth_key>
</deepl>
Das sollte es gewesen sein.
Im oberen Feld kommt die Domain des CODE-Servers rein incl. Port. Standard ist 9980. Im unteren Feld kommen die IP-Adressen des CODE-Servers rein. Ich habe hier die IPv4 & IPv6 Adressen eingegeben.
Wenn man Probleme mit den Zertifikaten hat, kann man zu Testzwecken Zertifikatüberprüfung deaktivieren (unsicher) aktivieren.
Wenn das grüne Lämpchen angeht, dann sollte der CODE-Server erreichbar sein.
In der Menüleiste sieht man das Icon Übersetzen, also erfolgreiche deepl.com Integration. Im Dokument ein Popup, wo man die Sprache auswählen kann.
Die deepl.com API kann man bis 500.000 Zeichen kostenlos benutzen, danach muss man bezahlen.
Die Zugriffe auf den CODE-Server blocken, nur der Nextcloud-Server darf zugreifen! Evt. erweiter ich das hier noch um meine Firewall-Regeln.
Viel Spaß beim Testen.
Ok, ich war leider nicht in der Lage den CODE-Server hinter einem Proxy zu installieren. Das CODE-Team scheint Docker zu lieben und das andere nur am Rande zu machen. Ohne Liebe
Da ich extrem lange Ladezeiten hatte und die Software insgesamt nicht den Eindruck machte, das man das gerne produktiv auf einem Server nutzen möchte, habe ich den Server eben wieder gelöscht.
Jetzt fehlt mir leider, die deepl.com Anbindung, aber das kann man ja auch über die Webseite nutzen.
Ich nutze jetzt wieder den eingebauten CODE-Server, der eigentlich ein App-Image ist.
Der klare Vorteil, es läuft incl. Dokumenten Freigabe
Nicht vergessen, unter Allow list for WOPI requests kommen die Server Adressen des Nextcloud-Webservers rein!
