Hi,
I am currently migrating from a classical two container setup (separated web_only and data containers) to a setup where the database is hosted on a central database server (not inside a docker container).
The central database was created from the dump.sql which is part of the backup file. The docker compose web_only.yaml uses
During the build of web_only I get the following error:
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 741 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
The database host is accessible with these data. Any ideas whats happening here? The same build with the standard database container finishes successfully.
Are you sure that the remote database is available from the server? It looks like it’s not. Can you telnet to the database port from the web server machine?
Concerning the DISCOURSE_DB_SOCKET: ‘’: as we use a remote connection, I would guess that the socket value is not relevant in both cases (dockered data or remote data)
…
docker_manager is already at latest compatible version
wp-discourse is already at latest compatible version
I, [2023-11-10T21:08:17.388213 #1] INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'
Plugin name is 'discourse-topic-voting', but plugin directory is named 'discourse-voting'
rake aborted!
ActiveRecord::StatementInvalid: PG::InsufficientPrivilege: ERROR: permission denied for table users (ActiveRecord::StatementInvalid)
So good news! It’s connecting fine, it’s that DB permissions need adjusting.
… ok ok, irt looks as if I have some more permission issues here, see /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
I already had a discourse database in the postgres but the discourse user/role had not all required privileges on it. And I did miss some major “behavioural” differences between mariadb and postgres …
Now I re-created all: user, database, permissions for the user/role (including ALTER DEFAULT PRIVILEGES FOR ROLE discourse IN SCHEMA public GRANT ALL ON TABLES TO “discourse”; to match tables created by this user in the future)
The build finished and the instance runs fine with the remote postgres server, so its ready for importing the backup from the older instance.
