Linuxでシステムのホスト名を表示・管理する方法

Linuxでホスト名を表示するだけなら、まずhostnameまたはhostnamectlを使います。ただし「ホスト名」という言葉は、短いノード名、完全修飾ドメイン名(FQDN)、systemdが管理するstatic・transient・pretty hostname、DNSで引ける名前を混同しやすい用語です。障害調査、監視登録、証明書申請、クラスタ構築では、どの種類の名前を求めているかを先に決めてください。本稿は表示方法を中心に、出力が食い違う理由と、やむを得ず変更する場合の安全な確認事項まで整理します。

目次

最短の確認はhostname

hostnameを引数なしで実行すると、現在のホスト名を表示します。多くの環境では短い名前が返りますが、設定や実装によってドットを含む名前が返ることもあるため、「必ず短縮名」と決めつけません。スクリプトへ組み込む前に対象ディストリビューションのマニュアルと実際の出力を確認します。表示だけなら管理者権限は通常不要です。

hostname

出力がweb01なら、それはその時点でカーネルが認識しているノード名です。これだけではweb01.example.netというFQDNがDNSで正しく引けること、証明書名と一致すること、監視台帳の資産名と一致することまでは証明できません。コマンド結果をチケットへ記録するときは、実行した日時、対象サーバー、コマンド、出力の種類を併記します。複数端末を開いている場合は、プロンプト表示だけを信用せず、接続先のIPやクラウドのインスタンスIDとも照合してください。

systemd環境ではhostnamectl status

systemd-hostnamedを使う環境では、hostnamectl statusがホスト名と関連情報をまとめて表示します。引数なしのhostnamectlも通常はstatus相当です。表示項目にはstatic hostname、transient hostname、pretty hostname、シャーシ、OS、カーネル、アーキテクチャなどが含まれることがあります。バージョンや環境によって項目は異なるため、記事の画面例と完全一致しなくても異常とは限りません。

hostnamectl status
hostnamectl --static
hostnamectl --transient
hostnamectl --pretty

3種類のホスト名

  • static hostname:管理者が永続的に設定する、通常のシステム名。DNSラベルに適した文字や長さの制約がある。
  • transient hostname:ネットワーク設定などから動的に得られる一時名。妥当なstatic名があれば通常はそちらが優先される。
  • pretty hostname:人が読む表示名。空白や特殊文字を含められるが、ネットワーク識別子として使う名前ではない。

たとえばpretty hostnameが「Tokyo Web Server 01」、static hostnameがweb01でも矛盾ではありません。自動化、DNS、SSH、監視では原則として機械向けのstatic名やFQDNを使い、pretty名を識別キーにしません。transient名だけが想定外の場合は、DHCPやNetworkManager、クラウド初期化、コンテナ設定など、名前を供給している経路を調べます。表示値をその場で変更して症状を隠すと、再起動後に戻ったり、別設定との競合が残ったりします。

短縮名とFQDNを分けて確認する

FQDNはhost.example.netのようにDNS階層を含む名前です。hostname --fqdnまたはhostname -fで表示できる実装がありますが、その結果はローカルの名前解決設定やDNSに依存します。単純に現在の短いホスト名へドメイン文字列を足しているわけではありません。/etc/hostsの並び、DNS検索ドメイン、NSS設定、ネットワーク未接続などで結果が変わります。コマンドが失敗したら、FQDNが存在しないのか、名前解決経路が壊れているのかを分けて調べます。

hostname --short
hostname --fqdn
hostname --domain

--short、--fqdn、--domainなどのオプションは利用しているhostname実装で確認してください。コンテナや最小構成OSではツール自体が入っていない場合もあります。その場合に無断でパッケージを追加せず、hostnamectlやuname -nなど、既存の読み取り手段を使います。POSIX互換性が必要なスクリプトでは、GNU/Linux固有オプションを前提にしない設計が必要です。

uname -nとの違い

uname -nはネットワークノードのホスト名を表示します。通常はhostnameと同じような値になりますが、コマンドの目的と提供パッケージが異なります。診断時は一つの結果だけを加工して都合よく合わせず、複数コマンドの生出力を記録します。自動化で値を取得する場合は末尾改行を除く処理、空文字、コマンド失敗を扱い、ファイル名やURLへ無検証で埋め込みません。ホスト名に想定外の文字があれば、許可する形式を明示して弾きます。

uname -n

IPアドレスはホスト名ではない

hostname -Iはホストに割り当てられたアドレスを表示する実装がありますが、複数NIC、IPv4とIPv6、コンテナ、VPN、ループバック、クラウドのプライベート/パブリックアドレスがあると複数値になります。表示された最初のアドレスを「サーバーのIP」と決め打ちしないでください。DNSが返すアドレスとも一致するとは限りません。接続元から到達すべきアドレスを知りたい場合は、用途、インターフェース、ルーティング、ロードバランサーを含めて確認します。

/etc/hostnameと/etc/hostsを読むときの注意

多くのディストリビューションは永続的なstatic hostnameを/etc/hostnameに保存しますが、ファイル形式や管理方法は一様ではありません。クラウドイメージ、コンテナ、構成管理ツール、NetworkManagerなどが生成・上書きする場合もあります。/etc/hostsはローカル名前解決の対応表であり、DNSの代替やホスト名そのものとは同義ではありません。確認目的なら内容を読み取れますが、表示結果を合わせるために安易に編集しないでください。特に127.0.0.1、127.0.1.1、IPv6ループバックの行を変更すると、sudo、メール、アプリケーション、起動処理へ影響することがあります。

cat /etc/hostname
getent hosts "$(hostname)"

getentはNSS設定に従った検索結果を見るのに役立ちます。結果が複数ある場合、どれが正しいかは用途次第です。逆引きDNSは別管理なので、正引き名と必ず一致するとは限りません。TLS証明書では証明書のSANに接続時の名前が含まれる必要があり、ホスト名表示が正しくても証明書検証が成功する保証はありません。

SSH接続先であることを確実にする

似た名前の本番・検証サーバーを取り違える事故を防ぐには、ホスト名のほかに複数の識別子を照合します。クラウドならインスタンスIDやアカウント、オンプレミスなら資産番号や管理IP、仮想環境ならVM IDを使います。SSHのホスト鍵フィンガープリントも有効ですが、再構築で変わる場合があるため台帳と照合します。プロンプトの色やターミナルのタブ名は利用者設定であり、証拠にはなりません。変更操作やログ取得を始める前に、少なくとも環境名と一意な識別子を確認します。

  • hostnameまたはhostnamectlの表示値
  • 接続先IPとネットワークセグメント
  • クラウドのプロジェクト・アカウント・リージョン・インスタンスID
  • OS、カーネル、稼働サービスなど変更を伴わない補助情報
  • 運用台帳に登録された役割、所有者、メンテナンス時間帯

ホスト名を変更する前の影響調査

確認だけが目的なら、set-hostnameなど変更サブコマンドを実行してはいけません。ホスト名変更は見た目以上に影響が広く、DNSのA/AAAA/PTRレコード、TLS証明書、SSH known_hosts、監視、バックアップ、ログ集約、ライセンス、メール、クラスタ、データベース複製、構成管理、クラウドエージェントが旧名を参照している可能性があります。変更が必要なら、旧値を記録し、依存先の所有者、変更順序、反映時間、再起動要否、ロールバック手順を承認済みの変更計画にします。

変更が承認された場合の流れ

  1. 現在のstatic、transient、pretty、FQDN、IP、名前解決結果を記録する。
  2. 新しい名前が命名規則、DNSラベル、長さ制限、資産台帳で利用可能か確認する。
  3. DNS、証明書、監視、バックアップ、クラスタ、アプリ設定の依存先を洗い出す。
  4. 検証環境で変更と再起動後の永続性を確認し、旧名へ戻す手順を試す。
  5. メンテナンス時間に承認された方法で変更し、サービスごとのヘルスチェックを行う。
  6. 正引き・逆引き、SSH、TLS、監視、ログ、ジョブ、再起動後の値まで検証する。

systemd環境ではhostnamectl hostname NAMEまたは従来のhostnamectl set-hostname NAMEが使われる版がありますが、記事の例をそのまま本番で実行せず、対象版の公式マニュアルを確認してください。変更権限も必要です。コンテナではホスト側のオーケストレーターが名前を決め、コンテナ内の変更が永続化しないことがあります。クラウドでは初期化エージェントが再起動時に上書きする場合があります。根本の管理元を特定することが先です。

出力が想定と違うときの切り分け

  • hostnameとhostnamectlが違う:static、transient、prettyのどれを比較しているか、systemd-hostnamedの状態を確認する。
  • FQDNが取得できない:/etc/hosts、DNS、検索ドメイン、NSS、ネットワーク到達性を順に確認する。
  • 再起動後に戻る:クラウド初期化、DHCP、NetworkManager、構成管理、コンテナ定義など上位の管理元を調べる。
  • 名前は合うが接続できない:DNSキャッシュ、ファイアウォール、ルーティング、サービス待受、証明書を別問題として調べる。
  • 一部ツールだけ旧名を表示する:そのツール固有のキャッシュ、資産ID、設定DB、再登録手順を確認する。

スクリプトで利用するとき

ホスト名を分岐条件にする自動化は、名前変更やクローンで誤動作しやすい設計です。可能なら環境を示す明示的な設定、クラウドタグ、一意なマシンID、構成管理のインベントリを使います。どうしてもホスト名を使う場合は、取得コマンドが成功したか、値が空でないか、許可した完全一致かを検査し、部分一致だけで本番処理を選ばないでください。FQDNの大文字小文字や末尾ドット、短縮名を正規化する規則も先に決めます。表示コマンドは簡単でも、その値が何を保証するかを限定して扱うことが安全な運用につながります。

公式情報・参考資料

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次