Skip to content

Nextcloud - Collabora Installation Debian Bookworm 12

Nextcloud
2 1 1.4k
  • 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

  • Restic v0.17.0 released

    Restic restic linux
    1
    0 Stimmen
    1 Beiträge
    166 Aufrufe
    Niemand hat geantwortet
  • Update 1.30.3 released

    Vaultwarden vaultwarden linux
    1
    0 Stimmen
    1 Beiträge
    146 Aufrufe
    Niemand hat geantwortet
  • duf - ein hübsches Kommandozeilen Tool

    Linux linux duf
    1
    1
    0 Stimmen
    1 Beiträge
    183 Aufrufe
    Niemand hat geantwortet
  • Debian 12 Bookworm released

    Linux debian linux
    5
    0 Stimmen
    5 Beiträge
    444 Aufrufe
    FrankMF
    Mein persönliches Fazit, alles läuft rund mit Debian Bookworm 12 Alle meine Hetzner VMs sind jetzt auf Bookworm Ok, was schwer und zeitaufwendig war, war die Nextcloud Installation bzw. der ganze PHP-Server. Das ist echt jedes mal eine Herausforderung, aber auch dabei werde ich die letzten Jahre sicherer. Hier die Story zum Nextcloud Server https://linux-nerds.org/topic/1437/nextcloud-upgrade-auf-bookworm-12 Richtig rund lief das Upgrade des NodeBB-Servers, war einfach und direkt auf Node18 hochgezogen. https://linux-nerds.org/topic/1444/nodebb-upgrade-auf-debian-bookworm-12 Damit ist jetzt alles hier auf Debian Bookworm 12 Haupt-PC VMs bei Hetzner VMs in der Proxmox Oh, da fällt mir gerade ein, der Proxmox ist noch fällig. Aber, dazu habe ich mir was einfallen lassen, da ist noch ein neues Mainboard unterwegs und dann gibt es dazu einen etwas größeren Beitrag. Danke Debian-Team, Debian Bookworm 12 ist eine runde Sache! Spannend wird jetzt, wie lange ich auf meinem Haupt-PC (Bookworm, KDE, Wayland) bleibe. Ich habe da so eine unangenehme Eigenschaft, wenn es um veraltete Pakete geht. Diesmal werde ich dann wahrscheinlich auf den Debian Unstable Zweig (sid) wechseln. Aber das dürfte noch was dauern, da ja aktuell erst mal alles passt.
  • Debian Bookworm 12 - Firefox

    Linux debian firefox linux
    1
    1
    0 Stimmen
    1 Beiträge
    470 Aufrufe
    Niemand hat geantwortet
  • VSCodium - Nach Umzug die Entwicklungsumgebung wieder aktivieren

    Linux linux vscodium
    1
    2
    0 Stimmen
    1 Beiträge
    200 Aufrufe
    Niemand hat geantwortet
  • ROCKPro64 - Debian Bullseye Teil 1

    ROCKPro64 debian linux rockpro64
    17
    4
    0 Stimmen
    17 Beiträge
    2k Aufrufe
    FrankMF
    Durch diesen Beitrag ist mir mal wieder eingefallen, das wir das erneut testen könnten Also die aktuellen Daten von Debian gezogen. Das Image gebaut, könnt ihr alles hier im ersten Beitrag nachlesen. Da die eingebaute Netzwerkschnittstelle nicht erkannt wurde, habe ich mal wieder den USB-to-LAN Adapter eingesetzt. Bus 005 Device 002: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet Die Installation wollte ich auf einem NVMe Riegel installieren. Die Debian Installation durchgezogen und nach erfolgreicher Installation neugestartet. Und siehe da, ohne das man alles möglich ändern musste, bootete die NVMe SSD Eingesetzter uboot -> 2020.01-ayufan-2013...... Die nicht erkannte LAN-Schnittstelle müsste an nicht freien Treibern liegen, hatte ich da irgendwo kurz gelesen. Beim Schreiben dieses Satzes kam die Nacht und ich konnte noch mal drüber schlafen. Heute Morgen, beim ersten Kaffee, dann noch mal logischer an die Sache ran gegangen. Wir schauen uns mal die wichtigsten Dinge an. root@debian:~# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 62:03:b0:d6:dc:b3 brd ff:ff:ff:ff:ff:ff 3: enx000acd26e2c8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:0a:cd:26:e2:c8 brd ff:ff:ff:ff:ff:ff inet 192.168.3.208/24 brd 192.168.3.255 scope global dynamic enx000acd26e2c8 valid_lft 42567sec preferred_lft 42567sec inet6 fd8a:6ff:2880:0:20a:cdff:fe26:e2c8/64 scope global dynamic mngtmpaddr valid_lft forever preferred_lft forever inet6 2a02:908:1260:13bc:20a:xxxx:xxxx:xxxx/64 scope global dynamic mngtmpaddr valid_lft 5426sec preferred_lft 1826sec inet6 fe80::20a:cdff:fe26:e2c8/64 scope link valid_lft forever preferred_lft forever Ok, er zeigt mir die Schnittstelle eth0 ja an, dann kann es an fehlenden Treibern ja nicht liegen. Lässt dann auf eine fehlerhafte Konfiguration schließen. Nächster Halt wäre dann /etc/network/interfaces Das trägt Debian ein # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug enx000acd26e2c8 iface enx000acd26e2c8 inet dhcp # This is an autoconfigured IPv6 interface iface enx000acd26e2c8 inet6 auto Gut, bei der Installation hat Debian ja nur die zusätzliche Netzwerkschnittstelle erkannt, folgerichtig ist die auch als primäre Schnittstelle eingetragen. Dann ändern wir das mal... # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface #allow-hotplug enx000acd26e2c8 allow-hotplug eth0 #iface enx000acd26e2c8 inet dhcp iface eth0 inet dhcp # This is an autoconfigured IPv6 interface #iface enx000acd26e2c8 inet6 auto iface eth0 inet6 auto Danach einmal alles neu starten bitte systemctl status networking Da fehlte mir aber jetzt die IPv4 Adresse, so das ich einmal komplett neugestartet habe. Der Ordnung halber, so hätte man die IPv4 Adresse bekommen. dhclient eth0 Nachdem Neustart kam dann das root@debian:/etc/network# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 62:03:b0:d6:dc:b3 brd ff:ff:ff:ff:ff:ff inet 192.168.3.172/24 brd 192.168.3.255 scope global dynamic eth0 valid_lft 42452sec preferred_lft 42452sec inet6 fd8a:6ff:2880:0:6003:b0ff:fed6:dcb3/64 scope global dynamic mngtmpaddr valid_lft forever preferred_lft forever inet6 2a02:908:1260:13bc:6003:xxxx:xxxx:xxxx/64 scope global dynamic mngtmpaddr valid_lft 5667sec preferred_lft 2067sec inet6 fe80::6003:b0ff:fed6:dcb3/64 scope link valid_lft forever preferred_lft forever 3: enx000acd26e2c8: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:0a:cd:26:e2:c8 brd ff:ff:ff:ff:ff:ff Fertig, eth0 läuft. Nun kann man den zusätzlichen Adapter entfernen oder halt konfigurieren, wenn man ihn braucht. Warum der Debian Installer die eth0 nicht erkennt verstehe ich nicht, aber vielleicht wird das irgendwann auch noch gefixt. Jetzt habe ich erst mal einen Workaround um eine Installation auf den ROCKPro64 zu bekommen.
  • checkmk - Agent installieren

    Verschoben checkmk checkmk linux
    1
    1
    0 Stimmen
    1 Beiträge
    3k Aufrufe
    Niemand hat geantwortet