Hallo,
ich migriere derzeit von einem klassischen Zwei-Container-Setup (getrennte Web-Only- und Datencontainer) zu einem Setup, bei dem die Datenbank auf einem zentralen Datenbankserver gehostet wird (nicht innerhalb eines Docker-Containers).
Die zentrale Datenbank wurde aus dem dump.sql erstellt, das Teil der Sicherungsdatei ist. Der Docker Compose web_only.yaml verwendet
Während des Builds von web_only erhalte ich folgende Fehlermeldung:
FEHLGESCHLAGEN
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' fehlgeschlagen mit Rückgabewert #<Process::Status: pid 741 exit 1>
Ort des Fehlschlags: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec fehlgeschlagen mit den Parametern {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
Bootstrap fehlgeschlagen mit Exit-Code 1
** BOOTSTRAP FEHLGESCHLAGEN ** Bitte scrollen Sie nach oben und suchen Sie nach früheren Fehlermeldungen, es kann mehr als eine geben.
Der Datenbankhost ist mit diesen Daten erreichbar. Irgendwelche Ideen, was hier passiert? Der gleiche Build mit dem Standard-Datenbankcontainer wird erfolgreich abgeschlossen.
Sind Sie sicher, dass die Remote-Datenbank vom Server aus verfügbar ist? Es sieht so aus, als ob sie es nicht ist. Können Sie von der Webserver-Maschine aus eine Telnet-Verbindung zum Datenbankport herstellen?
Betreffend DISCOURSE_DB_SOCKET: „“: Da wir eine Remote-Verbindung verwenden, würde ich vermuten, dass der Socket-Wert in beiden Fällen (docked data oder remote data) nicht relevant ist.
…
docker_manager ist bereits in der neuesten kompatiblen Version
wp-discourse ist bereits in der neuesten kompatiblen Version
I, [2023-11-10T21:08:17.388213 #1] INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate'
Plugin-Name ist 'discourse-topic-voting', aber das Plugin-Verzeichnis heißt 'discourse-voting'
rake abgebrochen!
ActiveRecord::StatementInvalid: PG::InsufficientPrivilege: ERROR: permission denied for table users (ActiveRecord::StatementInvalid)
Also gute Nachrichten! Es stellt eine Verbindung her, die DB-Berechtigungen müssen angepasst werden.
… ok ok, es sieht so aus, als hätte ich hier weitere Berechtigungsprobleme, siehe /var/log/postgresql/postgresql-13-main.log:
2023-11-10 22:07:58.371 UTC [196127] postgres@postgres STATEMENT: ALTER DEFAULT PRIVILEGES IN SCHEMA 'public' GRANT ALL ON TABLES TO 'discourse';
2023-11-10 22:10:18.270 UTC [196160] discourse@discourse ERROR: permission denied for table site_settings
2023-11-10 22:10:18.270 UTC [196160] discourse@discourse STATEMENT: SELECT name, data_type, value FROM site_settings
2023-11-10 22:10:18.313 UTC [196160] discourse@discourse ERROR: permission denied for table users
2023-11-10 22:10:18.313 UTC [196160] discourse@discourse STATEMENT: SELECT COUNT(*) FROM (SELECT 1 AS one FROM "users" LIMIT 20) subquery_for_count
OK, wie immer war es ein „Layer 8 Problem“
Ich hatte zwar schon eine Discourse-Datenbank in Postgres, aber der Discourse-Benutzer/die Rolle hatte nicht alle erforderlichen Berechtigungen dafür. Und ich habe einige wesentliche „Verhaltensunterschiede“ zwischen MariaDB und Postgres übersehen …
Jetzt habe ich alles neu erstellt: Benutzer, Datenbank, Berechtigungen für den Benutzer/die Rolle (einschließlich ALTER DEFAULT PRIVILEGES FOR ROLE discourse IN SCHEMA public GRANT ALL ON TABLES TO “discourse”; um auch zukünftig von diesem Benutzer erstellte Tabellen abzudecken)
Der Build ist abgeschlossen und die Instanz läuft einwandfrei mit dem Remote-Postgres-Server, sodass sie bereit für den Import des Backups von der älteren Instanz ist.
