Statische Fehlerseite anzeigen, während die Website nicht verfügbar ist

[piffy]

Ich möchte eine Seite anzeigen, auf der steht „Diese Seite wird gerade gewartet“, wenn sie während des Wiederaufbauprozesses offline geht.

Add an offline page to display when Discourse is rebuilding or starting up

This guide is intended for advanced users, who are already using nginx outside the docker container. By following this guide you make your setup more complicated and will loose some speed benefits like HTTP2 if you’re not running Ubuntu 16.04 or later. Proceed with caution! When Discourse is rebuilding or starting up, your users will usually either see an error message from their browser… [image] …or a not-so-nice 502 error message from Nginx: [image] If you’re a perfectionist l…

Dieses Thema ist im Grunde das, was ich tun möchte, scheint aber eine nicht standardmäßige Einrichtung zu erfordern. Gibt es eine einfachere Möglichkeit, dies für eine Standardinstallation zu tun? Danke!

[Falco]

@piffy

Gibt es eine einfachere Möglichkeit, dies für eine Standardinstallation zu tun?

Nein, im Moment gibt es nichts dergleichen.

[Alexander (Alexander Barrios)]

Tatsächlich verwendet dieses Verfahren eine „Standardinstallation“ (d. h. unter Verwendung der offiziellen Discourse Docker-Anleitung), zu der Nginx außerhalb des Containers neu bereitgestellt wird.

Das Verfahren erscheint zunächst beängstigend, ist es aber eigentlich nicht, ich kann Ihnen helfen, wenn Sie möchten.

[piffy]

@Falco

Nein, so etwas gibt es im Moment nicht.

Nicht die Antwort, die ich hören wollte, aber ich schätze die unmissverständliche Antwort trotzdem.

@Alexander

Eigentlich verwendet dieses Verfahren eine „Standardinstallation“ (d. h. unter Verwendung der offiziellen Discourse Docker-Anleitung), zu der Nginx außerhalb des Containers neu bereitgestellt wird.

Das Verfahren erscheint zunächst beängstigend, ist es aber eigentlich nicht. Ich kann Ihnen helfen, wenn Sie möchten.

Ich mache mir keine allzu großen Sorgen über den Prozess, sondern eher darüber, ob diese Einrichtung in Zukunft zusätzliche Überlegungen erfordert, wenn ich einfache Dinge wie die Installation eines neuen Plugins tue. Oder ist es hauptsächlich etwas, worüber ich nach der Einrichtung nicht mehr nachdenken muss?

[ClawdiaWolf (Claudia)]

@piffy

Oder ist es hauptsächlich etwas, das ich nach der Einrichtung nicht mehr beachten muss?

Seit ich 2020 NGINX dafür hinzugefügt habe, musste ich die Konfiguration zweimal bearbeiten. Beide Male ging es darum, Einstellungen für den Upload großer Dateien anzupassen, nachdem das Limit in Discourse aktualisiert wurde.

Die Verwendung von externem NGINX zur Bereitstellung der statischen Seite und als Reverse-Proxy für Discourse erfordert normalerweise keine Änderungen, sobald Sie es richtig eingerichtet haben.

[mcdanlj (Michael K Johnson)]

Beachten Sie, dass der externe Nginx neben der statischen Fehlerseite noch etwas anderes Wertvolles mitbringt: die korrekte Zuordnung von Quell-IP-Adressen für IPv6-Benutzer. Wenn Ihr Forum über IPv6 erreichbar ist und Sie nicht die externe Nginx-Konfiguration verwenden, werden alle Benutzer, die über IPv6 auf Ihre Website zugreifen, als von einer lokalen 172.x.y.z-Adresse kommend angezeigt. Das hilft nicht, wenn Sie versuchen, mit böswilligen Website-Benutzern wie Spammern umzugehen!

@piffy

Ich mache mir keine Sorgen um den Prozess, sondern eher darum, ob diese Einrichtung in Zukunft zusätzliche Überlegungen erfordert, wenn ich einfache Dinge wie die Installation eines neuen Plugins vornehme. Oder ist es hauptsächlich etwas, das ich nach der Einrichtung nicht mehr berücksichtigen muss?

Es ist genau dasselbe für das Hinzufügen neuer Plugins.

Ich denke, es erleichtert die Aktualisierung, da Sie wissen, dass Ihre Benutzer über Wartungsarbeiten informiert werden und einfach darauf warten, bis diese abgeschlossen sind.

Das Einzige, woran ich denken kann, ist, dass Sie sicherstellen möchten, dass Certbot Ihre Zertifikate korrekt erneuert. Das ist in der Standardkonfiguration enthalten, die keinen externen Nginx verwendet. Wenn Sie jedoch externen Nginx verwenden, müssen Sie auch externen Certbot verwenden und sicherstellen, dass dieser für die Erneuerung Ihres Zertifikats eingerichtet ist. Und nicht alle Installationsmethoden für Certbot handhaben dies.

Beachten Sie, dass die von Ihnen angefragte Dokumentation besagt:

Wenn Sie Certbot aus Ihrem Paket-Repository installiert haben, erfolgen Erneuerungen normalerweise automatisch. Andernfalls legen Sie eine Erinnerung fest, um letsencrypt renew && systemctl reload nginx.service auszuführen, bevor Ihr Zertifikat abläuft!

Eine Erinnerung festzulegen ist jedoch keine gute Methode. Sie werden es unweigerlich vergessen, und wenn Sie eine E-Mail von Letsencrypt verpassen, die Sie vor dem Ablauf des Zertifikats warnt, wird Ihre Website nicht mehr funktionieren. Glücklicherweise ist dies leicht zu umgehen.

Wenn automatische Erneuerungen nicht eingerichtet sind, erfahren Sie hier, wie Sie dies tun.

Erstellen Sie die Datei /etc/systemd/system/certbot.service mit folgendem Inhalt:

[Unit]
Description=Certbot
Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
Documentation=https://letsencrypt.readthedocs.io/en/latest/
[Service]
Type=oneshot
ExecStart=/usr/bin/certbot -q renew
PrivateTmp=true

Erstellen Sie die Datei /etc/systemd/system/certbot.timer mit folgendem Inhalt:

[Unit]
Description=Run certbot twice daily

[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=43200
Persistent=true

[Install]
WantedBy=timers.target

Teilen Sie dann systemd die neuen Dateien mit.

# systemctl daemon-reload
# systemctl enable --now certbot.timer

[pfaffman (Jay Pfaffman)]

Wenn Sie ein Zwei-Container-Setup verwenden, beträgt die Ausfallzeit weniger als eine Minute und Sie benötigen eine solche Seite nicht wirklich.

[Jagster (Jakke Lehtonen)]

Nach einiger Recherche hier ist es ziemlich klar, dass die Wartung von zwei Containern eine weitaus anspruchsvollere Aufgabe ist als Nginx. Zumindest auf meinem Fähigkeitsniveau.

[pfaffman (Jay Pfaffman)]

Ah. Ich verstehe. Aus meiner Sicht ist es fast dasselbe, nur dass man darauf achten muss, wann der Datumscontainer aktualisiert werden muss, was selten vorkommt, aber man muss darauf achten. Und wenn das passiert, ist die Website eine Weile nicht erreichbar.

[Jagster (Jakke Lehtonen)]

Das stimmt auch. Es ist immer ein Kompromiss – die Zeit, die ein Forum wegen Updates/Upgrades ausfällt, im Vergleich zur Zeit, die die Wartung separater Container benötigt (und besonders, wenn man (lies: ich) alles vermasselt und versucht, einige Fehlerbehebungen zu finden, und das Forum gleichzeitig ausfällt )