Skip to content

Nextcloud Talk

Nextcloud
5 1 987
  • In Zeiten von Corona gibt es ja zur Zeit ein Thema was wichtig ist - HomeOffice oder auch die Kommunikation mit Freunden, Verwandten und Kollegen.

    Jeder benutzt was anderes, viele kommerzielle Anbieter denen ich nicht traue usw. Was machen? Da fiel mir ein, das Nextcloud ja Nextcloud Talk enthält.

    bf501e55-c6d6-4e22-9cb8-e647bd2d2818-image.png

    Eigentlich gibt es da keine so großen Hürden. Telefonate funktionierten sofort aber Videotelefonate!?!? Ok, ab jetzt wird es schwieriger 🙂

    Eine sehr schöne Anleitung habe ich hier gefunden. Doch wie so oft, manchmal helfen solche Anleitungen nicht wirklich weiter. Ich hatte alles so eingestellt wie darin beschrieben, aber beim Test im Backend von Nextcloud tauchte immer ein Ausrufezeichen auf.

    nc.png

    Wenn der TURN-Server richtig eingerichtet ist, erscheint beim Testen ein Haken an der Position vor dem Mülleimer. Lange Zeit hatte ich dort immer ein Ausrufezeichen. Bei mir hatte das den Grund, das die TLS Verbindung nicht richtig funktionierte, weil das Zusammenspiel zwichen coturn und Letsencrypt bugbehaftet ist. Dazu morgen etwas ausführlichere Erläuterungen, für heute genug HomeOffice 🙂

  • coturn

    Was das?

    The TURN Server is a VoIP media traffic NAT traversal server and gateway. It can be used as a general-purpose network traffic TURN server and gateway, too.
    Quelle: https://github.com/coturn/coturn

    Ich bin kein Netzwerktechniker und muss mich da leider an die Erklärung vom Nextcloud Backend orientieren.

    Ein TURN-Server dient als Proxy für die Verbindungen von Teilnehmern hinter einer Firewall.

    Damit kann ich mir das dann ein wenig besser erklären. Aber, bevor ich hier Stuss schreibe, lasse ich es lieber. Machen wir weiter mit praktischen Dingen. Was ich ja vorher schon raus gefunden hatte, ohne diesen Server hat man kein Video. Ok, dann wollen wir mal einen aufsetzen. Da ich meine vorhandene Installation nicht gefährden wollte, habe ich schnell eine neue VM aufgesetzt. Dank Hetzner Cloud ein Kinderspiel. Ja, das war ein Werbeblock 🙂

    Also hatte ich jetzt ein jungfräuliches Debian 10 Buster. Dann mal coturn installieren.

    apt install coturn
    

    Nachdem ich ihn nach der Anleitung s.o. den coturn konfiguriert hatte, bekam ich nach dem Start folgendes.

    root@debian-2gb-nbg1-1-webserver:~# systemctl status coturn.service
    ● coturn.service - coTURN STUN/TURN Server
       Loaded: loaded (/lib/systemd/system/coturn.service; enabled; vendor preset: enabled)
       Active: failed (Result: exit-code) since Thu 2020-03-26 10:51:25 CET; 9s ago
         Docs: man:coturn(1)
               man:turnadmin(1)
               man:turnserver(1)
      Process: 671 ExecStart=/usr/bin/turnserver --daemon -c /etc/turnserver.conf --pidfile /run/turnserver/turnserver.pid (code=exited, s
    
    Mar 26 10:51:25 debian-2gb-nbg1-1-webserver systemd[1]: coturn.service: Control process exited, code=exited, status=255/EXCEPTION
    Mar 26 10:51:25 debian-2gb-nbg1-1-webserver systemd[1]: coturn.service: Failed with result 'exit-code'.
    Mar 26 10:51:25 debian-2gb-nbg1-1-webserver systemd[1]: Failed to start coTURN STUN/TURN Server.
    Mar 26 10:51:25 debian-2gb-nbg1-1-webserver systemd[1]: coturn.service: Service RestartSec=100ms expired, scheduling restart.
    Mar 26 10:51:25 debian-2gb-nbg1-1-webserver systemd[1]: coturn.service: Scheduled restart job, restart counter is at 5.
    Mar 26 10:51:25 debian-2gb-nbg1-1-webserver systemd[1]: Stopped coTURN STUN/TURN Server.
    Mar 26 10:51:25 debian-2gb-nbg1-1-webserver systemd[1]: coturn.service: Start request repeated too quickly.
    Mar 26 10:51:25 debian-2gb-nbg1-1-webserver systemd[1]: coturn.service: Failed with result 'exit-code'.
    Mar 26 10:51:25 debian-2gb-nbg1-1-webserver systemd[1]: Failed to start coTURN STUN/TURN Server.
    

    Ich habe lange dran getüftelt, bis ich verstanden hatte wo das Problem lag.

    Ausschnitt /etc/turnserver.conf

    # TURN listener port for UDP and TCP (Default: 3478).
    # Note: actually, TLS & DTLS sessions can connect to the 
    # "plain" TCP & UDP port(s), too - if allowed by configuration.
    #
    listening-port=3478
    
    # TURN listener port for TLS (Default: 5349).
    # Note: actually, "plain" TCP & UDP sessions can connect to the TLS & DTLS
    # port(s), too - if allowed by configuration. The TURN server 
    # "automatically" recognizes the type of traffic. Actually, two listening
    # endpoints (the "plain" one and the "tls" one) are equivalent in terms of
    # functionality; but we keep both endpoints to satisfy the RFC 5766 specs.
    # For secure TCP connections, we currently support SSL version 3 and 
    # TLS version 1.0, 1.1 and 1.2.
    # For secure UDP connections, we support DTLS version 1.
    #
    tls-listening-port=5349
    

    Der listening-port 3478 entspricht einer HTTP Verbindung, der tls-listening-port 5349 einer HTTPS Verbindung. So als Erklärung 😉 Nachdem ich dann raus gefunden hatte, das der Port 3478 funktionierte, ich hatte mich am Anfang nur auf TLS konzentriert, wusste ich das an der TLS Verbindung / Zertifikaten was nicht stimmte.

    Also, Tipp Nr.1

    Als erstes mit listening-port=3478 testen!

    Danach wenden wir uns der TLS Verbindung zu. Ich gehe davon aus, das die meisten mittlerweile wissen, wie man Letsencrypt Zertifikate auf einem Rootserver installiert? Wenn nicht, dann gibt es hier Lesestoff.

    Config coturn

    listening-port=3478
    tls-listening-port=5349
    fingerprint
    use-auth-secret
    static-auth-secret=PASSWORD
    server-name=xxxx.frank-mankel.org
    realm=xxxx.frank-mankel.org
    total-quota=100
    stale-nonce=600
    cert=/etc/letsencrypt/live/xxxx.frank-mankel.org/cert.pem
    pkey=/etc/letsencrypt/live/xxxx.frank-mankel.org/privkey.pem
    cipher-list=“ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384″
    dh-file=/etc/ssl/dhparam.pem
    no-stdout-log
    syslog
    simple-log
    no-multicast-peers
    cli-password=PASSWORD
    no-tlsv1
    no-tlsv1_1
    

    Die TLS Verbindung wollte aber nie starten. Das kam im /var/log/user.log

    Mar 26 10:29:21 debian-2gb-nbg1-1-webserver turnserver: 0: WARNING: cannot find certificate file: turn_server_cert.pem (1)
    Mar 26 10:29:21 debian-2gb-nbg1-1-webserver turnserver: 0: WARNING: cannot start TLS and DTLS listeners because certificate file is not set properly
    Mar 26 10:29:21 debian-2gb-nbg1-1-webserver turnserver: 0: WARNING: cannot find private key file: turn_server_pkey.pem (1)
    Mar 26 10:29:21 debian-2gb-nbg1-1-webserver turnserver: 0: WARNING: cannot start TLS and DTLS listeners because private key file is not set properly
    

    Dazu zwei Links

    Hier sieht man das coturn ein Problem damit hat die symbolischen Links zu verarbeiten. Ich hatte dann die richtigen Files reinkopiert und die symbolischen Links gelöscht. Ging dann aber immer noch nicht. Erst als auch der User turnserver die Rechte für den Ordner hatte, ging es.

    Das hat jetzt eine Menge von Nachteile. Die Zertifikate erneuern sich ja alle paar Monate von alleine, so das es jetzt knallt. Dann geht das wieder nicht.

    Mein Denkansatz ist jetzt, Letsencrypt wieder so installieren, das alles korrekt ist, dann klappt das auch mit der automatischen Aktualisierung. Dazu wird sowieso ein Cronjob benutzt. Nach Ausführung des Cronjobs werden die Zertifikate an einen anderen Ort kopiert, bekommen die richtigen Namen und die richtigen Rechte so das der Turnserver damit was anfangen kann.

    Wäre schön, wenn das jemand mit dem nötigen KnowHow fixen könnte!?

    Ob das so funktioniert, wie von mir ausgedacht, muss ich die Tage noch testen. Dank HomeOffice ist ja dafür nächste Woche ausreichend Zeit für vorhanden 😉

    Danach trägt man den Turnserver in Nextcloud ein und die Verbindung funktioniert einwandfrei. Was mir beim Testen aufgefallen ist, das die Signalisierung eines Anrufes auf einem Android Handy nicht durchkam. Aber das kennt man ja auch von vielen anderen Dingen. Kurz vorher dem Gesprächspartner eine Nachricht zukommen lassen, so das man die App schon mal startet, sollte da Abhilfe schaffen.

    Bitte denkt an ausreichende Absicherung des Servers!

  • Noch eine kleine Ergänzung, für Eure Firewall muss auf dem TURN-Server lediglich der Port 5349 offen sein. Wie ihr ja wisst, kann man das schön aus dem Nextcloud Backend testen!

  • Noch was, das Letsencrypt Problem konnte ich etwas vereinfachen. Ganz normale Installation von Letsencrypt.
    Danach einfach folgendes.

    chown -R turnserver:root /etc/letsencrypt/
    

    Dann sieht das so aus.

    root@debian-2gb-nbg1-1-webserver:/etc/letsencrypt# ls -lha live/xxxx.frank-mankel.org/
    total 12K
    drwxr-xr-x 2 turnserver root 4.0K Mar 29 14:02 .
    drwx------ 3 turnserver root 4.0K Mar 29 14:02 ..
    lrwxrwxrwx 1 turnserver root   45 Mar 29 14:02 cert.pem -> ../../archive/xxxx.frank-mankel.org/cert1.pem
    lrwxrwxrwx 1 turnserver root   46 Mar 29 14:02 chain.pem -> ../../archive/xxxx.frank-mankel.org/chain1.pem
    lrwxrwxrwx 1 turnserver root   50 Mar 29 14:02 fullchain.pem -> ../../archive/xxxx.frank-mankel.org/fullchain1.pem
    lrwxrwxrwx 1 turnserver root   48 Mar 29 14:02 privkey.pem -> ../../archive/xxxx.frank-mankel.org/privkey1.pem
    -rw-r--r-- 1 turnserver root  692 Mar 29 14:02 README
    

    Im coturn Logfile steht das drin.

    Mar 29 14:09:18 debian-2gb-nbg1-1-webserver turnserver: 0: SSL23: Certificate file found: /etc/letsencrypt/live/xxxx.frank-mankel.org/cert.pem
    Mar 29 14:09:18 debian-2gb-nbg1-1-webserver turnserver: 0: SSL23: Private key file found: /etc/letsencrypt/live/xxxx.frank-mankel.org/privkey.pem
    Mar 29 14:09:18 debian-2gb-nbg1-1-webserver turnserver: 0: TLS1.2: Certificate file found: /etc/letsencrypt/live/xxxx.frank-mankel.org/cert.pem
    Mar 29 14:09:18 debian-2gb-nbg1-1-webserver turnserver: 0: TLS1.2: Private key file found: /etc/letsencrypt/live/xxxx.frank-mankel.org/privkey.pem
    

    So sollte das jetzt schon was einfacher sein. Schnell noch einen Crontab angelegt.

    # m h  dom mon dow   command
    PATH=/usr/sbin:/usr/bin:/sbin:/bin
    0 4 1 * * /usr/bin/certbot renew --pre-hook "service coturn stop" --post-hook "service coturn start"
    

    Das bekannte Vorgehen. Jeden 1. im Monat coturn stoppen, Zertifikate erneuern, coturn wieder starten. Fertig!

    Jetzt sollte die ganze Sache aber rund sein. Hoffe ich .)

  • All I needed to do was setting the permissions to 744 for the archive directory and the symlinks resolved correctly after a reboot of coturn

    My turnserver installation on Debian runs as the user turnserver and not as root, nor is the user turnserver in any group owning the letsencrypt directory.
    If your turnserver does run as root, it should be fine just adding execute permissions.

    I hope this helps some of you.
    Quelle: https://help.nextcloud.com/t/lets-encrypt-symlink-breaks-coturn-configuration/70166

    Was zum Testen die Tage....

  • Forgejo Installation mit Podman Quadlet auf Hetzner VM

    Podman forgejo podman quadlet linux
    2
    0 Stimmen
    2 Beiträge
    204 Aufrufe
    FrankMF
    Schauen wir uns mal an, wie man die Container aktuell hält. In der postgres.container steht das hier (als Beispiel) [Container] Image=docker.io/library/postgres:17 AutoUpdate=registry Das AutoUpdate=registry ist die Voraussetzung, dass der Container aktualisiert werden darf. Mit diesem Befehl kann man sich anschauen, wie der Stand der DInge ist. root@debian-4gb-nbg1-2-forgejo:~# podman auto-update --dry-run UNIT CONTAINER IMAGE POLICY UPDATED forgejo-pod.service 6486189fb10c (postgres) docker.io/library/postgres:17 registry false forgejo-pod.service 7d5627e2d434 (forgejo) codeberg.org/forgejo/forgejo:11.0.1 registry false forgejo-pod.service 7fb26d4f8b58 (nginx) docker.io/library/nginx:latest registry false Podman hat aber standardmäßig einen systemd Dienst, der sich darum kümmert root@forgejo:/etc/containers/systemd# systemctl status podman-auto-update.service ○ podman-auto-update.service - Podman auto-update service Loaded: loaded (/usr/lib/systemd/system/podman-auto-update.service; enabled; preset: enabled) Active: inactive (dead) since Mon 2025-06-09 00:02:57 UTC; 12h ago Invocation: a098f0054b254a0888ee789200ac9507 TriggeredBy: ● podman-auto-update.timer Docs: man:podman-auto-update(1) Process: 68939 ExecStart=/usr/bin/podman auto-update (code=exited, status=0/SUCCESS) Process: 68947 ExecStartPost=/usr/bin/podman image prune -f (code=exited, status=0/SUCCESS) Main PID: 68939 (code=exited, status=0/SUCCESS) Mem peak: 14.4M CPU: 292ms Jun 09 00:02:55 forgejo systemd[1]: Starting podman-auto-update.service - Podman auto-update service... Jun 09 00:02:55 forgejo podman[68939]: 2025-06-09 00:02:55.368941 +0000 UTC m=+0.059687227 system auto-update Jun 09 00:02:57 forgejo podman[68939]: UNIT CONTAINER IMAGE POLICY UPDATED Jun 09 00:02:57 forgejo podman[68939]: forgejo-pod.service 6486189fb10c (postgres) docker.io/library/postgres:17 registry false Jun 09 00:02:57 forgejo podman[68939]: forgejo-pod.service 7d5627e2d434 (forgejo) codeberg.org/forgejo/forgejo:11.0.1 registry false Jun 09 00:02:57 forgejo podman[68939]: forgejo-pod.service f2e9eee72017 (nginx) docker.io/library/nginx:latest registry false Jun 09 00:02:57 forgejo systemd[1]: podman-auto-update.service: Deactivated successfully. Jun 09 00:02:57 forgejo systemd[1]: Finished podman-auto-update.service - Podman auto-update service. postgres Ok, die Container sollten automatisch aktualisiert werden. docker.io/library/postgres:17 Die Postgres DB ist auf die Version 17 festgezurrt. Aktuell ist root@forgejo:/etc/containers/systemd# podman exec postgres postgres --version postgres (PostgreSQL) 17.5 (Debian 17.5-1.pgdg120+1) Eine Version 17.6 wird jetzt automatisch installiert, eine Version 18 aber nicht. nginx docker.io/library/nginx:latest NGINX zieht sich also immer die letzte "latest" Version, die zur Verfügung gestellt wird. root@forgejo:/etc/containers/systemd# podman exec nginx nginx -v nginx version: nginx/1.27.5 Gerade mal gecheckt, 1.27.5 ist die letzte Mainline Version. Also sind wir aktuell. forgejo Der Eintrag codeberg.org/forgejo/forgejo:11.0.1 aktuelle Version, die installiert ist. root@forgejo:/etc/containers/systemd# podman exec forgejo forgejo -v Forgejo version 11.0.1+gitea-1.22.0 (release name 11.0.1) built with GNU Make 4.4.1, go1.24.2 : bindata, timetzdata, sqlite, sqlite_unlock_notify Ok, wir sind auf Version 11.0.1 Wenn jetzt die Version 11.0.2 herauskommt, wird diese nicht installiert, da wir im forgejo.container folgendes stehen haben. [Container] Image=codeberg.org/forgejo/forgejo:11.0.1 Das ist aber erst mal nicht so schlimm, ich lese da mit und bekomme das mit. Das mache ich auch lieber von Hand, dann kann ich besser sehen wo es klemmt
  • OpenCloud - Docker Compose local

    Verschoben OpenCloud opencloud linux
    3
    1
    0 Stimmen
    3 Beiträge
    690 Aufrufe
    FrankMF
    Noch was Wichtiges. Die Docker Installation nutzt folgende config. In meinem Beispiel findet man sie unter /home/frank/opencloud/deployments/examples/opencloud_full Darin liegt ein .env ## Basic Settings ## # Define the docker compose log driver used. # Defaults to local LOG_DRIVER= # If you're on an internet facing server, comment out following line. # It skips certificate validation for various parts of OpenCloud and is # needed when self signed certificates are used. INSECURE=true ## Traefik Settings ## # Note: Traefik is always enabled and can't be disabled. # Serve Traefik dashboard. # Defaults to "false". TRAEFIK_DASHBOARD= # Domain of Traefik, where you can find the dashboard. # Defaults to "traefik.opencloud.test" TRAEFIK_DOMAIN= # Basic authentication for the traefik dashboard. # Defaults to user "admin" and password "admin" (written as: "admin:$2y$05$KDHu3xq92SPaO3G8Ybkc7edd51pPLJcG1nWk3lmlrIdANQ/B6r5pq"). # To create user:password pair, it's possible to use this command: # echo $(htpasswd -nB user) | sed -e s/\\$/\\$\\$/g TRAEFIK_BASIC_AUTH_USERS= # Email address for obtaining LetsEncrypt certificates. # Needs only be changed if this is a public facing server. TRAEFIK_ACME_MAIL= # Set to the following for testing to check the certificate process: # "https://acme-staging-v02.api.letsencrypt.org/directory" # With staging configured, there will be an SSL error in the browser. # When certificates are displayed and are emitted by # "Fake LE Intermediate X1", # the process went well and the envvar can be reset to empty to get valid certificates. TRAEFIK_ACME_CASERVER= [....gekürzt....] Man kann dort etwas ändern und mittels docker compose up -d alles aktualisieren. Radicale OpenCloud nutzt im Moment folgendes https://radicale.org/v3.html als Backend Server für Kalender & Kontakte. Jemand hat mir dann erklärt, wie das so funktioniert. Danach hatte es dann klick gemacht. https://fosstodon.org/@h4kamp/114562514701351170 In der config findet man zum Beispiel die Konfiguration für radicale (Kalender- und Kontakte-App) Das ist nur eine rudimentäre Ablage, wird gesteuert über Clienten, z.B. die Thunderbird Kalender Funktion. ### Radicale Setting ### # Radicale is a small open-source CalDAV (calendars, to-do lists) and CardDAV (contacts) server. # When enabled OpenCloud is configured as a reverse proxy for Radicale, providing all authenticated # OpenCloud users access to a Personal Calendar and Addressbook RADICALE=:radicale.yml # Docker image to use for the Radicale Container #RADICALE_DOCKER_IMAGE=opencloudeu/radicale # Docker tag to pull for the Radicale Container #RADICALE_DOCKER_TAG=latest # Define the storage location for the Radicale data. Set the path to a local path. # Ensure that the configuration and data directories are owned by the user and group with ID 1000:1000. # This matches the default user inside the container and avoids permission issues when accessing files. # Leaving it default stores data in docker internal volumes. #RADICALE_DATA_DIR=/your/local/radicale/data In einer Standard Installation ist das auskommentiert. RADICALE=:radicale.yml Danach ein docker compose up -d und Eure Kalendereinträge (extern auf einem Clienten verwaltet) werden in der OpenCloud gesichert.
  • Pycharm & Docker

    Verschoben Linux pycharm docker linux
    1
    4
    0 Stimmen
    1 Beiträge
    334 Aufrufe
    Niemand hat geantwortet
  • LMDE Beta

    Linux lmde linux
    1
    1
    0 Stimmen
    1 Beiträge
    248 Aufrufe
    Niemand hat geantwortet
  • Kopia 0.7.x released

    Kopia kopia linux
    1
    0 Stimmen
    1 Beiträge
    254 Aufrufe
    Niemand hat geantwortet
  • ReactPHP auf einem ROCKPro64 testen

    Linux reactphp linux composer
    1
    1
    0 Stimmen
    1 Beiträge
    220 Aufrufe
    Niemand hat geantwortet
  • Wenn dir der Redis-Server flöten geht....

    Verschoben Redis linux redis
    3
    0 Stimmen
    3 Beiträge
    686 Aufrufe
    FrankMF
    So, nach einer kleinen Pause und ein wenig nachdenken ist mir doch noch was eingefallen Backports! Man so einfach! nano /etc/apt/sources.list Das folgende eintragen. # backports deb http://deb.debian.org/debian stretch-backports main Danach ein apt update Und dann schauen wir uns mal die Version an.... apt -t stretch-backports search redis-server Sorting... Done Full Text Search... Done golang-github-stvp-tempredis-dev/stretch-backports 0.0~git20160122.0.83f7aae-1~bpo9+1 all Go package to start and stop temporary redis-server processes libtest-redisserver-perl/oldstable,oldstable 0.20-1 all redis-server runner for tests python-hiredis/oldstable,oldstable 0.2.0-1+b2 amd64 redis protocol reader for Python 2.X using hiredis python3-hiredis/oldstable,oldstable 0.2.0-1+b2 amd64 redis protocol reader for Python using hiredis redis/stretch-backports 5:5.0.3-3~bpo9+2 all Persistent key-value database with network interface (metapackage) redis-server/stretch-backports 5:5.0.3-3~bpo9+2 amd64 [residual-config] Persistent key-value database with network interface Und die habe ich gestern Abend gebaut. 127.0.0.1:6379> INFO # Server redis_version:5.0.5 Ok, das schmerzt jetzt
  • Raid1 - Platte verschwunden!?

    Verschoben Linux linux
    1
    1
    1 Stimmen
    1 Beiträge
    465 Aufrufe
    Niemand hat geantwortet