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

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

Signaling-Server in Nextcloud