grommunio Meet 2026 produktionsnah einrichten

Ziel dieser Anleitung

Diese Anleitung zeigt dir, wie du grommunio Meet auf einer grommunio-2026.06.1-Appliance installierst, aktivierst, testest und eine instabile Videobridge gezielt reparierst. Es geht nicht nur darum, die Oberfläche zu öffnen. Entscheidend ist, dass mehrere Benutzer denselben Raum betreten können und die Verbindung danach stabil bleibt.

Du installierst die Meet-/Jitsi-Komponenten auf der bestehenden Appliance.
Du aktivierst das Meet-Plugin für grommunio Web.
Du prüfst Prosody, Jicofo, Videobridge, nginx und die Meet-Routen.
Du erkennst das Fehlerbild `videobridgeNotAvailable` und eine unhealthy JVB.
Du reparierst Jicofo-Konfiguration, JVB-Konfiguration, Colibri WebSocket, UDP 10000 und ICE/NAT-Mapping.
Du testest zwei und drei Teilnehmer mit echten Browser-Sessions.

Die Reihenfolge der grommunio-Serie bleibt bewusst praktisch: zuerst grommunio 2026.06.1 installieren, danach grommunio-auth mit Keycloak, grommunio-antispam mit Rspamd und jetzt grommunio Meet. Produktkontext findest du auf der grommunio-Produktseite.

Architektur: Was bei Meet zusammenspielt

grommunio Meet basiert auf Jitsi-Komponenten. Die Weboberfläche lädt den Raum, Prosody übernimmt XMPP-Signalisierung, Jicofo organisiert Konferenzen, und Jitsi Videobridge verteilt Audio-/Videostreams als SFU. Genau deshalb reicht ein HTTP-200 auf `/meet/` nicht als Abnahme: Wenn UDP, ICE oder die Videobridge nicht stimmen, sieht der Raum zuerst gut aus und bricht erst beim zweiten oder dritten Teilnehmer weg.

Browser
  -> /meet/ über nginx
  -> /meet/http-bind oder /meet/xmpp-websocket
  -> Prosody
  -> Jicofo
  -> Jitsi Videobridge
  -> UDP 10000 für Medien und Colibri WebSocket für Steuerkanal

Voraussetzungen

Eine lauffähige grommunio-2026.06.1-Appliance mit gültigem FQDN.
Funktionierender HTTPS-Zugriff auf grommunio Web und grommunio Admin.
DNS, Firewall und Reverse Proxy müssen zum verwendeten FQDN passen.
Für produktive Nutzung muss UDP `10000` von den Clients zur Videobridge erreichbar sein.
Wenn die Videobridge hinter NAT oder in einem privaten Netz steht, brauchst du ein korrektes ICE/NAT-Mapping.
Du brauchst administrativen Shell-Zugriff auf die Appliance.

Meet installieren

Auf der geprüften Appliance war Prosody bereits vorhanden, Jicofo, Jitsi Meet und Jitsi Videobridge wurden aber erst durch das Meet-Setup installiert. Prüfe zuerst, ob die Pakete schon vorhanden sind.

bash

rpm -qa | egrep 'jitsi|prosody|grommunio-web' | sort
systemctl is-enabled prosody jitsi-jicofo jitsi-videobridge 2>/dev/null || true

Die grommunio-Appliance bringt ein Setup-Teilskript für Meet mit. Verwende den echten FQDN deiner Umgebung. In unserer validierten Testumgebung war das `mail.example.test`.

bash

export FQDN="$(hostname -f)"
/usr/share/grommunio-setup/parts/grommunio-meet.sh

Nach dem Setup müssen Prosody, Jicofo und Videobridge aktiv sein. Genau hier fiel im Test zuerst Jicofo auf, weil die systemd-Unit den erwarteten Config-Pfad nicht gelesen hat.

bash

systemctl status --no-pager prosody jitsi-jicofo jitsi-videobridge
journalctl -u jitsi-jicofo -n 120 --no-pager
journalctl -u jitsi-videobridge -n 120 --no-pager

Meet in grommunio Web aktivieren

grommunio Web lädt Meet über das vorhandene Meet-Plugin. Prüfe die Konfiguration und aktiviere das Plugin bewusst. Danach startest du die Web-/PHP-Komponenten neu.

bash

grep -R "meet" -n /etc/grommunio-web /usr/share/grommunio-web/plugins/meet 2>/dev/null | head -80

# /etc/grommunio-web/config-meet.php
# Der Eintrag muss sinngemäß aktiv sein:
# 'enable' => true,

systemctl restart nginx php-fpm

Prüfe danach die öffentlichen Meet-Routen. `/meet/`, `/meet/config.js`, `/meet/http-bind`, `/meet/xmpp-websocket` und die Colibri-WebSocket-Pfade müssen über den gleichen FQDN erreichbar sein, den auch Benutzer im Browser verwenden.

bash

curl -kI https://mail.example.test/meet/
curl -kI https://mail.example.test/meet/config.js
curl -kI https://mail.example.test/meet/test-room

https://mail.example.test/meet/forgeone-meet-stability

Screenshot: Der Meet-Raum lädt und zeigt den Beitrittsdialog. Das allein ist noch keine technische Abnahme.

Jicofo-Fix: Config-Pfad explizit setzen

Im Test startete Jicofo zunächst nicht sauber. Die Meldung war sinngemäß: Jicofo benötigt eine Konfigurationsdatei und erwartet `JAVA_SYS_PROPS` mit `-Dconfig.file=...`. Der robuste Fix ist eine explizite `/etc/jitsi/jicofo/config` und eine klare HOCON-Datei.

bash

cat >/etc/jitsi/jicofo/config <<'EOF'
JAVA_SYS_PROPS="-Dconfig.file=/etc/jitsi/jicofo/jicofo.conf"
EOF

# /etc/jitsi/jicofo/jicofo.conf
jicofo {
  xmpp {
    client {
      hostname = "localhost"
      port = 5222
      domain = "auth.mail.example.test"
      xmpp-domain = "mail.example.test"
      username = "focus"
      password = "<generated-focus-password>"
      conference-muc-jid = "conference.mail.example.test"
      client-proxy = "focus.mail.example.test"
      disable-certificate-verification = true
    }
    trusted-domains = [ "recorder.mail.example.test" ]
  }
  bridge {
    brewery-jid = "JvbBrewery@internal.auth.mail.example.test"
  }
}

systemctl restart jitsi-jicofo
systemctl is-active jitsi-jicofo

Veröffentliche Passwörter oder generierte XMPP-Secrets nicht in Tickets, Screenshots oder Blogposts. In der Anleitung steht deshalb ein Platzhalter.

JVB-Fix: Config laden, WebSocket setzen, UDP und ICE prüfen

Die Videobridge muss ihre HOCON-Konfiguration wirklich laden. In der geprüften Paketlage war dafür ein systemd-Override nötig. Ohne diesen Override kann eine sauber aussehende Datei existieren, die JVB aber trotzdem ignoriert.

bash

mkdir -p /etc/systemd/system/jitsi-videobridge.service.d
cat >/etc/systemd/system/jitsi-videobridge.service.d/override.conf <<'EOF'
[Service]
Environment=JAVA_SYS_PROPS=-Dconfig.file=/etc/jitsi/videobridge/jvb.conf
EOF

systemctl daemon-reload

Für eine interne oder NAT-Topologie musst du zwei Dinge trennen: die lokale Adresse der Bridge und die Adresse, die Clients tatsächlich erreichen. In unserer validierten internen Umgebung war die Bridge in der VM `10.0.2.15`, erreichbar wurde sie vom Browser über die interne Host-Adresse. In Produktion ersetzt du diese Werte durch deine echten Adressen.

bash

# /etc/jitsi/videobridge/jvb.conf
videobridge {
  http-servers {
    public {
      host = 0.0.0.0
      port = 9090
      send-server-version = false
    }
    private {
      port = 8081
      tls-port = -1
    }
  }
  health {
    # Für rein interne 10.x-Topologien sinnvoll; bei Public Deployments vorher bewusst prüfen.
    require-valid-address = false
  }
  websockets {
    enabled = true
    domains = [ "mail.example.test:443" ]
    tls = true
  }
  apis.xmpp-client.configs {
    shard {
      hostname = "localhost"
      domain = "auth.mail.example.test"
      username = "jvb"
      password = "<generated-jvb-password>"
      muc_jids = "JvbBrewery@internal.auth.mail.example.test"
      muc_nickname = "<unique-bridge-id>"
      disable-certificate-verification = true
    }
  }
}

ice4j {
  harvest {
    use-ipv6 = false
    mapping {
      aws.enabled = false
      stun.enabled = false
      static-mappings = [
        {
          local-address = "10.0.2.15"
          public-address = "10.10.0.12"
        }
      ]
    }
  }
}

systemctl restart jitsi-videobridge jitsi-jicofo

Wichtig: `public-address` ist nicht automatisch eine öffentliche Internetadresse. Sie ist die Adresse, die deine Clients erreichen. In einem rein internen Deployment kann das eine interne 10er-Adresse sein. Bei externen Teilnehmern muss es die von außen erreichbare Adresse sein, und Firewall/NAT müssen UDP `10000` passend weiterleiten.

bash

ss -lntup | egrep '(:10000|:5222|:5280|:5281|:8081|:9090)' || true
journalctl -u jitsi-videobridge -n 120 --no-pager | egrep -i 'static mapping|Authenticated|Joined MUC|Health|No valid IP|SEVERE|ERROR' || true
curl -sS -w 'HTTP_STATUS=%{http_code}\n' http://127.0.0.1:8081/about/health || true

Fehlerbild: Wenn der zweite Teilnehmer alles kaputt macht

Der typische Fehler ist trügerisch. Der erste Benutzer kann den Raum öffnen, der zweite Benutzer kann kurz beitreten, danach verschwinden Teilnehmer, die Oberfläche zeigt Reconnect, und im Browser steht `conference.videobridgeNotAvailable` oder der BridgeChannel schließt.

CONFERENCE FAILED: conference.videobridgeNotAvailable
BridgeChannel closed
triggering ice restart

# Serverseitig war das entscheidende Signal:
Health check failed: No valid IP addresses available for harvesting.

In unserem Test war die Ursache nicht grommunio Web und nicht der Raum selbst. Jicofo, Prosody und JVB mussten korrekt zusammenspielen, und der Medienpfad über UDP `10000` musste für die Clients erreichbar sein.

Zwei Benutzer testen

Teste Meet nicht mit einem einzelnen Browserfenster. Verwende zwei getrennte Browser-Kontexte, zwei Profile oder zwei echte Geräte. Beide Benutzer müssen denselben Raum sehen und die Teilnehmeranzahl muss stabil bleiben.

https://mail.example.test/meet/forgeone-meet-stability

Screenshot: Der erste Benutzer ist im Raum. Das Video kommt aus einem Testgerät, damit der Ablauf reproduzierbar bleibt.

https://mail.example.test/meet/forgeone-meet-stability

Screenshot: Nach dem Fix bleiben zwei getrennte Browser-Sessions im selben Raum verbunden.

Abnahmekriterien für zwei Benutzer:
- beide klicken "Beitreten"
- beide sehen den anderen Teilnehmer
- Teilnehmerzähler bleibt bei 2
- keine fehlgeschlagenen /meet- oder /colibri-ws-Requests
- kein videobridgeNotAvailable
- kein ICE-Restart
- kein BridgeChannel-Close

Drei Benutzer und Stabilität testen

Der zweite Test geht weiter: drei getrennte Browser-Sessions treten demselben Raum bei. Danach wird nicht sofort abgebrochen, sondern über 30, 60 und 120 Sekunden geprüft. Genau dadurch fällt eine Videobridge auf, die erst nach ihrem Health-Intervall aus dem Pool fällt.

https://mail.example.test/meet/forgeone-meet-stability

Screenshot: Der dritte Benutzer tritt dem laufenden Raum bei.

https://mail.example.test/meet/forgeone-meet-stability

Screenshot: Nach 30 Sekunden sind drei Teilnehmer weiterhin sichtbar.

https://mail.example.test/meet/forgeone-meet-stability

Screenshot: Nach 60 Sekunden bleibt die Konferenz stabil.

https://mail.example.test/meet/forgeone-meet-stability

Screenshot: Nach 120 Sekunden sind alle drei Teilnehmer weiterhin verbunden.

Finale Abnahme aus dem Test:
- Prosody: active
- Jicofo: active
- Jitsi Videobridge: active
- JVB Health: HTTP 200
- drei Teilnehmer nach 30 Sekunden sichtbar
- drei Teilnehmer nach 60 Sekunden sichtbar
- drei Teilnehmer nach 120 Sekunden sichtbar
- failedRequests: 0
- videobridgeNotAvailable: 0
- BridgeChannel closed: 0

Produktions-Checkliste

FQDN, TLS-Zertifikat und nginx-Routen für `/meet/` prüfen.
Prosody, Jicofo und JVB als systemd-Dienste überwachen.
UDP `10000` aus den realen Client-Netzen zur Videobridge öffnen.
Colibri WebSocket über HTTPS/WebSocket-Proxy testen.
Bei NAT eine statische ICE-Zuordnung mit lokaler Bridge-Adresse und erreichbarer Client-Adresse setzen.
Bei rein interner 10.x-Nutzung JVB Health bewusst auf diese Topologie abstimmen.
IPv6 nur aktiv lassen, wenn DNS, Routing und Firewall dafür wirklich stimmen.
Zwei und drei Teilnehmer mit getrennten Geräten oder Browser-Profilen testen.
Logs auf `videobridgeNotAvailable`, `No valid IP addresses available for harvesting`, ICE-Restarts und BridgeChannel-Fehler prüfen.
Nach Updates denselben Mehrbenutzer-Test wiederholen.

Quellen und geprüfte Grundlage

grommunio 2026.06.1 Release Notes: grommunio Suite mit Meetings, Identitäten und neuer Admin-Oberfläche.
grommunio Roadmap: 2026.06.1 als aktuelle stabile GA-Version mit openSUSE-Leap-16.0-Appliance-Basis.
Jitsi Self-Hosting Guide: statisches ICE/NAT-Mapping in `ice4j.harvest.mapping.static-mappings` für Videobridges hinter NAT.
Geprüfte Appliance: grommunio 2026.06.1, Meet/Jitsi-Pakete aus dem grommunio-Repository, synthetischer FQDN `mail.example.test`, Mehrbenutzer-Test mit echten Browser-Kontexten.

grommunio 2026 Schritt für Schritt

Diese Reihe ist als praktische Reihenfolge gedacht: erst die Grundinstallation, danach Mail-Schutz, zentrale Anmeldung, Videokonferenzen und anschließend Chat.

grommunio 2026 installieren
grommunio-antispam mit Rspamd einrichten
grommunio-auth mit Keycloak einrichten
grommunio Meet einrichten und testen (du bist hier)
grommunio Chat einrichten und testen

Lizenzen und Evaluierung

Wenn du grommunio evaluieren möchtest oder Lizenzen für eine produktive Umgebung benötigst, kannst du dich an ForgeOne wenden. Als grommunio Gold Partner unterstützen wir bei Architektur, Lizenzierung, Installation, Migration, SSO, Antispam, Meet, Monitoring, Backup und Support.

grommunio Meet produktiv einführen

ForgeOne plant, lizenziert und betreibt grommunio als souveräne Collaboration-Plattform inklusive Mail, Kalender, Kontakte, grommunio-auth, grommunio-antispam, grommunio Meet, Monitoring, Backup und Support. Wenn du Videokonferenzen in deine grommunio-Umgebung integrieren willst, prüfen wir Netzwerkpfad, TLS, TURN/STUN, Firewall, Benutzerrechte und Betrieb gemeinsam.

grommunio Meet besprechen

grommunio Meet 2026 einrichten: Videokonferenzen, Jitsi Videobridge und Mehrbenutzer-Test

Ziel dieser Anleitung

Architektur: Was bei Meet zusammenspielt

Voraussetzungen

Meet installieren

Meet in grommunio Web aktivieren

Jicofo-Fix: Config-Pfad explizit setzen

JVB-Fix: Config laden, WebSocket setzen, UDP und ICE prüfen

Fehlerbild: Wenn der zweite Teilnehmer alles kaputt macht

Zwei Benutzer testen

Drei Benutzer und Stabilität testen

Produktions-Checkliste

Quellen und geprüfte Grundlage

grommunio 2026 Schritt für Schritt

Lizenzen und Evaluierung

grommunio Meet produktiv einführen

Ähnliche Beiträge

grommunio 2026 als Collaboration-Plattform installieren

grommunio-antispam für sichere Groupware betreiben

grommunio-auth mit Keycloak und MFA integrieren