Ciao,
Sto attualmente migrando da una classica configurazione a due container (container web_only e data separati) a una configurazione in cui il database è ospitato su un server di database centrale (non all’interno di un container Docker).
Il database centrale è stato creato dal dump.sql che fa parte del file di backup. Il file web_only.yaml di Docker Compose utilizza
Durante la build di web_only ricevo il seguente errore:
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.
L’host del database è accessibile con questi dati. Qualche idea su cosa sta succedendo qui? La stessa build con il container di database standard termina con successo.
Anche il nome del database, l’utente e la password in web_only.yml sono corretti. L’errore di compilazione è
FALLITO
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' fallito con ritorno #<Process:
:Status: pid 829 exit 1>
Posizione del fallimento: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec fallito con i parametri {\"cd\"=>\"$home\", \"hook\"=>\"db_migrate\", \"cmd\"=>[\"su discourse -c 'bundle exec rake db:migra
te'\"]}
bootstrap fallito con codice di uscita 1
Non sono un esperto di Ruby, quindi avrei bisogno di aiuto per il debug a partire dall’errore che appare qui.
Per quanto riguarda DISCOURSE_DB_SOCKET: ‘’: poiché utilizziamo una connessione remota, suppongo che il valore del socket non sia rilevante in entrambi i casi (dati dockered o dati remoti)
…
docker_manager è già alla versione compatibile più recente
wp-discourse è già alla versione compatibile più recente
I, [2023-11-10T21:08:17.388213 #1] INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate'
Il nome del plugin è 'discourse-topic-voting', ma la directory del plugin si chiama 'discourse-voting'
rake aborted!
ActiveRecord::StatementInvalid: PG::InsufficientPrivilege: ERROR: permission denied for table users (ActiveRecord::StatementInvalid)
Quindi buone notizie! Si sta connettendo correttamente, sono i permessi del DB che devono essere modificati.
… ok ok, sembra che abbia ancora alcuni problemi di permessi qui, vedi /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, come sempre, era un problema di “livello 8”
Ho già avuto un database discourse in postgres, ma l’utente/ruolo discourse non aveva tutti i privilegi richiesti su di esso. E mi sono sfuggite alcune importanti differenze “comportamentali” tra mariadb e postgres…
Ora ho ricreato tutto: utente, database, permessi per l’utente/ruolo (incluso ALTER DEFAULT PRIVILEGES FOR ROLE discourse IN SCHEMA public GRANT ALL ON TABLES TO “discourse”; per gestire le tabelle create da questo utente in futuro)
La build è terminata e l’istanza funziona bene con il server postgres remoto, quindi è pronta per importare il backup dalla vecchia istanza.
