So richten Sie einen Jibri-Aufnahme- und Streaming-Server für Jitsi Meet ein

Das aktuelle Docker-Handbuch von Jitsi beschreibt eine wichtige Änderung bei der Bereitstellung: Seit Version [Versionsnummer einfügen] stable-11146laufen die Container mit der Benutzer-ID/Gruppen-ID 1000 ohne Root-Rechte, und persistente Datenverzeichnisse müssen für diesen Container-Benutzer beschreibbar sein. Der Jibri-Dienst benötigt diese SYS_ADMINBerechtigung ebenfalls nicht mehr. Ältere Anleitungen, die privilegierte Container oder weitreichende 777Berechtigungen empfehlen, sollten nicht ohne Prüfung der versionsspezifischen Anweisungen in eine aktuelle Bereitstellung übernommen werden.

Diese Anleitung verwendet Docker Compose für eine bestehende, selbstgehostete Jitsi Meet-Installation. Sie basiert auf einem rein hypothetischen Beispiel: Das Riverview-Team betreibt Jitsi bereits unter [URL] meet.example.net, speichert die Konfiguration unter [Pfad /opt/jitsi-meet-cfg] und möchte, dass Moderatoren Meetings lokal aufzeichnen und gelegentlich an ein RTMP-Ziel streamen. Dies ist eine Beispielkonfiguration und kein Bericht über eine reale Installation oder einen Test.

Anmerkung zur Abbildung: Die untenstehenden Bildschirmansichten sind schematische Beispiele und keine Aufnahmen von einem realen Server; die angezeigten Befehlsausgaben und Besprechungszustände dienen nur der Veranschaulichung.

Was Jibri leistet und was es braucht

Jibri ist die Broadcasting-Infrastruktur von Jitsi für die Aufzeichnung oder das Live-Streaming von Konferenzen. Es nimmt über eine Browsersitzung an einer Besprechung teil, erfasst Audio und Video und kodiert anschließend die Ausgabe. Eine funktionierende Jibri-Konfiguration setzt daher voraus, dass sich der Jitsi-Webdienst, der Prosody-XMPP-Server und Jicofo auf das interne Aufzeichnungskonto und den Jibri-„Brewery“-Raum einigen, in dem sich verfügbare Instanzen melden.

Verwenden Sie eine vollständige Jitsi Meet-Installation, die Sie selbst verwalten. Jibri kann nicht wie ein eigener Server an den öffentlichen Dienst meet.jit.si angebunden werden. Das Jibri-Projekt beschreibt die Ausführung auf einem separaten Rechner oder einer virtuellen Maschine, ohne dass dessen Anzeige- oder Audiogeräte durch andere Anwendungen beansprucht werden. Die offizielle Docker Compose-Bereitstellung packt Jibri als zusätzlichen Dienst. Für eine kleine Installation genügt ein separater Container auf dem Compose-Host. Für den Dauerbetrieb sollten Sie Jibri dedizierte CPU, Arbeitsspeicher und Festplattenkapazität zuweisen oder einen entsprechend ausgestatteten Host verwenden.

Eine Jibri-Instanz kann jeweils nur eine Aufnahme- oder Streaming-Sitzung verarbeiten. Wenn Riverview mehrere Sitzungen gleichzeitig erwartet, sollte ein Jibri-Pool mit mehreren Instanzen eingerichtet und die im Jitsi-Handbuch beschriebene zusätzliche Audio-Loopback-Konfiguration berücksichtigt werden. Das Hinzufügen weiterer Container ohne separate Audiogeräte stellt keine vollständige Skalierungslösung dar.

Schritt 1: Docker Jitsi Meet-Umgebung vorbereiten

Verwenden Sie eine offizielle Docker Jitsi Meet-Version und die zugehörigen Compose-Dateien. Die .envDatei und die Compose-Dateien müssen aus derselben Version stammen. Aktivieren Sie in der Umgebungsdatei die Aufzeichnung.

ENABLE_RECORDING=1

Die Compose-Konfiguration von Jitsi verwendet interne XMPP-Konten für Jibri und die Browser-Sitzung des Recorders. Verwenden Sie sichere, unterschiedliche Passwörter für Jibri und den Recorder und geben Sie diese nicht weiter. Bei einem neuen Jitsi-Stack gen-passwords.shkann das Projektskript die internen Dienstpasswörter generieren. Da es die Umgebungsvariablen ändert, sollten Sie diese vorher sichern. Wenn der Jitsi-Stack bereits läuft, sollten Sie nicht einfach alle Passwörter neu generieren: Alle laufenden Komponenten müssen bei einem geplanten Neustart die aktualisierten Zugangsdaten erhalten.

Im Beispiel von Riverview ENABLE_RECORDING=1ist dies der erforderliche Schalter, während die Umgebungsvorlage der Version die Namen und Standardwerte für den XMPP-Benutzer, den Recorder-Benutzer, den Brewery-MUC, den Speicherpfad und weitere Optionen bereitstellt. Fügen Sie Passwörter niemals in ein öffentliches Issue, einen Terminal-Screenshot oder einen gemeinsamen Meeting-Chat ein.

Schritt 2: Beschreibbaren, persistenten Speicher erstellen

Aufzeichnungen müssen auch nach einem Containerwechsel erhalten bleiben. Daher bindet Jitsi Compose persistenten Hostspeicher für Jibri ein. Im Beispiel CONFIG=/opt/jitsi-meet-cfgist das Hostverzeichnis /opt/jitsi-meet-cfg/storage/jibri. Erstellen Sie es vor dem Start des Dienstes und machen Sie es für die UID/GID 1000 des Containers beschreibbar.

sudo mkdir -p /opt/jitsi-meet-cfg/storage/jibri
sudo chown 1000:1000 /opt/jitsi-meet-cfg/storage/jibri
sudo chmod 750 /opt/jitsi-meet-cfg/storage/jibri
ls -ldn /opt/jitsi-meet-cfg/storage/jibri

Die numerische Auflistung sollte Eigentümer und Gruppe anzeigen 1000. Verwenden Sie den tatsächlichen CONFIGPfad aus Ihrer Umgebungsvariablen-Datei, falls dieser abweicht. Vermeiden Sie es, die Eigentümerschaft des gesamten Jitsi-Konfigurationsverzeichnisses rekursiv zu ändern; weisen Sie die benötigte Eigentümerschaft dem Jibri-Speicherpfad zu und behalten Sie bestehende Aufnahmen bei, wenn Sie einen bestehenden Host anpassen. Auf SELinux-Systemen sollten die Volume-Label-Einstellungen aus der entsprechenden offiziellen Compose-Datei beibehalten und nicht entfernt werden.

Das Aufzeichnungsverzeichnis des Containers ist konfigurierbar; das im Handbuch dokumentierte Beispiel dafür JIBRI_RECORDING_DIRist /storage/recordings, das unterhalb des Jibri-Speicherverzeichnisses des Hosts eingebunden wird. Überprüfen Sie die Umgebungsvorlage Ihrer Release, bevor Sie Änderungen vornehmen. Stellen Sie sicher, dass der Host über ausreichend freien Speicherplatz und einen Aufbewahrungsplan verfügt: Ein aktiver Recorder kann mit der Zeit auch ein kleines Volume belegen.

Schritt 3: Jibri mit der passenden Compose-Datei starten

Starten Sie aus dem Verzeichnis, das die offiziellen Jitsi Compose-Dateien und die konfigurierte Umgebungsdatei enthält, den Basis-Stack mit der Jibri-Überschreibung:

docker compose -f docker-compose.yml -f jibri.yml up -d

Das offizielle Handbuch verwendet dieses Compose-Muster, um Jibri in die Docker-Bereitstellung einzubinden. Die Jibri-Überschreibung definiert das Container-Image, die Konfiguration, die Speichereinbindungen und die Zuweisung des gemeinsamen Speichers. Verwenden Sie die mit Ihrer gewählten Version mitgelieferte Datei; vermeiden Sie die Vermischung einer aktuellen jibri.ymlmit einer älteren .envoder einer Compose-Version.

Prüfen Sie, ob der Jibri-Dienst verfügbar bleibt, und überprüfen Sie dessen Protokolle zusammen mit Jicofo und Prosody:

docker compose ps jibri
docker compose logs --tail=100 jibri jicofo prosody

Ein laufender Container dient als erste Überprüfung und ist kein Beweis dafür, dass die Konferenz aufgezeichnet werden kann. Jibri muss sich beim korrekten XMPP-Host authentifizieren und dem erwarteten internen Brauerei-MUC beitreten. Falls die Protokolle Authentifizierungsfehler anzeigen, vergleichen Sie die XMPP-Domäne, den internen MUC, das Jibri-Konto, das Aufzeichnungskonto und die Passwörter in der Umgebungsdatei und der generierten Dienstkonfiguration. Die Werte müssen übereinstimmen; die Änderung des Passworts einer Komponente führt zum Abbruch des Handshakes.

Schritt 4: Testen Sie eine Aufnahme und einen RTMP-Stream

Nehmen Sie mit einem Moderatorenkonto an einer Testbesprechung teil meet.example.net. Überprüfen Sie im Menü „Weitere Aktionen“ der Besprechung, ob Aufzeichnung und Live-Streaming verfügbar sind. Starten Sie eine kurze Aufzeichnung, warten Sie, bis die Sitzung beendet ist, und prüfen Sie den konfigurierten Speicherpfad auf dem Host, um die Ausgabe zu finden. Die Aufzeichnung sollte auch nach dem Neuerstellen des Jibri-Containers erhalten bleiben, da sie auf dem eingebundenen Host-Volume und nicht nur im beschreibbaren Bereich des Containers gespeichert wird.

Für einen Livestream verwenden Sie die vom Zieldienst bereitgestellte RTMP-Ingest-URL und den Stream-Schlüssel. Geben Sie die aktuellen Provider-Werte im Livestream-Workflow von Jitsi ein und prüfen Sie den Vorschau- oder Empfangsstatus des Ziels. Da sich Provider-Dashboards und -Bezeichnungen ändern können, verwenden Sie die aktuellen RTMP-Anweisungen des Ziels. Behandeln Sie den Stream-Schlüssel wie ein Passwort: Veröffentlichen Sie ihn nicht im Meeting-Chat oder in Screenshots von Artikeln. Die Aufzeichnung im lokalen Speicher und das Senden eines Livestreams an einen RTMP-Dienst sind verwandte Jibri-Funktionen, verwenden jedoch unterschiedliche Ziele und führen unterschiedliche Prüfungen durch.

Fehlerbehebung anhand des Fehlerpunkts

• Es werden keine Aufzeichnungs- oder Stream-Aktionen angezeigt: Überprüfen Sie, ENABLE_RECORDING=1ob die entsprechende Umgebungsvariable in der aktiven Umgebungsdatei vorhanden ist und ob der zugehörige Compose-Stack nach der Änderung neu erstellt wurde. Überprüfen Sie die generierte Web-, Prosody- und Jicofo-Konfiguration, anstatt Dateien in einem laufenden Container zu bearbeiten; Docker generiert die Dienstkonfiguration anhand der Host-Eingaben neu.
• Die Aktion wird angezeigt, aber Jibri kann nicht beitreten: Überprüfen Sie die Jibri- und Jicofo-Protokolle auf XMPP-Authentifizierungs- oder MUC-Fehler. Überprüfen Sie den internen Host, die Recorder-Domäne, den Brewery-Namen und beide internen Passwörter anhand derselben Compose-Version.
• Der Container wird beendet oder neu gestartet: Überprüfen Sie die Protokolle auf einen fehlenden oder nicht beschreibbaren Speicherpfad. Stellen Sie bei aktuellen Images ohne Root-Rechte sicher, dass das eingebundene Verzeichnis für UID/GID 1000 beschreibbar ist. Überprüfen Sie außerdem den Host-Speicher und die in der offiziellen Jibri Compose-Datei angegebene Konfiguration für den gemeinsamen Speicher.
• Die Sitzung startet, aber es wird keine Aufzeichnungsdatei angezeigt: Überprüfen Sie, ob das konfigurierte Aufzeichnungsverzeichnis dem Host-Volume zugeordnet ist und ob die Sitzung ordnungsgemäß beendet wurde. Prüfen Sie den freien Speicherplatz und die Dateiberechtigungen.
• Die Aufnahme funktioniert, aber das Streaming schlägt fehl: Überprüfen Sie die RTMP-Ingest-URL und den Stream-Schlüssel, die aktuellen Anforderungen des Ziels und den ausgehenden Netzwerkpfad des Hosts. Suchen Sie in den Jibri-Protokollen nach dem Streaming-Fehler, anstatt ohne ersichtlichen Grund zusätzliche eingehende Ports zu öffnen.

Wenn ein Meeting funktioniert, Sie aber weitere gleichzeitige Aufnahmen benötigen, sollten Sie die Kapazität gezielt erhöhen. Da Jibri auf eine Sitzung pro Instanz beschränkt ist, benötigen parallele Aufträge mehr Instanzen. Das Docker-Handbuch empfiehlt außerdem, für mehrere Instanzen unterschiedliche Audio-Loopback-Schnittstellen auszuwählen. Testen Sie eine zusätzliche Instanz, bevor Sie den Pool erweitern, und stellen Sie sicher, dass jede Instanz eine separate Aufnahme erstellen kann.

Verwenden Sie diese offiziellen Referenzen

Befolgen Sie die Anweisungen, die zu Ihrer Bereitstellung passen, anstatt Einstellungen aus einer nicht zugehörigen Jibri-Version zu kopieren. Das Jitsi Docker-Handbuch dokumentiert den Compose-Workflow, Aufzeichnungsvariablen, Speicherpfade, Berechtigungen für Container ohne Root-Rechte und aktuelle Jibri-Hinweise. Die README-Datei des Jibri-Projekts erläutert die Rolle von Jibri, die Beschränkung auf eine einzelne Sitzung und das Konfigurationsmodell. Die offizielle Jibri Compose-Dienstdefinition und die Umgebungsvorlage sind die maßgebliche Quelle für versionsspezifische Variablennamen und Mounts.