Impossibile risolvere l'host: github.com

Ciao,

./launcher rebuild app

fatal: impossibile accedere a ‘GitHub - discourse/discourse: A platform for community discussion. Free, open, simple.’: Impossibile risolvere l’host: github.com

ma

root@discourse:/var/discourse# host github.com
github.com ha indirizzo 140.82.121.3
github.com mail è gestito da 1 aspmx.l.google.com.
github.com mail è gestito da 10 alt4.aspmx.l.google.com.
github.com mail è gestito da 10 alt3.aspmx.l.google.com.
github.com mail è gestito da 5 alt1.aspmx.l.google.com.
github.com mail è gestito da 5 alt2.aspmx.l.google.com.

Qualche idea?

Grazie


FALLITO
--------------------
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
' è fallito con ritorno #<Process::Status: pid 144 exit 128>
Posizione del fallimento: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec fallito con i parametri {"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 fallito con codice di uscita 128

Ciò è all’interno del container, quindi potrebbe esserci un problema di rete Docker, oppure potrebbe essere stato un problema temporaneo?

Il container utilizza /etc/resolv.conf dell’host per impostazione predefinita? Se c’è un resolver locale come nameserver 127.0.0.1, immagino che non sia disponibile dall’interno del container. Unbound è configurato per consentire query da tutti gli intervalli IP riservati, inclusi 172.16.0.0/12 utilizzati dai container Docker, quindi questo non è il problema.

Tuttavia, poiché riscontriamo lo stesso problema alla ricompilazione, e infatti abbiamo configurato il nostro Unbound nel frattempo, anche dopo aver rimosso la riga in modo che /etc/resolv.conf contenga di nuovo solo nameserver 1.1.1.1 come prima, la ricompilazione fallisce ancora nello stesso punto. Quindi forse è persino memorizzato nella cache da qualche parte? :thinking:

Dall’host, github.com può essere risolto senza problemi.

EDIT: No, /etc/resolv.conf non è più il problema. Ho aggiunto alcuni output di debug:

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: Anche apt update si blocca per sempre, anche un test curl fallisce, entrambi come test aggiunti ai template di Discourse per verificare se la rete è online. Anche nameserver 9.9.9.9 non funziona, quindi sembra che il container non abbia accesso alla rete, ma non si capisce perché.

… EDIT2: Ok, nel nostro caso Fail2Ban ha bannato l’IP del container a causa di un indirizzo email non valido dell’account utente che stava cercando di inviare email, attivando il filtro Fail2Ban Postfix :smile:.

Quindi, controllare Fail2Ban può essere un passaggio di debug se il container non ha accesso alla rete.

EDIT3: Nella configurazione jail di Fail2Ban:

ignoreip = 127.0.0.1/8 172.16.0.0/12

Per evitare che gli IP di loopback e Docker vengano bannati.