Nextcloud/Talk/HPB/Signaling-Server

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

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

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:

$ sudo systemctl restart signaling
$ sudo ./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 ...

Testfragen

Testfrage 1

Antwort1

Testfrage 2

Antwort2

Testfrage 3

Antwort3

Testfrage 4

Antwort4

Testfrage 5

Antwort5

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)