Impossible de résoudre l'hôte : github.com

Salut,

./launcher rebuild app

fatal: impossible d’accéder à ‘GitHub - discourse/discourse: A platform for community discussion. Free, open, simple.’: Impossible de résoudre l’hôte : github.com

mais

root@discourse:/var/discourse# host github.com
github.com has address 140.82.121.3
github.com mail is handled by 1 aspmx.l.google.com.
github.com mail is handled by 10 alt4.aspmx.l.google.com.
github.com mail is handled by 10 alt3.aspmx.l.google.com.
github.com mail is handled by 5 alt1.aspmx.l.google.com.
github.com mail is handled by 5 alt2.aspmx.l.google.com.

une idée ?

Merci


FAILED
--------------------
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
' failed with return #<Process::Status: pid 144 exit 128>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec failed with the params {"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 failed with exit code 128

Ceci est à l’intérieur du conteneur, donc vous pourriez avoir un problème de réseau docker, ou cela pourrait-il avoir été un problème temporaire ?

Le conteneur utilise-t-il /etc/resolv.conf de l’hôte par défaut ? S’il existe un résolveur local comme nameserver 127.0.0.1, je suppose qu’il ne sera pas disponible depuis le conteneur. Unbound est configuré pour autoriser les requêtes de toutes les plages IP réservées, y compris 172.16.0.0/12 utilisée par les conteneurs Docker, donc ce n’est pas le problème.

Cependant, comme nous rencontrons le même problème lors de la reconstruction, et que nous avons configuré notre propre Unbound entre-temps, même après avoir supprimé la ligne afin que /etc/resolv.conf ne contienne à nouveau que nameserver 1.1.1.1 comme avant, la reconstruction échoue toujours au même point. Alors peut-être est-ce même mis en cache quelque part ? :thinking:

Depuis l’hôte, github.com peut être résolu sans problème.

EDIT : Non, /etc/resolv.conf n’est pas le problème maintenant. J’ai ajouté une sortie de débogage :

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 échoue également indéfiniment, un test curl échoue également, tous deux sont des tests ajoutés aux modèles Discourse pour vérifier si le réseau est en ligne. nameserver 9.9.9.9 ne fonctionne pas non plus, il semble donc que le conteneur n’ait pas d’accès réseau, mais je ne sais pas pourquoi.

… EDIT2 : D’accord, dans notre cas, Fail2Ban a banni l’IP du conteneur en raison d’une adresse e-mail de compte utilisateur invalide qu’il essayait d’envoyer, déclenchant le filtre Postfix de Fail2Ban :smile:.

Par conséquent, vérifier Fail2Ban peut être une étape de débogage si le conteneur n’a pas de réseau.

EDIT3 : Dans la configuration de la jail de Fail2Ban :

ignoreip = 127.0.0.1/8 172.16.0.0/12

Pour éviter que les boucles locales et les IP Docker ne soient bannies.