Aggiornamento a 3.0.2: NameError: metodo non definito `call' per la classe `Redis::Client' (con una "correzione")

Installazione
1

Ho appena provato ad aggiornare da 3.0.1 a 3.0.2 e ho riscontrato questo errore durante la fase di 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/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'

Per farla breve, ho scoperto che fissare la versione di redis a 4.8.0 invece di lasciare la versione di redis non specificata nel Gemfile ha risolto il problema. Cioè, per il Gemfile:

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

Non mi sento molto a mio agio a giocherellare con questo, ma mi sembra che questo sia un effetto collaterale non intenzionale dell’aggiornamento di redis altrove dall’ultimo mio aggiornamento (a 3.0.1), e che una reinstallazione di Discourse 3.0.1 mostrerebbe ora lo stesso problema.

Spero che questo aiuti qualcuno, e per favore fatemi sapere se questo lascia il mio sistema in uno stato vulnerabile :slight_smile:

1 Mi Piace
2

Impostiamo le versioni delle gem sul file Gemfile.lock, ed è già impostato sulla stessa versione

3

Certamente! Strano, dato che non avevo mai sentito parlare né di Gemfile né di Gemfile.lock prima. Ma avendo altri 20 forum su cui ripetere l’installazione (sospiro), si scopre che tutto è iniziato con un problema diverso durante l’installazione, dove le lamentele si sono concluse con la raccomandazione di provare a eliminare Gemfile.lock:

Bundler ha trovato requisiti contrastanti per la versione di Ruby:
  In Gemfile:
    actionmailer (= 7.0.4.3) è stato risolto in 7.0.4.3, che dipende da
      Ruby (>= 2.7.0)

    sassc-rails è stato risolto in 2.1.2, che dipende da
      sprockets-rails è stato risolto in 3.4.2, che dipende da
        Ruby (>= 2.5)

    json è stato risolto in 2.6.3, che dipende da
      Ruby (>= 2.3)

    json_schemer è stato risolto in 0.2.23, che dipende da
      ecma-re-validator (~> 0.3) è stato risolto in 0.4.0, che dipende da
        Ruby (>= 2.6, < 4.0)

    rspec è stato risolto in 3.12.0, che dipende da
      rspec-expectations (~> 3.12.0) è stato risolto in 3.12.2, che dipende da
        diff-lcs (>= 1.2.0, < 2.0) è stato risolto in 1.5.0, che dipende da
          Ruby (>= 1.8)

    web-push è stato risolto in 3.0.0, che dipende da
      Ruby (>= 3.0)

  Versione Ruby corrente:
    Ruby (= 2.7.6)

Bundler non è riuscito a trovare versioni compatibili per la gemma "hkdf":
  In snapshot (Gemfile.lock):
    hkdf (= 1.0.0)

  In Gemfile:
    web-push è stato risolto in 1.0.0, che dipende da
      hkdf (~> 0.2)

Eliminare il file Gemfile.lock ed eseguire `bundle install` ricostruirà il tuo
snapshot da zero, utilizzando solo
le gemme nel tuo Gemfile, il che potrebbe risolvere il conflitto.

Quindi, ho superato quell’errore iniziale dopo aver rimosso il file di blocco come suggerito, poi mi sono imbattuto nel NameError: undefined method ‘call’ descritto in precedenza. L’ho risolto fissando la versione di redis. Poi, tutto ha funzionato.

Quindi, il mio script è stato modificato per a) rimuovere Gemfile.lock (a causa dell’errore citato sopra) e b) modificare automaticamente Gemfile per fissare redis a 4.8.0. Tutto liscio… pensavo. Questo ha funzionato su tre delle 20 macchine “identiche”! Le altre hanno dato questo nuovo errore:

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

Il che era davvero, davvero strano perché i file /var/discourse/config/initializers/100-sidekiq.rb erano identici su tutte le macchine, e certamente non contenevano ‘logger=’, ma un’istruzione ‘logger = …’.

Alla fine ho capito che sulle macchine dove ha funzionato, /usr/local/bin/bundle era la versione 2.3.20, non 2.3.26 come sulle macchine dove ha fallito. Quindi, in sintesi, aggiungere questo prima del comando di installazione per discourse ha fatto il trucco per me (non è stato sufficiente fare il pinning di bundler a 2.3.20 dopo l’installazione di bundler di discourse, doveva essere prima):

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

Perché diavolo alcune di quelle macchine avevano bundler 2.3.26 e altre 2.3.20 non ho idea… ma probabilmente non è colpa tua :laughing:.

4

E questo è il motivo per cui uso la versione stabile :laughing:

5

Ruby 2.7 è EOL e non è più supportato da noi. Non si ottiene quella versione quando si installa Discourse seguendo la guida di installazione standard da un po’ di tempo, quindi presumo che si tratti di un’installazione personalizzata?

Raccomando di attenersi alla guida di installazione ufficiale supportata anche per le persone che hanno familiarità con lo stack di Discourse, e ciò è ancora più importante per le persone che non hanno familiarità con le tecnologie utilizzate.

6

Sì, farlo nel modo ufficiale mi avrebbe quasi certamente causato meno grattacapi (molto probabilmente nessuno). Il problema è che non mi è permesso utilizzare immagini docker non pre-approvate dal nostro reparto di sicurezza IT, e la tua non lo è.

Quindi questa è effettivamente un’installazione nativa personalizzata su macchine RHEL8, che ha anche richiesto qualche trucco SELinux per funzionare.

Forse ci sono altri là fuori con lo stesso problema: forse sarebbe utile per loro se pubblicassi un argomento con la mia procedura di installazione? Sentiti libero di protestare: posso capire che questo potrebbe essere preso come un “incoraggiamento” a installarlo in questo modo anche se non strettamente necessario, il che potrebbe portare a più domande per te.

A parte questo, quando cerchi soluzioni a qualsiasi problema SELinux su Google, il consiglio più frequente che troverai è “ecco come disabilitarlo”: :joy:. Ma questa non è un’opzione qui.

Grazie per il tuo aiuto!

7

Grazie per il contesto. Tieni presente che non offriamo supporto gratuito per installazioni personalizzate qui.

Questa installazione utilizza già una versione di Ruby che non funziona con nessuna delle versioni attuali di Discourse, non rispetta nessuna delle versioni di gem attentamente gestite e non utilizza tutte le librerie condivise a livello di sistema operativo gestite manualmente che forniamo. Pertanto, il problema non è se si verificherà un’interruzione, ma piuttosto quando.

3 Mi Piace
8

Potresti suggerire al tuo team di sicurezza che un’immagine verificata e utilizzata dagli sviluppatori è molto, molto più sicura rispetto al tuo tentativo di applicare patch di sicurezza a cose che non puoi assolutamente tenere sotto controllo a meno che non sia il tuo unico lavoro.

. . . . Ma, probabilmente non è d’aiuto.

9

Ahah, sì (probabilmente più sicuro con le tue immagini) e no (non utile - ma grazie comunque per il commento😊).

Questo non è certo il mio lavoro principale, gestisco questi forum “perché sono quello che poteva farlo” come programma pilota in modo da poter convincere il nostro reparto IT a occuparsene e gestirlo per l’intera Università di Oslo.

Fortunatamente, sembra che abbia funzionato, quindi spero che questo sia l’ultimo semestre in cui dovrò gestire la situazione. Scommetto che il reparto IT userà le immagini… :wink:

E grazie, @Falco, per aver segnalato la discrepanza nella versione di Ruby, ci darò un’occhiata se/quando incontrerò problemi con futuri aggiornamenti.

1 Mi Piace
10

Santo cielo! Essendo stato docente in diverse università negli Stati Uniti, sono piuttosto impressionato.

1 Mi Piace
11

Oops, ho dimenticato di premere il pulsante Rispondi molto tempo fa…

@pfaffman Haha, sì. Non siamo ancora fuori pericolo al 100%, anche se l’IT dice ok: deve essere approvato ai massimi livelli (dal consiglio di amministrazione dell’università) come canale di comunicazione ufficiale prima. Fortunatamente, abbiamo coinvolto molto il Dipartimento di Scienze Naturali, e loro lo stanno spingendo attraverso gli ostacoli.

Sono abbastanza orgoglioso di aver potuto gestire queste istanze pilota - non molte persone non appartenenti al dipartimento IT sarebbero state in grado di farlo (all’interno delle necessarie politiche di sicurezza, per intenderci). Le persone delle Scienze Naturali si riferiscono costantemente ad esso come “Astro-Discourse” (sono all’Istituto di Astrofisica Teorica) :laughing:.

12

Ma ora… sembra che dovrò gestire questo spettacolo per un altro semestre, con la stessa configurazione non standard. Mi chiedo con quale/i versione/i di pgsql sia compatibile la versione corrente di Discourse?