JitsiMeet für Synology

[DIY]

Zum Vergleich, das Setup meinerseits ist gegenüber dem Standard des Tosoboso-Pakets leicht angepasst:

Container 'jitsi_jvb'
- DOCKER_HOST_ADRESSS (lokale IP der DS anstatt der öffentlichen IP)
- JVB_TCP_HARVESTER_DISABLED (false anstatt true)

Container 'jitsi_prosody'
- AUTH_TYPE (internal anstatt 'auskommentiert')

--> anpassbar in DSM 'Jitsi_Admin' Docker-Environment

Noch vorhanden:
- Eigene Domain per DYNDNS
- Eigenes Zertifikat für die Subdomain per LetsEncrypt und im Paket SYNOPKG_SYNO_CERT_SYNC=1 gesetzt

--> anpassbar in DSM 'Jitsi_Admin' Package-Config


ggf. ausprobieren und ggf. bitte Feedback ... ohne Gewähr - läuft halt hier ganz gut ;-)

 

[DIY]

Im Forum hier ...

https://www.synology-forum.de/threads/hinweise-zu-verwendung-von-jitsi-im-docker.111276/
... finden sich noch Hinweise zu dem Problem von Jitsi und dem Reverse Proxy

 

[flyerbln]

Hallo DIY
ersteinmal Danke für deine Einstellung
Ich habe versucht herauszufinden, was diese Einstellungen bewirken:
Container 'jitsi_prosody'
- AUTH_TYPE (internal anstatt 'auskommentiert')
&
Eigenes Zertifikat für die Subdomain per LetsEncrypt und im Paket SYNOPKG_SYNO_CERT_SYNC=1 gesetzt
Konnte es aber nicht herausfinden.
könntest du kurz sagen, was diese bewirken?
Lieben Dank.
Gruß David

 

[DIY]

Die Erklärung zu:

- SYNOPKG_SYNO_CERT_SYNC=1 ...
... wird am Anfang des Threads erklärt (schlappe 161 Beiträge zuvor ;-))
der 'Haken' kann schon bei der der Installation des Pakets gesetzt/gewählt werden

- AUTH_TYPE ...
... findet sich in der offiziellen Doku (https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-docker#internal-authentication)
warum dies beim Paket auskommentiert ist erschließt sich mir leider nicht




Frohes Neues

Hi, zum Thema Zertifikat mit LetsEncrypt (LE)
Bitte nicht verwirren lassen und NICHT die LE Einstellungen von Jitsi Meet nehmen. Das geht nämlich nicht, da die Synology den HTTP/HTTPS Port 80/443 belegt und eben nicht der Jitsi Container. -Das werde ich in Zukunft im Packet FAQ aufnehmen..
Stattdessen verwendet man das Zertifikat auf der Synology, das per LE erzeugt wurde und in den Container kopiert wird (siehe Pkg-Cfg SYNOPKG_SYNO_CERT_SYNC=1). Konkret wird nach dem Zertifikat auf die Domaine hier im Beispiel meet.mycloud.me gesucht. Zu Empfehlen ist auch die Real-IP des Reverse-Proxy weiter zu leiten, wenn man die echten Zugriffe wissen will (SYNOPKG_X_REALIP_TO_NGINX=1).

Bei Jitsi auf der Synology ist ein SSL Zertifikat im Jitsi Container übrigens nicht zwingend nötig (nur für Power-User, die wie ich ein WAF auf der Firewall haben und dann den Synology Reverse-Proxy nicht nutzen). Solange man ein Zertifikat auf der Synology hat und dann per ReverseProxy den Jitsi-Webcontainer auf 8080 anfährt, siehe Screenshot im Control-Panel, Application-Portal-Reverse-Proxy.

PS: Die neue Version 0.7 ist eingecheckt und sollte im Community Package Hub bald verfügbar sein.
Anhang anzeigen 54780 Anhang anzeigen 54781
-TosoBoso

Hi!
Zunächst mal dickes DANKE Tosoboso für #2. Der hat Jitzi-Meet bei mir zum laufen gebracht.
Dennoch gibt´s div. "Klemmer":
Am Folgetag nach funktionierender Inbetriebnahme stürzt die Konferenz nach ca. 20-30 Sekunden in einer Dauerschleife immer wieder ab:

Anhang anzeigen 54895

So habe ich mich mal über einen längeren Zeitraum immer wieder kurz damit beschäftigt.

Scheint das daran zu liegen, dass die DOCKER_HOST_ADDRESS im Docker-Evironment noch die IP-Adresse vom Vortag beinhaltet? Ist mir jedenfalls aufgefallen.
Nach einem Neustart der Synology wird die IP-Adresse aktualisiert, schmeißt aber die Zugangsdaten des Organisators raus. Diese muss dann per "add-usr <name> <passwort>" neu angelegt werden. Danach funktioniert Jitzi-Meet bis zum nächsten Tag zuverlässig, stabil, einwandfrei und mit 100/40 Mbit/s nahezu latenzfrei auf einer VDSM 6.2.3 mit 2 Kernen und 4GB RAM einer 1619xs+. Ich nutze Version 0.6 aus dem Community-Paketzentrum.

Viele Grüße
Mic777

 

[Formicum]

Hallo, Eru hier,
ich bin auch neu...

Ich habe alle Container am Laufen, reverse proxy eingerichtet. Ich bekomme bei der Verbindung im LAN unter myIP:8080 das gleiche Bild wie flyerbln. (Ihre Verbindung ist getrennt worden)
Gleiches passiert von außen, wenn ich über meine Synology-dynDNS-adresse von außen zugreife. Was für eine URL trage ich eigentlich unter SYNOPKG_MEET_DOMAIN_NAME= ein? Muss diese bereits existieren auf der Synology und irgendwo registriert sein? Bin gerade etwas hilflos.
Edit: Die Zusatzeinstellungen im ReverseProxy habe ich auch schon, bei xxx.synology.me:443 kommt keine Verbindung, Bei http://lokale_IP_der_DS/443 kommt eine nginx Fehler 404 bei https://lokale_IP_der_DS/443 bei http://lokale_IP_der_DS:8080 der disconnect_loop

Danke für jeden Input

Beste Grüße, Eru

 

[no.one]

Hallo zusammen,

ich habe die Tage auch erfolgreich das Paket installiert. Es funktioniert auch alles soweit ganz gut, mit einer Ausnahme:
Die Videoqualität bleibt immer bei 360p anstatt auf HD oder FullHD zu gehen.

Hat jemand eine Vermutung woran das liegen kann, oder an welcher Stelle ich im Jitsi-Admin Tool ich ansetzen kann?

LG no.one

 

[mic777]

Hi !
Habe das gleiche Problem wie Formicum in Beitrag #165.

Bewundernswert ist bei mir, dass die Version vom 16.10.2020 einwandfrei läuft. Wenn ich auf das Release vom 23.12.2020 und das davor via "refresh" update, war´s das. Bezüglich der Ports und ReverseProxy habe ich bereits alles probiert. Das Zertifikat passt auch. Glücklicherweise kann ich per Snapshot auf die alte Version zurück.

Ich muss vielleicht warten, bis es von den Entwicklern einer merkt und warte mal eben, bis eine funktionierende Version gelauncht wird.

So long
Gruß Mic

 

[Formicum]

Hi !
Habe das gleiche Problem wie Formicum in Beitrag #165.

Danke mic777. Das befreit mich von Selbstzweifeln... Ich dachte ich bin zu blöd. Da es ein privates Projekt ist will ich aber überhaupt nicht meckern. Ich hatte nur den Wunsch, eine sichere Konferenz auf eigener Hardware zu machen, jetzt in den Zeiten der Pandemie werden oft selbst in großen Firmen die Datenschutzvorgaben ignoriert und leichtfertig Kundendaten über Teams und Co. verteilt. Das kann ich mir als kleines Unternehmen im Prototypenbereich einfach nicht leisten...
Herzliche Grüße!

-formicum-

 

[geimist]

Glücklicherweise kann ich per Snapshot auf die alte Version zurück.

Wie machst du das?
Die Images liegen doch nicht in einem gemeinsamen Ordner, für den man einen Snapshot anlegen kann

 

[mic777]

Bei mir liegt Jitsi Meet in einer virtuellen DSM auf einer RS1619xs+. Damit kann man innerhalb 10 Sek. auf einen vorherigen Stand zurück.

 

[DIY]

Da hätte ich noch einen Beitrag zum Thema 'Dauerschleife'

Aufruf über
- https://192.168.x.x:8443 -> Dauerschleife
- https://mein.server.beispiel -> Alles OK

Allerdings ist der Wert der Variablen DOCKER_HOST_ADRESS im jitsi_jvb Container
auf die lokale IP der DS gesetzt - also 192.168.x.x - anstatt der öffentlichen IP oder der Docker-Netz IP.

Problem:



Problem gelöst durch:
Hinzufügen der Umgebungsvariable 'XMPP_CROSS_DOMAIN' mit Wert 'true'
im Container von 'prosody'

(im originalen '/etc/jitsi/.env' ist diese auskommentiert und logischerweise im Container dann nicht vorhanden)




Im Ergebnis klappt der Zugriff dann auch mittels der internen IP und nicht nur durch die Subdomain

 

[OliverJ]

Wow, super. Danke für den Tipp. Ich kann gleich auch noch was beisteuern, das dem ein oder anderen vielleicht weiterhelfen könnte. Ich hatte ja immer das Problem, dass bei mehreren Teilnehmern nichts mehr ging. Heute habe ich wohl endlich herausgefunden, was Probleme gemacht hat: Der Browser. Ich verwendete einen Chrome-Fork namens Slimjet, mit dem eigentlich immer alles funktioniert hat. Heute wieder gleiches Problem. Nun habe ich den original Chrome-Browser installiert und verwendet und siehe da - es klappt. Übrigens hatte ich nun auch schon zweimal Teilnehmer die mit Firefox eingeloggt waren, was ebenfalls problemlos funktionierte. Die Kombination Firefox und Jitsi war ja eine zeitlang problembehaftet. Also, auch wenn ein Browser auf Chrome basieren sollte: Bei Problemen mal das Original ausprobieren.
Nachtrag: Dass diverse Browser Problemebereiten können, ist natürlich bekannt und nichts Neues. Ich wollte noch hinzufügen, dass es manchmal klappte, dann wieder nicht, weshalb ich in diesem Fall nicht gleich auf die Idee kam, dass es am Browser liegen könnte. Deshalb meine Erfahrung: Auch, wenn nur mal temporär Probleme auftauchen, was zumindest in meinem Fall dazu führte, die Ursache anderswo zu suchen, kann es am Browser liegen.

 

[DIY]

Moin Zusammen,
die Konfiguration in config.js (Verzeichnis /etc/jitsi/web/) wird bekanntlich bei jedem Containerstart überschrieben, das ist ein nerviges Problemchen.

Im Jitsi-Community-Forum findet sich die Lösung:
-Anlegen einer Datei (Verzeichnis /etc/jitsi/web/)
custom-config.js
-Inhalt (Beispiele)
config.enableWelcomePage = false;
config.requireDisplayName = true;

ausprobiert ...
... die Inhalte werden an die bestehende config.js angehängt und das ständige gepfriemel entfällt.

 

[flyerbln]

Hallo ihr lieben,
ich wollte gerade jitsi auf meiner Synology ds 220+ neu instalieren. Wenn ich das richtig sehe ist das Paket nicht mehr online, kann das sein?

 

[flyerbln]

Hallo noch mal, ich hab eben mal jemanden, der eine Ds 281+ im Einsatz hat gefragt, ob er die Installation vom jitsi Paket mal machen kann. Es stellte sich heraus, dass er auch den Fehler angezeigt bekommt:

"jitsi Meet“ konnte nicht installiert werden
Repository nicht verfügbar https://raw.githubusercontent.com/Jitsi/docket-Jitsi-meet/master

Weiß jemand, woran das liegen kann?

Übrigens auch noch mal von mir ein ganz großen Dank an Tosoboso für diese tolle Arbeit, besonders in der jetzigen Zeit ist die Videokonferenzen eine wichtige und wertvolle Angelegenheit.
L.G. David

 

[kyreon]

Auch von meiner Seite einen riesen Dank für das Paket.

Was mir aufgefallen ist, wenn ich zusätzliche user mit add-usr über das admin interface hinzufüge, sind sie nach einem neustart (per scheduled cron job) dann wieder weg. Das mache ich jeden Tag über

#!/bin/bash
jitsi-cli start

um sicherzustellen, dass die aktuelle externe IP im Container landet.

Kann man das irgendwie umgehen ohne in dem cron job "add-usr name pw" noch mit aufzunehmen?

 

[DIY]

Im DSM im Terminalfenster des Prosody-Container:
-> Erstellen --> Mit neuem Befehl starten

...
Eingabe in der Maske:
prosodyctl --config /config/prosody.cfg.lua adduser Gastbenutzer@meet.jitsi

...
Es wird das Passwort abgefragt
Es wird die Bestätigung des Passworts abgefragt
Hier oben mit neuem Benutzer 'Gastbenutzer' als Beispiel

...
Wird im Verzeichnis /etc/jitsi/prosody/ ... /accounts gespeichert:




Und - übersteht einen Neustart der Container - zumindest bei mir ;-)

 

[flyerbln]

Hallo noch mal, ich hab eben mal jemanden, der eine Ds 281+ im Einsatz hat gefragt, ob er die Installation vom jitsi Paket mal machen kann. Es stellte sich heraus, dass er auch den Fehler angezeigt bekommt:

"jitsi Meet“ konnte nicht installiert werden
Repository nicht verfügbar https://raw.githubusercontent.com/Jitsi/docket-Jitsi-meet/master

Weiß jemand, woran das liegen kann?

Übrigens auch noch mal von mir ein ganz großen Dank an Tosoboso für diese tolle Arbeit, besonders in der jetzigen Zeit ist die Videokonferenzen eine wichtige und wertvolle Angelegenheit.
L.G. David

Ich meinte eine ds 218+

 

[kyreon]

Im DSM im Terminalfenster des Prosody-Container:
-> Erstellen --> Mit neuem Befehl starten

...
Eingabe in der Maske:
prosodyctl --config /config/prosody.cfg.lua adduser Gastbenutzer@meet.jitsi

....

Und - übersteht einen Neustart der Container - zumindest bei mir ;-)

Komisch, so hatte ich das am Anfang auch gemacht und der Nutzer hatte den Neustart nicht überlebt...

Werde es im Auge behalten. Aber danke für die Rückmeldung.

 

[Tosoboso]

Hallo ihr lieben, ich wollte gerade jitsi auf meiner Synology ds 220+ neu instalieren. Wenn ich das richtig sehe ist das Paket nicht mehr online, kann das sein?Anhang anzeigen 58305

Hallo zusammen, das Problem ist behoben und eine neue Version 0.9 im Community Package Hub eingecheckt, die dann in 1-2 Tagen bereitsteht.
Grund war, dass Github auf den Webservern den HTTP Return Code von "200 OK" auf "200" geändert hat, was nicht wirklich RFC 7231 konform ist...
Ich habe den Download-Check angepasst und es wird auch 200 akzeptiert ohne OK. Die Dateien sind noch da und es war also ein Fehlalarm wegen neuer Return Codes..
-TosoBoso