Nextcloud/Talk/HPB: Unterschied zwischen den Versionen

Aus Foxwiki
Subpages:
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen VersionsunterschiedZum nächsten Versionsunterschied →
VisuellWikitext
Zeile 487: Zeile 487:


The maximum bandwidth per publishing stream can also be configured in the section <tt>[mcu]</tt>, see properties <tt>maxstreambitrate</tt> and <tt>maxscreenbitrate</tt>.
The maximum bandwidth per publishing stream can also be configured in the section <tt>[mcu]</tt>, see properties <tt>maxstreambitrate</tt> and <tt>maxscreenbitrate</tt>.
== Schlüssel für den TURN-Server ==
* Talk-Einstellungen der Nextcloud
'''TODO:''' Beschreibung des Klickwegs als Text
'''TODO:''' Screenshot hinzufügen
Sofern bereits ein TURN-Server installiert ist, kann der benötigte Schlüssel im Administrator-Bereich der Nextcloud ausgelesen werden: Einstellungen >> Talk.
Über den Link: https://cloud.itw-berlin.net/settings/admin/talk gelangt man direkt zu den Einstellungen. Der Schlüssel findet sich auch in der Datei /etc/turnserver.conf (static-auth-secret=<Schlüssel>).
{|
| [[Datei:TURN-Server-Key.png | links | 800px | TURN-Server-Konfiguration im Administrator-Bereich der Nextcloud-Talk-App]]
|}


= Test und Benchmarking =
= Test und Benchmarking =

Version vom 20. April 2022, 08:49 Uhr

Nextcloud Talk High Performance Backend

Komponenten des HighPerformanceBackends

TODO: Grafische Darstellung der Kooperation der verwendeten Dienste

Janus WebRTC gateway

TODO: Funktion und Aufgabe des Dienstes beschreiben

WebRTC ist eine Abkürzung für Web Real-Time Communication, also Echtzeitkommunikation. WebRTC ist ein offener Standard, der durch eine Sammlung von Kommunikationsprotokollen und Programmierschnittstellen definiert wird. Dieser Standard ermöglicht es Clients (wie beispielsweise Webbrowsern) eine direkte Verbindung zueinander aufzubauen. Der Vorteil besteht darin, daß keine zusätzliche Software installiert werden muss, wie es etwa bei Skype oder Zoom der Fall ist. Des Weiteren werden Server-Ressourcen geschont. WebRTC läuft innerhalb der Browser-Sandbox und ist dadurch auch sicher - es werden keine PlugIns benötigt oder andere Prozesse gestartet. Damit die Clients voneinander erfahren, wie sie die direkte Verbindung zueinander aufbauen können, sind die Dienste eines Signaling-Servers notwendig.

Weitere Informationen
  1. https://github.com/meetecho/janus-gateway

NATS messaging server

TODO: Funktion und Aufgabe des Dienstes beschreiben

Der NATS-Server ermöglicht es Anwendungen und Diensten Daten auszutauschen, die in Nachrichten unterteilt sind. Clients stellen über eine URL eine Verbindung zum NATS-Server her und können anschließend Nachrichten zu einem bestimmten Betreff abonnieren oder veröffentlichen.

Weitere Informationen
  1. https://nats.io/

Nextcloud Talk signaling server

TODO: Funktion und Aufgabe des Dienstes beschreiben

Der Signaling-Server 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.

Weitere Informationen
  1. https://github.com/strukturag/nextcloud-spreed-signaling

Apache Webserver

TODO: Funktion und Aufgabe des Dienstes beschreiben

Der Apache Webserver ist einer der meistgenutzten Webserver im Internet. Die Software ist modular aufgebaut und dementsprechend durch die Installation von zusätzlichen Modulen in ihrer Funktionalität erweiterbar. Für den Signaling-Server wird eine eigene Subdomain erzeugt (signaling.foxtom.de) und Apache als Reverse-Proxy konfiguriert. Bei einem solchen Szenario beantwortet der Webserver die Anfragen nicht selbst, sondern übergibt sie an einen Backend-Server, der keine direkte Verbindung zum Internet hat. Der Backend-Server - in diesem Fall der Signaling-Server - bearbeitet die Anfrage und übergibt den Inhalt zurück an den Apache-Webserver, der damit die HTTP-Antwort erzeugt und zurück an den anfragenden Client sendet. Im Endeffekt wird hier ein Zugang zum Signaling-Server über HTTPS geschaffen.

Weitere Informationen
  1. https://httpd.apache.org/docs/2.4/ Dokumentation zum Apache HTTP Server
  2. https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html Reverse Proxy

Vorbereitung der Installation

  • Für die einzelnen Komponenten werden Schlüssel (keys) benötigt
  • die im Vorfeld wie folgt erzeugt werden können:

TODO: Was machen und bedeuten die folgenden Kommandos?

TODO: Warum brauchen wir diese Schlüssel?

TODO: Sind die vorgeschlagenen Einstellungen sicher genug?

TODO: Wie ist mit diesen Daten umzugehen?

Mit dem Kommandozeilenprogramm openssl können in Verbindung mit der Option rand Pseudozufallszeichenketten einer bestimmten Kodierung und der angegebenen Länge erzeugt werden. Mit der Option base64 wird eine Zeichenkette aus Zahlen, Groß- & Kleinbuchstaben, sowie den Zeichen '+' und '/' generiert, während mit der Option hex eine Zeichenkette aus Hexadezimalzahlen erzeugt wird.

<api-Key> für Janus

 openssl rand -base64 16

Hash-Key

 openssl rand -hex 16

Block-Key

 openssl rand -hex 16

Secret Key für die Nextcloud

 openssl rand -hex 16

Server-Adressen

Nextcloud-Server: cloud.itw-berlin.net
TURN-Server:      cloud.itw-berlin.net:5349
Signaling Server: signaling.foxtom.de

Janus

Installation

apt install janus

Konfiguration

Mit einer Janus-Instanz kann auf verschiedenen Wegen interagiert werden - über HTTP, Websockets, RabbitMQ und einigen mehr. Für jede dieser Möglichkeiten werden im Verzeichnis /etc/janus eigene Konfigurationsdateien angelegt. 

cp -i /etc/janus/janus.jcfg.sample /etc/janus/janus.jcfg

/etc/janus/janus.jcfg

...
stun_server = "cloud.itw-berlin.net"
stun_port = 5349
...
full_trickle = true
...
turn_server = "cloud.itw-berlin.net"
turn_port = 5349
...
turn_rest_api_key = "<api-Key>"
...

/etc/janus/janus.transport.http.jcfg

Janus-Server soll nur das lokale Interface abhören 

...
interface = "lo" 
...

/etc/janus/janus.transport.websockets.jcfg

TODO: Warum muss das hier nochmals konfiguriert werden? (siehe 3.2)

Janus-Server soll nur das lokale Interface abhören 

...
ws_interface = "lo"
...

Dienst starten

TODO: Gibt es eine Möglichkeit, dass systemctl start direkt eine Statusmeldung ausgibt?

Der Janus-Server kann mit dem Befehl systemctl start/stop manuell gestartet bzw. angehalten werden. Eine Ausgabe eventueller Fehler erhält man jedoch nicht. Zur Fehlersuche läßt sich das Programm jedoch manuell starten, indem mit der Option debug-level festgelegt werden kann, wie detailliert die Ausgabe erfolgen soll. 

# janus --debug-level=<1..7>

# systemctl start janus

Status prüfen

TODO: Was bedeutet diese Ausgabe?

TODO: Wie ist der gemeldete Fehler zu korrigieren?

TODO: Welche Bedeutung haben die einzelnen Warnungen?

Ist ein entsprechendes Janus-PlugIn nicht installiert, oder dessen Konfigurationsdatei nicht nicht vorhanden, wird eine Fehlermeldung erzeugt. In der Konfigurationsdatei /etc/janus/janus.jcfg läßt sich die Verwendung des PlugIns für RabbitMQ abstellen, indem die entsprechende Zeile auskommentiert wird: 

# You can choose which of the available transports should be enabled or
# not. Use the 'disable' directive to prevent Janus from loading one
# or more transport: use a comma separated list of transport file names
# to identify the transports to disable. By default all available
# transports are enabled and loaded at startup.
transports: {
        #disable = "libjanus_rabbitmq.so"
}
...

# systemctl status janus

● janus.service - Janus WebRTC gateway
   Loaded: loaded (/lib/systemd/system/janus.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2021-01-06 23:53:56 CET; 12s ago
     Docs: https://janus.conf.meetecho.com/docs/index.html
 Main PID: 10220 (janus)
    Tasks: 24 (limit: 2296)
   Memory: 11.1M
   CGroup: /system.slice/janus.service
           └─10220 /usr/bin/janus -o

Jan 06 23:53:57 signaling janus[10220]: [ERR] [config.c:janus_config_parse:191]   -- Error reading configuration file 'janus.transport.rabbitmq.cfg'... error 2 (No such file or directory)
Jan 06 23:53:57 signaling janus[10220]: RabbitMQ SSL support disabled
Jan 06 23:53:57 signaling janus[10220]: [WARN] RabbitMQ support disabled (Janus API)
Jan 06 23:53:57 signaling janus[10220]: [WARN] RabbitMQ support disabled (Admin API)
Jan 06 23:53:57 signaling janus[10220]: [WARN] RabbitMQ support disabled for both Janus and Admin API, giving up
Jan 06 23:53:57 signaling janus[10220]: [WARN] The 'janus.transport.rabbitmq' plugin could not be initialized
Jan 06 23:53:57 signaling janus[10220]: [WARN] libnice version outdated: 0.1.14 installed, at least 0.1.15 recommended
Jan 06 23:53:57 signaling janus[10220]: HTTP transport timer started
Jan 06 23:54:09 signaling janus[10220]: Creating new session: 7609464843575521; 0x7f1b4c001db0
Jan 06 23:54:09 signaling janus[10220]: Creating new handle in session 7609464843575521: 3636178337595333; 0x7f1b4c001db0 0x7f1b4c0031a0

Debugging

Die Systemd-Protokolle zum Janus-Server lassen sich mit journalctl ausgeben: 

$ sudo journalctl -u janus
-- Logs begin at Mon 2021-02-01 13:52:30 CET, end at Tue 2021-02-02 11:19:16 CET. --
Feb 02 08:54:04 signaling janus[21010]: Creating new handle in session 5338086438572651: 2325140291688110; 0x7f9da4048db0 0x7f9da4133dc0
Feb 02 08:54:04 signaling janus[21010]: [2325140291688110] Creating ICE agent (ICE Full mode, controlled)
Feb 02 08:54:04 signaling janus[21010]: nice_agent_set_relay_info: assertion 'username' failed
Feb 02 08:54:04 signaling janus[21010]: [WARN] Could not set TURN server, is the address correct? (2a01:4f8:231:45cd::2:5349)
Feb 02 08:54:04 signaling janus[21010]: [ERR] [sdp-utils.c:janus_sdp_get_codec_rtpmap:779] Unsupported codec 'none'
Feb 02 08:54:05 signaling janus[21010]: [2325140291688110] The DTLS handshake has been completed
Feb 02 08:54:05 signaling janus[21010]: [janus.plugin.videoroom-0x7f9da41f45c0] WebRTC media is now available
...

Debug-/Loglevel einstellen

Soll der Janus-Server seine Ausgaben in eine eigene Log-Datei schreiben, kann dies in der Datei /etc/janus/janus.jcfg konfiguriert werden. Die Angabe eines Debug-Levels ist hierbei ebenfalls möglich: 

...
# The next settings configure logging
       #log_to_stdout = false                                  # Whether the Janus output should be written
                                                                                       # to stdout or not (default=true)
       #log_to_file = "/path/to/janus.log"             # Whether to use a log file or not
       debug_level = 4                                                 # Debug/logging level, valid values are 0-7
       #debug_timestamps = true                                # Whether to show a timestamp for each log line
       #debug_colors = false                                   # Whether colors should be disabled in the log
       #debug_locks = true                                             # Whether to enable debugging of locks (very verbose!)
       #log_prefix = "[janus] "                                # In case you want log lines to be prefixed by some
...

Log prüfen

NATS

Installation

Repository hinzufügen

TODO: Ausgabe der Befehle hinzufügen

Der folgende Befehl erzeugt keine Ausgabe. Mit ihm wird der öffentliche Schlüssel des Repositorys bezogen und im Verzeichnis /etc/apt/trusted.gpg.d abgelegt: 

# curl -sL -o /etc/apt/trusted.gpg.d/morph027-nats-server.asc https://packaging.gitlab.io/nats-server/gpg.key

Der nächste Befehl fügt der Konfiguration des Paketmanagers das Repository des NATS-Servers hinzu. Es wird im Verzeichnis /etc/apt/sources.list.d die Datei morph027-nats-server.list erstellt und der einzutragende Inhalt ausgegeben: 

# echo "deb https://packaging.gitlab.io/nats-server nats main" | tee /etc/apt/sources.list.d/morph027-nats-server.list

Installation durchführen

# apt update
# apt install nats-server

Konfiguration

/etc/nats/nats.conf

TODO: Was machen diese Befehle?

TODO: Warum sollte man hier sudo und nicht root benutzen?

TODO: Bitte Warum sollte man hier sudo und nicht root benutzen? install

Mit dem folgenden Befehl wird wird das Verzeichnis /etc/nats erzeugt und dieses dem Besitzer sowie der Gruppe nats zugewiesen: 

# install -d -o nats -g nats /etc/nats

Anschließend wird (als Benutzer nats) die Konfigurationsdatei für den NATS-Server erzeugt, die nur einen Eintrag erhält (listen: 127.0.0.1:4222). 

# sudo -u nats echo "listen: 127.0.0.1:4222" > /etc/nats/nats.conf

Dienst starten

sudo systemctl start nats-server
sudo systemctl status nats-server

● nats-server.service - NATS messaging server
   Loaded: loaded (/lib/systemd/system/nats-server.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2021-01-07 00:00:02 CET; 9s ago
     Docs: https://docs.nats.io/nats-server/
 Main PID: 10269 (nats-server)
    Tasks: 6 (limit: 2296)
   Memory: 6.5M
   CGroup: /system.slice/nats-server.service
           └─10269 /usr/bin/nats-server --config /etc/nats/nats.conf

Jan 07 00:00:02 signaling systemd[1]: Started NATS messaging server.
Jan 07 00:00:02 signaling nats-server[10269]: [10269] 2021/01/07 00:00:02.815032 [INF] Starting nats-server version 2.1.9
Jan 07 00:00:02 signaling nats-server[10269]: [10269] 2021/01/07 00:00:02.815675 [INF] Git commit [7c76626]
Jan 07 00:00:02 signaling nats-server[10269]: [10269] 2021/01/07 00:00:02.816182 [INF] Listening for client connections on localhost:4222
Jan 07 00:00:02 signaling nats-server[10269]: [10269] 2021/01/07 00:00:02.816342 [INF] Server id is NDBF27HOCXESCE4M7QWO6T3ZWCRQPRSXLJWWJDCTXFGD36LOFCTZJAYR
Jan 07 00:00:02 signaling nats-server[10269]: [10269] 2021/01/07 00:00:02.816475 [INF] Server is ready

Signaling Server

Zur Installation des Servers wird das Paket golang-go benötigt, welches über die Paketverwaltung installiert werden kann: 

apt install golang-go

Installation

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

Beispielkonfiguration 

/usr/src/nextcloud-spreed-signaling/server.conf.in

Diese Datei wird nach /etc/signaling/server.conf kopiert: 

mkdir -p /etc/signaling
cd /usr/src/nextcloud-spreed-signaling
cp server.conf.in /etc/signaling/server.conf

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.itw-berlin.net
​...
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.itw-berlin.net:5349?transport=udp,turn:cloud.itw-berlin.net: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

Starten des Signaling-Servers

Ist Janus-Server bereits gestartet, kann der Signaling-Server für einen Test direkt aufgerufen werden: 

sudo /usr/src/nextcloud-spreed-signaling/bin/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.itw-berlin.net/
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.itw-berlin.net:5349?transport=udp" as TURN server
2021-01-06 15:11:51.115372 I | backend_server.go:97: Adding "turn:cloud.itw-berlin.net: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: 

$ sudo 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 & 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

Frontend-Webserver (Apache)

  • [Normalerweise?] wird der Signalisierungsserver hinter einem Webserver ausgeführt, der das SSL-Protokoll ausführt oder als Load Balancer für mehrere Signalisierungsserver fungiert.

Installation

Konfuguration

  • Um den Apache-Webservice als Frontend für den 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

Virtual-Host einrichten

Jetzt kann die Virtual-Host-Konfiguration von Apache erweitert werden, um Anfragen an den Signalisierungsserver weiterzuleiten (vorausgesetzt, der Server wird auf der lokalen Schnittstelle an Port 8080 ausgeführt). Für signaling.foxtom.de sollte die Datei /etc/apache2/sites-available/signaling.foxtom.de.conf wie folgt editiert werden: 

<IfModule mod_ssl.c>
<VirtualHost *:443>
      
       ServerAdmin webmaster@localhost
       DocumentRoot /var/www/html
      
       ErrorLog ${APACHE_LOG_DIR}/error.log
       CustomLog ${APACHE_LOG_DIR}/access.log combined
      
ServerName signaling.foxtom.de
SSLCertificateFile /etc/letsencrypt/live/signaling.foxtom.de/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/signaling.foxtom.de/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

ProxyErrorOverride On
DocumentRoot "/var/www/html"
ProxyPass /error/ !
ErrorDocument 404 /error/404_proxy.html
ProxyPass / "http://127.0.0.1:8080/"
RewriteEngine on
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteCond %{HTTP:Connection} upgrade [NC]
RewriteRule ^/?(.*) "ws://127.0.0.1:8080/$1" [P,L]

</VirtualHost>
</IfModule>

Debugging

Log prüfen

Die Log-Dateien des Apache-Webservers werden im Verzeichnis /var/log/apache2/ gespeichert. Dabei kommt der Datei error.log die größte Bedeutung zu - sie ist der erste Anlaufpunkt zu Fehlerdiagnose: 

$ sudo tail -f /var/log/apache2/error.log
[Tue Feb 02 00:00:01.238481 2021] [mpm_event:notice] [pid 22518:tid 139736999879808] AH00489: Apache/2.4.38 (Debian) OpenSSL/1.1.1d configured -- resuming normal operations
[Tue Feb 02 00:00:01.238532 2021] [core:notice] [pid 22518:tid 139736999879808] AH00094: Command line: '/usr/sbin/apache2'

Die access-Log-Dateien protokollieren jeden Zugriff auf denn Webserver: 

$ sudo tail -f /var/log/apache2/access.log
116.202.118.50 - - [01/Feb/2021:15:01:53 +0100] "POST /api/v1/room/maf38kte HTTP/1.1" 200 3898 "-" "Nextcloud Server Crawler"
116.202.118.50 - - [01/Feb/2021:15:02:10 +0100] "POST /api/v1/room/maf38kte HTTP/1.1" 200 3930 "-" "Nextcloud Server Crawler"
...
116.202.118.50 - - [01/Feb/2021:15:03:04 +0100] "POST /api/v1/room/maf38kte HTTP/1.1" 200 3914 "-" "Nextcloud Server Crawler"
116.202.118.50 - - [01/Feb/2021:15:03:17 +0100] "POST /api/v1/room/maf38kte HTTP/1.1" 200 3898 "-" "Nextcloud Server Crawler"

$ sudo tail -f /var/log/apache2/other_vhosts_access.log

Debug-/Loglevel einstellen

Sollten die in den Log-Dateien erfassten Informationen zur Fehlerdiagnose nicht ausreichen, läßt sich durch Modifikation der Konfigurationsdatei des Webservers das Log-Level erhöhen. Der Standardeintrag in der Datei /etc/apache2/apache2.conf ist "LogLevel warn". Detailliertere Informationen können mit notice, info oder debug erhalten werden. Es besteht auch die Möglichkeit, das Log-Level einzelner Module des Werbservers anzupassen, wie zum Beispiel mit: "LogLevel warn proxy:debug"

Firewall konfigurieren

TODO: Welche Ports müssen geöffnet sein?

TODO: Welche Schritte sind notwendig, um dies mit ufw zu tun?

TODO: Wie kann die Konfiguration geprüft werden? 

$ sudo apt install ufw

$ sudo ufw allow http
$ sudo ufw allow https
$ sudo ufw allow ssh
$ sudo ufw allow 5349/tcp
$ sudo ufw allow 5349/udp

$ sudo ufw enable

$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
80/tcp                     ALLOW       Anywhere                  
443/tcp                    ALLOW       Anywhere                  
22/tcp                     ALLOW       Anywhere                  
5349/tcp                   ALLOW       Anywhere                  
5349/udp                   ALLOW       Anywhere                  
80/tcp (v6)                ALLOW       Anywhere (v6)             
443/tcp (v6)               ALLOW       Anywhere (v6)             
22/tcp (v6)                ALLOW       Anywhere (v6)             
5349/tcp (v6)              ALLOW       Anywhere (v6)             
5349/udp (v6)              ALLOW       Anywhere (v6)

Einbinden in Nextcloud Talk

  • Dies geschieht unter Einstellungen > Talk.
  • Ganz unten wird nun ein Signaling Server mit dem Plus-Zeichen hinzugefügt.
  • Die Domain lautet hierfür https://signaling.meinedomain.de/standalone-signaling.
  • Unter Gemeinsames Geheimnis wird nun der Nextcloud Secret Key hinterlegt, den wir ganz am Anfang erzeugt haben:

Hinterlegen des Signaling Servers in der Nextcloud Talk Konfiguration

Die Option SSL Zertifikat überprüfen sollte hier aktiviert werden, wenn der Signaling Server über ein valides Zertifikat verfügt (zum Beispiel Let’s Encrypt).


Quelle: https://nichteinschalten.de/signalisierungsserver-fuer-nextcloud-aufsetzen-how-to/ 

netstat -tulpen | grep 8080

http://nats.io/documentation/tutorials/gnatsd-install/


https://github.com/meetecho/janus-gateway) can be used to act as a WebRTC gateway. See the documentation of Janus on how to configure and run the server. At least the VideoRoom plugin and the websocket transport of Janus must be enabled.

The signaling server uses the VideoRoom plugin of Janus to manage sessions. All gateway details are hidden from the clients, all messages are sent through the signaling server. Only WebRTC media is exchanged directly between the gateway and the clients.

Edit the server.conf and enter the URL to the websocket endpoint of Janus in the section [mcu] and key url. During startup, the signaling server will connect to Janus and log information of the gateway.

The maximum bandwidth per publishing stream can also be configured in the section [mcu], see properties maxstreambitrate and maxscreenbitrate.

Schlüssel für den TURN-Server

  • Talk-Einstellungen der Nextcloud

TODO: Beschreibung des Klickwegs als Text

TODO: Screenshot hinzufügen

Sofern bereits ein TURN-Server installiert ist, kann der benötigte Schlüssel im Administrator-Bereich der Nextcloud ausgelesen werden: Einstellungen >> Talk. Über den Link: https://cloud.itw-berlin.net/settings/admin/talk gelangt man direkt zu den Einstellungen. Der Schlüssel findet sich auch in der Datei /etc/turnserver.conf (static-auth-secret=<Schlüssel>).

TURN-Server-Konfiguration im Administrator-Bereich der Nextcloud-Talk-App
TURN-Server-Konfiguration im Administrator-Bereich der Nextcloud-Talk-App

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/src/client
$ 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 ...


Links

Intern

TODO: Links zu relevanten internen Artikeln hinzufügen

Extern

TODO: Linke beschreiben und ich Gruppen aufteilen

  1. https://github.com/strukturag/nextcloud-spreed-signaling
  2. https://de.wikipedia.org/wiki/WebRTC
  3. https://decatec.de/home-server/nextcloud-talk-mit-eigenem-signaling-server-high-performance-backend/
  4. https://decatec.de/home-server/nextcloud-auf-ubuntu-server-20-04-lts-mit-nginx-mariadb-php-lets-encrypt-redis-und-fail2ban/
  5. https://decatec.de/home-server/nextcloud-talk-mit-eigenem-turn-server-coturn/
  6. https://decatec.de/linux/lets-encrypt-zertifikate-mit-acme-sh-und-nginx/
  7. https://decatec.de/home-server/rsa-und-ecdsa-zertifikate-mit-nginx-hybrid-loesung/
  8. https://decatec.de/home-server/tlsv1-3-unter-ubuntu-server-18-04-lts-mit-nginx/
  9. https://decatec.de/home-server/docker-auf-ubuntu-server/
Abgerufen von „https://wiki.foxtom.de/index.php?title=Nextcloud/Talk/HPB&oldid=33279“