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.

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 </ 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

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