Version vom 29. März 2023, 10:52 Uhr

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>       
  ServerName signaling.foxtom.de
  ServerAdmin couldmaster@foxtom.de
  DocumentRoot /var/www/html

  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined
        
  Include /etc/letsencrypt/options-ssl-apache.conf
  SSLCertificateFile /etc/letsencrypt/live/signaling.foxtom.de/fullchain.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/signaling.foxtom.de/privkey.pem
  
  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:

# 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:

# 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"

# 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 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_wstunnelJetzt 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 WebserverDer 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 Informationenhttps://httpd.apache.org/docs/2.4/ Dokumentation zum Apache HTTP Server https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html Reverse Proxy