JitsiMeet für Synology

[OliverJ]

Gerade das neue Docker-Image installiert:
Leider kein Imprint-Footer mehr vorhanden, dafür neuer Startbildschirm, und auch das Lobby-Feature (Beitrittsanfrage) lässt sich nicht mehr aktivieren. Kann nur noch ein Passwort gesetzt werden. Wurde wohl in der neuen Jitsi-Version entfernt, wie es aussieht.

 

[coldjack]

Leider geht es doch nicht mehr. Ich kann nicht einmal die Befehle in der config nutzen. Ich habe nichts geändert. Zugriff auf jitsi habe ich, erhalte dann aber die Verbindungsabbrüche.

 

[OliverJ]

Nachtrag: Das Lobby-Feature läuft wieder. Scheinbar muss dazu enable_guests=0 gesetzt werden.

 

[flyerbln]

Hallo OliverJ,
läuft denn der Imprint-Footer auch wieder?
L.G. David

 

[OliverJ]

Leider nein. Wird nichts eingebunden.

 

[DIY]

Anderswo gesehen - keine direkte Lösung des Problems, es kann aber die erste Zeile der 'Welcome-Page' individuell abgeändert werden
und funktioniert zumindest in der Version 5142-4 ...

Nötig ist eine Datei namens 'body.html' mit beispielsweisem Inhalt:

<style>
.welcome .header .header-text-title {
    font-size: 0;
}
.header-text-title::before {
    content: 'Jitsi wird betrieben von MeineFirma Meine Strasse Meine Stadt MeineTelefonnummer MeineEmaildresse';
    font-size: 2.4rem; 
}
</style>

kopieren mittels config-mod oder mounten in den jitsi_web Container als Ziel in:
/usr/share/jitsi-meet/body.html

(wie das Ändern bzw. Anpassen des Wasserzeichens - nur ein anderer Pfad bzw Dateiname)

... Ergebnis

 

[OliverJ]

Leider verstehe ich bis heute nicht, wie ich an Dateien in Dockercontainern herankomme, diese gegebenfalls modifiziere usw. Könnte das mal jemand detailliert und Schritt für Schritt erläutern? Oder anders ausgedrückt: Geht das nur über SSH-Zugriff?

 

[DIY]

Es geht ohne den direkten Zugriff, beispielsweise aufgezeigt wie in #206 oder #215
oder am Beispiel des 'config-mod' Skripts anhand der letzten zwei Zeilen.

...
...
#docker cp -a /etc/jitsi/*.html jitsi_web:/usr/share/jitsi-meet/static/
#docker cp -a /etc/jitsi/watermark.png jitsi_web:/usr/share/jitsi-meet/images/

(hier ist jeweils im letzten Teil der Zeile der Pfad im Container zu sehen)

PS
Die Dateien und Verzeichnisse kannst Du im Terminal des Containers einsehen, siehe #217

 

[OliverJ]

enable_guests=0 war doch keine so gute Idee. Jetzt können sich nur noch Leute zuschalten, die die Logindaten für Moderatoren kennen. Also wieder aktiviert, dafür ist der Lobby-Modus wieder weg.
Gerade gesehen: Gibt schon wieder ein Docker-Update. Mal sehen, wie es sich danach verhält.
Edit: Lobby-Feature nach Update wieder da.

 

[DIY]

Leider verstehe ich bis heute nicht, wie ich an Dateien in Dockercontainern herankomme, diese gegebenfalls modifiziere usw. Könnte das mal jemand detailliert und Schritt für Schritt erläutern? Oder anders ausgedrückt: Geht das nur über SSH-Zugriff?

OK - 'Rauskopieren & Anschauen' ohne SSH Konsole am Beispiel des Containers jitsi_web...

Anlegen eines Verzeichnisses zur Ablage der Dateien und des Skripts
- über den DSM z.b. als docker/jitsi_web/copy_out/ (liegt tatsächlich in /volume1/docker/jitsi_web/copy_out/)


Anlegen einer Datei mit Skriptbefehlen und Abspeichern im gleichen Verzeichnis
- über den Texteditor des DSM z.b. als copy_out.sh (Pfadangabe also /volume1/docker/jitsi_web/copy_out/copy_out.sh)

#!/bin/bash
docker cp jitsi_web:/config/config.js /volume1/docker/jitsi_web/copy_out/config.js
docker cp jitsi_web:/config/interface_config.js /volume1/docker/jitsi_web/copy_out/interface_config.js
docker cp jitsi_web:/config/custom-config.js /volume1/docker/jitsi_web/copy_out/custom-config.js
docker cp jitsi_web:/usr/share/jitsi-meet/css/all.css /volume1/docker/jitsi_web/copy_out/all.css
docker cp jitsi_web:/usr/share/jitsi-meet/images/avatar.png /volume1/docker/jitsi_web/copy_out/avatar.png
docker cp jitsi_web:/usr/share/jitsi-meet/images/watermark.png /volume1/docker/jitsi_web/copy_out/watermark.png
docker cp jitsi_web:/usr/share/jitsi-meet/static/close3.html /volume1/docker/jitsi_web/copy_out/close3.html
docker cp jitsi_web:/usr/share/jitsi-meet/static/welcomePageAdditionalContent.html /volume1/docker/jitsi_web/copy_out/welcomePageAdditionalContent.html
docker cp jitsi_web:/usr/share/jitsi-meet/body.html /volume1/docker/jitsi_web/copy_out/body.html

Anlegen eines benutzerdefinierten Skripts ('Geplante Aufgabe') mit ordentlicher Benennung ('Kopie aus Docker ...) im Aufgabenplaner des DSM als Benutzer 'root' und ohne sofortige Ausführung (abwählen von 'Aktiviert') und mit dem unteren Schnipsel (Pfad zum Skript) füllen

/volume1/docker/jitsi_web/copy_out/copy_out.sh

Skript in der Liste suchen und Ausführen
- Es finden sich im Verzeichnis docker/jitsi_web/copy_out/ nun die Dateien
config.js
interface_config.js
...
...

...Ergebnis




Ansehen nun bspw mit dem Texteditor.

Have Fun!

 

[OliverJ]

Super nachvollziehbar. Muchas Gracias

 

[DIY]

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

Gerade ausprobiert ...
... im VMM frischen vDSM mit Docker und Perl aufgesetzt
... Paket 0.9 installiert
... Firewall eingerichtet
... ReverseProxy eingerichet
... Router angepasst

Läuft 'out of the Box' ohne weitere Verrenkungen und ab jetzt mit Snapshot-Garantie

Super, Danke für den Tipp!

 

[DIY]

läuft denn der Imprint-Footer auch wieder?

Leider nein. Wird nichts eingebunden.

Irgendwo ausgegraben - guggt ihr hier...

...zusätzliche Ergänzungen bzw. Änderungen (class=...) in der bisherigen 'welcomePageAdditionalContent.html'

<template id = "welcome-page-additional-content-template">
    <div class="welcome-page-content">
            <div class="welcome-footer">
                    <div class="welcome-footer-content">
                        <div class="welcome-footer-about">
                            <div>
                                 
                                     DEIN TEXT |
                                      <a href="https://yourdomain.tld" style="color: #fff; text-decoration: underline;">Webseite</a> |
                                      <a href="https://yourdomain.tld/datenschutz" style="color: #fff; text-decoration: underline;">Datenschutz</a> |
                                      <a href=" https://yourdomain.tld/impressum" style="color: #fff; text-decoration: underline;">Impressum</a>
                                
                            </div>
                    </div>
            </div>
    </div>
</template>

...zusätzliche Datei im Container 'jitsi_web' namens 'plugin.head.html' im Verzeichnis /usr/share/jitsi-meet/

<style>
.welcome-page-content {
    display: flex;
    flex-direction: column;
    flex-grow: 1;
    justify-content: space-between;
    position: relative;
    z-index: 1;
    margin-top: 30px;
    width: 100%
}
.welcome-page-content .welcome-footer {
    color: #FFF;
    display: flex;
    padding-bottom: 10px;
    padding-top: 10px;
    width: 100%;
    z-index: 1
}
.welcome-page-content .welcome-footer-content a {
    color: #fff !important;
    text-decoration: underline
}

.welcome-page-content .welcome-footer-content {
    display: flex;
    justify-content: center;
    width: 100%;
    z-index: 2
}

.welcome-page-content .welcome-footer-about {
    display: flex;
    flex-direction: column;
    flex: 1;
    font-size: 20px;
    line-height: 20px;
    text-align: center;
    justify-content: center
}


.welcome-page-content .welcome-footer-about:last-child {
    margin-left: 4px
}
</style>

...entsprechende Settings in der 'interface_config.js'

DISPLAY_WELCOME_FOOTER: false,
DISPLAY_WELCOME_PAGE_ADDITIONAL_CARD: false,
DISPLAY_WELCOME_PAGE_CONTENT: true,
DISPLAY_WELCOME_PAGE_TOOLBAR_ADDITIONAL_CONTENT: true,


...getestet mit der aktuellen Version 5390-3

 

[Tosoboso]

= Abhilfe Jitsi Meet Synology Verbindungsabbruch Websockets & Reverse Proxy =

mit Updates des Jitsi Docker Containers im Jan/Feb gab es häufige Anfragen zu Verbindungsabbruch beim Jitsi Paket.
Seit Wochen war ich am Recherchieren nach dem Grund: Jitsi in Kombination mit Reverse Proxy "non-websocket aware".

Hinweis Gab es Dank folgendem Beitrag im Jitsi Forum: https://community.jitsi.org/t/jitsi-dockers-and-synology-nas/17284/27
In Essenz: Websocket muss auf dem ReverseProxy aktiviert werden und Synology hat das ab DSM 6.2.1 per GUI umgesetzt siehe hier: https://github.com/orobardet/dsm-reverse-proxy-websocket
Abhilfe bringt Folgende Einstellung im Reverse-Proxy: Application Portal -> Custom Headers -> Create -> Websocket führt zu: Upgrade=$http_upgrade, Connection=$connection_upgrade.
Ich werde einen Hinweis im Paket FAQ hinterlegen und Prüfen, ob ich im Health Check Abfrage Hinweis und auf die WebSocket Einstellungen machen kann.

-TosoBoso

 

[Lineflyer]

Hallo Zusammen,

ich habe mich gestern mal daran gewagt Jitsi auf meiner DS218+ lauffähig zu bekommen. Dank des tollen Paketes war alles fast Plug&Play.

Eine Sache hat mich jedoch lange beschäftigt, bis ich auf die (eigentlich offensichtliche) Lösung gekommen bin:
- Ich habe die Pakete mit den Standard-Ports installiert
- Ich kann allerdings nicht, die Ports 80/443 nach außen hin nutzen, daher habe ich im Reverse Proxy der DSM den Proxy auf Port 9443 konfiguriert und auf localhost:8080 zeigen lassen.

Ich hatte danach das Problem (welches ich hier auch öfters mal gelesen habe), dass Web-Sitzungen sich nicht verbinden (Startseite erscheint, Meeting kann gestartet werden, nach ca. 10-20 Sekunden erscheint die Meldung, dass die Verbindung getrennt wurde, "Websocket failed"). Erst beim Nachforschen in der Browserkonsole ich mir aufgefallen, dass es nicht an fehlender/falscher Websocket-Unterstützung liegt, sondern schlicht und ergreifend daran, dass der benutzerdefinierte Port nicht verwendet wird, um die Meeting-Session zu starten.
Abhilfe: Bei der Installation des Pakets die PUBLIC_URL um den Port ergänzen, z.B. meet.xyz.de:9443, so dass bei den Dockern PUBLIC_URL=https://meet.xyz.de:9443 erscheint. Seitdem funktioniert alles.

@Tosoboso
Vielleicht könntest du bei der Abfrage der Parameter während der Installation ergänzen, dass der Port in der Public URL mit angegeben werden muss, wenn nach außen hin nicht der Standard-Port verwendet wird.

Eine zweite Sache, die bei mir ein wenig gedauert hat, es zu verstehen:
Das Kopieren von Zertifikaten vom Host in den Container funktioniert scheinbar bei mir nicht, da ich nicht die LetsEncrypt-Zertifikate nutze, sondern eines aus anderer Quelle (manuell in den DSM-Zertifikatsmanager zugefügt).
Auf den Reverse-Proxy als Lösung hierfür bin ich erst sehr spät gekommen, da dies leider auch nicht in den FAQ, o.ä. beschrieben wird. Noch idealer wäre natürlich die Unterstützung des Kopierens benutzerdefinierter Zertifikate von der DSM in den Container.

Ich hoffe mein Erfahrungsbericht konnte einigen helfen.

 

[Tosoboso]

Hallo Zusammen, ... Eine Sache hat mich jedoch lange beschäftigt, bis ich auf die (eigentlich offensichtliche) Lösung gekommen bin:
- Ich habe die Pakete mit den Standard-Ports installiert, Ich kann allerdings nicht, die Ports 80/443 nach außen hin nutzen
> daher habe ich im Reverse Proxy der DSM den Proxy auf Port 9443 konfiguriert und auf localhost:8080 zeigen lassen.
Ich hatte danach das Problem.. nach ca. 10-20 Sekunden erscheint die Meldung, dass die Verbindung getrennt wurde, "Websocket failed").
Abhilfe: Bei der Installation des Pakets die PUBLIC_URL um den Port ergänzen, z.B. meet.xyz.de:9443, so dass bei den Dockern PUBLIC_URL=https://meet.xyz.de:9443 erscheint. Seitdem funktioniert alles.
@Tosoboso
Vielleicht könntest du bei der Abfrage der Parameter während der Installation ergänzen, dass der Port in der Public URL mit angegeben werden muss, wenn nach außen hin nicht der Standard-Port verwendet wird.
..Auf den Reverse-Proxy als Lösung hierfür bin ich erst sehr spät gekommen, da dies leider auch nicht in den FAQ, o.ä. beschrieben wird. Noch idealer wäre natürlich die Unterstützung des Kopierens benutzerdefinierter Zertifikate von der DSM in den Container.

Moin,
Deine Beschreibung ist logisch, aber den Port der Synology nach Außen nicht mit 80/443 zu nutzen ist sehr exotisch. Normalerweise wird 80/443 auf v-host, oder Reverse Proxy geleitet. Insofern ist dein Wunsch nach einem Health check ungewöhnlich. Ich baue eine Check ein, der prüft, ob die Public-URL im env einem Reverse Proxy Eintrag entspricht und dieser WebSockets Header hat; ggf. kann ich da auch die Ports aufnehmen.
Das mit dem Kopieren der Zertifikate, wenn man kein Lets-Encrypt nutzt ist zu aufwendig und exotisch. Du kannst aber mit den Mod-Scripts so etwas erreichen: die Jitsi-Certs liegen unter: etc/jistsi/web/keys/cert.key bzw. cert.crt und bei jedem Reset / Refresh, wo ja das Mod Script aufgerufen wird kannst du deine Zertifikate kopieren. Normalerweise kann man Jitsi ohne eigene Zertifikate nutzen und das steht auch im FAQ plus beim Install wird von advanced Config gesprochen (z.B: bei WAF: web app fw) , da man ja den Synology Reverse Proxy auf localhost:8080 hat.
-TosoBoso

 

[Lineflyer]

Moin,
Deine Beschreibung ist logisch, aber den Port der Synology nach Außen nicht mit 80/443 zu nutzen ist sehr exotisch. Normalerweise wird 80/443 auf v-host, oder Reverse Proxy geleitet. Insofern ist dein Wunsch nach einem Health check ungewöhnlich. Ich baue eine Check ein, der prüft, ob die Public-URL im env einem Reverse Proxy Eintrag entspricht und dieser WebSockets Header hat; ggf. kann ich da auch die Ports aufnehmen.

Hi TosoBoso,

danke für die schnelle Antwort (und überhaupt auch für das Paket, was prima funktioniert)!!

Ich bin mir nicht sicher, ob du mich wirklich richtig verstanden hast (oder meine Kenntnis einfach nicht so tiefgehend ist und ich daher die Antwort nicht 100% verstehe ), daher hier meine Portkonfig in der Übersicht:

Prefix=8000, also HTTP=8080 und HTTPS=8443 vom Container
Public URL: www.xyz.de
Reverse Proxy auf der DSM: HTTPS 9443 nach außen auf HTTP 8080 nach innen (Proxy um mein Zertifikat auf der DSM zu nutzen, Port, weil unter 80/443 schon ein Webserver läuft).

Verhalten:
- Wenn ich die Jitsi-App auf Android nehme, kann ich dort in der App schon https://www.xyz.de:9443 aufnehmen und alles läuft prima
- Wenn ich mit dem Browser (Chrome und FF getestet) die https://www.xyz.de:9443 öffne sieht erst alles gut aus. Wenn ich ein Meeting starte, dann kommt die Verbindung zur Videobridge allerdings nicht zustande. In der Browserkonsole sieht man, dass der Port in der Anfrage fehlt, wodurch sie an 443 geht.

Die Behebung war während der Installation für die Public URL bereits den Port anzuhängen (also Public URL=www.xyz.de:9443).

Im Grund braucht es keinen Health_Check (Was immer das genau ist), sondern nur eine Ergänzung im Text der Konfiguration während der Installation, dass man die Public URL ggf. um den Port ergänzen soll, unter dem die Installation nachher von außen erreichbar ist.

Das mit dem Zertifikat ist für mich gar kein Problem. Der Reverse-Proxy erledigt das Problem und funktioniert gut. Da verzichte ich gerne auf manuelles Kopieren, etc.

 

[blinddark]

Gibt es einen Status zur Kompatibilität mit DSM 7?

 

[Lineflyer]

Guten Tag Zusammen,

ich habe noch ein Frage (vermutlich aufgrund meiner mangelnden Erfahrung mit Docker Containern):
Ich habe einige Einstellungen für jitsi_web angepasst, indem ich eine custom_config.js in /config des Containers abgelegt habe. Wenn ich dann den Container neu starte, werden die Einstellungen angewendet und alles ist gut.

Nun hatte ich jedoch Docker und die Container ein paar Tage abgeschaltet und musste feststellen, dass meine custom_config.js verschwunden ist.
Offensichtlich war das nicht der richtige Weg um den Container wirklich dauerhaft anzupassen oder was ist hier passiert?
Wie muss ich vorgehen um diese Einstellungen dauerhaft zu haben?

 

[DIY]

Moinmoin Lineflyer,

die Datei sollte 'custom-config.js' benannt sein (also '-' anstatt '_').

Um komfortabel nachzusehen welche Dateien zur Laufzeit im Container jitsi_web vorhanden oder auch nicht vorhanden sind
kann beispielsweise der Midnight Commander (mc) im Container nachinstalliert werden.

- Im Terminal des laufenden Containers 'jitsi_web':
Erstellen -> Mit Befehl starten -> Eingabe 'bash' ...
... Konsole 'bash' als root@jitsi-web

- In der Konsole 'bash'
apt-get update
apt-get install mc
mc
... mc läuft

Die mit dem Prefix '*' gekennzeichneten Dateien sind in den Container gemappt - und obacht geben ... läuft als root.