JitsiMeet für Synology

[OliverJ]

Davon abgesehen hoffe ich, dass mit TosoBoso alles okay ist. Laut seines Profils war er zuletzt letztes Jahr im Juli hier eingeloggt und eigentlich ja immer sehr aktiv.

 

[Monacum]

Änderungen vorliegen

Da liegen keine Änderungen vor. Deine yml/env ist deine yml/env. Was passieren kann ist, dass es neue Funktionen mit neuen Variablen gibt – die kannst du dann in deine env einarbeiten oder aber auch nicht. Man muss aber nicht zwingend, so lange die Entwickler eines Containers das nicht explizit verlangen, keine Anpassungen an yml/env vornehmen oder gar immer eine neue kopieren.

Es kann, wie bei ioBroker, sein, dass man nicht auf latest ist, sondern auf einer spezifischen Version, dann muss aber auch in der yml nur diese Versionsnummer angepasst werden und nicht die ganze Datei.

 

[42HAL]

Moin zusammen,

gibt es aktuelle Erfahrungen bezüglich einer letzten stabilen Version?
Ich wollte meine Umgebung auf den letzten Stand bringen und wäre für Hinweise dankbar.

Grüße

 

[OliverJ]

Hallo 42HAL, ich bringe mit "docker-compose up -d" Jitsi immer auf den aktuellen Stand wenn ich sehe, dass es eine neuere Version gibt. Läuft alles einwandfrei, lediglich Benutzername und Kennwort müssen nach dem Update neu gesetzt werden.

 

[OliverJ]

EDIT: Seit der neuesten Version müssen Benutzer und Kennwort offenbar nicht mehr neu gesetzt werden sondern werden übernommen.

 

[42HAL]

Hallo zusammen,

ich hänge nach einer Neuinstallation Jistis-Projekt in Container Manager an folgenden Problem:

alle Einzelcontainer up & running

wenn ich versuche die Seite mit dem DNS-Namen aufzurufen, bekomme ich einen leeren, schwarzen Bildschirm
in den logs des Web-Containers steht, dass Berechtigungen fehlen:
2024/11/01 09:43:31,stderr,"2024/11/01 09:43:31 [error] 287#287: *1364 open() \"/config/interface_config.js\" failed (13: Permission denied), client: 172.23.0.1, server: _, request: \"GET / HTTP/1.1\", subrequest: \"/interface_config.js\", host: \"DNS-Name\"
Wer oder was (user / IP) benötigt welche Berechtigungen?

Hat jemand eine Idee?

Grüße

 

[OliverJ]

Hast du einen Reverse Proxy eingerichtet?

 

[42HAL]

Ja, der Reverse Proxy ist eingerichtet.
Die Webseite kann auch ohne Fehler aufgerufen werden, es wird jedoch nur eine "schwarze" Seite angezeigt (weil vermutlich nicht auf das config-Verzeichnis zugegriffen werden kann)...

 

[OliverJ]

ist der Ordner vielleicht schreibgeschützt?

 

[DIY]

Gerade eben aktualisiert auf 'stable-9823' - alles läuft wie erwartet.

Allerdings ist in der aktuellen docker-compose.yml ein Unterordner für 'web' dazugekommen
welchen ich händisch im 'jitsi-meet-config' Verzeichnis der DS' unter web hinzugefügt habe - vielleicht liegts daran

version: '3.5'

services:

# Frontend
web:
image: jitsi/web:${JITSI_IMAGE_VERSION:-stable}
restart: ${RESTART_POLICY:-unless-stopped}
volumes:
- ${CONFIG}/web:/config
- ${CONFIG}/web/crontabs:/var/spool/cron/crontabs
- ${CONFIG}/transcripts:/usr/share/jitsi-meet/transcripts
- ${CONFIG}/web/load-test:/usr/share/jitsi-meet/load-test

...
...

bei mir also:
volume1/docker/jitsi-meet-config/web/load-test/

wie bekannt:
der Pfad hängt von Angabe in der jeweiligen .env ab, bei mir hier also
CONFIG=/volume1/docker/jitsi-meet-config

 

[42HAL]

Ich habe den Grund gefunden!
Die Lösung benötigt für "others" offensichtlicht zwingend rx-Rechte auf das "web"-Verzeichnis und die darunterliegenden Dateien und Ordnern, nun läuft es.

Ich habe nichts Dementsprechendes bei meinen Recherchen gefunden, falls jemand nähere Informationen hat (um ggfs. die Rechte auf einzelenn Dateien bzw. Verzeichnisse begrenzen zu können, wäre ich dankbar!

Danke für die Unterstützung und Anregungen!

 

[DIY]

Interessant, bei meinem Docker-Jitsi sehen die Berechtigung für 'web' im DSM so aus:

 

[42HAL]

administrators haben bei mir derzeit nur Lese-Berechtigungen, kann sein, dass ich heier etwas geändert habe.
Was ist denn ContainerManager für ein Objekt / Symbol, das finder ich bei mir nicht bzw. könnte die Zugriffsrechte auch nicht addieren?

 

[DIY]

Das ist wohl der Container Manager des Docker-DSM-Pakets, wird augenscheinlich automatisch angelegt.

 

[42HAL]

Da war auch mein Gedanke, jedoch:
a.) er erscheint nicht in der RechteVergabe - muss er vielleicht auch nicht? noch in Users & Groups
b.) woher sollte "er denn wissen", dass "er" nur nun Rechte auf das besagte Verzeichnis hat, die Verzeichnisstruktur wird ja nicht durch eine YAML - oder sonstige Datei erzeugt, sondern die habe ich manuell angelegt (in der damaligen Anleitung per cron-job)

 

[thool]

Hallo zusammen,
Ich verwende Synology DS220+ und versuche gerade Jitsi-Meet zu installieren.
An dieser Stelle vielen Dank an @DIY für die Kurzanleitung.
Leider breche ich mir gerade die Finger beim Versuch Jitsi-Meet danach einzurichten.
Docker-compose war nach einigen Fehlversuchen endlich erfolgreich, aber der Web-Container läuft nicht:

Die Fehlermeldung lautet:
Error response from daemon: driver failed programming external connectivity on endpoint jitsi-meet-config-web-1 (ad146dbe463fb029437b217191a5df0fd880bfd65f65b973516d9791e3ea0c6d): Error starting userland proxy: listen tcp4 0.0.0.0:8443: bind: address already in use
meine .env Variablen lauten:
HTTP: 8000
HTTPS: 8443
PUBLIC_URL=https://meet.<Synology DDNS hostname>:${HTTPS_PORT}

Mir ist aufgefallen, dass in der docker-compose.yml folgendes Ports festgelegt sind:
# Frontend
web:
'${HTTP_PORT}:80'
'${HTTPS_PORT}:443'
Muss man diese Ports auch anpassen? In der DIY Kurzanleitung war davon nicht die Rede.

Den Reverseproxy habe ich mit der PUBLIC_URL und den o.g. Ports eingerichtet, wie weiter oben in diesem Thread beschrieben.
Bin leider überhaupt nicht fit in diesen Netzwerkthemen und finde alles sehr verwirrend und schwer nachvollziehbar.

Ist es überhaupt möglich, den Synology DDNS hostname in dieser Weise mit einer "meet"-Subdomain zu erweitern?
Der Aufrauf dieser Domain mit dem HTTPS port 8443 funktioniert nicht (Seite kann nicht gefunden werden.
Der Aufruf mit meinem Synology Standard HTTPS port funktioniert in der Weise, dass die Synology Login Seite anstatt der Jitsi-Meet Seite erscheint.

Ich steh im Wald und wäre euch dankbar, wenn ihr mir den Weg heraus weisen könntet.
Vielen Dank.

 

[thool]

Hallo nochmal,
Der Vollständigkeit halber auf meiner DS220+ läuft DSM 7.2.2-72806 Update 3.
Ich habe mir inzwischen einen weiteren DDNS mit einer neuen Domain erstellt, den Reverseproxy angepasst, ein neues LetEncrypt Zertifiakat erstellt und die .env Datei entsprechend angepasst.
Wobei ich die Ports bis jetzt nicht geändert habe (HTTP: 8000, HTTPS:8443).
Anschliessend habe ich zum Aktualisieren nochmals

docker-compose up -d

laufen lassen mit folgendem Ergebnis:

Container jitsi-meet-config-prosody-1 Recreate
Container jitsi-meet-config-prosody-1 Recreated
Container jitsi-meet-config-jvb-1 Recreate
Container jitsi-meet-config-jicofo-1 Recreate
Container jitsi-meet-config-jicofo-1 Recreated
Container jitsi-meet-config-jvb-1 Recreated
Container jitsi-meet-config-web-1 Recreate
Container jitsi-meet-config-web-1 Recreated
Container jitsi-meet-config-prosody-1 Starting
Container jitsi-meet-config-prosody-1 Started
Container jitsi-meet-config-jicofo-1 Starting
Container jitsi-meet-config-jvb-1 Starting
Container jitsi-meet-config-jicofo-1 Started
Container jitsi-meet-config-jvb-1 Started
Container jitsi-meet-config-web-1 Starting
Error response from daemon: driver failed programming external connectivity on endpoint jitsi-meet-config-web-1 (cb416626554c93b47a86b31f11782ea6baf8e03f55b16e614ae65f676ee96674): Error starting userland proxy: listen tcp4 0.0.0.0:8443: bind: address already in use

Also am Ende derselbe Fehler wie vorher. Welche Adresse ist hier genau gemeint und wie kann ich das korrigieren?
Beim Aufruf der PUBLIC_URL=https://<meinedomain>.<dyndnsservice>.net:8443 kommt folgender Fehler:

Was kann ich jetzt noch tun?

 

[DIY]

Moin,
vorweg - ein aktuelles Jitsi habe ich momentan nicht in Betrieb.
auch müsste ich erst selbst die kurze Kurzanleitung nochmals durchsehen.

Es könnte sein dass der Port 8443 schon anderweitig belegt/vergeben ist,
eventuell wäre z.B. die Änderung in 9443 oder 10443 einen Testlauf wert.

Der Reverse-Proxy regelt die Erreichbarkeit per Subdomain über den normal verwendeten https Port , also i.d.R 443
damit ist der Aufruf
aus dem Internet dann:
https://<meinedomain>.<dyndnsservice>.net:443 (oder ohne 443)
aus dem Intranet dann:
https://<interne IP der DS>:8443 (um im Beispiel zu bleiben)

 

[thool]

Hallo und Danke @DIY, Dein Hinweis mit dem Reverseproxy hats gelöst.
Ich habe den Reverseproxy entsprechend angepasst, also mit HTTPS Port 443 (Standard).
Anschliessend die Jitsi-Container gestoppt und dann docker-compose up -d nochmal laufen lassen.
und diesmal ging es ohne Fehler durch - Yippeee!

Jetzt fehlt noch ein Testlauf mit mehreren Teilnehmern
und dann würde ich gerne nochmal alle Einstellungen gegenchecken, ob ich da nicht irgendwelche Schwachstellen eingebaut habe.

Melde mich dann wieder...

 

[thool]

Der Aufruf über die externe Domain funktioniert tatsächlich. Ein Meeting zu starten habe ich noch nicht getestet.
Der Aufruf über die interne Adresse http://192.168.xxx.xxx:8000/ wird allerdings auf diese Fehlerseite umgeleitet:
http://192.168.xxx.xxx:8000/static/recommendedBrowsers.html



Warum funktioniert die Seite in demselben Browser (Firefox) mit HTTPS und mit HTTP nicht???
Chrome leitet auch auf diese Seite weiter.
Stimmt noch etwas mit der Konfiguration nicht?