最近、/etc/hostname を通じて sudoers ファイルとホスト名を変更しました。これらのファイルを変更した後、sudo コマンドに非常に時間がかかるようになりました。また、sudo がホスト kaagini (マシンのホスト名) を解決できないというメッセージが表示されます。
何かに権限を与えるために、sudo がホスト名を知る必要があるのはなぜですか?
私の sudoers ファイルには、コマンド「Defaults env_reset」があります。 同様の質問をいくつか見ましたが、ここではリモート ログインのコンテキストではありません。 エラーはローカルホストで表示されています。
この問題について最初にグーグルで検索したところ、/etc/hosts ファイルに 127.0.0.1 の実際のホスト名がなければならないとのことでした。これで問題は解決しました。しかし、私の本当の疑問は、なぜ sudo にこれが必要なのかということです。ログイン場所に関係なく sudo は機能するのでしょうか。
答え1
この/etc/sudoersファイルは複数のサーバーに分散できるように設計されています。これを実現するために、ファイル内の各権限にはホスト部分があります。
これは通常 に設定され、ALL=権限がどのサーバーに対しても有効であることを意味しますが、特定のホストに設定することもできます。
%sudo kaagini=(ALL) ALL
sudo がこのルールを適用すべきかどうかを知るには、実行されているホストを検索する必要があります。 が/etc/hosts正しいことを前提とした呼び出しを使用するため、正しくない場合は失敗します。
sudoホスト部分がすべての権限に対して設定されている場合は、名前の検索を行う必要がないと主張する人もいるかもしれませんALL=が、実際にはそのようには機能しません。ルールを処理する前に、どこで実行されているかを判断するようです。
これは、sudo が /etc/sudoers を読み取り、ユーザーが現在のマシンで何ができるかを確認するだけなので、メンテナンスの容易さを目的としたものです。しかし、100 台のサーバーを管理する管理者の場合、100 個の異なる /etc/sudoers ファイルの管理が必要になる可能性があります。sudoers の権限にはホスト部分があるため、単一の sudoers ファイルを管理してすべてのマシンに配布し、各マシンでユーザーが実行できる操作を細かく制御できます。
答え2
おかげリンクされたバグレポートMatthias Urlichs が別のコメントで報告したように、次のコマンドで問題は解決しました。
Defaults !fqdn
この行を/etc/sudoersファイル内に配置します
答え3
傀儡は、Puppet マニフェスト ファイルを読み取って、サーバー群を自動的に構成できる構成管理ソフトウェアです。このようなファイルには、/etc/sudoers ファイルの定義を含めることができます。この定義は、Puppet の「マスター」からすべての Puppet の「エージェント」にプッシュできます。その後、すべてのホストは、HOST 定義を含めることができる (含めるべき) /etc/sudoers ファイルの同じコピーを取得します。これにより、一部のユーザーにいくつかのコマンドを許可できます。一部のホスト（ただし、他のものには適用されません）。