No se pudo resolver el host: github.com

Hola,

./launcher rebuild app

fatal: no se puede acceder a ‘GitHub - discourse/discourse: A platform for community discussion. Free, open, simple.’: No se puede resolver el host: github.com

pero

root@discourse:/var/discourse# host github.com
github.com tiene la dirección 140.82.121.3
github.com mail es manejado por 1 aspmx.l.google.com.
github.com mail es manejado por 10 alt4.aspmx.l.google.com.
github.com mail es manejado por 10 alt3.aspmx.l.google.com.
github.com mail es manejado por 5 alt1.aspmx.l.google.com.
github.com mail es manejado por 5 alt2.aspmx.l.google.com.

¿Alguna idea?

Gracias


FALLÓ
--------------------
Pups::ExecError: cd /var/www/discourse && sudo -H -E -u discourse bash -c '
  set -o errexit
  if [ $(git rev-parse --is-shallow-repository) == "true" ]; then
      git remote set-branches --add origin main
      git remote set-branches origin tests-passed
      git fetch --depth 1 origin tests-passed
  else
      git fetch --tags --prune-tags --prune --force origin
  fi
' falló con el retorno #<Process::Status: pid 144 exit 128>
Ubicación del fallo: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec falló con los parámetros {"cd"=>"$home", "hook"=>"code", "cmd"=>["sudo -H -E -u discourse git clean -f", "sudo -H -E -u discourse bash -c '\n  set -o errexit\n  if [ $(git rev-parse --is-shallow-repository) == \"true\" ]; then\n      git remote set-branches --add origin main\n      git remote set-branches origin $version\n      git fetch --depth 1 origin $version\n  else\n      git fetch --tags --prune-tags --prune --force origin\n  fi\n'", "sudo -H -E -u discourse bash -c '\n  set -o errexit\n  if [[ $(git symbolic-ref --short HEAD) == $version ]] ; then\n      git pull\n  else\n      git -c advice.detachedHead=false checkout $version\n  fi\n'", "sudo -H -E -u discourse git config user.discourse-version $version", "mkdir -p tmp", "chown discourse:www-data tmp", "mkdir -p tmp/pids", "mkdir -p tmp/sockets", "touch tmp/.gitkeep", "mkdir -p                    /shared/log/rails", "bash -c \"touch -a           /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log\"", "bash -c \"ln    -s           /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log $home/log\"", "bash -c \"mkdir -p           /shared/{uploads,backups}\"", "bash -c \"ln    -s           /shared/{uploads,backups} $home/public\"", "bash -c \"mkdir -p           /shared/tmp/{backups,restores}\"", "bash -c \"ln    -s           /shared/tmp/{backups,restores} $home/tmp\"", "chown -R discourse:www-data /shared/log/rails /shared/uploads /shared/backups /shared/tmp\"", "[ ! -d public/plugins ] || find public/plugins/ -maxdepth 1 -xtype l -delete"]}
bootstrap falló con el código de salida 128

Eso está dentro del contenedor, así que podrías tener un problema de red de Docker, o podría haber sido un problema temporal.

¿El contenedor utiliza /etc/resolv.conf del host por defecto? Si hay un resolvedor local como nameserver 127.0.0.1, supongo que no estaría disponible desde dentro del contenedor. Unbound está configurado para permitir consultas de todos los rangos de IP reservados, incluyendo 172.16.0.0/12 utilizado por los contenedores de Docker, así que ese no es el problema.

Sin embargo, como nos encontramos con el mismo problema en la reconstrucción, e incluso configuramos nuestro propio Unbound mientras tanto, también después de eliminar la línea para que /etc/resolv.conf contenga de nuevo solo nameserver 1.1.1.1 como antes, la reconstrucción todavía falla en el mismo punto. Así que, ¿quizás está incluso en caché en algún lugar? :thinking:

Desde el host, github.com se puede resolver sin problemas.

EDIT: No, /etc/resolv.conf no es el problema ahora. Añadí algunas salidas de depuración:

I, [2025-09-25T17:32:38.092043 #1]  INFO -- : cd /var/www/discourse & cat /etc/resolv.conf
I, [2025-09-25T17:32:38.093195 #1]  INFO -- : # Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.

nameserver 1.1.1.1

# Based on host file: '/etc/resolv.conf' (legacy)
# Overrides: []

I, [2025-09-25T17:32:38.093221 #1]  INFO -- : cd /var/www/discourse & getent hosts github.com
I, [2025-09-25T17:32:58.111177 #1]  INFO -- :
I, [2025-09-25T17:32:58.111456 #1]  INFO -- : Terminating async processes

EDIT: apt update también se cuelga para siempre, una prueba curl también falla, ambas como pruebas añadidas a las plantillas de Discourse para comprobar si la red está en línea. nameserver 9.9.9.9 tampoco funciona, así que parece que el contenedor no tiene acceso a la red, pero no tengo ni idea de por qué.

… EDIT2: Bueno, en nuestro caso Fail2Ban baneó la IP del contenedor debido a una dirección de correo electrónico de cuenta de usuario inválida a la que intentaba enviar correos electrónicos, activando el filtro Fail2Ban Postfix :smile:.

Por lo tanto, comprobar Fail2Ban puede ser un paso de depuración si el contenedor no tiene red.

EDIT3: En la configuración de la cárcel de Fail2Ban:

ignoreip = 127.0.0.1/8 172.16.0.0/12

Para evitar que se baneen las IPs de loopback y de Docker.