JitsiMeet für Synology

[mic777]

Neues Paket für Online-Meetings von Jitsi team und Tosoboso

Hi@all,

Neuerdings gibt es ein Community-Paket von JitsiMeet.



Habs zum laugen gekriegt. Alle Docker Container laufen, jedoch gibt´s bei mir Probleme mit SSL:
Ich habe zwar in der Diskstation ein funktionierendes Let's Encrypt-Zertifikat, kann dieses jedoch nicht auf das Paket anwenden.

Mit Jitsi-Admin gibts im Docker-Environment folgende Eintragungen, die scheinen aber nicht zu greifen:

#
# Let's Encrypt configuration
#

# Enable Let's Encrypt certificate generation
#ENABLE_LETSENCRYPT=1

# Domain for which to generate the certificate
#LETSENCRYPT_DOMAIN=meet.domain.de

# E-Mail for receiving important account notifications (mandatory)
#LETSENCRYPT_EMAIL=info@domain.de

Weiß jemand, wie man hierbei vorzugehen hat?

Ich bin dankbar für jegliche Unterstützung.

Gruß mic777

 

[Tosoboso]

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.

-TosoBoso

 

[NSFH]

Interessantes Projekt.
Mich werden hier die Erfahrungen sehr interessieren was Delay in der Kommunikation angeht (ein häufiges Problem der öffentlichen Jitsi Server) aber auch die Auslastungsgrenzen, die die Syno noch mitmacht ohne den lokalen Betrieb im LAN zu beeinträchtigen.
Ohne eine performante Internetanbindung im up und downlink kann man so ein Projekt sowieso gleich vergessen.
Bin gespannt!

 

[Tosoboso]

Hi,
Ich betreibe Jitsi auf einer 100er DSL mit 40er upload, was Problemlos funktioniert. NAS is eine DS620+ mit etwas mehr Memory und die Auslastung ist nicht auffällig. Der Setup verkrafet locker 100 User auf einer x86 dual core NAS mit 2, besser 6+GB Ram.
Ich habe auch keinen Delay in der Kommunikation. Mit dem Ansatz geschlossener Räume, d.h. ein Moderator mit Passwort öffnet den Raum hat man auch keine freien Trittbrettfahrer, die an der Performance nagen.

Zum Thema Auslastung siehe auch hier: https://jotbe.io/blog/2020/04/jitsi...ehmende-kann-ein-jitsi-meet-server-verkraften
Einfach ausprobieren und die Erfahrungen Teilen, denn mit Installations Routine und Admin GUI ist der Jitsi Betrieb viel einfacher..
PS: die neue version 0.7 ist eingecheckt und bald im CPH verfügbar
-TosoBoso

 

[synfor]

NAS is eine DS620+

Mit Sicherheit nicht. Es gibt keine DS620+.

 

[Iarn]

Ach, es wird wohl eine 620 Slim sein. Wobei die durchaus zu den plus Modellen gezählt werden kann, da da Intel CPU und erweiterbarer RAM.

 

[synfor]

Das ist ein Plus-Modell. Das spielt aber keine Rolle. Die Produktbezeichnung lautet DS620slim und nicht DS620+

 

[NSFH]

Habe hier noch ein Glas Erbsen zu verschenken....

 

[mic777]

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:



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

 

[njanert]

Vielen Dank für das Bereitstellen des Paketes. Dieses nimmt einem wirklich viel Arbeit ab.

Ich habe alles problemlos unter Verwendung des Reverse-Proxy zum Laufen bekommen, nur ein Punkt stört mich. Ich möchte ungern, dass jeder der die URL kennt ein Meeting starten kann. Ist eine Absicherung möglich, evtl. durch Log-On-Seite bzw. User / Password möglich?

 

[Tosoboso]

Vielen Dank für das Bereitstellen des Paketes. Dieses nimmt einem wirklich viel Arbeit ab..
nur ein Punkt stört mich. Ich möchte ungern, dass jeder der die URL kennt ein Meeting starten kann. Ist eine Absicherung möglich, evtl. durch Log-On-Seite bzw. User / Password möglich?

Gerne. Auf deine Befürchtung, das Andere die Konferenz starten, wenn die URL bekannt ist, das geht eben nicht.
Jitsi unterstützt den Modus, dass nur Moderatoren den Raum öffnen können und dann erst Gäste teilnehmen können.
Genau das ist die Default Einstellung des Jitsi Pakets und darum wird ein Moderator User beim Install verlangt.
Weitere Moderatoren kann mann mit jitsi-cli add-usr anlegen und mit jedem Container Rebuild wird das neu gesetzt.
Zusätzlich kann der Moderator für den Raum ein Passwort setzten, das den Teilnehmern bekannt sein muss und damit gibt es keine Trittbrettfahrer.
-TosoBoso

 

[blurrrr]

Zusätzlich kann der Moderator für den Raum ein Passwort setzten, das den Teilnehmern bekannt sein muss und damit gibt es keine Trittbrettfahrer.

Greift da dann wenigstens ein fail2ban-Jail, oder kann man sich dann erstmal ordentlich bruteforce-technisch daran austoben?

 

[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":... Scheint das daran zu liegen, dass die DOCKER_HOST_ADDRESS im Docker-Evironment noch die IP-Adresse vom Vortag beinhaltet? 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

Also, die IP für Docker-Host ist die externe IP deines Routers und die ändert sich nicht mit Restart der Synology, sondern bei Zwangstrennung bzw. Verbindungsrestart des DSL-Routers. So was braucht man heute nicht mehr, eine Fritzbox mit abgeschaltetem Verbinfungsrestart hält die IP Monate. Egal, wenn du jeden Morgen ein Restart des Jitsi-Paket aud den Scheduler packst, löst sich das Problem automatisch: die externe IP wird aktualisiert und an den Container gegeben..
Ist die IP nicht aktuell bricht die Konferenz häufig schnell ab, weil TURN dann nicht mehr funktioniert.. Ich kann den Punkt in den FAQs aufnehmen: restart package each morning if your external ip changes each day to get it updated in container..
-TosoBoso

 

[geimist]

… So was braucht man heute nicht mehr, eine Fritzbox mit abgeschaltetem Verbinfungsrestart hält die IP Monate. …

Ganz sicher?
Es kommt ganz auf den Provider an. 1&1 trennt freudig jede Nacht auch ohne selbst gesetztem Zeitfenster.

Hilft bei diesem Problem nicht dieser Eintrag in der .env?

# STUN servers used to discover the server's public IP
JVB_STUN_SERVERS=meet-jit-si-turnrelay.jitsi.net:443

 

[Tosoboso]

Hilft bei diesem Problem nicht dieser Eintrag in der .env?

# STUN servers used to discover the server's public IP
JVB_STUN_SERVERS=meet-jit-si-turnrelay.jitsi.net:443

Hi, es hilft der Eintrag Docker_Host und das Packet hält das aktuell, wenn man es restartet.
Einfach ausprobieren, funktioniert stabil. Der Stun Server ist eine weitere Komponente, aber woher hat der Stun Server wohl die IP des Jitsi zu weiterreichen?...
PS: Das mit der Zwangstrennung war ein Hinweis kein Diskussionsstart, hier solltes um das Packet gehen..

 

[Arpke]

Hallo
... Neuerdings gibt es ein Community-Paket von JitsiMeet. ...

Ich habe bei Paketquellen in meiner DS114 eingegeben: http://packages.synocommunity.com

Der Community-Reiter links ist dann auch da.
Leider kann ich dort das Paket JitsiMeet nicht finden.

Muss ich ggf. eine andere Paketquelle angeben ?

Danke und Gruß
NK

 

[synfor]

Auf https://synocommunity.com/packages ist das nicht zu finden. Abgesehen davon, hast du möglicherweise auch keine unterstützte DS (falsche Architektur).

 

[Arpke]

Hallo,
guter Hinweis.
Meine DS114 hat einen ARM-Prozessor.
Ich werde das noch mal bei meiner DS115 testen - Intel-Prozessor.

Welches Paket muss ich für Community angeben ?

 

[geimist]

Das Paket von @Tosoboso stellt er auf cphub.net zur Verfügung - Paketquelle muss also https://cphub.net lauten.
Aber auch deine DS115 hat keine Intel-CPU und ist daher nicht kompatibel.

 

[Arpke]

Ich habe noch eine DS118 - irgendwo war ein Intel-Prozessor drin.
Danke für den Hinweis und die Tipps !
Gruß
Norbert