テクノロジー · 実用ガイド
sudo の「unable to resolve host」：まず NSS で local hostname を追跡する
runtime hostnameと実際のNSS経路を証明し、設定ownerを特定してから一層だけ修正しsudoを再検証します。
この警告は現在のhostnameを設定済みhosts databaseで解決できないことを示します。Internet DNS障害の証明ではありません。正確なnameと実際のlookup pathを先に保存します。
local identityを固定する
sudo警告の文字列、hostname出力、利用可能ならhostnamectl、host・container・CI runnerの別を記録します。domain追加やcase変更、誤ったfileの推測はまだ行いません。
実際のhosts databaseを試す
正確なhostnameでgetent hostsを実行し、address familyが必要ならgetent ahostsを使います。これはNSS経路を通ります。hostやdigはlocal filesやNSS moduleを迂回し得るため、結果が違っても矛盾ではありません。
有効なsource順を読む
/etc/nsswitch.confのhosts行でfiles、myhostname、resolve、dnsなどの順序と条件を記録します。local nameへ答えるべきsourceだけを調べます。files欠落、module欠落、DNS-only failureは別です。
persistent ownerを特定する
静的Debian系hostではruntime name、persistent hostname、確認済みlocal mappingを比較します。cloud、DHCP、NetworkManager、cloud-init、systemd-hostnamed、container、orchestrationでは再生成するlayerを特定します。
一つの証明済みlayerだけ直す
確認した不一致かmodule設定を一つ修正します。localhostと正しいaliasを保ち、警告を消すだけの推測address追加や全体renameは避けます。ephemeral環境はimage、entrypoint、runtime mappingを直します。
DNSと分けて完了を証明する
hostnameとgetentを繰り返し、無害なsudo検証と元のcommandを実行します。ownerが必要とする場合だけreboot/recreateし、その後再試験します。外部DNSは別に確認します。
