Erro ao atualizar de 2.3.5 para 2.4.2

Suporte Instalação
1

Estou tentando atualizar da versão 2.3.5 para a 2.4.2 (em um contêiner Docker da Bitnami, no Google Cloud).

A restauração do arquivo de backup do 2.3.5 para o novo 2.4.2 falhou completamente.

Descompactei o arquivo e obtive o arquivo pg_dump, que carreguei em um novo banco de dados. Parecia estar tudo bem na maior parte, exceto por dois erros:

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

Então, algo está faltando…

Tentei isso mesmo assim…

> /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)

Qualquer orientação é bem-vinda.

2

Sinto muito, mas o pacote Bitnami não é suportado aqui. Trata-se de um pacote de terceiros e, se desejar continuar a utilizá-lo, precisará entrar em contato com eles para obter qualquer assistência.

Nossa recomendação é fazer um backup completo e reinstalar usando o método de instalação padrão suportado.

3

Olá Stephen,

A restauração de um arquivo de backup da versão 2.3.5 em uma instalação padrão da versão 2.4.2 deve funcionar sem problemas?

4

Deveria, mas não confie apenas na minha palavra e não deixe de ter uma estratégia de contingência. Lembre-se de que você está em uma instalação não suportada, então posso oferecer sugestões sobre como migrar para um caminho mais sustentável. No entanto, as instalações do Bitnami são problemáticas — o ideal é se preparar para o pior.

Se você criar em um servidor separado, poderá testar isso antes de fazer alterações irreversíveis na sua instalação existente.

5

Um pouco de contexto:

Temos a versão 2.3.5 rodando na Amazon.

Tentamos criar o pacote de instalação padrão do Docker em uma VM Ubuntu 18.04 LTS tanto na Google Cloud quanto no VirtualBox aqui. O mesmo problema ocorre.

Não conseguimos construir o Docker do Discourse v2.3.5 (com PostgreSQL/Redis embutidos), nem a v2.3.10. Ambos falham com algum problema de permissão do PostgreSQL, tanto na Google Cloud quanto na VM VirtualBox com Ubuntu 18.04.

No entanto, a versão estável (2.4.2) constrói, mas nem a imagem Docker 2.4.2 na Google Cloud nem no VirtualBox consegue carregar. Ambas falham ao construir “discourse functions”.

Vamos tentar o processo de construção conforme o link que nos enviou e retornaremos com o resultado. Devo registrar cada tentativa de ambiente como um tópico diferente?

6

Assim, poderei postar onde cada ambiente especificamente trava. Se isso acontecer.

Instâncias do Google Cloud com Ubuntu 18.0.4 são suportadas? E com o SQL deles?

7

Sim, mas é um ambiente mais complexo do que o DigitalOcean. A instalação no DO leva no máximo 30 minutos e você não precisará se preocupar com ACLs e políticas de rede.

8

Veja /var/discourse/templates/web_only.yml (ou algo similar, isso é de memória) como exemplo de como usar um banco de dados externo.

Depois de configurar um site vazio, você poderá restaurar um backup com discourse restore.

9

Tentamos construir o Discourse 2.3.5 em uma VM Ubuntu 18.04. Adicionamos a versão “v2.3.5” ao app.yml e falhou aqui:

> 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.

** FALHA NO BOOTSTRAP ** por favor, role para cima e procure mensagens de erro anteriores, pode haver mais de uma. O ./discourse-doctor pode ajudar a diagnosticar o problema.

10

Devo tentar no DigitalOcean ou com um banco de dados externo?

11

Parece que a instância do Google All-in-One 18.0.4 LTS com o contêiner Discourse v2.3.5 falhou aqui:

> [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
12

Por que não compilar a stable e testar a restauração nela?

13

Ok, vamos tentar isso e reportar o erro.

14

Deveríamos usar um comando de linha de comando ou a ação de restauração pela interface?

15

Qualquer um dos dois deve funcionar. O que for mais fácil.

16

Ok, então conseguimos montar um ambiente 2.4.2. No entanto, o backup foi feito a partir de uma implantação na Amazon com S3 configurado. A restauração para um ambiente fora da Amazon falha em alguns scripts do S3.

> Reconectando ao banco de dados...
> Recarregando as configurações do site...
> Desativando e-mails de saída para usuários não staff...
> Desativando o modo somente leitura...
> Limpando o cache de categorias...
> Limpando o cache de emojis...
> Limpando o cache do tema
> Remapeando uploads...
> Restaurando uploads, isso pode levar um tempo...
> Migrando uploads para o S3 para 'default'...
> Enviando arquivos para o S3...
>  - Listando arquivos locais
>  => 3 arquivos
>  - Listando arquivos no S3
> . => 3 arquivos
>  - Sincronizando arquivos com o S3
> ...
> Atualizando as URLs no banco de dados...
> Removendo imagens otimizadas antigas...
> Marcando todas as postagens contendo lightboxes para rebake
> 182 postagens foram marcadas para rebake
> EXCEÇÃO: 215 de 295 uploads não foram migrados para o S3. A migração para o S3 falhou para o banco de dados '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>'
> Tentando reverter...
> Revertendo...
> Limpando arquivos...
> Removendo funções do esquema discourse_functions...
> Removendo diretório tmp '/var/www/discourse/tmp/restores/default/2020-05-01-230400'...
> Retomando o sidekiq...
> Marcando a restauração como concluída...
> Notificando 'system' sobre o fim da restauração...
> Concluído!
> [FALHA]
> Restauração concluída.

E agora?

18

Faça um backup e restauração apenas do banco de dados e mova os ativos locais manualmente.

Os sites com os quais estou tendo esse problema possuem ativos em dois buckets S3 diferentes.