Mise à niveau vers 3.0.2 : NameError : méthode non définie `call' pour la classe `Redis::Client' (avec un "fix")

Installation
1

Je viens d’essayer de passer de la version 3.0.1 à la version 3.0.2, et j’ai obtenu cette erreur lors de l’étape rake db:migrate :

rake aborted!
NameError: undefined method `call' for class `Redis::Client'
Did you mean?  caller
/var/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-3.0.0/lib/mini_profiler/profiling_methods.rb:83:in `alias_method'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-3.0.0/lib/mini_profiler/profiling_methods.rb:83:in `profile_method'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-3.0.0/lib/mini_profiler/profiling_methods.rb:65:in `counter_method'
/var/discourse/config/initializers/006-mini_profiler.rb:90:in `<main>'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4.3/lib/rails/engine.rb:667:in `load'

Pour faire court, j’ai découvert qu’en fixant la version de redis à 4.8.0 au lieu de laisser la version de redis non spécifiée dans le Gemfile, cela a fonctionné. C’est-à-dire, pour le Gemfile :

-gem "redis"
+gem "redis", "4.8.0"

Je ne suis pas très à l’aise avec ce genre de manipulation, mais il me semble que c’est un effet secondaire involontaire de la mise à niveau de redis ailleurs depuis ma dernière mise à niveau (vers la version 3.0.1), et qu’une réinstallation de Discourse 3.0.1 présenterait maintenant le même problème.

J’espère que cela aidera quelqu’un, et faites-moi savoir si cela laisse mon système dans un état vulnérable :slight_smile:

1 « J'aime »
2

Nous définissons les versions des gems dans le fichier Gemfile.lock, et il est déjà défini sur cette même version

3

Absolument ! Étrange, car je n’avais jamais entendu parler de Gemfile ni de Gemfile.lock auparavant. Mais en ayant 20 autres forums pour répéter l’installation (soupir), il s’avère que tout a commencé par un problème différent lors de l’installation où les plaintes se sont terminées par une recommandation d’essayer de supprimer le Gemfile.lock :

Bundler a trouvé des exigences conflictuelles pour la version de Ruby :
  Dans Gemfile :
    actionmailer (= 7.0.4.3) a été résolu en 7.0.4.3, qui dépend de
      Ruby (>= 2.7.0)

    sassc-rails a été résolu en 2.1.2, qui dépend de
      sprockets-rails a été résolu en 3.4.2, qui dépend de
        Ruby (>= 2.5)

    json a été résolu en 2.6.3, qui dépend de
      Ruby (>= 2.3)

    json_schemer a été résolu en 0.2.23, qui dépend de
      ecma-re-validator (~> 0.3) a été résolu en 0.4.0, qui dépend de
        Ruby (>= 2.6, < 4.0)

    rspec a été résolu en 3.12.0, qui dépend de
      rspec-expectations (~> 3.12.0) a été résolu en 3.12.2, qui dépend de
        diff-lcs (>= 1.2.0, < 2.0) a été résolu en 1.5.0, qui dépend de
          Ruby (>= 1.8)

    web-push a été résolu en 3.0.0, qui dépend de
      Ruby (>= 3.0)

  Version Ruby actuelle :
    Ruby (= 2.7.6)

Bundler n'a pas pu trouver de versions compatibles pour le gem "hkdf" :
  Dans snapshot (Gemfile.lock) :
    hkdf (= 1.0.0)

  Dans Gemfile :
    web-push a été résolu en 1.0.0, qui dépend de
      hkdf (~> 0.2)

La suppression de votre fichier Gemfile.lock et l'exécution de `bundle install` reconstruiront votre
snapshot à partir de zéro, en utilisant uniquement
les gems de votre Gemfile, ce qui peut résoudre le conflit.

J’ai donc résolu ce premier problème après avoir supprimé le fichier de verrouillage comme suggéré, puis j’ai rencontré le NameError : undefined method ‘call’ décrit précédemment. Je l’ai résolu en fixant la version de redis. Ensuite, tout a fonctionné.

Mon script a donc été modifié pour a) supprimer Gemfile.lock (en raison de l’erreur citée ci-dessus) et b) modifier automatiquement le Gemfile pour fixer redis à 4.8.0. Tout allait bien… pensais-je. Cela a fonctionné sur trois des 20 machines “identiques” ! Les autres ont rencontré cette nouvelle erreur :

[discourse@in3020-discourse discourse]$ cd $INSTA; RAILS_ENV=production /usr/local/bin/bundle exec rake db:migrate # stuffing a lot of stuff into the database
rake aborted!
NoMethodError: undefined method `logger=' for Sidekiq:Module
Did you mean?  logger
/var/discourse/config/initializers/100-sidekiq.rb:58:in `<main>'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4.3/lib/rails/engine.rb:667:in `load'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4.3/lib/rails/engine.rb:667:in `block in load_config_initializer'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4.3/lib/active_support/notifications.rb:208:in `instrument'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4.3/lib/rails/engine.rb:666:in `load_config_initializer'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4.3/lib/rails/engine.rb:620:in `block (2 levels) in <class:Engine>'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4.3/lib/rails/engine.rb:619:in `each'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4.3/lib/rails/engine.rb:619:in `block in <class:Engine>'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4.3/lib/rails/initializable.rb:32:in `instance_exec'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4.3/lib/rails/initializable.rb:32:in `run'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4.3/lib/rails/initializable.rb:61:in `block in run_initializers'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4.3/lib/rails/initializable.rb:50:in `each'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4.3/lib/rails/initializable.rb:50:in `tsort_each_child'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4.3/lib/rails/initializable.rb:60:in `run_initializers'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4.3/lib/rails/application.rb:372:in `initialize!'
/var/discourse/config/environment.rb:7:in `<main>'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.16.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.16.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/zeitwerk-2.6.7/lib/zeitwerk/kernel.rb:38:in `require'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4.3/lib/rails/application.rb:348:in `require_environment!'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4.3/lib/rails/application.rb:511:in `block in run_tasks_blocks'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
/usr/local/share/gems/gems/bundler-2.3.26/lib/bundler/cli/exec.rb:58:in `load'
/usr/local/share/gems/gems/bundler-2.3.26/lib/bundler/cli/exec.rb:58:in `kernel_load'
/usr/local/share/gems/gems/bundler-2.3.26/lib/bundler/cli/exec.rb:23:in `run'
/usr/local/share/gems/gems/bundler-2.3.26/lib/bundler/cli.rb:486:in `exec'
/usr/local/share/gems/gems/bundler-2.3.26/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/share/gems/gems/bundler-2.3.26/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/share/gems/gems/bundler-2.3.26/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
/usr/local/share/gems/gems/bundler-2.3.26/lib/bundler/cli.rb:31:in `dispatch'
/usr/local/share/gems/gems/bundler-2.3.26/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
/usr/local/share/gems/gems/bundler-2.3.26/lib/bundler/cli.rb:25:in `start'
/usr/local/share/gems/gems/bundler-2.3.26/exe/bundle:48:in `block in <top (required)>'
/usr/local/share/gems/gems/bundler-2.3.26/lib/bundler/friendly_errors.rb:120:in `with_friendly_errors'
/usr/local/share/gems/gems/bundler-2.3.26/exe/bundle:36:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Tasks: TOP => db:migrate => db:load_config => environment
(See full trace by running task with --trace)

Ce qui était vraiment, vraiment étrange car les fichiers /var/discourse/config/initializers/100-sidekiq.rb étaient identiques sur toutes les machines, et ne contenaient certainement pas ‘logger=’, mais une déclaration ‘logger = …’.

J’ai finalement compris que sur les machines où cela fonctionnait, /usr/local/bin/bundle était la version 2.3.20, et non 2.3.26 comme sur les machines où cela échouait. Donc, en résumé, ajouter ceci avant la commande d’installation pour discourse a résolu le problème pour moi (il n’a pas suffi de fixer bundler à 2.3.20 après l’installation de bundler de discourse, cela devait être fait avant) :

rm Gemfile.lock
perl -pi.bak -e 's/gem \"redis\"/gem \"redis\",\"4.8.0\"/;' Gemfile

/usr/bin/gem uninstall bundler -v 2.3.26
/usr/bin/gem install bundler -v 2.3.20
RAILS_ENV=production /usr/local/bin/bundle install
RAILS_ENV=production /usr/local/bin/bundle exec rake db:migrate
RAILS_ENV=production /usr/local/bin/bundle exec rake assets:precompile

Pourquoi diable certaines de ces machines avaient-elles bundler 2.3.26 et d’autres 2.3.20, je n’en ai aucune idée… mais ce n’est probablement pas de votre faute :laughing:.

4

Et c’est pourquoi j’utilise la version stable :rire:

5

Ruby 2.7 est obsolète et n’est plus pris en charge par nous. Vous n’obtenez plus cette version lors de l’installation de Discourse en suivant le guide d’installation standard, j’imagine donc qu’il s’agit d’une installation personnalisée ?

Je recommande de s’en tenir au guide d’installation officiel pris en charge, même pour les personnes familières avec la pile Discourse, et c’est encore plus important pour les personnes peu familières avec les technologies utilisées.

6

Oui, le faire de la manière officielle m’aurait presque certainement évité plus de maux de tête (très probablement aucun). Le problème est que je n’ai pas le droit d’utiliser des images Docker qui ne sont pas pré-approuvées par notre département de sécurité informatique - et la vôtre ne l’est pas.

Il s’agit donc bien d’une installation personnalisée et native sur des machines RHEL8, qui a également nécessité quelques astuces SELinux pour fonctionner.

Peut-être que d’autres rencontrent le même problème - peut-être leur serait-il utile si je publiais un sujet avec ma procédure d’installation ? N’hésitez pas à protester - je comprends que cela puisse être considéré comme un « encouragement » à l’installer ainsi même si ce n’est pas strictement nécessaire, ce qui pourrait vous amener plus de questions.

Par ailleurs, en cherchant des solutions à tout problème SELinux sur Google, le conseil le plus fréquent que vous trouverez est « voici comment le désactiver » :rire:. Mais ce n’est pas une option ici.

Merci pour votre aide !

7

Merci pour le contexte. Sachez simplement que nous n’offrons pas de support gratuit pour les installations personnalisées ici.

Cette installation utilise déjà une version de Ruby qui ne fonctionne pas avec les versions actuelles de Discourse, ne respecte aucune des versions de gemmes soigneusement gérées et n’utilise pas toutes les bibliothèques partagées au niveau du système d’exploitation gérées manuellement que nous fournissons. Par conséquent, la rupture n’est pas une question de savoir si, mais plutôt de savoir quand.

3 « J'aime »
8

Vous pourriez suggérer à votre équipe de sécurité qu’une image qui est examinée et utilisée par les développeurs est beaucoup, beaucoup plus sûre que vous n’essayiez d’appliquer des correctifs de sécurité à des choses que vous ne pouvez absolument pas suivre, à moins que ce ne soit votre seule tâche.

. . . . Mais, ce n’est probablement pas utile.

9

Haha, oui (probablement plus sûr avec vos images) et non (pas utile - mais merci pour le commentaire de toute façon😊).

Ce n’est effectivement pas mon travail à temps plein, je gère ces forums « parce que je suis celui qui pouvait le faire » dans le cadre d’un programme pilote afin de convaincre notre département informatique de le prendre en charge et de le gérer pour l’ensemble de l’Université d’Oslo.

Heureusement, cela semble avoir fonctionné, donc j’espère que c’est le dernier semestre où je devrai gérer tout cela. Je parie que le département informatique utilisera les images… :wink:

Et merci, @Falco, d’avoir signalé qu’il y avait une incompatibilité de version Ruby, j’y jetterai un œil si/quand je rencontrerai des problèmes avec les futures mises à jour.

1 « J'aime »
10

Sainte vache ! Ayant été professeur dans plusieurs universités aux États-Unis, je suis assez impressionné.

1 « J'aime »
11

Oups, j’ai oublié d’appuyer sur le bouton Répondre il y a longtemps…

@pfaffman Haha, oui. Nous ne sommes pas encore sortis complètement des bois, même si le service informatique dit oui : il doit d’abord être approuvé au plus haut niveau (par le conseil de l’université) en tant que canal de communication officiel. Heureusement, nous avons rallié le département des sciences naturelles en force, et ils ont fait le nécessaire.

Je suis assez fier d’avoir pu gérer ces instances pilotes - peu de personnes extérieures au département informatique auraient pu le faire (dans le respect des politiques de sécurité nécessaires, bien sûr). Les gens des sciences naturelles y font constamment référence sous le nom de « Astro-Discourse » (je suis à l’Institut d’Astrophysique Théorique) :laughing:.

12

Mais maintenant… il semble que je doive diriger ce spectacle un semestre de plus, avec la même configuration non standard. Je me demande avec quelle(s) version(s) de pgsql la version actuelle de Discourse est compatible ?