JitsiMeet für Synology

Tosoboso

Benutzer
Mitglied seit
27. Aug 2012
Beiträge
1.231
Punkte für Reaktionen
46
Punkte
74
Hi ich bekomme das Paket auf DSM 7 nicht ans laufen. "Der Paketdienst konnte nicht ausgeführt werden".
ERROR: for web Cannot start service web: Bind mount failed: '/var/packages/Jitsi-Meet/home/.jitsi-meet-cfg/web' does not exists
ERROR: for prosody Cannot start service prosody: Bind mount failed: '/var/packages/Jitsi-Meet/home/.jitsi-meet-cfg/prosody/prosody-plugins-custom' does not exists
Hi, dein "Docker-Compose-Core" oder "Docker-Environment" (siehe Admin-UI) ist falsch eingerichtet
Die Fehler entstehen, weil das Mounten von Verzeichnisse nicht geht. Es wird unter Volumes im Compose File folgendes gemounted:
- ${CONFIG}/web:/config & - ${CONFIG}/prosody/prosody-plugins-custom:/prosody-plugins-custom
CONFIG ist demnach bei dir eingerichtet als: '/var/packages/Jitsi-Meet/home/.jitsi-meet-cfg' es muss aber 'CONFIG=/var/packages/Jitsi-Meet/etc' sein
-TosoBoso
 
Zuletzt bearbeitet:

blinddark

Benutzer
Mitglied seit
03. Jan 2013
Beiträge
1.371
Punkte für Reaktionen
29
Punkte
68
Hi, wie kommt dies zu Stande? Ich habe lediglich das bereitgestellte Package installiert und keine Variable manuell angepasst.

Wie kann ich das Verzeichnis anpassen?

Vielen Dank im Voraus
 

Tosoboso

Benutzer
Mitglied seit
27. Aug 2012
Beiträge
1.231
Punkte für Reaktionen
46
Punkte
74
Der Jitsi-Admin hat einen eingebauten Editor: einfach die Dateien Öffnen, Anpassen, Speichern.
Fals der Save Butten deaktiviert ist, das it ein Bug in der JS-Klasse: man muss etwas Hinzufügen. Einfach Leerzeichen am Ende der Zeile und wieder wegnehmen, dann ist der Save Button aktiv.
Wenn das ohne dein Zutun bei der Installation gekommen ist, dann brauche ich Details zum Nachstellen: DSM-6 oder 7, welche Version des Pakets, Neuinstallation, oder Update..
-TosoBoso
 

Lineflyer

Benutzer
Mitglied seit
27. Mrz 2021
Beiträge
12
Punkte für Reaktionen
1
Punkte
3
Hallo Zusammen,

das Jitsi-Paket läuft tadellos auf meiner DS218+.

Einige Parameter habe ich (wie vorab schonmal gefragt) in der custom-config.js angepasst und nun das Optimum für mich gefunden.

Es gibt jedoch eine Sache, bei der ich (als Non-Profi) nicht weiterkomme:
- Ich habe Authentisierung bei der Installation abgeschaltet, da mein Server (das Paket) per Aufgabenplaner nur begrenzte Zeit gestartet wird und in dieser Zeit jeder den Server nutzen können soll, ich aber nicht für alle Nutzer einen Account anlegen möchte (das wäre die Notlösung). Ist ein wenig schwierig, da potentiell neue Nutzer spontan dazukommen.
- Wie bei Jitsi üblich, wird jedoch nur dem User, der die Konferenz startet das Moderationsrecht gegeben. Dies ist nun leider nicht unbedingt der "wissende" Nutzer, so dass im Zweifel ein Nutzer Mod-Rechte hat, der sie nicht nutzen kann/soll und der Leiter der Konferenz leider nicht

Daher folgende Fragen (alternative Lösungen für mich):
1. Ideale Lösung: Alle Teilnehmer sollen Moderationsrechte haben. Wie mache ich das?
2. Notlösung: Kann ich mich - wenn ich die bestehende Konferenz betrete - als Moderator authentisieren (Account habe ich bei der Installation dennoch angegeben)

@Tosoboso
Ich werde gleich mal deinen Spendenlink nutzen. Das Tools ist in der momentanen Zeit einfach Gold wert.
 

blinddark

Benutzer
Mitglied seit
03. Jan 2013
Beiträge
1.371
Punkte für Reaktionen
29
Punkte
68
Hi,

der Jitsi-Admin lässt sich nicht aufrufen. Es wird kein Container gestartet.

Es handelt sich um DSM7 und war eine Neuinstallation.
 

Tosoboso

Benutzer
Mitglied seit
27. Aug 2012
Beiträge
1.231
Punkte für Reaktionen
46
Punkte
74
Hi, der Jitsi-Admin lässt sich nicht aufrufen. Es wird kein Container gestartet. Es handelt sich um DSM7 und war eine Neuinstallation.
Und du hast Docker neu gestartet, danach das Paket neu gestartet? Dann wird das aus gegraute Icon auf dem Desktop verfügbar.
Es gibt einen wichtigen Hinweis bei der Erst-Installation, dass wegen ALC / Zugriffsrechten Dies geschehen muss. Der Jitsi-Admin kann erst benutzt werden, nachdem System-Dateien für Authentifizierung rüber kopiert wurden, via Docker, sobald der Packet User auf den Docker Socket zugreifen darf.
-TosoBoso
 

blinddark

Benutzer
Mitglied seit
03. Jan 2013
Beiträge
1.371
Punkte für Reaktionen
29
Punkte
68
Ja, beides neu gestartet. Beim Start des Paketes Jitsi kommt dann nur die Meldung, dass der Paketdienst nicht ausgeführt werden kann und ich könnte das Paket reparieren, was mit dem gleichen Fehler endet.
 

42HAL

Benutzer
Mitglied seit
10. Apr 2018
Beiträge
20
Punkte für Reaktionen
0
Punkte
1
Hallo Zusammen,

erst einmal vielen Dank an Todoboso für Deinen Einsatz!

Ich habe ein paar Fragen:

1.) Wie ist die Situation hinsichtlich der verschiedenen Bowser (FF, CHR, Edge etc.) - funktionieren alle gelich gut / schlecht, gibt es Präferenzen (meine Erfahrungen: Chrome ok, FF kein Video (jeweils aktuelle Versionen))?
2. Kann / muß man innnerhalb der Installation Anpassungen vornehmen, so daß (bestimmte) Browser überhaupt oder besser unterstützt werden?

Vielen Dank.
 

Lineflyer

Benutzer
Mitglied seit
27. Mrz 2021
Beiträge
12
Punkte für Reaktionen
1
Punkte
3
1.) Wie ist die Situation hinsichtlich der verschiedenen Bowser (FF, CHR, Edge etc.) - funktionieren alle gelich gut / schlecht, gibt es Präferenzen (meine Erfahrungen: Chrome ok, FF kein Video (jeweils aktuelle Versionen))?

Mein persönliche Erfahrung ist, dass Jitsi mit Chrome wesentlich performanter (bzw. ressourcenschonender) läuft als mit Firefox. Grundsätzlich funktioniert hat es allerdings bei mir auch mit Firefox.

2. Kann / muß man innnerhalb der Installation Anpassungen vornehmen, so daß (bestimmte) Browser überhaupt oder besser unterstützt werden?

Ich habe als "Hint" für die Nutzer daher Firefox in der interface-config.js aus den idealen Browsern entfernt, so dass mit Firefox eine Warnung angezeigt wird, dass man besser Chrome verwenden sollte.
Generell braucht man keine Anpassungen für einzelne Browser vornehmen. Das Javascript läuft identisch in allen Browsern.
 

Lineflyer

Benutzer
Mitglied seit
27. Mrz 2021
Beiträge
12
Punkte für Reaktionen
1
Punkte
3
Daher folgende Fragen (alternative Lösungen für mich):
1. Ideale Lösung: Alle Teilnehmer sollen Moderationsrechte haben. Wie mache ich das?

Habe inzwischen eine Lösung gefunden und möchte sie hier kurz wiedergeben, falls sie für jemandem von Nutzen sein kann (vielleicht kann man dies sogar als wählbare Option bei der Installation des Jitsi-Pakets realisieren?!

Prosody muss wie folgt angepasst werden:

1. Eine Datei mod_muc_moderators.lua erstellen mit folgendem Inhalt:
Code:
local muc_svc = module:depends("muc");

function module.load()
    muc_svc.room_mt.get_affiliation = function (room, jid)
      return "owner";
  end
end

Quelle: https://community.jitsi.org/t/install-allowners-prosody-module/66218/9

2. Diese Datei im prosody Container ablegen unter /prosody-plugins/

3. Die vorhandene Datei jitsi-meet.cfg.lua im Container im Order /defaults/conf.d/ wie folgt anpassen:
In der Komponente "muc.meet.jitsi" bei den "modules_enabled" die Zeile "muc_moderators" ergänzen, so dass es danach wie folgt aussieht:
Code:
Component "muc.meet.jitsi" "muc"
    storage = "memory"
    modules_enabled = {
        "muc_meeting_id";
        "muc_moderators";
        
    }

4. Container neu starten

Ab sofort werden allen Teilnehmern beim Betreten der Konferenz Moderatorenrechte vergeben (und nicht mehr nur dem ersten Teilnehmer).
 
  • Like
Reaktionen: geimist

Tosoboso

Benutzer
Mitglied seit
27. Aug 2012
Beiträge
1.231
Punkte für Reaktionen
46
Punkte
74
Habe inzwischen eine Lösung gefunden und möchte sie hier kurz wiedergeben, falls sie für jemandem von Nutzen sein kann (vielleicht kann man dies sogar als wählbare Option bei der Installation des Jitsi-Pakets realisieren?!
Es gibt im Jitsi-Paket das mod Script und da kann man das Reinpacken zum automatisieren
Code:
echo "local muc_svc = module:depends(\"muc\")" > /tmp/mod_muc_moderators.lua
echo "function module.load()" >> /tmp/mod_muc_moderators.lua
echo "muc_svc.room_mt.get_affiliation = function (room, jid)" >> /tmp/mod_muc_moderators.lua
echo "return "owner";" >> /tmp/mod_muc_moderators.lua
echo "end" >> /tmp/mod_muc_moderators.lua
echo "end" >> /tmp/mod_muc_moderators.lua
mv /tmp/mod_muc_moderators.lua /var/packages/Jitsi-Meet/etc/prosody/prosody-plugins-custom
sed -i -e "s~\"muc_meeting_id\";~\"muc_meeting_id\";\n\t\t\"muc_moderators\";~" /var/packages/Jitsi-Meet/etc/prosody/config/conf.d/jitsi-meet.cfg.lua
echo "allowed all subsequent users to be moderator.."
 
  • Like
Reaktionen: Lineflyer

Lineflyer

Benutzer
Mitglied seit
27. Mrz 2021
Beiträge
12
Punkte für Reaktionen
1
Punkte
3
Danke @Tosoboso. Mit diesen Mod-Scripten muss ich mich noch beschäftigen.


In diesem Zusammenhang noch eine Frage:
Diese oben beschriebenen Änderungen, die ich im Prosody-Container vorgenommen habe und auch Anpassungen der config.js im Web-Container blieben eigentlich immer erhalten, wenn ich das Jitsi-Paket gestoppt und wieder gestartet habe. Ich habe im Aufgabenplaner hierfür einen Job angelegt, der Jitsi an den 3 Terminen, in denen ich es pro Woche brauche, startet und stoppt.

Bislang hat das problemlos (inkl. Beibehaltung der individuellen Einstellungen) funktioniert. Diese Woche jedoch habe ich schon zum zweiten Mal den Effekt, dass alle Anpassungen der Container weg sind.
Ich bin leider überhaupt kein Experte für Docker-Container, aber kann mir jemand erklären warum es so ist? Oder ist das ein Fehler und sollte nicht passieren?
 

Lineflyer

Benutzer
Mitglied seit
27. Mrz 2021
Beiträge
12
Punkte für Reaktionen
1
Punkte
3
Zu meinem oben beschriebenen Problem:
Könnte es sein, dass durch die Referenz auf `:latest` bei den Paketen beim Starten der Docker-Pakete die Konfiguration weg ist, sobald eine neuere Version von Jitsi vorliegt? Sorry...bin wie gesagt noch nicht so vertraut mit der Arbeitsweise von Docker.
 

Andy+

Benutzer
Mitglied seit
25. Jan 2016
Beiträge
3.792
Punkte für Reaktionen
97
Punkte
114
In aller Regel muss ein neues Image manuell geladen und in einen Container gestartet werden. Automatische Abläufe sind mir nicht bekannt. Allerdings kenne ich die Konzeption von Tosoboso so, dass lokal alle Einstellungen usw. gespeichert sind und bei Updates keine neuen Konfigurationen erforderlich sind. So wäre das Zusammenspiel von SPK und Docker zu betrachten.

Nur auf Docker bezogen, können zu einem Container die Konfigurationen gespeichert und beim Neustart eines Containers importiert werden. Aber diese Vorgehensweise für einen Single-Container schliesse ich für diese Multi-Containerumgebung aus. Es wird sicherlich wie bei Kopano4S laufen, ebenso ein Gewächs von Tosoboso, dass über den Admin auch die Updates der Images laufen und damit wäre das ziemlich easy und ohne die Konfigurationen zu verlieren.
 
Zuletzt bearbeitet: