Después de instalar Discourse con “Docker version 20.10.5, build 55c4c8” en CentOS 8, tengo el sitio funcionando, pero siempre se agota el tiempo en las llamadas DELETE a /draft.json.
Tengo Apache ejecutándose y probé tanto con proxy inverso de Apache como con HAProxy; el comportamiento es el mismo.
No sé si está relacionado de alguna manera, pero encuentro muchos de estos errores en unicorn.stdout.log:
==> ./shared/standalone/log/rails/unicorn.stdout.log <==
2021-03-18T10:02:25.138Z pid=108 tid=ocs ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Starting up 1 supervised sidekiqs
Loading Sidekiq in process id 119
2021-03-18T10:40:09.682Z pid=119 tid=orn ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.684Z pid=119 tid=ohf ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.685Z pid=119 tid=owv ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.683Z pid=119 tid=oob ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.683Z pid=119 tid=omr ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Starting up 1 supervised sidekiqs
Loading Sidekiq in process id 121
53:M 18 Mar 2021 17:07:05.076 * 10 cambios en 300 segundos. Guardando...
53:M 18 Mar 2021 17:07:05.076 * Guardado en segundo plano iniciado por el pid 25018
25018:C 18 Mar 2021 17:07:05.126 * Base de datos guardada en disco
25018:C 18 Mar 2021 17:07:05.127 * RDB: 2 MB de memoria utilizados por copia al escribir
53:M 18 Mar 2021 17:07:05.177 * Guardado en segundo plano finalizado con éxito
53:M 18 Mar 2021 17:12:06.097 * 10 cambios en 300 segundos. Guardando...
53:M 18 Mar 2021 17:12:06.098 * Guardado en segundo plano iniciado por el pid 25337
25337:C 18 Mar 2021 17:12:06.145 * Base de datos guardada en disco
25337:C 18 Mar 2021 17:12:06.145 * RDB: 2 MB de memoria utilizados por copia al escribir
53:M 18 Mar 2021 17:12:06.198 * Guardado en segundo plano finalizado con éxito
Aún no puedo eliminar publicaciones, invitaciones ni modificaciones de publicaciones anuladas.
Parece ser un problema en todas las llamadas con el método HTTP DELETE. ¿Podría decirse que Discourse debería usar POST en lugar de DELETE? Parece similar a How can Discourse make POST instead of DELETE for "smart" CDN?, pero no estoy utilizando ningún CDN, solo un servidor virtual estándar con instalación de CentOS y Docker siguiendo las instrucciones del sitio de Discourse.
Parte del registro de Haproxy con errores 408 en solicitudes HTTP DELETE. ¿Qué podría estar “descartando” las solicitudes DELETE @codinghorror? Si estas solicitudes DELETE llegan a Haproxy, también deberían llegar al software dentro de Docker. ¿Podría haber algo allí que sea “responsable” del problema?
Este es production.log; nunca veo que aparezca una solicitud de eliminación, pero sí registro todo lo demás (apertura de publicación, modificación, guardado, etc.):
Completed 200 OK en 81ms (Vistas: 0.2ms | ActiveRecord: 0.0ms | Asignaciones: 14861)
Started GET "/composer_messages?composer_action=edit&topic_id=10&post_id=13" para 176.243.226.205 el 2021-03-20 15:51:09 +0100
Procesando mediante ComposerMessagesController#index como JSON
Parámetros: {"composer_action"=>"edit", "topic_id"=>"10", "post_id"=>"13"}
Completed 200 OK en 1191ms (Vistas: 0.2ms | ActiveRecord: 0.0ms | Asignaciones: 16940)
Started POST "/presence/publish" para 176.243.226.205 el 2021-03-20 15:51:14 +0100
Procesando mediante Presence::PresencesController#handle_message como */*
Parámetros: {"state"=>"editing", "topic_id"=>"10", "post_id"=>"13"}
Completed 200 OK en 9ms (Vistas: 0.2ms | ActiveRecord: 0.0ms | Asignaciones: 3192)
Started PUT "/t/e-previsto-un-ritorno-di-freddo-nutro/10" para 176.243.226.205 el 2021-03-20 15:51:17 +0100
Procesando mediante TopicsController#update como */*
Parámetros: {"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 en 19ms (Vistas: 0.2ms | ActiveRecord: 0.0ms | Asignaciones: 5149)
Started POST "/presence/publish" para 176.243.226.205 el 2021-03-20 15:51:17 +0100
Procesando mediante Presence::PresencesController#handle_message como */*
Parámetros: {"state"=>"closed", "topic_id"=>"10"}
Completed 200 OK en 10ms (Vistas: 0.2ms | ActiveRecord: 0.0ms | Asignaciones: 3159)
Started PUT "/posts/13" para 176.243.226.205 el 2021-03-20 15:51:17 +0100
Procesando mediante PostsController#update como */*
Parámetros: {"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 en 3296ms (Vistas: 0.1ms | ActiveRecord: 0.0ms | Asignaciones: 86638)
Started GET "/t/10.json" para 176.243.226.205 el 2021-03-20 15:51:20 +0100
Procesando mediante TopicsController#show como JSON
Parámetros: {"id"=>"10"}
Completed 200 OK en 143ms (Vistas: 0.1ms | ActiveRecord: 0.0ms | Asignaciones: 52707)
Started GET "/draft.json?draft_key=topic_10" para 176.243.226.205 el 2021-03-20 15:51:27 +0100
Procesando mediante DraftController#show como JSON
Parámetros: {"draft_key"=>"topic_10"}
Completed 200 OK en 38ms (Vistas: 0.2ms | ActiveRecord: 0.0ms | Asignaciones: 4317)
Started GET "/posts/13" para 176.243.226.205 el 2021-03-20 15:51:27 +0100
Procesando mediante PostsController#show como JSON
Parámetros: {"id"=>"13"}
Completed 200 OK en 16ms (Vistas: 0.1ms | ActiveRecord: 0.0ms | Asignaciones: 5026)
Started POST "/presence/publish" para 176.243.226.205 el 2021-03-20 15:51:29 +0100
Procesando mediante Presence::PresencesController#handle_message como */*
Parámetros: {"state"=>"editing", "topic_id"=>"10", "post_id"=>"13"}
Completed 200 OK en 20ms (Vistas: 0.3ms | ActiveRecord: 0.0ms | Asignaciones: 3304)
Started GET "/posts/13" para 176.243.226.205 el 2021-03-20 15:51:38 +0100
Procesando mediante PostsController#show como JSON
Parámetros: {"id"=>"13"}
Completed 200 OK en 121ms (Vistas: 0.2ms | ActiveRecord: 0.0ms | Asignaciones: 56890)
Eso significa que tu proxy inversor está mal configurado y está descartando las solicitudes que no son GET o POST. Es un problema bastante común, y una de las razones por las que ofrecemos un proxy inversor preconfigurado dentro del contenedor es para que las personas no tengan que lidiar con esto.
¿El problema persiste si eliminas HAProxy y permites que el propio contenedor escuche en los puertos 80/443?
@Falco Acabo de probarlo y el problema sigue ocurriendo. ¿Podría ser que sea el propio Puma, como servidor web, el que esté descartando las solicitudes DELETE?
Utilizamos los verbos DELETE/PUT en toda la aplicación para cada instalación y no hemos detectado ningún problema, así que supongo que se trata de algo específico de tu instalación.
Es poco probable, pero ¿tienes algún tipo de WAF frente a este dominio @Andrea_Giovacchini?
He probado una instalación alternativa después de intentar la oficial, que presentaba el mismo problema.
Ahora he intentado nuevamente la configuración oficial (discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub), pero falla al ejecutar “./launcher rebuild app” con el siguiente mensaje (hace dos días no fallaba, aunque también estaba afectado por el problema de DELETE):
Asegúrate de que `gem install libv8 -v '8.4.255.0' --source 'https://rubygems.org/'` se ejecute correctamente antes de bundling.
En el Gemfile:
mini_racer fue resuelto a 0.3.1, el cual depende de
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 -- : Terminando procesos asíncronos
I, [2021-03-20T23:42:40.998991 #1] INFO -- : Enviando 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 -- : Enviando 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: solicitud de apagado rápido recibida
183:signal-handler (1616283760) SIGTERM recibido, programando apagado...
2021-03-20 23:42:41.013 UTC [66] LOG: abortando cualquier transacción activa
2021-03-20 23:42:41.014 UTC [66] LOG: el trabajador en segundo plano "logical replication launcher" (PID 75) salió con código de salida 1
2021-03-20 23:42:41.016 UTC [70] LOG: apagando
183:M 20 Mar 2021 23:42:41.058 # Apagado solicitado por el usuario...
183:M 20 Mar 2021 23:42:41.058 * Guardando la última instantánea RDB antes de salir.
183:M 20 Mar 2021 23:42:41.061 * Base de datos guardada en disco
183:M 20 Mar 2021 23:42:41.061 # Redis está listo para salir, adiós...
2021-03-20 23:42:41.263 UTC [66] LOG: el sistema de base de datos se ha apagado
FALLÓ
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle install --deployment --retry 3 --jobs 4 --verbose --without test development' falló con el retorno #<Process::Status: pid 348 exit 5>
Ubicación del fallo: /pups/lib/pups/exec_command.rb:112:in `spawn'
exec falló con los parámetros {"cd"=>"$home", "hook"=>"bundle_exec", "cmd"=>["su discourse -c 'bundle install --deployment --retry 3 --jobs 4 --verbose --without test development'"]}
9b0ca932a7dd52ccdd11e268910e3edcd8369c0c08f65e7f8686d542b9be473b
** FALLO AL INICIALIZAR ** por favor, desliza hacia arriba y busca mensajes de error anteriores, puede haber más de uno.
./discourse-doctor puede ayudar a diagnosticar el problema.
➜ discourse git:(master) ✗
@Falco probé la configuración oficial nuevamente, pero con “tests-passed” en lugar de “stable”, y aunque ya no aparece el error del gem mini_racer, sigo teniendo el problema de DELETE, como puedes ver en el video donde se muestra el seguimiento del log de nginx y el navegador con la consola abierta.
Los POST aparecen inmediatamente en el log de nginx, mientras que los DELETE solo se registran después del error, lo cual es extraño.
Oh, ya veo. Dado que el problema no se puede reproducir en una instalación nueva, diría que podemos cerrar este caso. Si el problema vuelve a ocurrir, por favor abre otro tema con los pasos para reproducirlo.
El comando curl genera un CSRF incorrecto y aparece inmediatamente en el registro interno de nginx de Discourse, pero la eliminación desde la interfaz no funciona y aparece en el registro con un retraso de unos 35 segundos, como en el video que envié.
Si configuro discourse.apicolturaitalianafb.it:8880 como nombre de host en app.yml, reconstruyo y accedo a http://discourse.apicolturaitalianafb.it:8880, funciona con normalidad, pero no puedo usarlo de esa manera.
Tengo Apache ejecutando un sitio web en producción. He intentado colocarlo detrás de haproxy según la documentación de este sitio web y las eliminaciones desde Discourse dejan de funcionar, aunque tu comando curl sí funciona. También probé con un proxy inverso de Apache: curl funciona, pero la eliminación desde Discourse no. Intenté configurar Discourse para que funcione mediante un socket Unix y usar un proxy inverso hacia él, pero el problema es el mismo.
Para mí, la evidencia indica que el proxy inverso no “mata” las eliminaciones, sino que los scripts de JavaScript en Discourse, por alguna razón, dejan de realizar correctamente las eliminaciones HTML.
¿Tu instalación nueva que probaste estaba expuesta directamente?
.