Não foi possível resolver o host: github.com

Olá,

./launcher rebuild app

fatal: impossível acessar ‘GitHub - discourse/discourse: A platform for community discussion. Free, open, simple.’: Não foi possível resolver o host: github.com

mas

root@discourse:/var/discourse# host github.com
github.com tem o endereço 140.82.121.3
o e-mail do github.com é tratado por 1 aspmx.l.google.com.
o e-mail do github.com é tratado por 10 alt4.aspmx.l.google.com.
o e-mail do github.com é tratado por 10 alt3.aspmx.l.google.com.
o e-mail do github.com é tratado por 5 alt1.aspmx.l.google.com.
o e-mail do github.com é tratado por 5 alt2.aspmx.l.google.com.

Alguma ideia?

Obrigado


FALHA
--------------------
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
' falhou com o retorno #<Process::Status: pid 144 exit 128>
Localização da falha: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec falhou com os 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"]}
falha na inicialização com código de saída 128

Isso está dentro do contêiner, então você pode ter um problema de rede do Docker, ou pode ter sido um problema temporário?

O contêiner está usando o /etc/resolv.conf do host por padrão? Se houver um resolvedor local como nameserver 127.0.0.1, suponho que ele não esteja disponível de dentro do contêiner. O Unbound está configurado para permitir consultas de todos os intervalos de IP reservados, incluindo 172.16.0.0/12 usado por contêineres Docker, então esse não é o problema.

Embora tenhamos encontrado o mesmo problema na reconstrução, e de fato tenhamos configurado nosso próprio Unbound nesse ínterim, também após remover a linha para que /etc/resolv.conf contenha novamente apenas nameserver 1.1.1.1 como antes, a reconstrução ainda falha no mesmo ponto. Então, talvez esteja até em cache em algum lugar? :thinking:

Do host, github.com pode ser resolvido sem problemas.

EDIT: Não, o /etc/resolv.conf não é o problema agora. Adicionei algumas saídas de depuração:

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 também trava para sempre, um teste curl também falha, ambos como testes adicionados aos modelos do Discourse para verificar se a rede está online. nameserver 9.9.9.9 também não funciona, então parece que o contêiner não tem acesso à rede, mas não sei por quê.

… EDIT2: Ok, no nosso caso, o Fail2Ban baniu o IP do contêiner devido a um endereço de e-mail de usuário inválido que ele estava tentando enviar, acionando o filtro Postfix do Fail2Ban :smile:.

Portanto, verificar o Fail2Ban pode ser uma etapa de depuração se o contêiner não tiver rede.

EDIT3: Na configuração do jail do Fail2Ban:

ignoreip = 127.0.0.1/8 172.16.0.0/12

Para evitar que IPs de loopback e Docker sejam banidos.