Talk-Hochleistungs-Backend

Diese optionale Erweiterung folgt nach der abgeschlossenen Nextcloud- und HTTPS-Einrichtung. Sie gilt für die normale Installation und Quick Install v2. Alle Shell-Befehle werden als Root auf dem Server ausgeführt.

Warnmeldung verstehen

Kein Hochleistungs-Backend eingerichtet – Ohne das Hochleistungs-Backend skaliert Talk nur für kleinere Meetings (max. 2–3 Teilnehmer). Bitte das Hochleistungs-Backend einrichten, um sicherzustellen, dass Meetings mit mehreren Teilnehmern reibungslos funktionieren.

Das Hochleistungs-Backend (HPB) übernimmt die Signalisierung und die Verteilung von Audio- und Videodaten für Talk-Konferenzen. Die Angabe in der Warnung ist keine feste technische Teilnehmergrenze: Die nutzbare Größe hängt auch von Bandbreite, Hardware und den beteiligten Geräten ab.

Client-Push beschleunigt Änderungsbenachrichtigungen und ersetzt kein Talk-Hochleistungs-Backend. Für kleine Übungen kann die Warnung zunächst bestehen bleiben.

Voraussetzungen prüfen

Diese Variante ergänzt die manuell installierte Nextcloud um den eigenständigen Talk-Container aus Nextcloud AIO. Eine Neuinstallation der vorhandenen Nextcloud als AIO ist dafür nicht erforderlich.

• Nextcloud und HTTPS funktionieren; Talk ist installiert.
• Docker läuft auf dem vorgesehenen Host. Die Einrichtung richtet sich nach der Docker-Anleitung für Ubuntu.
• Der Docker-Host und der Container können den Nextcloud-Hostnamen auflösen und Nextcloud über HTTPS erreichen.
• Die HTTPS-Zertifikate werden von Nextcloud, dem Container und den Clients als vertrauenswürdig akzeptiert.
• Der lokale TCP-Port 8081 ist frei. Bei einer anderen Belegung die folgenden Portangaben konsistent anpassen.

Bei einem LXC-Testserver muss die Containerplattform den Betrieb von Docker unterstützen. Andernfalls einen separaten geeigneten Docker-Host verwenden; die hier gezeigte Apache-Zieladresse müsste dann entsprechend angepasst werden.

docker version
docker info

Falls Talk noch nicht installiert ist:

sudo -u www-data php -d apc.enable_cli=1 /var/www/nextcloud/occ app:install spreed

Talk-Container vorbereiten

Die Konfiguration in einer nur für Root lesbaren Datei ablegen:

install -d -m 700 /etc/nextcloud-talk-hpb
(umask 077; touch /etc/nextcloud-talk-hpb/container.env)
vi /etc/nextcloud-talk-hpb/container.env

Folgende Werte eintragen. NC_DOMAIN enthält den tatsächlichen Nextcloud-Hostnamen ohne Protokoll und ohne Pfad. Die drei Geheimnisse sind voneinander unabhängig; für jeden Platzhalter einmal openssl rand -hex 32 ausführen und das Ergebnis übernehmen. Es handelt sich um Dienstgeheimnisse, nicht um die Benutzerpasswörter aus der Workshop-Vorlage.

NC_DOMAIN=nc.home.arpa
TALK_PORT=3478
TURN_SECRET=TURN_GEHEIMNIS_EINTRAGEN
SIGNALING_SECRET=SIGNALING_GEHEIMNIS_EINTRAGEN
INTERNAL_SECRET=INTERNAL_GEHEIMNIS_EINTRAGEN

Den Container starten:

docker run --detach \
  --name nextcloud-talk-hpb \
  --restart unless-stopped \
  --env-file /etc/nextcloud-talk-hpb/container.env \
  --publish 127.0.0.1:8081:8081 \
  ghcr.io/nextcloud-releases/aio-talk:latest

Ohne DNS kann vor dem Image-Namen zusätzlich beispielsweise --add-host nc.home.arpa:10.174.243.218 eingefügt werden. Hostname und IP müssen zur tatsächlichen, vom Container erreichbaren Nextcloud-Adresse passen. Das ersetzt nicht die Einrichtung des Zertifikatsvertrauens.

Der Signalisierungsport ist nur lokal erreichbar; den externen Zugriff übernimmt Apache über HTTPS. Den lokalen Dienst prüfen:

curl --fail http://127.0.0.1:8081/api/v1/welcome
docker logs --tail 50 nextcloud-talk-hpb

Die Antwort muss JSON mit nextcloud-spreed-signaling und Welcome enthalten. Bei Containerfehlern zuerst die Protokolle auswerten.

Apache als Reverse Proxy ergänzen

Die Proxy-Module aktivieren und die vorhandene HTTPS-Site öffnen:

a2enmod proxy proxy_http proxy_wstunnel
vi /etc/apache2/sites-available/nextcloud-ssl.conf

Innerhalb des bestehenden <VirtualHost *:443>-Blocks folgende Regeln ergänzen. Die spezifische WebSocket-Regel muss vor der allgemeinen HTTP-Regel stehen. Vorhandene Nextcloud-, TLS- und HSTS-Einstellungen beibehalten:

ProxyPass "/standalone-signaling/spreed" "ws://127.0.0.1:8081/spreed"
ProxyPass "/standalone-signaling/" "http://127.0.0.1:8081/"
ProxyPassReverse "/standalone-signaling/" "http://127.0.0.1:8081/"

Konfiguration prüfen:

apache2ctl configtest

Nur bei Syntax OK Apache neu laden:

systemctl reload apache2

Den HTTPS-Endpunkt prüfen:

curl --fail https://nc.home.arpa/standalone-signaling/api/v1/welcome

Auch hier muss die JSON-Willkommensmeldung erscheinen. Bei einem lokalen Zertifikat gegebenenfalls dessen vertrauenswürdige CA mit --cacert angeben; Zertifikatsfehler nicht mit -k umgehen.

Backend in Talk eintragen

Unter Administrationseinstellungen → Talk → Hochleistungs-Backend eintragen:

Die Verbindung prüfen. Erst bei erfolgreicher Prüfung mit einem echten Testgespräch fortfahren. Die Warnung anschließend in der Administrationsübersicht erneut kontrollieren.

Audio und Video mit mehreren Teilnehmern prüfen

Ein erfolgreicher Signalisierungstest bestätigt noch keine funktionierende Medienverbindung. Ein Gespräch mit mindestens drei Geräten testen und Mikrofon, Kamera sowie Bildschirmfreigabe prüfen. Ein Test aus einem zweiten Netzwerk hilft, Probleme durch NAT und Firewalls zu erkennen.

Für eingeschränkte Netze ist häufig zusätzlich ein TURN-Server erforderlich. Der AIO-Talk-Container enthält eine TURN-Komponente; der obige Startbefehl veröffentlicht deren Ports jedoch noch nicht. Für die zusätzliche Einrichtung TALK_HOST, die TCP-/UDP-Portfreigaben und die TURN-Einstellungen in Talk nach der offiziellen TURN-Option konfigurieren. Die grundlegenden Netzwerkzusammenhänge beschreibt die Talk-Dokumentation zu TURN. Bei fehlenden Audio-/Videodaten auch die Medienpfade des WebRTC-Gateways prüfen.

Typische Fehler eingrenzen

Die Einrichtung wurde als Anleitung dokumentiert; die konkrete Testumgebung muss mit den oben beschriebenen Verbindungs- und Gesprächsprüfungen validiert werden.

Quellen: Talk-Installation mit Docker und Signalisierungsserver und Apache-Anbindung.