Hier ist ein Fall, den ich trotz vieler fehlerloser Discourse-Installationen und -Migrationen nicht lösen kann.
Hintergrund:
Wir hatten Discourse reibungslos in einem Docker-Container laufen und arbeiteten an einigen Feinheiten der PostgreSQL-Datenbank.
Das Problem trat auf, als wir mit den Ergebnissen des Neubakeins (rebaking) von Rohbeiträgen nicht zufrieden waren. Nichts funktionierte wie geplant, also beschlossen wir, die PostgreSQL-Datenbank fallen zu lassen und neu zu erstellen. Doch die App lief weiterhin mit verschiedenen Berechtigungsfehlern usw. ab.
Ich habe versucht, die Datenbank zu löschen, bekomme aber weiterhin diesen Berechtigungsfehler:
/var/www/discourse# su postgres -c 'psql'
psql (10.12 (Debian 10.12-1.pgdg100+1))
Tippe "help" für Hilfe.
postgres=# drop database discourse;
FEHLER: Die Datenbank "discourse" wird von anderen Benutzern genutzt
DETAIL: Es gibt 3 andere Sitzungen, die die Datenbank verwenden.
Meine beste Vermutung ist, dass du den laufenden Docker-Container nicht gelöscht hast, aber behauptest, die Images gelöscht zu haben. Und es scheint, als hättest du eine andere Meldung erhalten.
Oder nutzt du eine externe PostgreSQL-Instanz statt der im Container?
Normalerweise reicht es, /var/discourse/shared zu löschen und einen Neuaufbau durchzuführen.
Building app
WARNING: We are about to start downloading the Discourse base image
This process may take anywhere between a few minutes to an hour, depending on your network speed
Please be patient
Nach einem fehlerfreien Neuaufbau und Start funktioniert es immer noch nicht.
Also haben wir es erneut versucht, indem wir die LETSENCRYPT-Option deaktiviert haben:
* Optional email address for Let's Encrypt warnings? (Enter 'OFF' to disable.) []: OFF
Es wird immer noch die zuvor zerstörte Instanz (von vor Stunden) gebaut, weil in dieser Instanz eine Reihe von Themes installiert wurden, die auch nach dem `droppen` der `discourse`-Datenbank noch in diesem Build vorhanden sind:
Start compiling CSS: 2020-03-15 10:16:20 UTC
Compiling css for default 2020-03-15 10:16:20 UTC
precompile target: desktop Dark
precompile target: mobile Dark
precompile target: desktop_rtl Dark
precompile target: mobile_rtl Dark
precompile target: desktop_theme Dark
precompile target: mobile_theme Dark
precompile target: admin Dark
precompile target: desktop Light
precompile target: mobile Light
precompile target: desktop_rtl Light
precompile target: mobile_rtl Light
precompile target: desktop_theme Light
precompile target: mobile_theme Light
precompile target: admin Light
precompile target: desktop
precompile target: mobile
precompile target: desktop_rtl
precompile target: mobile_rtl
precompile target: desktop_theme
precompile target: mobile_theme
precompile target: admin
Done compiling CSS: 2020-03-15 10:16:27 UTC
Wie ist es möglich, dass wir nach dem Löschen der gesamten `discourse`-Datenbank, dem Entfernen aller Docker-Images und Container, dem Löschen von `rm -rf /var/discourse` und dem Neuaufbau von Grund auf immer noch alle installierten Themes aus dem vielen Stunden alten Build sehen, den wir komplett zerstören wollen?
Das ergibt bei einer frischen Installation keinen Sinn.
Nun, wir haben von vorne angefangen, die LETSENCRYPT-Vorlagen und die E-Mail-Option auskommentiert, den Neuaufbau erfolgreich durchgeführt und die Admin-Anmeldeseite für die Feier erreicht.
Fortschritt!
Jetzt werden wir die app.yml bearbeiten und versuchen, SSL wieder in Betrieb zu nehmen.
Vor jedem Build haben wir alle alten Docker-Images usw. wie folgt gelöscht:
docker system prune -a
Es handelt sich also nicht um ein Problem mit Docker-Images.
Wir gehen davon aus, dass das Problem mit dem LETSENCRYPT-SSL-Zertifikat zusammenhängt; denn als wir die Subdomain änderten und im Build-Prozess auf derselben Server-IP ein neues SSL-Zertifikat generierten, funktionierte alles wie erwartet. Kehren wir jedoch zur ursprünglichen Subdomain zurück, bleibt das Problem bestehen.
Daher haben wir vorerst auf die problematische Subdomain verzichtet (es war ohnehin nur eine Staging-Domain) und sind weitergegangen.