Ich habe Discourse erfolgreich auf meinem Server installiert, mich als erster Benutzer registriert und mein erstes Thema erstellt. Alles auf der Discourse-Seite scheint also zu funktionieren.
Allerdings musste ich meinen Apache httpd-Daemon deaktivieren, um Discourse zu installieren und in Betrieb zu nehmen. Das ist für mich ein großes Problem, da ich damit im Grunde meinen gesamten Webserver abgeschaltet habe, der eine Reihe von Domains sowie einen Jitsi-Conferenzserver umfasst.
Meine Jitsi-Installation läuft als separater virtueller Host unter einer Subdomain einer der von mir gehosteten Websites. Da Jitsi den Port 443 mit dem übrigen Webverkehr teilen kann, möchte ich dasselbe auch mit Discourse tun.
Hat jemand eine Vorlage für eine virtuelle Host-Definition, die den Verkehr an Discourse weiterleitet, wenn er über die Discourse-Subdomain hereinkommt?
Im Wesentlichen gelöst, jedoch scheint die Startseite sehr lange zu brauchen, um die Anfrage abzuschließen, selbst nachdem die Seite vollständig geladen zu sein scheint. (Ich bin mir nicht sicher, ob dies ein normales Verhalten ist oder nicht.)
Discourse
Ich habe den expose-Block in /var/discourse/containers/app.yml wie folgt geändert:
Dies leitet vom localhost auf den Docker-Container weiter. Danach ist ein Neuaufbau mit ./launcher rebuild app erforderlich.
Apache2 2.4.43 (Ubuntu)
Ich habe einen neuen Virtual Host für die Subdomain discourse.<myDomain>.com.conf in sites-available hinzugefügt, der den Verkehr der Subdomain an den localhost-Port weiterleitet, auf den die Discourse-Docker-Instanz lauscht. Die Virtual-Host-Definition lautet wie folgt:
<VirtualHost *:80>
ServerName discourse.<myDomain>.com
Redirect permanent / https://discourse.<myDomain>.com/
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
<VirtualHost *:443>
ServerName discourse.<myDomain>.com
SSLProtocol TLSv1 TLSv1.1 TLSv1.2
SSLEngine on
SSLProxyEngine on
SSLCertificateFile /etc/letsencrypt/live/<myDomain>.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/<myDomain>.com/privkey.pem
SSLCACertificateFile /etc/letsencrypt/live/<myDomain>.com/chain.pem
SSLCipherSuite "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED"
SSLHonorCipherOrder on
Header set Strict-Transport-Security "max-age=31536000"
<Location />
Order allow,deny
Allow from all
Require all granted
</Location>
ProxyPreserveHost on
ProxyRequests Off
RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}
RequestHeader set X-Real-IP expr=%{REMOTE_ADDR}
ProxyPass / https://127.0.0.1:8443/
ProxyPassReverse / https://127.0.0.1:8443/
</VirtualHost>
Da ich nicht viel Zeit mit der Konfiguration von Apache verbringe, können einige Zeilen unnötig sein oder es könnten weitere hinzugefügt oder verbessert werden. Jegliches Feedback ist willkommen.
Ich betreibe Discourse auf mehreren Servern mit Apache2 als Frontend-Reverse-Proxy zu einem Unix-Socket. Die Konfiguration funktioniert einwandfrei (wie wir alle wissen, ist sie etwas langsamer als nginx, das ich ebenfalls auf einigen Servern verwende, aber sie funktioniert gut.)
Im Grunde konfiguriere ich den VirtualHost so:
Port-80-Konfiguration
<VirtualHost *:80>
ServerAdmin webmaster@localhost
ServerName discourse.mygreatwebsite.com
DocumentRoot /website/discourse # oft nicht erforderlich
RewriteEngine On
ProxyPreserveHost On
ProxyRequests Off
ErrorLog /var/log/apache2/discourse.error.log
LogLevel warn
CustomLog /var/log/apache2/discourse.access.log combined
RewriteCond %{SERVER_NAME} =discourse.mygreatwebsite.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
Port-443-Konfiguration:
<VirtualHost *:443>
ServerAdmin webmaster@localhost
ServerName discourse.mygreatwebsite.com
DocumentRoot /website/nginx # in dieser Konfiguration meist nicht erforderlich
SSLProxyEngine on
RewriteEngine On
ProxyPreserveHost On
ProxyRequests Off
RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}
RequestHeader set X-Real-IP expr=%{REMOTE_ADDR}
ProxyPass / unix:/var/discourse/shared/socket-only/discourse.http.sock|http://my.ip.address.here/
ProxyPassReverse / unix:/var/discourse/shared/socket-only/discourse.http.sock|http://my.ip.address.here/
ErrorLog /var/log/apache2/discourse-ssl.error.log
LogLevel warn
CustomLog /var/log/apache2/discourse-ssl.access.log combined
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/discourse.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/discourse.com/privkey.pem
</VirtualHost>
Hinweise:
Normalerweise lasse ich letsecrypt certbot die gesamte Arbeit bezüglich der Einrichtung aller SSL-Zertifikate und Umleitungen usw. erledigen.
Wir verwenden die IP-Adresse, an die Apache2 gebunden ist, in den Apache2-Konfigurationsdateien.
Wir konfigurieren dies (exponieren) immer mit Unix-Sockets im Discourse-Container und exponieren in dieser Konfiguration keine TCP/IP-Container-Ports.
Viele Grüße und hoffe, dass dies auch spät im Spiel noch einen Mehrwert bietet.
Wenn Sie statt eines direkten Proxys einen Unix-Socket verwenden möchten, können Sie dies tun (nachdem Sie die web.socketed.template.yml in Ihrer app.yml aktiviert haben) wie folgt:
ProxyPreserveHost On
ProxyRequests Off
RequestHeader set X-Forwarded-Proto https
RequestHeader set X-Real-IP expr=%{REMOTE_ADDR}
<Location />
ProxyPass unix:/var/discourse/shared/standalone/nginx.http.sock|http://localhost/
ProxyPassReverse unix:/var/discourse/shared/standalone/nginx.http.sock|http://localhost/
</Location>
Beachten Sie, dass Sie wahrscheinlich mit SELinux umgehen müssen, wenn Sie Apache versuchen lassen, von /var/discourse zu lesen. Etwas wie semanage fcontext -a -t httpd_sys_rw_content_t /var/discourse/shared/standalone/nginx.http.sock gefolgt von einem restorecon /var/discourse/shared/standalone/nginx.http.sock sollte dafür ausreichen.
Apache verfügt über das ziemlich großartige mod_md, das automatisch Ihre LetsEncrypt-Zertifikate für Sie besorgen kann. Ich empfehle es sehr.