Actualmente estoy migrando de una configuración clásica de dos contenedores (contenedores web_only y data separados) a una configuración donde la base de datos está alojada en un servidor de base de datos central (no dentro de un contenedor docker).
La base de datos central se creó a partir del volcado dump.sql que forma parte del archivo de copia de seguridad. El docker compose web_only.yaml utiliza
Durante la compilación de web_only, obtengo el siguiente error:
FALLÓ
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' falló con el retorno #<Process::Status: pid 741 exit 1>
Ubicación del fallo: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec falló con los parámetros {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
falló el arranque con el código de salida 1
** FALLÓ EL ARRANQUE ** por favor, desplázate hacia arriba y busca mensajes de error anteriores, puede haber más de uno.
Se puede acceder al host de la base de datos con estos datos. ¿Alguna idea de lo que está pasando aquí? La misma compilación con el contenedor de base de datos estándar finaliza con éxito.
¿Está seguro de que la base de datos remota está disponible desde el servidor? Parece que no lo está. ¿Puede hacer telnet al puerto de la base de datos desde la máquina del servidor web?
En cuanto a DISCOURSE_DB_SOCKET: ‘’: como usamos una conexión remota, supongo que el valor del socket no es relevante en ambos casos (datos dockerizados o datos remotos)
El error estaba más arriba en el registro de compilación:
…
docker_manager ya está en la última versión compatible
wp-discourse ya está en la última versión compatible
I, [2023-11-10T21:08:17.388213 #1] INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate'
El nombre del plugin es 'discourse-topic-voting', pero el directorio del plugin se llama 'discourse-voting'
rake abortado!
ActiveRecord::StatementInvalid: PG::InsufficientPrivilege: ERROR: permiso denegado para la tabla users (ActiveRecord::StatementInvalid)
¡Así que buenas noticias! Se está conectando bien, son los permisos de la base de datos los que necesitan ajustarse.
… ok ok, parece que tengo algunos problemas más de permisos aquí, mira /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, como siempre, fue un “problema de capa 8”
Ya tenía una base de datos de discourse en postgres, pero el usuario/rol de discourse no tenía todos los privilegios requeridos sobre ella. Y me perdí algunas diferencias importantes de “comportamiento” entre mariadb y postgres…
Ahora recreé todo: usuario, base de datos, permisos para el usuario/rol (incluyendo ALTER DEFAULT PRIVILEGES FOR ROLE discourse IN SCHEMA public GRANT ALL ON TABLES TO “discourse”; para que coincida con las tablas creadas por este usuario en el futuro)
La compilación terminó y la instancia funciona bien con el servidor postgres remoto, así que está lista para importar la copia de seguridad de la instancia anterior.
