Skip to content

Nextcloud - Collabora Installation Debian Bookworm 12

Nextcloud
  • 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...

    Vorgeschichte

    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.

    f51c70a2-ac9e-411a-902e-172c480d589f-grafik.png

    Installation von CODE (Collabora Online Development Edition)

    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!

    Nur zum Testen, nicht so laufen lassen!

    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.

    Zertifikate

    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.

    Achtung! Wenn das Zertifikat abläuft und erneuert wird, knallt es. Dafür gibt es aber eine Lösung.

    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>/
    

    Konfigration coolwsd.xml

    Was war noch wichtig?

    Netzwerk

    <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

    <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.

    Nextcloud

    Screenshot_20230905_120200.png

    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.

    Test-Dokument

    c981851e-bacb-40c0-9995-2acfc259a6f2-grafik.png

    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.

    Thema Sicherheit

    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.

    28c41010-5ce1-4f7c-89d5-1c9b253011d0-grafik.png

    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!

    c1a06c2c-86b5-4750-a062-7ba9d8dd8253-grafik.png

  • Flask Projekt auf einem anderen Rechner installieren

    Python3
    1
    0 Stimmen
    1 Beiträge
    148 Aufrufe
    Niemand hat geantwortet
  • Nextcloud 28.0.0 - OpenAI Integration

    Nextcloud
    2
    6
    0 Stimmen
    2 Beiträge
    806 Aufrufe
    FrankMF
    Noch eine Ergänzung. Wenn ihr jetzt viele User habt und das nur auf eine Gruppe beschränken wollt, könnt ihr das so machen. Unter Apps, Nextcloud Assistant suchen und die gewünschten Gruppen eintragen. Fertig [image: 1702725312285-197deae4-d72a-4729-bba7-bfa9b4bef334-grafik.png]
  • Restic v0.12.0 released

    Restic
    1
    0 Stimmen
    1 Beiträge
    235 Aufrufe
    Niemand hat geantwortet
  • Mainline 5.11.x

    Images
    1
    0 Stimmen
    1 Beiträge
    246 Aufrufe
    Niemand hat geantwortet
  • OpenWRT - Zonen

    Verschoben OpenWRT & Ubiquiti ER-X
    2
    3
    0 Stimmen
    2 Beiträge
    601 Aufrufe
    FrankMF
    Es ist was heller geworden [image: 1610188645165-7b86e97c-31a5-44b6-809f-25d9d1c2ee4a-image.png] Die besagte Forward Regel [image: 1610188840619-zonen.png] Diese Forward Regel zieht erst dann, wenn es mehrere Interfaces in einer Zone gibt. Aus der Doku INPUT rules for a zone describe what happens to traffic trying to reach the router itself through an interface in that zone. OUTPUT rules for a zone describe what happens to traffic originating from the router itself going through an interface in that zone. FORWARD rules for a zone describe what happens to traffic passing between different interfaces belonging in the same zone. Das heisst nun, das ein Forwarding zwischen zwei Zonen immer eine spezifische Regel unter Traffic Rules benötigt. Forwarding between zones always requires a specific rule. Somit ist ein Forwarding zwischen zwei Zonen in den Standard Einstellungen nicht erlaubt. Das kann ich hier auch so bestätigen. Das ist ja auch das was ich mit meiner "DMZ"-Zone erreichen möchte. Kein Zugriff auf LAN. Unter Zone ⇒ Forwardings kann man jetzt sehen, das das Forwarding von LAN in Richtung WAN und DMZ erlaubt ist. WAN ist logisch, sonst komme ich ja nicht ins Internet. DMZ habe ich eingestellt, damit ich auch Teilnehmer im DMZ Netz erreichen kann, wenn ich da mal ran muss. [image: 1610189307657-8a548c29-8bc5-4074-8099-66460bcea9a8-image.png] Stelle ich das jetzt so ein. [image: 1610189398985-dca8b393-f613-4cab-a377-ffbc2bb8ddf5-image.png] Dann kann ich von der DMZ Zone aus das LAN erreichen. Aha, so langsam verstehe ich Quelle: https://forum.openwrt.org/t/firewall-zones-and-settings/84369
  • Nextcloud - Desktop Integration

    Nextcloud
    1
    3
    0 Stimmen
    1 Beiträge
    296 Aufrufe
    Niemand hat geantwortet
  • Linux Umstieg - 6 Jahre

    Verschoben Allgemeine Diskussionen
    1
    1
    1 Stimmen
    1 Beiträge
    275 Aufrufe
    Niemand hat geantwortet
  • NodeBB auf dem Raspberry3 B+ installieren

    RaspberryPi
    1
    0 Stimmen
    1 Beiträge
    857 Aufrufe
    Niemand hat geantwortet