Nextcloud/Talk/HPB/Apache
Apache Frontend Webserver
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
Konfiguration
- 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"
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 </ tt> getestet werden:
$ curl -i https: //myserver.domain.invalid/standalone-signaling/api/v1/welcome HTTP / 1.1 200 OK Server: nextcloud-spreed-signalisierung / 1.0.0 Inhaltstyp: application / json; Zeichensatz = utf-8 Inhaltslänge: 59
{"nextcloud-spreed-signalisierung": "Willkommen", "Version": "1.0.0"}
- Um den Apache-Webservice als Frontend für den eigenständigen Signalisierungsserver zu konfigurieren, müssen die Module mod_proxy_http </ tt> und mod_proxy_wstunnel </ tt> aktiviert sein, damit WebSocket- und API-Backend-Anforderungen als Proxy verwendet werden können:
# a2enmod Proxy # a2enmod proxy_http # a2enmod proxy_wstunnel
- Jetzt kann die Apache VirtualHost </ tt>-Konfiguration erweitert werden, um Anforderungen an den eigenständigen Signalisierungsserver weiterzuleiten (vorausgesetzt, der Server wird auf der lokalen Schnittstelle an Port 8080 </ tt> unten ausgeführt):
<VirtualHost *: 443> <nowiki> # ... vorhandene Konfiguration ... </ nowiki> <nowiki> # Aktivieren Sie das Proxying von Websocket-Anforderungen an den eigenständigen Signalisierungsserver. </ nowiki> ProxyPass "/ Standalone-Signaling /" "ws: //127.0.0.1: 8080 /" RewriteEngine On <nowiki> # Websocket-Verbindungen von den Clients. </ nowiki> RewriteRule ^ / Standalone-Signaling / Spreed $ - [L] <nowiki> # Backend-Verbindungen von Nextcloud. </ nowiki> RewriteRule ^ / Standalone-Signaling / api /(.*) http://127.0.0.1:8080/api/$1 [L, P] <nowiki> # ... vorhandene Konfiguration ... </ nowiki>
Apache Webserver
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
- https://httpd.apache.org/docs/2.4/ Dokumentation zum Apache HTTP Server
- https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html Reverse Proxy