Dopo aver installato Discourse con “Docker version 20.10.5, build 55c4c8” su CentOS 8, il sito è in esecuzione, ma le chiamate DELETE a /draft.json vanno sempre in timeout.
Ho Apache in esecuzione e ho provato sia con un reverse proxy Apache che con HAProxy; il comportamento è lo stesso.
Non so se sia in qualche modo correlato, ma trovo molti di questi errori in unicorn.stdout.log:
==> ./shared/standalone/log/rails/unicorn.stdout.log <==
2021-03-18T10:02:25.138Z pid=108 tid=ocs ERROR: Errore durante il recupero del job: Errore di connessione a Redis su localhost:6379 (Errno::EADDRNOTAVAIL)
Avvio di 1 sidekiq supervisionato
Caricamento di Sidekiq nel processo id 119
2021-03-18T10:40:09.682Z pid=119 tid=orn ERROR: Errore durante il recupero del job: Errore di connessione a Redis su localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.684Z pid=119 tid=ohf ERROR: Errore durante il recupero del job: Errore di connessione a Redis su localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.685Z pid=119 tid=owv ERROR: Errore durante il recupero del job: Errore di connessione a Redis su localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.683Z pid=119 tid=oob ERROR: Errore durante il recupero del job: Errore di connessione a Redis su localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.683Z pid=119 tid=omr ERROR: Errore durante il recupero del job: Errore di connessione a Redis su localhost:6379 (Errno::EADDRNOTAVAIL)
Avvio di 1 sidekiq supervisionato
Caricamento di Sidekiq nel processo id 121
53:M 18 Mar 2021 17:07:05.076 * 10 modifiche in 300 secondi. Salvataggio in corso...
53:M 18 Mar 2021 17:07:05.076 * Salvataggio in background avviato dal processo 25018
25018:C 18 Mar 2021 17:07:05.126 * Database salvato su disco
25018:C 18 Mar 2021 17:07:05.127 * RDB: 2 MB di memoria utilizzati da copy-on-write
53:M 18 Mar 2021 17:07:05.177 * Salvataggio in background terminato con successo
53:M 18 Mar 2021 17:12:06.097 * 10 modifiche in 300 secondi. Salvataggio in corso...
53:M 18 Mar 2021 17:12:06.098 * Salvataggio in background avviato dal processo 25337
25337:C 18 Mar 2021 17:12:06.145 * Database salvato su disco
25337:C 18 Mar 2021 17:12:06.145 * RDB: 2 MB di memoria utilizzati da copy-on-write
53:M 18 Mar 2021 17:12:06.198 * Salvataggio in background terminato con successo
Non riesco ancora a eliminare post, inviti e modifiche ai post annullati.
Sembra esserci un problema in tutte le chiamate che utilizzano il metodo HTTP DELETE. Posso suggerire a Discourse di utilizzare POST invece di DELETE? Sembra di sì, come discusso qui: How can Discourse make POST instead of DELETE for "smart" CDN?. Tuttavia, non sto utilizzando alcuna CDN; ho solo un server virtuale standard con CentOS e Docker, installato seguendo le istruzioni del sito di Discourse.
Parte del log di Haproxy con errori 408 su HTTP DELETE. Cosa potrebbe causare l’abbandono delle richieste DELETE @codinghorror? Se queste richieste DELETE raggiungono Haproxy, dovrebbero anche raggiungere il software all’interno di Docker. C’è qualcosa lì dentro che potrebbe essere “responsabile” del problema?
Questo è production.log. Non vedo mai apparire una richiesta di eliminazione, ma registro tutto il resto (apertura del post, modifica, salvataggio, ecc.):
Completed 200 OK in 81ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 14861)
Started GET "/composer_messages?composer_action=edit&topic_id=10&post_id=13" for 176.243.226.205 at 2021-03-20 15:51:09 +0100
Processing by ComposerMessagesController#index as JSON
Parameters: {"composer_action"=>"edit", "topic_id"=>"10", "post_id"=>"13"}
Completed 200 OK in 1191ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 16940)
Started POST "/presence/publish" for 176.243.226.205 at 2021-03-20 15:51:14 +0100
Processing by Presence::PresencesController#handle_message as */*
Parameters: {"state"=>"editing", "topic_id"=>"10", "post_id"=>"13"}
Completed 200 OK in 9ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 3192)
Started PUT "/t/e-previsto-un-ritorno-di-freddo-nutro/10" for 176.243.226.205 at 2021-03-20 15:51:17 +0100
Processing by TopicsController#update as */*
Parameters: {"title"=>"E' previsto un ritorno di freddo, nutro?", "category_id"=>1, "slug"=>"e-previsto-un-ritorno-di-freddo-nutro", "topic_id"=>"10", "topic"=>{"title"=>"E' previsto un ritorno di freddo, nutro?", "category_id"=>1}}
Completed 200 OK in 19ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 5149)
Started POST "/presence/publish" for 176.243.226.205 at 2021-03-20 15:51:17 +0100
Processing by Presence::PresencesController#handle_message as */*
Parameters: {"state"=>"closed", "topic_id"=>"10"}
Completed 200 OK in 10ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 3159)
Started PUT "/posts/13" for 176.243.226.205 at 2021-03-20 15:51:17 +0100
Processing by PostsController#update as */*
Parameters: {"post"=>{"edit_reason"=>"", "cooked"=>"<p>post di test per vedere. ssss</p>", "raw"=>"post di test per vedere. ssss", "topic_id"=>"10", "raw_old"=>""}, "id"=>"13"}
Completed 200 OK in 3296ms (Views: 0.1ms | ActiveRecord: 0.0ms | Allocations: 86638)
Started GET "/t/10.json" for 176.243.226.205 at 2021-03-20 15:51:20 +0100
Processing by TopicsController#show as JSON
Parameters: {"id"=>"10"}
Completed 200 OK in 143ms (Views: 0.1ms | ActiveRecord: 0.0ms | Allocations: 52707)
Started GET "/draft.json?draft_key=topic_10" for 176.243.226.205 at 2021-03-20 15:51:27 +0100
Processing by DraftController#show as JSON
Parameters: {"draft_key"=>"topic_10"}
Completed 200 OK in 38ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 4317)
Started GET "/posts/13" for 176.243.226.205 at 2021-03-20 15:51:27 +0100
Processing by PostsController#show as JSON
Parameters: {"id"=>"13"}
Completed 200 OK in 16ms (Views: 0.1ms | ActiveRecord: 0.0ms | Allocations: 5026)
Started POST "/presence/publish" for 176.243.226.205 at 2021-03-20 15:51:29 +0100
Processing by Presence::PresencesController#handle_message as */*
Parameters: {"state"=>"editing", "topic_id"=>"10", "post_id"=>"13"}
Completed 200 OK in 20ms (Views: 0.3ms | ActiveRecord: 0.0ms | Allocations: 3304)
Started GET "/posts/13" for 176.243.226.205 at 2021-03-20 15:51:38 +0100
Processing by PostsController#show as JSON
Parameters: {"id"=>"13"}
Completed 200 OK in 121ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 56890)
Ciò significa che il tuo reverse proxy è configurato in modo errato e sta scartando le richieste diverse da GET/POST. È un problema piuttosto comune, ed è uno dei motivi per cui forniamo un reverse proxy preconfigurato all’interno del container, così gli utenti non devono occuparsene.
Se rimuovi HAProxy e fai sì che il container stesso ascolti sulla porta 80/443, il problema si verifica ancora?
Utilizziamo i verbi DELETE/PUT in tutta l’applicazione per ogni singola installazione e non riscontriamo alcun problema, quindi ipotizzo che si tratti di qualcosa di specifico della tua installazione.
È una possibilità remota, ma hai un WAF di qualche tipo che fronteggia questo dominio @Andrea_Giovacchini?
Assicurati che `gem install libv8 -v '8.4.255.0' --source 'https://rubygems.org/'` abbia esito positivo prima di eseguire bundling.
Nel file Gemfile:
mini_racer è stato risolto alla versione 0.3.1, che dipende da
libv8
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer/parallel_installer.rb:220:in `handle_error'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer/parallel_installer.rb:102:in `call'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer/parallel_installer.rb:71:in `call'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:270:in `install_in_parallel'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:210:in `install'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:90:in `block in run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/process_lock.rb:12:in `block in lock'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/process_lock.rb:9:in `open'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/process_lock.rb:9:in `lock'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:72:in `run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:24:in `install'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli/install.rb:64:in `run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli.rb:259:in `block in install'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/settings.rb:115:in `temporary'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli.rb:258:in `install'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli.rb:30:in `dispatch'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli.rb:24:in `start'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/exe/bundle:49:in `block in <top (required)>'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/friendly_errors.rb:130:in `with_friendly_errors'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/exe/bundle:37:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
I, [2021-03-20T23:42:40.998961 #1] INFO -- : Terminazione dei processi asincroni
I, [2021-03-20T23:42:40.998991 #1] INFO -- : Invio di INT a HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main pid: 66
I, [2021-03-20T23:42:40.999030 #1] INFO -- : Invio di TERM a exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 183
2021-03-20 23:42:40.999 UTC [66] LOG: richiesta di arresto rapido ricevuta
183:signal-handler (1616283760) SIGTERM ricevuto, programmazione dell'arresto...
2021-03-20 23:42:41.013 UTC [66] LOG: annullamento di tutte le transazioni attive
2021-03-20 23:42:41.014 UTC [66] LOG: il worker di background "logical replication launcher" (PID 75) è uscito con codice di uscita 1
2021-03-20 23:42:41.016 UTC [70] LOG: arresto in corso
183:M 20 Mar 2021 23:42:41.058 # Richiesta di arresto da parte dell'utente...
183:M 20 Mar 2021 23:42:41.058 * Salvataggio dell'ultimo snapshot RDB prima dell'uscita.
183:M 20 Mar 2021 23:42:41.061 * Database salvato su disco
183:M 20 Mar 2021 23:42:41.061 # Redis è ora pronto per uscire, arrivederci...
2021-03-20 23:42:41.263 UTC [66] LOG: il sistema di database è spento
FALLITO
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle install --deployment --retry 3 --jobs 4 --verbose --without test development' fallito con codice di uscita #<Process::Status: pid 348 exit 5>
Posizione dell'errore: /pups/lib/pups/exec_command.rb:112:in `spawn'
Esecuzione fallita con i parametri {"cd"=>"$home", "hook"=>"bundle_exec", "cmd"=>["su discourse -c 'bundle install --deployment --retry 3 --jobs 4 --verbose --without test development'"]}
9b0ca932a7dd52ccdd11e268910e3edcd8369c0c08f65e7f8686d542b9be473b
** FALLIMENTO DURANTE L'AVVIO ** scorri verso l'alto e cerca eventuali messaggi di errore precedenti; potrebbero essercene più di uno.
./discourse-doctor può aiutare a diagnosticare il problema.
➜ discourse git:(master) ✗
@Falco ho riprovato la configurazione ufficiale, ma usando “tests-passed” invece di “stable”. Non compare più l’errore relativo al gem mini_racer, ma persiste il problema DELETE, come si può vedere nel video con l’output di tail sui log di nginx e il browser con la console aperta.
I POST appaiono immediatamente nei log di nginx, mentre i DELETE compaiono solo dopo l’errore, il che è strano.
Ah, capisco. Dato che il problema non può essere riprodotto in una nuova installazione, direi che possiamo chiudere questa discussione. Se il problema si ripresenta, ti preghiamo di aprire un nuovo argomento con i passaggi per la riproduzione.
Il comando curl restituisce un CSRF errato e appare immediatamente nel log interno di nginx di Discourse, ma la cancellazione dall’interfaccia non funziona e appare nel log con un ritardo di circa 35 secondi, come nel video che ho inviato.
Se impostiamo discourse.apicolturaitalianafb.it:8880 come hostname in app.yml, ricostruiamo e accediamo a http://discourse.apicolturaitalianafb.it:8880, tutto funziona normalmente, ma non possiamo usarlo in questo modo.
Avendo Apache che esegue un sito web in produzione, ho provato a metterlo dietro a haproxy come indicato nella documentazione di questo sito: le cancellazioni da Discourse smettono di funzionare, ma il tuo comando curl funziona. Ho provato anche il proxy inverso di Apache: curl funziona, ma le cancellazioni da Discourse no. Ho anche provato a configurare Discourse per funzionare su un socket Unix e a fare il reverse proxy verso di esso, ma il problema rimane lo stesso.
Per me l’evidenza è che il reverse proxy non “blocca” le cancellazioni, ma gli script JavaScript in Discourse, per qualche motivo, smettono di eseguire correttamente le cancellazioni HTML.
La tua installazione fresca che hai provato è esposta direttamente?
.