Erreur de mise à niveau de 2.3.5 vers 2.4.2

J’essaie de passer de la version 2.3.5 à la 2.4.2 (dans un conteneur Docker Bitnami sur Google Cloud).

La restauration de l’archive de sauvegarde 2.3.5 dans une nouvelle instance 2.4.2 a échoué purement et simplement.

J’ai décompressé l’archive, récupéré le fichier pg_dump et l’ai chargé dans une nouvelle base de données. Cela semblait correct dans l’ensemble, à l’exception de deux erreurs :

> ERROR:  schema "discourse_functions" does not exist
> ERROR:  schema "discourse_functions" does not exist

Il manque donc quelque chose…

J’ai tout de même essayé ceci…

> /opt/bitnami/apps/discourse/htdocs$ sudo bin/rake db:migrate RAILS_ENV=production
> rake aborted!
> PG::InsufficientPrivilege: ERROR:  permission denied for table 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
> (See full trace by running task with --trace)

Toute orientation serait appréciée.

Je suis désolé, mais le paquet Bitnami n’est pas pris en charge ici. Il s’agit d’un paquet tiers, et si vous souhaitez continuer à l’utiliser, vous devrez contacter leurs équipes pour obtenir une assistance.

Nous vous recommandons de procéder à une sauvegarde complète et de réinstaller en utilisant la méthode d’installation standard prise en charge.

2 « J'aime »

Bonjour Stephen,

Un archivage de sauvegarde 2.3.5 devrait-il pouvoir être restauré sur une installation standard 2.4.2 sans problème ?

Cela devrait fonctionner, mais ne vous fiez pas uniquement à mon avis et prévoyez toujours une stratégie de repli. Rappelez-vous que vous êtes sur une installation non prise en charge, je peux donc vous proposer des suggestions pour vous orienter vers une voie mieux supportée, mais les installations Bitnami sont problématiques — il est préférable de se préparer au pire.

Si vous construisez sur un serveur séparé, vous pouvez tester cela avant d’apporter des modifications irréversibles à votre installation existante.

Quelques éléments de contexte :

Nous exécutons la version 2.3.5 sur Amazon.

Nous avons essayé de créer le paquet d’installation standard sur Docker, à la fois sur une machine virtuelle Ubuntu 18.04 LTS dans le cloud Google et sur VirtualBox ici. Le même problème se produit.

Nous n’avons pas pu construire l’image Docker de Discourse v2.3.5 (avec PostgreSQL/Redis intégrés), ni la v2.3.10. Toutes deux échouent avec une erreur de permission PostgreSQL, tant sur le cloud Google que sur la machine virtuelle VirtualBox avec Ubuntu 18.04.

Cependant, la version stable (2.4.2) se construit, mais ni l’image Docker 2.4.2 sur le cloud Google ni celle sur VirtualBox ne se chargent. Toutes deux échouent lors de la création des « fonctions Discourse ».

Nous allons essayer le processus de construction selon le lien que vous nous avez envoyé et nous vous tiendrons informés. Dois-je créer un sujet différent pour chaque tentative d’environnement ?

Je pourrai alors indiquer où chaque environnement bloque spécifiquement. Si c’est le cas.

Les instances Google Cloud avec Ubuntu 18.04 sont-elles prises en charge ? Et leur SQL ?

Oui, mais l’environnement est plus complexe que celui de DigitalOcean. L’installation sur DO prend au maximum 30 minutes et vous n’aurez pas à vous soucier des ACL et des politiques réseau.

Consultez /var/discourse/templates/web_only.yml (ou un fichier similaire, c’est de mémoire) pour un exemple d’utilisation d’une base de données externe.

Une fois que vous aurez un site vide en ligne, vous pourrez restaurer une sauvegarde avec discourse restore.

2 « J'aime »

Nous avons essayé de compiler la version 2.3.5 de Discourse dans une machine virtuelle Ubuntu 18.0.4. La version « v2.3.5 » a été ajoutée au fichier app.yml, mais l’opération échoue ici :

> ÉCHEC--------------------Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle install --deployment --retry 3 --jobs 4 --verbose --without test development' a échoué avec le code de retour #<Process::Status: pid 353 exit 1>Emplacement de l'échec : /pups/lib/pups/exec_command.rb:112:in `spawn' L'exécution a échoué avec les paramètres {"cd"=>"$home", "hook"=>"bundle_exec", "cmd"=>["su discourse -c 'bundle install --deployment --retry 3 --jobs 4 --verbose --without test development'"]}a3cebbd8e5a24b8a2b248886f0fa195f401720a6dc7084ad78af6cee345de9a9** ÉCHEC DU BOOTSTRAP ** veuillez défiler vers le haut et rechercher les messages d'erreur antérieurs, il peut y en avoir plus d'un../discourse-doctor peut aider à diagnostiquer le problème.

Devrais-je essayer avec DigitalOcean ou avec une base de données externe ?

Il semble que l’installation de l’instance v2.3.5 de Discourse sur Google All-in-One 18.0.4 LTS se soit arrêtée ici :

> [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': Could not find 'bundler' (1.17.3) required by your /var/www/discourse/Gemfile.lock. (Gem::GemNotFoundException)To update to the latest version installed on your system, run `bundle update --bundler`.To install the missing version, run `gem install bundler:1.17.3`        from /usr/local/lib/ruby/site_ruby/2.6.0/rubygems.rb:294:in `activate_bin_path'        from /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 -- : Terminating async processesI, [2020-05-01T18:54:21.235582 #1]  INFO -- : Sending INT to 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 -- : Sending TERM to 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:  received fast shutdown request181:signal-handler (1588359261) Received SIGTERM scheduling shutdown...2020-05-01 18:54:21.241 UTC [64] LOG:  aborting any active transactions2020-05-01 18:54:21.248 UTC [64] LOG:  worker process: logical replication launcher (PID 73) exited with exit code 12020-05-01 18:54:21.248 UTC [68] LOG:  shutting down181:M 01 May 2020 18:54:21.268 # User requested shutdown...181:M 01 May 2020 18:54:21.269 * Saving the final RDB snapshot before exiting.181:M 01 May 2020 18:54:21.271 * DB saved on disk181:M 01 May 2020 18:54:21.271 # Redis is now ready to exit, bye bye...2020-05-01 18:54:21.288 UTC [64] LOG:  database system is shut down

Pourquoi ne pas construire stable et tester la restauration dans celle-ci ?

Ok, nous allons essayer cela et vous signaler l’erreur.

Faut-il utiliser une commande en ligne de commande ou l’action de restauration via l’interface utilisateur ?

Les deux devraient fonctionner. Peu importe ce qui est plus facile.

1 « J'aime »

Ok, nous avons réussi à créer un environnement 2.4.2. Cependant, la sauvegarde a été effectuée à partir d’un déploiement Amazon avec S3 configuré. La restauration vers un environnement non Amazon échoue lors de certains scripts S3.

> Reconnexion à la base de données...
> Rechargement des paramètres du site...
> Désactivation des emails sortants pour les utilisateurs non membres du personnel...
> Désactivation du mode lecture seule...
> Vidage du cache des catégories...
> Vidage du cache des émojis...
> Vidage du cache du thème
> Réaffectation des fichiers uploadés...
> Restauration des fichiers uploadés, cela peut prendre un certain temps...
> Migration des fichiers uploadés vers S3 pour 'default'...
> Téléversement des fichiers vers S3...
>  - Répertoriation des fichiers locaux
>  => 3 fichiers
>  - Répertoriation des fichiers S3
> . => 3 fichiers
>  - Synchronisation des fichiers vers S3
> ...
> Mise à jour des URLs dans la base de données...
> Suppression des anciennes images optimisées...
> Marquage de tous les posts contenant des lightboxes pour une nouvelle cuisson
> 182 posts ont été marqués pour une nouvelle cuisson
> EXCEPTION : 215 des 295 fichiers uploadés n'ont pas été migrés vers S3. La migration S3 a échoué pour la base de données '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>'
> Tentative de retour en arrière...
> Retour en arrière en cours...
> Nettoyage des éléments...
> Suppression des fonctions du schéma discourse_functions...
> Suppression du répertoire tmp '/var/www/discourse/tmp/restores/default/2020-05-01-230400'...
> Réactivation de sidekiq...
> Marquage de la restauration comme terminée...
> Notification à 'system' de la fin de la restauration...
> Terminé !
> [ÉCHÉC]
> Restauration terminée.

Et maintenant ?

Effectuez une sauvegarde et une restauration uniquement de la base de données, puis déplacez manuellement les ressources locales.

Les sites concernés par ce problème contiennent des ressources dans deux buckets S3 différents.

1 « J'aime »