Nextcloud/Talk/HPB/Signaling-Server: Unterschied zwischen den Versionen
| Zeile 209: | Zeile 209: | ||
==== Anwendung ==== | ==== Anwendung ==== | ||
'''Wichtig''': Vor dem Ausführen des Programms muß die Konfigurationsdatei des Signaling-Servers dahingehend editiert werden, daß nicht nur das eigentliche Backend zugelassen wird, sondern alle. Dazu muß in der Datei /etc/signaling/server.conf der Eintrag "'''allowall = true'''" vorhanden sein. Nachdem Neustart des Signaling-Servers kann der Test-Client gestartet werden: | '''Wichtig''': Vor dem Ausführen des Programms muß die Konfigurationsdatei des Signaling-Servers dahingehend editiert werden, daß nicht nur das eigentliche Backend zugelassen wird, sondern alle. Dazu muß in der Datei /etc/signaling/server.conf der Eintrag "'''allowall = true'''" vorhanden sein. Nachdem Neustart des Signaling-Servers kann der Test-Client gestartet werden: | ||
# '''systemctl restart signaling''' | |||
# '''client -addr localhost:8080 -config /etc/signaling/server.conf''' | |||
==== Bewertung der Ergebinisse ==== | ==== Bewertung der Ergebinisse ==== | ||
Version vom 23. April 2022, 14:01 Uhr
topic kurze Beschreibung
Beschreibung
- Der Signaling-Server (https://github.com/strukturag/nextcloud-spreed-signaling) ermöglicht Clients, die eine direkte Verbindung zueinander aufbauen wollen, den Austausch von Informationen, die dies gewährleisten.
- Möchte sich ein Client A mit einem Client B verbinden, signalisiert er dies dem Signaling-Server.
- Sollte Client B der Verbindungsanfrage zustimmen, übermittelt dieser seine Verbindungsinformationen an den Signaling-Server, der diese an Client A weiterreicht.
- Daraufhin erfolgt der direkte Verbindungsaufbau zwischen den Clients A und B.
Installation
Zur Installation des Servers wird das Paket golang-go benötigt, welches über die Paketverwaltung installiert werden kann:
# apt install golang-go
Die benötigten Quellpakete werden über GitHub bezogen und hier im Verzeichnis /usr/src abgelegt:
cd /usr/src git clone https://github.com/strukturag/nextcloud-spreed-signaling.git cd /usr/src/nextcloud-spreed-signaling
Der anschließende Befehl make build erstellt das Programm bin/signaling
make build
Syntax
Parameter
Optionen
Konfiguration
# mkdir -p /etc/signaling # cp /usr/src/nextcloud-spreed-signaling/server.conf.in /etc/signaling/server.conf
und die Berechtigungen angepasst:
# chmod 600 /etc/signaling/server.conf # chown signaling: /etc/signaling/server.conf
Entsprechend den lokalen Begebenheiten wir diese Datei wie folgt editiert:
listen = 127.0.0.1:8080 ... [sessions] hashkey = <Hash-Key> ... blockkey = <Block-Key> ... [backend] backends = backend1 [backend1] url = https://cloud.foxtom.de ... secret = <Nextcloud Secret Key> ... [nats] url = nats://localhost:4222 ... [mcu] type = janus ... url = ws://127.0.0.1:8188 ... [turn] apikey = <api-key> secret = <TURN-Server-Key> servers = turn:cloud.foxtom.de:5349?transport=udp,turn:cloud.foxtom.de:5349?transport=tcp ...
Zum automatischen Starten des Signaling-Servers als Systemdienst werden die folgenden Befehle ausgeführt:
cp dist/init/systemd/signaling.service /etc/systemd/system/signaling.service systemctl enable signaling.service systemctl start signaling.service
Um den Signaling-Server als Systemdienst installieren zu können, wird ein Benutzer und eine Gruppe angelegt:
groupadd signaling useradd --system --gid signaling --shell /usr/sbin/nologin --comment "Standalone signaling server for Nextcloud Talk." signaling
und die Berechtigungen angepasst:
chmod 600 /etc/signaling/server.conf chown signaling: /etc/signaling/server.conf
Entsprechend den lokalen Begebenheiten wir diese Datei wie folgt editiert:
listen = 127.0.0.1:8080 ... [sessions] hashkey = <Hash-Key> ... blockkey = <Block-Key> ... [backend] backends = backend1 [backend1] url = https://cloud.foxtom.de ... secret = <Nextcloud Secret Key> ... [nats] url = nats://localhost:4222 ... [mcu] type = janus ... url = ws://127.0.0.1:8188 ... [turn] apikey = <api-key> secret = <TURN-Server-Key> servers = turn:cloud.foxtom.de:5349?transport=udp,turn:cloud.foxtom.de:5349?transport=tcp ...
Signaling Server als Systemdienst
Zum automatischen Starten des Signaling-Servers als Systemdienst werden die folgenden Befehle ausgeführt:
cp dist/init/systemd/signaling.service /etc/systemd/system/signaling.service systemctl enable signaling.service systemctl start signaling.service
- Damit der Signaling Server nicht jedesmal über die Konsole im Vordergrund gestartet werden muss, sollte dieser als Systemdienst installiert werden.
- Dazu stoppen wir erst einmal die Konsolen-Instanz.
- Zunächst legen wir uns einen speziellen User für den Signaling Server an:
groupadd signaling useradd --system --gid signaling --shell /usr/sbin/nologin --comment "Standalone signaling server for Nextcloud Talk." signaling
- Anschließend wird die Konfigurationsdatei des Servers noch an einen anderen Ort kopiert (damit diese zum Beispiel bei einem Update nicht überschrieben wird).
- Ebenso werden die entsprechenden Berechtigungen gesetzt:
mkdir -p /etc/signaling cp server.conf /etc/signaling/server.conf chmod 600 /etc/signaling/server.conf chown signaling: /etc/signaling/server.conf
- Nun editieren wir noch die Datei für den Systemdienst:
vi dist/init/systemd/signaling.service [Unit] Description=Nextcloud Talk signaling server [Service] ExecStart=/etc/nextcloud-spreed-signaling/bin/signaling --config /etc/signaling/server.conf User=signaling Group=signaling Restart=on-failure [Install] WantedBy=multi-user.target
Der Dienst wird im System registriert und aktiviert:
cp dist/init/systemd/signaling.service /etc/systemd/system/signaling.service systemctl enable signaling.service systemctl start signaling.service
Anschließend wird der Signaling Server bei jedem Systemstart gestartet.
Anwendungen
Starten des Signaling-Servers
Ist Janus-Server bereits gestartet, kann der Signaling-Server für einen Test direkt aufgerufen werden:
# signaling --config /etc/signaling/server.conf 2021-01-06 15:11:51.109402 I | main.go:130: Starting up version 64cccab641874b3e688c1eb9029b5bb9215741e5/go1.11.6 as pid 9913 2021-01-06 15:11:51.109824 I | main.go:139: Using a maximum of 1 CPUs 2021-01-06 15:11:51.111647 I | natsclient.go:116: Connection established to nats://localhost:4222 (ND2IPCPXAOZMW5QPQ3R476UVGKI42RUNGIQ7YOHLNHK3QLTS7HXIVIWH) 2021-01-06 15:11:51.111713 I | backend_configuration.go:77: Backend backend1 added for https://cloud.foxtom.de/ 2021-01-06 15:11:51.111723 I | hub.go:177: Using a maximum of 8 concurrent backend connections per host 2021-01-06 15:11:51.111739 I | hub.go:184: Using a timeout of 10s for backend connections 2021-01-06 15:11:51.111759 I | hub.go:270: Not using GeoIP database 2021-01-06 15:11:51.113242 I | mcu_janus.go:289: Connected to Janus WebRTC Server 0.9.2 by Meetecho s.r.l. 2021-01-06 15:11:51.113260 I | mcu_janus.go:293: Found JANUS VideoRoom plugin 0.0.9 by Meetecho s.r.l. 2021-01-06 15:11:51.113269 I | mcu_janus.go:299: Data channels are supported 2021-01-06 15:11:51.113274 I | mcu_janus.go:305: Full-Trickle is enabled 2021-01-06 15:11:51.113280 I | mcu_janus.go:308: Maximum bandwidth 1048576 bits/sec per publishing stream 2021-01-06 15:11:51.113285 I | mcu_janus.go:309: Maximum bandwidth 2097152 bits/sec per screensharing stream 2021-01-06 15:11:51.114259 I | mcu_janus.go:315: Created Janus session 6900302758812903 2021-01-06 15:11:51.114951 I | mcu_janus.go:322: Created Janus handle 7778710372665701 2021-01-06 15:11:51.115064 I | main.go:226: Using janus MCU 2021-01-06 15:11:51.115132 I | hub.go:357: Using a timeout of 10s for MCU requests 2021-01-06 15:11:51.115192 I | backend_server.go:94: Using configured TURN API key 2021-01-06 15:11:51.115250 I | backend_server.go:95: Using configured shared TURN secret 2021-01-06 15:11:51.115315 I | backend_server.go:97: Adding "turn:cloud.foxtom.de:5349?transport=udp" as TURN server 2021-01-06 15:11:51.115372 I | backend_server.go:97: Adding "turn:cloud.foxtom.de:5349?transport=tcp" as TURN server 2021-01-06 15:11:51.115420 I | backend_server.go:104: No IPs configured for the stats endpoint, only allowing access from 127.0.0.1 2021-01-06 15:11:51.115613 I | main.go:302: Listening on 127.0.0.1:8080
Debugging
Log prüfen
Mit dem Befehl journalctl lassen sich die Einträge des Systemd-Logbuchs zum Siganling-Servers ausgeben:
# journalctl -u signaling -- Logs begin at Mon 2021-02-01 13:01:38 CET, end at Mon 2021-02-01 14:21:47 CET. -- Feb 01 13:01:38 signaling signaling[10668]: client.go:251: Client from 46.90.62.181 has RTT of 127 ms (127.606144ms) Feb 01 13:01:38 signaling signaling[10668]: client.go:251: Client from 91.64.35.249 has RTT of 71 ms (71.768255ms) Feb 01 13:01:38 signaling signaling[10668]: client.go:251: Client from 91.64.2.4 has RTT of 49 ms (49.079442ms) Feb 01 13:01:38 signaling signaling[10668]: client.go:251: Client from 89.249.64.252 has RTT of 60 ms (60.899805ms) Feb 01 13:01:39 signaling signaling[10668]: client.go:251: Client from 217.94.247.3 has RTT of 37 ms (37.689669ms) Feb 01 13:01:39 signaling signaling[10668]: client.go:251: Client from 95.90.232.210 has RTT of 57 ms (57.636709ms) Feb 01 13:01:39 signaling signaling[10668]: client.go:251: Client from 91.64.50.230 has RTT of 54 ms (54.221002ms) ...
Fehlermeldungen sind bei der aktuell laufenden Instanz des Signaling-Servers von dieser Art und nur sporadisch:
Feb 01 13:02:23 signaling signaling[10668]: client.go:271: Error reading from 95.90.245.7: read tcp 127.0.0.1:8080->127.0.0.1:35230: use of closed network connection
Debug-/Loglevel einstellen
Test und Benchmarking
Benchmark client
Installation
Zum Testen des Signaling-Servers wird ein einfaches Client-Programm zur Verfügung gestellt, welches jedoch zuvor kompiliert werden muß:
$ cd /usr/src/nextcloud-spreed-signaling/ $ make client
Konfiguration
Das Programm befindet sich im Anschluß im Verzeichnis /usr/src/nextcloud-spreed-signaling/bin/ und kann mit folgenden Optionen ausgeführt werden:
- -addr <http-Service-Adresse> (Standard ist localhost:28080)
- -config <Konfigurationsdatei>
- -maxClients <Anzahl der Client-Verbindungen> (Standardwert ist 100)
Anwendung
Wichtig: Vor dem Ausführen des Programms muß die Konfigurationsdatei des Signaling-Servers dahingehend editiert werden, daß nicht nur das eigentliche Backend zugelassen wird, sondern alle. Dazu muß in der Datei /etc/signaling/server.conf der Eintrag "allowall = true" vorhanden sein. Nachdem Neustart des Signaling-Servers kann der Test-Client gestartet werden:
# systemctl restart signaling # client -addr localhost:8080 -config /etc/signaling/server.conf
Bewertung der Ergebinisse
Bei der derzeitigen Implementierung des (laufenden) Signaling-Servers werden jedoch Fehler erzeugt:
2021-02-01 12:53:51.717590 I | Using a maximum of 1 CPUs 2021-02-01 12:53:51.717978 I | Backend server running on http://95.217.178.11:33031 2021-02-01 12:53:51.718066 I | Connecting to [ws://localhost:8080/spreed] 2021-02-01 12:53:51.718130 I | Starting 100 clients 2021-02-01 12:53:51.720849 I | Unsupported message type: {Id: Type:error Error:Incomplete OCS response Hello:<nil> Bye:<nil> Room:<nil> Message:<nil> Control:<nil> Event:<nil>} ... 2021-02-01 12:53:51.856629 I | Unsupported message type: {Id: Type:error Error:Incomplete OCS response Hello:<nil> Bye:<nil> Room:<nil> Message:<nil> Control:<nil> Event:<nil>} 2021-02-01 12:53:51.857998 I | Clients created 2021-02-01 12:53:51.859424 I | Unsupported message type: {Id: Type:error Error:Incomplete OCS response Hello:<nil> Bye:<nil> Room:<nil> Message:<nil> Control:<nil> Event:<nil>} 2021-02-01 12:53:54.072980 I | Received bye: &{Reason:hello_timeout} ... 2021-02-01 12:53:54.090515 I | Received bye: &{Reason:hello_timeout}
Die Ausgabe einer erfolgreichen Programmausführung ist folgend gezeigt (die user-ID's der sample-user wurden stark verkürzt):
$ ./client -addr localhost:8081 -config /etc/signaling/server.conf 2021-02-01 13:02:45.432124 I | Using a maximum of 2 CPUs 2021-02-01 13:02:45.433055 I | Backend server running on http://192.168.178.63:40305 2021-02-01 13:02:45.433136 I | Connecting to [ws://localhost:8081/spreed] 2021-02-01 13:02:45.433157 I | Starting 100 clients 2021-02-01 13:02:45.448228 I | Registered as MTYxMjE4MDk2NXxaUXQxVEVydXVxLXEwZm1zRZUdHQmyVW (userid sample-user) 2021-02-01 13:02:45.450357 I | Registered as MTYxMjE4MDk2NXw1aHRKWU14TWxoWWwyaM2ZhQTy88IIDt (userid sample-user) ... 2021-02-01 13:02:45.584143 I | Registered as MTYxMjE4MDk2NXxsUXVtblgyM0stanRGWDBDVlU1CaFRYO (userid sample-user) 2021-02-01 13:02:45.585374 I | Clients created 2021-02-01 13:02:45.585884 I | Registered as MTYxMjE4MDk2NXxMOTJzNkV1UkJMNGlueGR5OjOcJwcQiv (userid sample-user) 2021-02-01 13:02:45.586546 I | Registered as MTYxMjE4MDk2NXxkMmNLaHZVamY5OWpsWEJmDYeRaCx7L0 (userid sample-user) 2021-02-01 13:02:45.586572 I | All connections established 2021-02-01 13:02:55.589250 I | Stats: sent=386158 (38615/sec), recv=386154 (38615/sec), delta=4 2021-02-01 13:03:05.587561 I | Stats: sent=766105 (42216/sec), recv=765975 (42202/sec), delta=130 ... 2021-02-01 13:04:15.586929 I | Stats: sent=3377364 (40248/sec), recv=3376924 (40219/sec), delta=440 2021-02-01 13:04:25.589070 I | Stats: sent=3754158 (37679/sec), recv=3754115 (37719/sec), delta=43 ^C2021-02-01 13:04:31.612013 I | Interrupted 2021-02-01 13:04:31.612031 I | Waiting for clients to terminate ...
Sicherheit
Dokumentation
RFC
Man-Pages
Info-Pages
Projekt-Homepage
Links
Siehe auch
Weblinks
Einzelnachweise
Testfragen
Testfrage 1
Testfrage 2
Testfrage 3
Testfrage 4
Testfrage 5
TMP
Signalisierungsserver für Nextcloud
Vor kurzem wurde die Software zum Betrieb von Nextcloud Talk in größeren Nextcloudumgebungen als Open Source veröffentlicht: man braucht einen eigenen Signalisierungsserver, um mit mehreren Leuten parallel effektiv über Nextcloud Talk arbeiten zu können.
- Per Default wird der interne verwendet.
- Aufsetzen des Signalisierungsservers: https://github.com/strukturag/nextcloud-spreed-signaling
Voraussetzungen
Einen STUN Server als auch den Signalisierungsserver auf eigenen VMs betreiben.
- Den STUN Server sollte man bereits auf einer anderen Maschine gesondert betreiben:
Installation der Services
Sytemvoraussetzung: Debian 10
Den Signaling Server direkt von Github selbst kompilieren:
# apt install git automake golang build-essential certbot nginx apt-transport-https ca-certificates curl gnupg-agent software-properties-common
cd /usr/src
git clone https://github.com/strukturag/nextcloud-spreed-signaling.git cd nextcloud-spreed-signaling/
make build
cp bin/signaling /usr/bin/
Nun die Konfigurationsdatei aus dem Repo an die richtige Stelle kopieren.:
mkdir /etc/signaling/
cp server.conf.in /etc/signaling/server.conf
Anlegen eines users:
useradd --system --shell /usr/sbin/nologin --comment "Standalone signaling server for Nextcloud Talk." signaling
chown signaling: /etc/signaling/server.conf
chmod 600 /etc/signaling/server.conf
Anschließend den Service für den Signaling Server einrichten und vorher natürlich die Systemd Datei entsprechend eurer Pfade anpassen, wenn abweichend:
cp dist/init/systemd/signaling.service /etc/systemd/system/signaling.service
systemctl daemon-reload
systemctl enable signaling
Konfiguration des Signaling Servers
Abschließend müssen wir den Signaling Server noch konfigurieren:
vi /etc/signaling/server.conf
- hashkey mit openssl rand -hex 16 generieren
- blockkey mit openssl rand -hex 16 generieren
- internalsecret ebenfalls mit einem String Generator setzen
- unter allowed alle Hostnamen eintragen, die dieses Backend verwenden dürfen
- direkt darunter bei secret ein Secret generieren:
Das wird später bei Nextcloud in den Settings eingetragen
- connectionsperhost sollte adaptiert werden
- unter nats wird die url so gesetzt: url = nats://localhost:4222
- bei mcu wird die url so gesetzt: url = ws://0.0.0.0:8188 (Janus läuft nicht localhost, ist noch ein offenes Security Thema)
- unter turn wird apikey mit dem gleichen Wert vom Janus Server (turn_rest_api_key) gesetzt
- das secret in der Rubrik turn bekommt den gleichen Wert wie static-auth-secret des Turnserver gesetzt
- bei servers werden alle Turnserver kommasepariert so gesetzt: turn:116.202.113.XXX:5349?transport=tcp
Nun sollte
systemctl status signaling
erfolgreich sein.
Nextcloud Integration
Installiert die Beta Version von Nextcloud Talk – am besten zum Testen mal in einer eigenen Installation auf dem Beta Release Channel für Nextcloud 19.
- In den Einstellungen von Nextcloud im Reiter Talk nun folgende Konfiguration setzen:
STUN und Signaling Server
- Das gemeinsame Geheimnis ist das secret aus der Signaling Server conf.
Quelle: https://nichteinschalten.de/signalisierungsserver-fuer-nextcloud-aufsetzen-how-to/
Apache
Um den Apache-Webservice als Frontend für den eigenständigen Signalisierungsserver zu konfigurieren, müssen die Module mod_proxy_http und mod_proxy_wstunnel aktiviert sein, damit WebSocket- und API-Backend-Anforderungen weitergeleitet werden können:
# a2enmod proxy # a2enmod proxy_http # a2enmod proxy_wstunnel
Jetzt kann die Apache VirtualHost -Konfiguration erweitert werden, um Anforderungen an den eigenständigen Signalisierungsserver weiterzuleiten (vorausgesetzt, der Server wird auf der lokalen Schnittstelle an Port 8080 unten ausgeführt):
<VirtualHost *:443> # ... existing configuration ... # Enable proxying Websocket requests to the standalone signaling server. ProxyPass "/standalone-signaling/" "ws://127.0.0.1:8080/" RewriteEngine On # Websocket connections from the clients. RewriteRule ^/standalone-signaling/spreed$ - [L] # Backend connections from Nextcloud. RewriteRule ^/standalone-signaling/api/(.*) http://127.0.0.1:8080/api/$1 [L,P] # ... existing configuration ... </VirtualHost>
Einrichtung des Frontend-Webservers
Normalerweise wird der eigenständige Signalisierungsserver hinter einem Webserver ausgeführt, der das SSL-Protokoll ausführt oder als Load Balancer für mehrere Signalisierungsserver fungiert.
In den folgenden Konfigurationsbeispielen wird von einem vorkonfigurierten Webserver (Nginx oder Apache) mit einem funktionierenden HTTPS-Setup ausgegangen, der die externe Schnittstelle des Servers überwacht, auf dem sich der eigenständige Signalisierungsserver befindet.
Nachdem alles eingerichtet wurde, kann die Konfiguration mit curl getestet werden:
$ curl -i https: //myserver.domain.invalid/standalone-signaling/api/v1/welcome HTTP / 1.1 200 OK Datum: Do, 05. Juli 2018 09:28:08 GMT Server: nextcloud-spreed-signalisierung / 1.0 .0 Inhaltstyp: application / json; Zeichensatz = utf-8 Inhaltslänge: 59
{"nextcloud-spreed-signalisierung": "Willkommen", "Version": "1.0.0"}
Einrichtung von Nextcloud Talk
Melden Sie sich bei Ihrer Nextcloud als Administrator an und öffnen Sie die Seite mit den zusätzlichen Einstellungen.
Scrollen Sie zum Abschnitt "Talk" und geben Sie die Basis-URL Ihres eigenständigen Signalisierungsservers in das Feld "Externer Signalisierungsserver" ein.
Bitte beachten Sie, dass Sie https verwenden müssen, wenn Ihre Nextcloud auch unter https ausgeführt wird.
Normalerweise sollten Sie https: // myhostname / Standalone-Signaling als URL eingeben.
Der Wert "Shared Secret für externen Signalisierungsserver" muss mit dem Eigenschaftsgeheimnis im Abschnitt "Backend" Ihrer server.conf übereinstimmen.
Wenn Sie ein selbstsigniertes Zertifikat für die Entwicklung verwenden, müssen Sie das Kontrollkästchen SSL-Zertifikat validieren deaktivieren, damit Backend-Anforderungen von Nextcloud an den Signalisierungsserver ausgeführt werden können.
Benchmarking des Servers
Es gibt einen einfachen Client zum Benchmarking des Servers. Beachten Sie, dass die Benchmarking-Funktionen möglicherweise nicht die gesamte Funktionalität abdecken. Überprüfen Sie die Implementierung in src / client auf Details zum Client.
Um neue Clientverbindungen zum Signalisierungsserver zu authentifizieren, startet der Client einen Dummy-Authentifizierungshandler auf einer lokalen Schnittstelle und übergibt die URL in der Hallo-Anforderung. Daher sollte der Signalisierungsserver so konfiguriert sein, dass alle Backend-Hosts zulässig sind (Option allowall im Abschnitt backend).
Der Client wird nicht standardmäßig kompiliert, kann jedoch das Clientziel verwenden:
$ Client machen Verwendung:
$ ./bin/client Verwendung von ./bin/client:
-addr string
http-Dienstadresse (Standard "localhost: 28080")
-config string
Zu verwendende Konfigurationsdatei (Standard "server.conf")
-maxClients int
Anzahl der Clientverbindungen (Standard 100)