Host konnte nicht aufgelöst werden: github.com

Hallo,

./launcher rebuild app

fatal: konnte nicht auf ‘GitHub - discourse/discourse: A platform for community discussion. Free, open, simple.’ zugreifen: Hostname github.com konnte nicht aufgelöst werden

aber

root@discourse:/var/discourse# host github.com
github.com hat die Adresse 140.82.121.3
github.com Mail wird von 1 aspmx.l.google.com behandelt.
github.com Mail wird von 10 alt4.aspmx.l.google.com behandelt.
github.com Mail wird von 10 alt3.aspmx.l.google.com behandelt.
github.com Mail wird von 5 alt1.aspmx.l.google.com behandelt.
github.com Mail wird von 5 alt2.aspmx.l.google.com behandelt.

Irgendwelche Ideen?

Danke


FEHLGESCHLAGEN
--------------------
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
' fehlgeschlagen mit Rückgabewert #<Process::Status: pid 144 exit 128>
Ort des Fehlschlags: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec fehlgeschlagen mit den Parametern {"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 fehlgeschlagen mit Exit-Code 128

Das ist im Container, also könnte es ein Docker-Netzwerkproblem sein, oder es könnte ein temporäres Problem gewesen sein?

Verwendet der Container standardmäßig die /etc/resolv.conf des Hosts? Wenn es einen lokalen Resolver wie nameserver 127.0.0.1 gibt, vermute ich, dass dieser aus dem Container heraus nicht verfügbar ist. Unbound ist so konfiguriert, dass es Abfragen von allen reservierten IP-Bereichen zulässt, einschließlich 172.16.0.0/12, das von Docker-Containern verwendet wird, also ist das nicht das Problem.

Da wir beim Neuerstellen auf dasselbe Problem stoßen und inzwischen sogar unseren eigenen Unbound eingerichtet haben, und nachdem wir die Zeile entfernt haben, sodass /etc/resolv.conf wieder nur nameserver 1.1.1.1 enthält wie zuvor, schlägt die Neuerstellung immer noch an derselben Stelle fehl. Könnte es also sogar irgendwo zwischengespeichert sein? :thinking:

Vom Host aus kann github.com ohne Probleme aufgelöst werden.

EDIT: Nein, die /etc/resolv.conf ist jetzt nicht das Problem. Ich habe einige Debug-Ausgaben hinzugefügt:

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 hängt ebenfalls ewig, ein Test curl schlägt ebenfalls fehl, beides als Test zu den Discourse-Vorlagen hinzugefügt, um zu prüfen, ob das Netzwerk online ist. nameserver 9.9.9.9 funktioniert auch nicht, sieht also so aus, als hätte der Container keinen Netzwerkzugriff, aber keine Ahnung warum.

… EDIT2: In unserem Fall hat Fail2Ban die Container-IP wegen einer ungültigen E-Mail-Adresse des Benutzerkontos, an das es E-Mails senden wollte, gesperrt, was den Fail2Ban Postfix-Filter ausgelöst hat :smile:.

Daher kann die Überprüfung von Fail2Ban ein Debugging-Schritt sein, wenn der Container kein Netzwerk hat.

EDIT3: In der Jail-Konfiguration von Fail2Ban:

ignoreip = 127.0.0.1/8 172.16.0.0/12

Um Loopback- und Docker-IPs von der Sperrung auszuschließen.