Error al actualizar de 2.3.5 a 2.4.2

Soporte Instalación
1

Estoy intentando actualizar de la versión 2.3.5 a la 2.4.2 (en un contenedor Docker de Bitnami, en Google Cloud).

La restauración del archivo de respaldo de 2.3.5 en una nueva instalación de 2.4.2 falló directamente.

Descomprimí el archivo y obtuve el archivo pg_dump, que cargué en una nueva base de datos. Parecía estar bien en su mayoría, excepto por dos errores:

> ERROR: el esquema "discourse_functions" no existe
> ERROR: el esquema "discourse_functions" no existe

Así que falta algo…

De todos modos, intenté esto…

> /opt/bitnami/apps/discourse/htdocs$ sudo bin/rake db:migrate RAILS_ENV=production
> rake aborted!
> PG::InsufficientPrivilege: ERROR: permiso denegado para la tabla site_settings
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/mini_sql-0.2.4/lib/mini_sql/postgres/connection.rb
> :118:in `exec'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/mini_sql-0.2.4/lib/mini_sql/postgres/connection.rb
> :118:in `run'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/mini_sql-0.2.4/lib/mini_sql/postgres/connection.rb
> :82:in `query'
> /opt/bitnami/apps/discourse/htdocs/lib/site_settings/db_provider.rb:19:in `all'
> /opt/bitnami/apps/discourse/htdocs/lib/site_settings/defaults_provider.rb:29:in `db_all'
> /opt/bitnami/apps/discourse/htdocs/lib/site_setting_extension.rb:277:in `block in refresh!'
> /opt/bitnami/apps/discourse/htdocs/lib/site_setting_extension.rb:274:in `synchronize'
> /opt/bitnami/apps/discourse/htdocs/lib/site_setting_extension.rb:274:in `refresh!'
> /opt/bitnami/apps/discourse/htdocs/lib/site_setting_extension.rb:495:in `block in setup_methods'
> /opt/bitnami/apps/discourse/htdocs/config/initializers/004-message_bus.rb:120:in `<top (required)>'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/dependencie
> s.rb:319:in `load'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/dependencie
> s.rb:319:in `block in load'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/dependencie
> s.rb:291:in `load_dependency'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/dependencie
> s.rb:319:in `load'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/engine.rb:667:in `block i
> n load_config_initializer'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/notificatio
> ns.rb:182:in `instrument'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/engine.rb:666:in `load_co
> nfig_initializer'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/engine.rb:624:in `block (
> 2 levels) in <class:Engine>'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/engine.rb:623:in `each'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/engine.rb:623:in `block i
> n <class:Engine>'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/initializable.rb:32:in `i
> nstance_exec'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/initializable.rb:32:in `r
> un'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/initializable.rb:61:in `b
> lock in run_initializers'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/initializable.rb:50:in `e
> ach'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/initializable.rb:50:in `t
> sort_each_child'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/initializable.rb:60:in `r
> un_initializers'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/application.rb:363:in `in
> itialize!'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/railtie.rb:190:in `public
> _send'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/railtie.rb:190:in `method
> _missing'
> /opt/bitnami/apps/discourse/htdocs/config/environment.rb:7:in `<top (required)>'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/zeitwerk-2.2.2/lib/zeitwerk/kernel.rb:23:in `requi
> re'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/zeitwerk-2.2.2/lib/zeitwerk/kernel.rb:23:in `requi
> re'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/dependencie
> s.rb:325:in `block in require'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/dependencie
> s.rb:291:in `load_dependency'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/dependencie
> s.rb:325:in `require'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/application.rb:339:in `re
> quire_environment!'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/application.rb:515:in `bl
> ock in run_tasks_blocks'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/rake-13.0.1/exe/rake:27:in `<top (required)>'
> Tasks: TOP => db:migrate => db:load_config => environment
> (Véase el rastreo completo ejecutando la tarea con --trace)

Agradezco cualquier orientación.

2

Lo siento, pero el paquete de Bitnami no es compatible aquí. Es un paquete de terceros y, si deseas seguir utilizándolo, necesitarás contactar con ellos para obtener asistencia.

Nuestra recomendación sería realizar una copia de seguridad completa y reinstalar utilizando el método de instalación estándar compatible.

3

Hola Stephen,

¿Debería funcionar sin problemas la restauración de un archivo de copia de seguridad 2.3.5 en una instalación estándar 2.4.2?

4

Debería, pero no te fíes solo de mi palabra y asegúrate de tener una estrategia de respaldo. Recuerda que estás en una instalación sin soporte, así que puedo darte sugerencias sobre cómo pasar a un camino más sostenible, pero las instalaciones de Bitnami son problemáticas: lo mejor es prepararse para lo peor.

Si lo construyes en un servidor separado, puedes probarlo antes de realizar cambios irreversibles en tu instalación actual.

5

Un poco de contexto:

Tenemos la versión 2.3.5 ejecutándose en Amazon.

Hemos intentado construir el paquete de instalación estándar en Docker sobre una máquina virtual Ubuntu 18.04 LTS, tanto en Google Cloud como en VirtualBox local. El mismo problema ocurre en ambos casos.

No pudimos construir la imagen de Discourse Docker v2.3.5 (con PostgreSQL y Redis integrados), ni tampoco la v2.3.10. Ambas fallan con un problema de permisos de PostgreSQL, tanto en Google Cloud como en la máquina virtual VirtualBox con Ubuntu 18.04.

Sin embargo, la versión estable (2.4.2) sí se construye, pero ni la imagen Docker 2.4.2 en Google Cloud ni en VirtualBox logran cargarse. Ambas fallan al construir “discourse functions”.

Probaremos el proceso de construcción según el enlace que nos enviaste y te informaremos. ¿Debería crear un tema diferente para cada intento en cada entorno?

6

Entonces puedo publicar dónde se atasca específicamente cada entorno. Si es así.

¿Se admiten instancias de Google Cloud con Ubuntu 18.04 y su SQL?

7

Sí, pero es un entorno más complejo que DigitalOcean. La instalación en DO es un proceso de máximo 30 minutos y no tendrás que preocuparte por las ACL y las políticas de red.

8

Consulta /var/discourse/templates/web_only.yml (o algo similar, eso es de memoria) como ejemplo de cómo usar una base de datos externa.

Una vez que tengas un sitio vacío en funcionamiento, podrás restaurar una copia de seguridad con discourse restore.

9

Intentamos compilar discourse 2.3.5 en una máquina virtual con Ubuntu 18.0.4. Se agregó la versión “v2.3.5” a app.yml y falló aquí:

> FAILED--------------------Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle install --deployment --retry 3 --jobs 4 --verbose --without test development' failed with return #<Process::Status: pid 353 exit 1>Location of failure: /pups/lib/pups/exec_command.rb:112:in `spawn'exec failed with the params {"cd"=>"$home", "hook"=>"bundle_exec", "cmd"=>["su discourse -c 'bundle install --deployment --retry 3 --jobs 4 --verbose --without test development'"]}a3cebbd8e5a24b8a2b248886f0fa195f401720a6dc7084ad78af6cee345de9a9** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one../discourse-doctor may help diagnose the problem.

Por favor, revise los mensajes de error anteriores; puede haber más de uno. ../discourse-doctor puede ayudar a diagnosticar el problema.

10

¿Debería probar en DigitalOcean o con una base de datos externa?

11

Parece que la instancia de Google All-in-One 18.0.4 LTS con el contenedor de Discourse v2.3.5 falló aquí:

> [2020-05-01T18:54:20.903566 #1]  INFO -- : > cd /var/www/discourse && su discourse -c 'bundle install --deployment --retry 3 --jobs 4 --verbose --without test development'/usr/local/lib/ruby/site_ruby/2.6.0/rubygems.rb:275:in `find_spec_for_exe': No se pudo encontrar 'bundler' (1.17.3) requerido por tu /var/www/discourse/Gemfile.lock. (Gem::GemNotFoundException)Para actualizar a la versión más reciente instalada en tu sistema, ejecuta `bundle update --bundler`.Para instalar la versión faltante, ejecuta `gem install bundler:1.17.3`        desde /usr/local/lib/ruby/site_ruby/2.6.0/rubygems.rb:294:in `activate_bin_path'        desde /usr/local/bin/bundle:23:in `<main>'I, [2020-05-01T18:54:21.234673 #1]  INFO -- : I, [2020-05-01T18:54:21.235321 #1]  INFO -- : Finalizando procesos asíncronosI, [2020-05-01T18:54:21.235582 #1]  INFO -- : Enviando INT a HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/10/bin/postmaster -D /etc/postgresql/10/main pid: 64I, [2020-05-01T18:54:21.235838 #1]  INFO -- : Enviando TERM a exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 1812020-05-01 18:54:21.236 UTC [64] LOG:  solicitud de apagado rápido recibida181:signal-handler (1588359261) Se recibió SIGTERM programando el apagado...2020-05-01 18:54:21.241 UTC [64] LOG:  abortando cualquier transacción activa2020-05-01 18:54:21.248 UTC [64] LOG:  proceso worker: lanzador de replicación lógica (PID 73) salió con código de salida 12020-05-01 18:54:21.248 UTC [68] LOG:  apagándose181:M 01 May 2020 18:54:21.268 # El usuario solicitó el apagado...181:M 01 May 2020 18:54:21.269 * Guardando la instantánea RDB final antes de salir.181:M 01 May 2020 18:54:21.271 * DB guardada en disco181:M 01 May 2020 18:54:21.271 # Redis ahora está listo para salir, adiós...2020-05-01 18:54:21.288 UTC [64] LOG:  el sistema de base de datos está apagado
12

¿Por qué no compilar stable y probar la restauración en ese entorno?

13

Ok, lo intentaremos y reportaremos el error.

14

¿Deberíamos usar un comando de línea de comandos o la acción de restauración a través de la interfaz de usuario?

15

Cualquiera debería funcionar. Lo que sea más fácil.

16

Bien, logramos crear un entorno de la versión 2.4.2. Sin embargo, la copia de seguridad se realizó en una implementación de Amazon con S3 configurado. La restauración en un entorno que no es de Amazon falla en algunos scripts de S3.

> Reconectando a la base de datos...
> Volviendo a cargar la configuración del sitio...
> Desactivando los correos salientes para usuarios que no son del personal...
> Desactivando el modo de solo lectura...
> Limpiando la caché de categorías...
> Limpiando la caché de emojis...
> Limpiando la caché del tema
> Remapeando las cargas...
> Restaurando las cargas, esto puede tardar un rato...
> Migrando las cargas a S3 para 'default'...
> Subiendo archivos a S3...
>  - Listando archivos locales
>  => 3 archivos
>  - Listando archivos en S3
> . => 3 archivos
>  - Sincronizando archivos con S3
> ...
> Actualizando las URLs en la base de datos...
> Eliminando imágenes optimizadas antiguas...
> Marcando todos los posts que contienen lightboxes para reb
> 182 posts fueron marcados para una nueva elaboración
> EXCEPCIÓN: 215 de 295 cargas no se migraron a S3. La migración a S3 falló para la base de datos 'default'.
> /var/www/discourse/lib/file_store/to_s3_migration.rb:131:in `raise_or_log'
> /var/www/discourse/lib/file_store/to_s3_migration.rb:78:in `migration_successful?'
> /var/www/discourse/lib/file_store/to_s3_migration.rb:351:in `migrate_to_s3'
> /var/www/discourse/lib/file_store/to_s3_migration.rb:65:in `migrate'
> /var/www/discourse/lib/file_store/s3_store.rb:203:in `copy_from'
> /var/www/discourse/lib/backup_restore/uploads_restorer.rb:48:in `restore_uploads'
> /var/www/discourse/lib/backup_restore/uploads_restorer.rb:30:in `restore'
> /var/www/discourse/lib/backup_restore/restorer.rb:59:in `run'
> script/discourse:143:in `restore'
> /var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/command.rb:27:in `run'
> /var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/invocation.rb:127:in `invoke_command'
> /var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor.rb:392:in `dispatch'
> /var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/base.rb:485:in `start'
> script/discourse:284:in `<top (required)>'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `load'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `kernel_load'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:28:in `run'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:476:in `exec'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invok
> e_command'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor.rb:399:in `dispatch'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:30:in `dispatch'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/base.rb:476:in `start'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:24:in `start'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:46:in `block in <top (required)>'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:34:in `<top (required)>'
> /usr/local/bin/bundle:23:in `load'
> /usr/local/bin/bundle:23:in `<main>'
> Intentando revertir...
> Revertiendo...
> Limpiando cosas...
> Eliminando funciones del esquema discourse_functions...
> Eliminando el directorio temporal '/var/www/discourse/tmp/restores/default/2020-05-01-230400'...
> Reanudando sidekiq...
> Marcando la restauración como finalizada...
> Notificando a 'system' sobre el final de la restauración...
> ¡Finalizado!
> [FALLÓ]
> Restauración completada.

¿Y ahora qué?

18

Realiza una copia de seguridad y restauración solo de la base de datos y mueve los activos locales manualmente.

Los sitios con los que tengo ese problema tienen activos en dos buckets de S3 diferentes.