Copia de seguridad multisite usando user discourse en lugar de DB_USER o valor de multisite.yml

Error
1

EDITAR/Tl;dr: ActiveRecord::Base.connection_pool.db_config.configuration_hash tiene el nombre de usuario en user, no en username, pero Discourse lo busca en username.
PR trivial: FIX: backup_restore.rb wants db user from user, not username by pfaffman · Pull Request #28229 · discourse/discourse · GitHub

…

Tengo una instancia multisitio usando postgres alojado de Digital Ocean. Funciona bien, pero cuando intento hacer una copia de seguridad, obtengo un error que dice

[2024-08-05 16:13:31] pg_dump: error: connection to server at "private-forum-cluster-postgresql-prod-do-user-1230.j.db.ondigitalocean.com" (10.11.1.6), port 25060 failed: FATAL: password authentication failed for user "discourse"

Pero el usuario no es discourse. Está usando el usuario correcto en otros lugares, incluyendo ActiveRecord::Base.connection_pool.db_config.configuration_hash y BackupRestore.database_configuration (cuando ejecuto esos comandos en RAILS_DB=sitename rails c). PG_USER no está configurado en el entorno (que yo pueda ver).

Parece que esto es lo que lo causa:

Lo edité en el contenedor (para sacarlo de DISCOURSE_DB_USER, lo que parecía una buena idea en ese momento) y la copia de seguridad funciona ahora. No sé si se supone que se puede extraer la información de conexión de multisite.yml o no, pero ignorar DB_USER parece incorrecto.
¿O tal vez solo debería hacer que el usuario sea discourse como supongo que todos los demás deben estar haciendo?

EDITAR: Espera. No.
config['username'] debería ser config['user']

    config = ActiveRecord::Base.connection_pool.db_config.configuration_hash

¡devuelve esto!


=> {:adapter=>"postgresql",
 :database=>"theDatabase",
 :pool=>25,
 :port=>25060,
 :timeout=>5000,
 :host=>"private-forum-cluster-postgresql-prod-do-user-123-0.j.db.ondigitalocean.com",
 :user=>"theCurrentUsername",
 :password=>"supersecret",
 :host_names=>["forum.example.com"],
 :db_key=>"mydb",
 :prepared_statements=>false}

Entonces

    config["username"] || username || ENV["USER"] || "postgres",

debería ser

    config["user"] || username || ENV["USER"] || "postgres",
2 Me gusta
2

@pfaffman Lamento informarte que tuvimos que revertir esto, porque rompió la restauración de copias de seguridad en nuestros entornos de producción.

Nuestra configuración de multisitio de ejemplo (y, de hecho, la configuración de producción) la tiene bajo ‘username’:

2 Me gusta
3

Lo siento mucho. Todavía estoy confundido sobre cómo funciona para todo excepto para la copia de seguridad.

Hmm.

Quizás ese sea mi problema. Pero, ¿cómo funciona para todo lo demás?

Quizás todo lo demás utiliza la configuración global de una variable de entorno.

2 Me gusta
4

Lo siento mucho.

No se me ocurrió que ActiveRecord::Base.connection_pool.db_config.configuration_hash fuera simplemente cualquier tontería que pusiera en el archivo multisite.yml.

Renombré todos mis campos user: erróneos como username: y ahora mi copia de seguridad funciona.

Mi explicación (que no he probado) es que el resto de Rails anula el db_username de GlobalSettings si se establece allí, pero cuando va a obtener esa información para hacer la llamada externa a pg_dump, la extrae de la configuración de multisite.

Todavía creo que es un error que la copia de seguridad obtenga un usuario diferente y que la solución sería incluir la extracción de env['DISCOURSE_DB_USERNAME'] en algún lugar de esa declaración de asignación, pero no estoy dispuesto a arriesgarme a romper la producción de nuevo, y ahora está funcionando.

¡Deberías dejar de dar “me gusta” a mi publicación y quitarme mi insignia! :crying_cat_face:

2 Me gusta
5

No te preocupes, estas cosas pasan. Lo ideal habría sido detectarlo en CI, pero supongo que no tenemos cobertura de esta lógica (quizás sea difícil, ya que la configuración de la base de datos es completamente diferente en las pruebas de todos modos).

Gracias por documentar lo que encontraste, estoy seguro de que ayudará a otros en el futuro. Estoy de acuerdo en que la inconsistencia aquí es mala y sería bueno arreglarla en algún momento.

3 Me gusta