Das ist nicht wahr.
- Die Links, die ich im obigen Kommentar angehängt habe, stammten von einem
git blame. Hier ist die neueste Version der Datei (relevante Zeile verlinkt): discourse_docker/templates/web.ssl.template.yml at 247c71a1e45d32b0b814a8e9d5fdaa4faaf727b9 · discourse/discourse_docker · GitHub - Die neue Site-Installation meines Freundes war von vor einer Woche. Zeile 37 der obigen Vorlage lautet:
return 301 https://${DISCOURSE_HOSTNAME}$request_uri;, aber im Discourse Docker Container liest sowohl ihre (als auch meine)/etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.confreturn 301 https://<your_discourse_site>;. Beachten Sie, dass$request_urientfernt wird. Etwas bewirkt, dass dies verschwindet! (Ich weiß nicht was). - Ich habe heute Morgen eine simulierte erzwungene Erneuerung als Teil meiner Untersuchung durchgeführt. Sie ist fehlgeschlagen. Ich habe dann
/etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.confgeändert. Sie war erfolgreich!
Das ist eigentlich in Ordnung; ich werde 20-redirect-http-to-https.conf einfach jedes Mal manuell bearbeiten, wenn ich Discourse aktualisiere. Für diejenigen, die auf diesen Kommentar stoßen, lautet der auszuführende Befehl:
cat > /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf << 'EOF'
server {
listen 80;
listen [::]:80;
location ~ /.well-known {
root /var/www/discourse/public;
allow all;
}
location / {
return 301 https://<DEINE_FORUM_ADRESSE>$request_uri;
}
}
EOF
Ich bin mir nicht ganz sicher, was dieses Scheitern verursacht, aber ich weiß, dass die Änderung der obigen Konfiguration es behebt. Aber ich habe auch Benachrichtigungen so modifiziert, dass Let’s Encrypt-Erneuerungen nicht mehr stillschweigend fehlschlagen – damit ich eine gewisse Vorwarnung habe. Dachte nur, Sie würden es wissen wollen!