JitsiMeet für Synology

[OliverJ]

Hallo, das von TosoBoso bereitgestellte Jitsi-Paket ist für die Dockerinstallation vorgesehen. Da es allerdings seit einiger Zeit nicht weiterentwickelt wurde kann ich leider nichts sagen, ob es sich derzeit fehlerfrei installieren lässt. Ein Versuch ist es aber sicher wert.

 

[geimist]

Ich schätze TosoBosos Bemühungen dahingehend sehr, aber leider lief Jitsi damit bei mir nie stabil. Ich hatte es dann nochmal mit Ubuntu-Server in einer VM probiert, was wesentlich schmerzfreier war. Dazu noch ein Updatescript für die nötigen Modifikationen und gut war.

(Grundsätzlich vermisse ich noch eine Konfigurationsoberfläche, wo man etwas bequemer einiges anpassen könnte).

 

[DIY]

Hallo zusammen

Hat jemand schon auf DSM 7.* Jitsi auf dem DSM Docker (Web Oberfläche) zum laufen gebracht, bzw hat eine Anleitung dafür?

Besten Dank

Moin,

selbstverständlich kann händisch eine aktuelle lauffähige Jitsi Version aufsetzt werden,
bei mir unter vDSM 7.1 U4 läuft die Version 'stable-7882'.

Keine Raketentechnik, allerdings ist ein schmerzfreier Umgang mit einem Editor zwecks ein paar Anpassungen erforderlich - das geht nix mit klicki bunti.

Falls da wirklich Bedarf besteht könnte ich eine Kurzfasssung beisteuern.

 

[nobody23]

Gerne!
Besten Dank!

 

[DIY]

Ganzkurzfassung:

a) Download der Images jitsi stable-7882 für web / jvb / jifico / prosody per Docker Obefläche

b) Download der Einzeldateien von https://github.com/jitsi/docker-jitsi-meet

- env.example
- gen-passwords.sh
- docker-compose.yml

und Ablage beipielsweise im selbst erstellten Verzeichnis 'jitsi-meet-config',
sichtbarer Pfad im DSM per Filestation wäre hier /docker/jitsi-meet-config - voller Pfad allerdings /volume1/docker/jitsi-meet-config (merken!)

c) Erzeugen aller Unterverzeichnisse beipielsweise per Aufgabenplaner
mkdir -p /volume1/docker/jitsi-meet-config/{web,web/crontabs,transcripts,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb,jigasi,jibri}

d) Editieren der docker-compose.yml
Gegenüber dem Original geändert:
-# Frontend
web:
image: jitsi/web:${JITSI_IMAGE_VERSION:-stable} (-stable anstatt -unstable)
volumes:
- ${CONFIG}/web:/config
- ${CONFIG}/web/crontabs:/var/spool/cron/crontabs
- ${CONFIG}/transcripts:/usr/share/jitsi-meet/transcripts ( ':Z' jeweils entfernt)

-# XMPP server
prosody:
image: jitsi/prosody:${JITSI_IMAGE_VERSION:-stable} (-stable anstatt -unstable)
volumes:
- ${CONFIG}/prosody/config:/config
- ${CONFIG}/prosody/prosody-plugins-custom:/prosody-plugins-custom (':Z' jeweils entfernt)

-# Focus component
jicofo:
image: jitsi/jicofo:${JITSI_IMAGE_VERSION:-stable} (-stable anstatt -unstable)
volumes:
- ${CONFIG}/jicofo:/config (':Z' jeweils entfernt)
-# Video bridge
jvb:
image: jitsi/jvb:${JITSI_IMAGE_VERSION:-stable} (-stable anstatt -unstable)
restart: ${RESTART_POLICY:-unless-stopped}
ports:
- '${JVB_PORT:-10000}:${JVB_PORT:-10000}/udp'
- '127.0.0.1:${JVB_COLIBRI_PORT:-8084}:8080' (8084 anstatt 8080)
volumes:
- ${CONFIG}/jvb:/config (':Z' jeweils entfernt)




e) Editieren von env.example (nach dem Editieren das Umbenennen der env.example in .env nicht vergessen - wichtig (!))

# Directory where all configuration will be stored
CONFIG=/volume1/docker/jitsi-meet-config (hier stehr der absolute Pfad zum config-Verzeichnis)
# Exposed HTTP port
HTTP_PORT=8082 (nach eigener Wahl, aber bitte merken)
# Exposed HTTPS port
HTTPS_PORT=8443 (nach eigener Wahl, aber bitte merken)
# System time zone
TZ=CET (die Zeitzone Mitteleuropa)
# Public URL for the web service (required)
PUBLIC_URL=https://subdomain.domain.tld (nach eigener Wahl, bitte für den Reverseproxy merken)
# Media IP addresses to advertise by the JVB
# This setting deprecates DOCKER_HOST_ADDRESS, and supports a comma separated list of IPs
# See the "Running behind NAT or on a LAN environment" section in the Handbook:
# https://jitsi.github.io/handbook/do...er#running-behind-nat-or-on-a-lan-environment
JVB_ADVERTISE_IPS=192.168.xxx.xxx (IPv4 der Syno im Heimnetz / NAT)
# Authentication configuration (see handbook for details)
# Enable authentication
ENABLE_AUTH=1
# Enable guest access
ENABLE_GUESTS=1
# Select authentication type: internal, jwt, ldap or matrix
AUTH_TYPE=internal
# Jitsi image version (useful for local development)
JITSI_IMAGE_VERSION=stable-7882


sonstige Einstellungen, z.B.
ENABLE_WELCOME_PAGE=0



f) Ausführen von gen-passwards.sh beipielsweise per Aufgabenplaner
bash /volume1/docker/jitsi-meet-config/gen-passwords.sh

g) Ausführen von docker-compose up -d beipielsweise per Aufgabenplaner (als root)
cd /volume1/docker/jitsi-meet-config/
docker-compose up -d

Normalerweise wurden jetzt alle Container und das Bidge Netzwerk angelegt und gestartet.




h) Dem Terminal des prosody Containers einen Besuch abstatten, Terminal mit 'bash' und Auführen
prosodyctl --config /config/prosody.cfg.lua register Benutzername meet.jitsi Passwort
wobei der Benutzername und das Passwort natürlich passend gewählt werden sollten

Am Ende noch Einrichten:
Reverseproxy und Letsencrypt-SSL (https://subdomain.domain.tld -> 192.168.xxx.xxx:8443) nebst den passenden Einstellungen (wenn unklar - Suche hier im Thread empfohlen)

Aufruf über https://subdomain.domain.tld

Falls ihr oder ich nix vergessen habt ... Läuft.





PS
Anstatt des Aufgabenplaners kann auch ein root-Terminal verwendet weden, ist m.E. nach günstiger da hier evtl. aufkommemde Fehlermeldungen direkt ausgewürfelt werde.

 

[OliverJ]

Danke für die ausführliche Erklärung. Dann werde ich auch mal mein Glück versuchen. Dass TosoBosos Paket nicht "rund" lief, kann ich eigentlich so nicht betätigen. Und leider ist es ja auch nicht seine Schuld, wenn sich da intern bei Jitsi immer mal wieder was ändert und er dann ständig wieder sein Paket anpassen muss. Ich kann nachvollziehen, dass es irgendwann nervt und ich verstehe auch nicht, weshalb da bei Jitsi-Updates ganze Pfade geändert werden müssen etc. Ein Update soll doch in erster Linie Verbesserungen bringen, die Stabilität verbessern und nicht alles Mögliche über den Haufen schmeißen. Dann musste TosoBoso ja auch nochmals von Grund auf neu programmieren, um Jitsi unter DSM7 lauffähig zu bekommen. So hatte er sich das vermutlich nicht vorgestellt und war wohl davon ausgegangen, dass sich nur marginal Dinge ändern, die dann ohne allzu großen Aufwand in seinem Paket geändert werden können. Es sieht wohl ganz danach aus, dass es war mit dem Paket. Aber ganz habe ich die Hoffnung noch nicht aufgegeben, dass es doch irgendwann ein Update gibt. Oder aber jemand Anderes irgendwann das Projekt weiterführt, so etwas hat es ja bei anderer Software auch schon häufig gegeben.
Aber jetzt versuche ich mein Glück mal auf diese Weise. Nochmals Danke für die ausführliche Anleitung.

 

[kyreon]

Also ich muss sagen, super Anleitung. Hat mit dem ersten Versuch geklappt! Besten Dank DIY.

 

[OliverJ]

Mal eine kurze Frage in die Runde: Es wurde ja schon einmal darüber diskutiert, dass es im Falle einer Trennung des Routers zu Verbindungsabbrüchen bei Jitsi kommen kann, weil die IP-Adresse nicht mehr stimmt. Dies lässt sich entsprechend mit einem Jitsi-Cli-Befehl korrigieren. Den gleichen Effekt bzw. eine Angleichung der IP-Adresse müsste sich doch auch erreichen lassen, wenn ich einfach die Docker-Container anhalte und neu starte. Oder liege ich da falsch?

Andere Frage: Es gibt ja auch die Möglichkeit, Jitsi auf der Syno in einer virtuellen Maschine laufen zu lassen. Gibt es da eigentlich Unterschiede hinsichtlich der Performance? Verbraucht z.B. die Docker-Lösung mehr Systemressourcen als eine VM oder umgekehrt?

 

[geimist]

Es gibt ja auch die Möglichkeit, Jitsi auf der Syno in einer virtuellen Maschine laufen zu lassen. Gibt es da eigentlich Unterschiede hinsichtlich der Performance?

Im Leerlauf verbraucht die VM auf meiner DS920+ unter 1% Host-CPU (meist 0,7%). Zugewiesen habe ich 2 Kerne und 2 GB RAM.

Den gleichen Effekt bzw. eine Angleichung der IP-Adresse müsste sich doch auch erreichen lassen, wenn ich einfach die Docker-Container anhalte und neu starte.

So mache ich das (in der VM). Dazu läuft permanent ein kleines Überwachungsskript, welches jede Minute die öffentliche IP mit dem letzten Wert vergleicht.

#!/bin/bash
# Aufrufe:
# ./jitsi_check_public_ip.sh start &
# ./jitsi_check_public_ip.sh stop

# wait for system startup:
sleep 60

own_path=${0%/*}

start() {
    echo "[$(date +%Y-%m-%d_%H-%M-%S)] start monitoring ..." >> "${own_path}/jitsi_check_public_ip.log"

    current_ip=$(curl -s ifconfig.me)

    while true; do
        new_ip=$(curl -s ifconfig.me)

        sleep 60

        if [ "$current_ip" != "$new_ip" ]; then
            echo "[$(date +%Y-%m-%d_%H-%M-%S)] dedected ip change [$current_ip ➜ $new_ip] - restarting services ..." >> "${own_path}/jitsi_check_public_ip.log"
            service prosody restart
            service jicofo restart
            service jitsi-videobridge2 restart
            service nginx restart

            current_ip=$new_ip
        fi
    done
}

stop() {
    echo "latest log:"
    cat "${own_path}/jitsi_check_public_ip.log" | tail -n10
    kill $(ps aux | grep -v "grep" | grep -E  "/bin/bash .*/jitsi_check_public_ip" | awk -F' ' '{print $2}')
}


if [ "$1" = start ]; then
    echo "start monitoring ..."
    start
elif [ "$1" = stop ]; then
    echo "stop monitoring ..."
    stop
fi

 

[OliverJ]

Danke für die prompte Antwort. Aktuell läuft bei mir immer noch die Installation über TosoBosos Paket, nur leider lässt sich auf der GUI nichts mehr anstellen, da diese leer bleibt. Die Grund-Dockerinstallation ist damit ja dann eigentlich gemacht, werde dann mal den Rest der Anleitung in Angriff nehmen, um die Docker-Installation künftig ohne Zuhilfenahme der GUI von TosoBosos Paket betreiben zu können. Parallel werde ich es wohl tatsächlich auch mal mit einer VM versuchen und mal sehen, was mir mehr zusagt. Danke für die vielen Tipps und Anleitungen.
Beißt sich eine minütliche Abfrage der IP nicht im laufenden Betrieb einer Videokonferenz?

 

[OliverJ]

Ein Erfahrungsbericht zum Thema Jitsi-Docker:
Neulich hat sich eine meiner WD NAS-Festplatten nach gerade mal 2 Jahren verabschiedet. Schon länger war mir aufgefallen, dass meine 720+ permanent auf die Festplatten zugreift und fast nie zur Ruhe kommt, davon, dass sie jemals in den Energiesparmodus geht, ganz zu schweigen. Wie schon einmal erwähnt, habe ich noch die Jitsi-Installation aus TosoBosos Paket laufen. Nun habe ich einmal die Jitsi-Container angehalten und siehe da: Kein permanentes Rattern der Platten mehr und die Syno ist in den Ruhezustand gegeangen und schlummert brav vor sich hin. Nun bin ich doch etwas überrascht, dass Jitsi als Dockerinstallation bzw. wohl eauch andere Programme die unter Docker laufen permanent das System beanspruchen und es nie zur Ruhe kommen lassen. Ich habe mir nun vorgenommen, die Container nur noch dann zu starten, wenn ich tatsächlich eine Videokonferenz abhalte und ansonsten ausgeschaltet zu lassen.

 

[OliverJ]

Heute bin ich endlich einmal dazu gekommen, die Kurzanleitung von DIY in Angriff zu nehmen und will an dieser Stelle nochmals ein ganz großes Dankeschön aussprechen: Dank deiner wirklich einfach nachvollziehenden Anleitung habe ich alles hinbekommen. TosoBosos Paket habe ich nun deinstalliert, es war bis jetzt im Einsatz, obwohl Oberflächenzugriff und Updates nicht mehr möglich waren. Jitsi selbst lief, nur eben in einer mittlerweile recht alten Version. Nun habe ich auch endlich die neueste Version installiert. Eine Frage hätte ich aber noch: Wie verhält es sich mit Updates? Werden diese wie in TosoBosos Paket angezeigt und automatisch geupdatet? Oder muss dazu immer mal wieder ausgeführt bzw. im Taskplaner eingetragen werden?

 

[OliverJ]

Immer mal wieder "docker-compose up -d" ausgeführt bzw. im Taskplaner eingetragen werden, meinte ich.

 

[DIY]

Moin,
die Lösung ist/war halt 'quick & dirty', ich bin überrascht dass das immer noch probemlos(?) klappt.

Im Falle eines Updates lösche ich alle entprechenden Dateien und Verzeichnisse und lade/editiere die betreffenden Dateien (...*env ...*yml) für die erneute Ausführung mittels Taskmanager 'neu'.

Für ein automatisierte bzw. scriptbasierte Lösung oder ein Paket fehlen mir leider die Kenntnisse -Sorry.

 

[Monacum]

Aber warum alles löschen? Der Weg über

docker stop containername
cd /volume1/docker/pfad/zum/container
docker-compose pull
docker-compose up -d

ist der grundsätzlich unterstützte, unter Verwendung des Aufgabenplaners auch regelmäßig möglich. Oder man verwendet Watchtower. Das Löschen der ganzen Daten halte ich erstmal für unnötig, wenn es nicht zu Problemen gekommen ist.

 

[DIY]

Danke




Beispielsweise im Taskmanager als 'root'

docker stop jitsi-meet-config_web_1
docker stop jitsi-meet-config_jvb_1
docker stop jitsi-meet-config_prosody_1
docker stop jitsi-meet-config_jicofo_1

cd /volume1/docker/jitsi-meet-config
docker-compose pull
docker-compose up -d


PS
In der .env (aus dem Post #365) habe ich die Zeile zu
# JITSI_IMAGE_VERSION=stable-7882
geändert (auskommentiert)

 

[DIY]

Weil grad 'Tag der Arbeit' ist ...

was bleibt ist der handische bzw. manuelle Check
(auf Github ' jitsi/docker-jitsi-meet' -> Tags -> aktuellste 'stable - xxxx')
auf die aktualisierten Version von
- docker-compose.yml
- example.env aka .env
bezüglich Änderungen gegenüber den editierten Dateien VOR dem Update - ggf muss man diese neu editieren und einpflegen.

 

[Monacum]

Vielleicht verstehe ich dich auch falsch, aber man/frau muss die yml und env nicht „aktualisieren“; das einzige, was man da eventuell anpassen muss, ist der Versionstag, also :latest oder eben irgendetwas anderes.

 

[DIY]

Könnte sein dass ich daneben liege bzw mein Wissen nicht ausreicht,
aber wie siehts aus falls im Vergleich der docker-compose.yml der vorherig installierten Version mit der demnächstigen aktuellen Version
Änderungen vorliegen,
konkret im 'enviroment' Block - werden die automatisch gemerged?

 

[OliverJ]

Ich hatte ja vor einiger Zeit geschrieben, dass der laufende Betrieb der Dockercontainer bei meiner Syno ständige Unruhe und permanente Festplattenzugriffe verursachten. Scheint wohl ein Problem mit der veralteten Version von TosoBosos Paket gewesen zu sein, irgendetwas lief da im Hintergrund wohl nicht mehr ganz rund. Jetzt ist jedenfalls Ruhe. In letzter Zeit häuften sich auch Probleme, dass manche Teilnehmer ihr Mikro nicht zuschalten konnten, hauptsächlich, wenn sie sich mit ihrem Handy eingeloggt hatten. Konnte noch nicht testen, ob dieses Problem nun auch behoben ist, aber zumindest verliefen bis jetzt mal generell sämtliche Testläufe erfolgreich. Da das Problem aber gelöst war, wenn wir einfach auf eine andere Jitsiinstanz gingen nehme ich auch mal an, dass es an der veralteten Jitsiversion im Zusammenspiel mit dem ebenfalls veralteten Paket von TosoBoso hing.