Ziemlich! Seltsam, da ich vorher noch nie von Gemfile oder Gemfile.lock gehört hatte. Aber da ich 20 andere Foren habe, auf denen ich die Installation wiederholen muss (seufz), stellt sich heraus, dass die ganze Sache mit einem anderen Problem während der Installation begann, bei dem die Beschwerden mit der Empfehlung endeten, das Gemfile.lock zu löschen:
Bundler fand widersprüchliche Anforderungen für die Ruby-Version:
In Gemfile:
actionmailer (= 7.0.4.3) wurde zu 7.0.4.3 aufgelöst, was davon abhängt
Ruby (>= 2.7.0)
sassc-rails wurde zu 2.1.2 aufgelöst, was davon abhängt
sprockets-rails wurde zu 3.4.2 aufgelöst, was davon abhängt
Ruby (>= 2.5)
json wurde zu 2.6.3 aufgelöst, was davon abhängt
Ruby (>= 2.3)
:
:
:
json_schemer wurde zu 0.2.23 aufgelöst, was davon abhängt
ecma-re-validator (~> 0.3) wurde zu 0.4.0 aufgelöst, was davon abhängt
Ruby (>= 2.6, < 4.0)
rspec wurde zu 3.12.0 aufgelöst, was davon abhängt
rspec-expectations (~> 3.12.0) wurde zu 3.12.2 aufgelöst, was davon abhängt
diff-lcs (>= 1.2.0, < 2.0) wurde zu 1.5.0 aufgelöst, was davon abhängt
Ruby (>= 1.8)
web-push wurde zu 3.0.0 aufgelöst, was davon abhängt
Ruby (>= 3.0)
Aktuelle Ruby-Version:
Ruby (= 2.7.6)
Bundler konnte keine kompatiblen Versionen für Gem "hkdf" finden:
In Snapshot (Gemfile.lock):
hkdf (= 1.0.0)
In Gemfile:
web-push wurde zu 1.0.0 aufgelöst, was davon abhängt
hkdf (~> 0.2)
Das Löschen Ihrer Gemfile.lock-Datei und die Ausführung von `bundle install` wird Ihren
Snapshot von Grund auf neu erstellen, nur mit
den Gems in Ihrer Gemfile, was den Konflikt beheben kann.
Nachdem ich diesen anfänglichen Fehler behoben hatte, indem ich die Lock-Datei wie vorgeschlagen entfernt hatte, stieß ich auf den NameError: undefined method ‘call’, der zuvor beschrieben wurde. Dies wurde behoben, indem die Redis-Version festgelegt wurde. Dann funktionierte alles.
Mein Skript wurde also modifiziert, um a) Gemfile.lock zu entfernen (wegen des oben zitierten Fehlers) und b) automatisch die Gemfile zu ändern, um Redis auf 4.8.0 festzulegen. Alles paletti… dachte ich. Das funktionierte auf drei der 20 “identischen” Maschinen! Die anderen zeigten diesen neuen Fehler:
[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)
Was wirklich, wirklich seltsam war, denn die Dateien /var/discourse/config/initializers/100-sidekiq.rb waren auf allen Maschinen identisch und enthielten sicherlich nicht ‘logger=’, sondern eine ‘logger = …’-Anweisung.
Ich fand schließlich heraus, dass auf den Maschinen, auf denen es funktionierte, /usr/local/bin/bundle Version 2.3.20 war und nicht 2.3.26 wie auf den Maschinen, auf denen es fehlschlug. Zusammenfassend lässt sich sagen, dass das Hinzufügen von Folgendem vor dem Installationsbefehl für Discourse den Trick für mich gemacht hat (es reichte nicht aus, die Bundler-Festlegung auf 2.3.20 nach der Bundler-Installation von Discourse vorzunehmen, es musste vorher geschehen):
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
Warum auf einigen dieser Maschinen bundler 2.3.26 und auf anderen 2.3.20 war, weiß ich nicht… aber es ist wahrscheinlich nicht Ihre Schuld 
.
