Ich glaube, das bringt eine Discourse-Instanz zum Absturz. Sie kommt nicht über die “Oops…”-Meldung zur hohen Auslastung hinaus.
Create new order error. Le_OrderFinalize not found. {
"type": "urn:ietf:params:acme:error:rateLimited",
"detail": "too many certificates (5) already issued for this exact set of identifiers in the last 168h0m0s, retry after ....
Ich sehe, dass andere aus irgendeinem Grund auf dieses Problem gestoßen sind, aber gibt es eine Lösung?
Ich denke, du müsstest einfach ein paar Stunden warten und es dann erneut versuchen. Wenn ich mich recht erinnere, wird das Rate-Limit stündlich zurückgesetzt. Du könntest auch um ein www-Präfix für die Domain bitten, um ein neues Zertifikat zu erhalten und den Zähler zurückzusetzen.
Danke für den Hinweis. Ich versuche es jetzt mal mit einem Neuaufbau, da es schon ein paar Stunden her ist.
Es stellt sich heraus, dass laut @Ed_S hier eine Wartezeit von 7 Tagen angesetzt ist!
Ein Rebuild hat nicht funktioniert.
Ich habe die Wizard-Einrichtung erneut ausgeführt, um www hinzuzufügen und ein neues Zertifikat zu erhalten. Das schien zu funktionieren, aber ich musste @pfaffmans Vorschlag befolgen und die Verbindungsprüfung deaktivieren, um den Fehler „443 nicht erreichbar“ zu umgehen.
Jetzt schlägt das Laden des Zertifikats fehl, laut Logs:
...PEM_read_bio_X509_AUX() failed (SSL: error:0480006C:PEM routines::no start line:Expecting: TRUSTED CERTIFICATE)
Dies könnte mit dem Problem der geschlossenen Ports 443/80 zusammenhängen, was ein weiteres Problem ist, das ich als häufig vorkommend erkenne.
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 72556/docker-proxy
tcp6 0 0 :::443 :::* LISTEN 72564/docker-proxy
Wenn man die Ports über einen externen Prüfdienst scannt, werden sie als geschlossen angezeigt 
Okay, ich habe auf einen anderen Server mit einer wiederhergestellten Version der DB zurückgegriffen, bei dem die Ports 80/443 offen waren. Ich habe vor der Fortsetzung mit einem externen Portscanner überprüft, ob sie tatsächlich offen sind.
Als ich ./launcher discourse-setup ausführte, trat der Fehler auf, dass der Port 443 nicht zugänglich ist.
Daraufhin habe ich den Server erneut gescannt – Ports 80 und 443 melden sich nun als geschlossen.
Es ist, als würde das Ausführen des Wizards die Ports schließen?!
Ich glaube nicht, dass der Assistent mehrere Domainnamen unterstützt, aber ich benutze ihn schon länger nicht mehr.
Das ist mit sehr hoher Wahrscheinlichkeit dein Problem. Wahrscheinlich ist dein DNS nicht richtig eingerichtet oder etwas blockiert den eingehenden Traffic.
Hi, danke, ja, ich habe den oben genannten PEM_red...-Fehler behoben, indem ich „grey clouds“ zurückgesetzt habe. Den Tipp habe ich in einem anderen Thread gefunden.
Als ich den Wizard ausgeführt habe, habe ich nur die www.-Domain eingegeben. Könnte es falsch sein, das zu tun? Das habe ich gemacht, um das Rate-Limit zu umgehen.
Nach dem PEM-Fehler kam dann dieser Fehler:
fail: nginx: runsv not running
[Wed Sep .... UTC 2026] Reload error for :
C=US, O=Let's Encrypt, CN=YR1
error 2 at 1 depth lookup: unable to get issuer certificate
error fullchain.cer: verification failed
C=US, O=Let's Encrypt, CN=YE2
error 2 at 1 depth lookup: unable to get issuer certificate
error fullchain.cer: verification failed
Das sieht aber eher harmlos aus, denn im Log gibt es eine Reihe erfolgreicher Zertifikatsmeldungen, die vor dem Einsatz von „grey clouds“ gar nicht aufgetaucht sind.
Außerdem sind die Ports 80 und 443 als offen angezeigt.
Am Ende der Logs wird auch mehrfach Folgendes ausgegeben:
X-Accel-Mapping header missing
Ich möchte noch etwas Kontext hinzufügen: Die Instanz löst die Domain auf und erlaubt den Login. Der Anmeldebildschirm erscheint (auf „nur Login“ eingestellt) und akzeptiert die Zugangsdaten sowie die Zwei-Faktor-Authentifizierung. Nach dem erfolgreichen Login lande ich dann aber wieder auf dem „Oops…“-Bildschirm mit der Meldung „oh not again“.
Das bedeutet, ich bin wieder bei dem Punkt, an dem ich angefangen habe.
Am ursprünglichen Server-Instanz wurde nichts geändert. Aus dem Nichts gab es einige Tage lang ein schlechtes Verhalten. Während dieser Zeit zeigten die Metriken eine seltsame, zyklische Serverlast, die über dem Normalwert lag. Es war, als würde der Motor hochdrehen, aber nicht vorankommen, bis er schließlich in einen permanenten „Oops“-Zustand kippte.
Also habe ich angefangen, daran zu arbeiten. Eine Lösung war, ein Backup zu erstellen und auf ein frisches Discourse-Setup wiederherzustellen. Dort stehe ich jetzt, d. h. ich kann mich anmelden, lande aber wieder bei „Oops“.
Noch eine historische Anmerkung: In der Vergangenheit hatte ich Probleme mit „Full“ oder „Full (strict)“. „Full (strict)“ hat nicht immer funktioniert, und ich musste auf „Full“ zurückgreifen. Das ist aber vielleicht nebensächlich.
Oh mein Gott 
Okay, ich kann den Erfolg bestätigen. Ich habe einen älteren, nicht-administrativen Benutzer verwendet und konnte mich erfolgreich anmelden.
Wir sind offensichtlich im Kreis gefahren, obwohl das das eigentliche Problem war!