PXEブートできない場合のネットワークインストール

PXEインストールは、ブートCD/DVDを使わずに、ネットワーク経由でOSをインストールする方法だ。これに関して、『CentOS 5でXenを使ってみる』でちょっとだけ触れた。

PXEインストールは、当然だがPXEブートに対応したBIOS/NICを持つマシンでしか利用できない。また、PXEブートに対応していても、なぜかTFTPに失敗してPXEインストールできない場合もあるようだ(手元の富士通FMV 6350CLではPXEインストールできなかった)。そういった場合にネットワークインストールをする方法。

Fedora/Fedora Coreの場合であれば、Rescue CDを使ってインストールする。途中でインストール元を選択する画面が出るので、そこでHTTPなりFTPなりを選択する。

一方、CentOSにはRescue CDが準備されていない。CentOSの場合は、CDの一枚目だけを準備しておき、起動直後のboot:プロンプトの時点で、

boot: linux askmethod

と入力し、[Enter]キーを押す。すると、Fedora/Fedora Coreと同様、インストールプロセスが開始され、途中でインストール元を選択する画面が現れる。

注意！IPマルチキャストに関して訂正・本編

2008.11.3(月):注意！この記事の内容も正しくありませんでした。訂正記事を掲載しました。
『注意！IPマルチキャストに関して訂正』で予告した、以下の記事に関する訂正です。
[1] 『IPマルチキャストを使う』
[2] 『IPマルチキャストを使う・補足・VLANと』
端的に言うと、ntpdのIPマルチキャストを使ってIPマルチキャスト通信の検証を行っていたので、ntpd固有の問題とIPマルチキャスト一般の問題を混同してしまったのが間違いの原因です。

記事[1]の中で当初、

IPマルチキャストを使用する場合、そのホストが持っているネットワークインターフェースの内、どのインターフェースの先にIPマルチキャストネットワークが存在しているかを指定しなければならない。

と書いていました。これは実際には誤りで、何も指定していなければどのインターフェースにもIPマルチキャストネットワークが存在するものと理解しているはずです。ただ、IPマルチキャストアドレスに対する経路を明示的に設定することができる、というだけのことです。

ただし、ntpdに関しては事情が違います。Ntpdは、その認証機構がIPアドレスと結びついているため、マルチキャストパケットを送信する際に、送信元となる自分自身のIPアドレスをntpd自身が明示的に知る必要があります。そのため、IPマルチキャスト用のソケット(socket)を取得する際、そのIPマルチキャストアドレス(通常なら224.0.1.1)で経路情報(routing table)を引き、得られたネットワークインターフェースのIPアドレスを送信元IPアドレスとするようです。
これは、マルチキャストクライアントの場合も同様のようです。つまり、listenするIPマルチキャストアドレス(通常なら224.0.1.1)で経路情報を引いて得られたネットワークインターフェースからのみ、NTPマルチキャストパケットを受け取ります。

このntpdの動作は、Linux機にネットワークインターフェースが一つしかない場合には問題になりません。なぜなら、既定経路(default route)が存在していれば、それは必ず唯一のネットワークインターフェースに結びついているからです。

注意！IPマルチキャストに関して訂正

以下の記事の内容が間違っていました。近日中に訂正記事を掲載します。
『IPマルチキャストを使う』
『IPマルチキャストを使う・補足・VLANと』

NTP認証: マルチキャスト・共通鍵認証篇

NTP認証シリーズでは、ユニキャストおよびブロードキャストで共通鍵認証を使う方法を解説してきた([1]、[2])。今回は、マルチキャスト(multicast)で共通鍵認証を使う方法について解説する。

NTPでマルチキャストを使う場合は、当然IPマルチキャストが使える様設定しておかねばならないが、この設定についてはここでは解説しない。『IPマルチキャストを使う』および『IPマルチキャストを使う・補足・VLANと』を参考にして欲しい。

共通鍵の設定については、サーバ側、クライアント側ともユニキャスト・ブロードキャストの場合と同様。他の設定についても、ブロードキャストの場合と大きく違わない。鍵の生成およびクライアントへの鍵配布については、ここでは省略する。『NTP認証: ユニキャスト・共通鍵認証篇』を参考にして欲しい。

サーバ側
サーバの設定は、ブロードキャストの場合とほとんど同じで、/etc/ntp.confの中のbroadcastコマンドに与えるアドレスを、マルチキャストアドレス224.0.1.1(NTP.MCAST.NET)に変更するだけだ。鍵ファイル/etc/ntp/keysは既に生成してあるものとして、/etc/ntp.confに以下のように記述する。

restrict 192.168.55.0 mask 255.255.255.0 nomodify notrap
keys /etc/ntp/keys
trustedkey 10
broadcast 224.0.1.1 key 10

ここでは鍵番号10を使用したが、これは適宜変更してもらって構わない。また、LANのIPアドレス192.168.55.0は、環境によって変更する必要がある。
変更したらservice ntpd restartを実行し、ntpdを再起動する。
Stratum的に上位のNTPサーバへの時刻同期は、通常と同様なので割愛する。

クライアント側
クライアントの設定もブロードキャストの場合と似ている。違うのは、、/etc/ntp.confの中でbroadcastclientの代わりにmulticastclientコマンドを使用する点。鍵の配布は既に終わっているものとして、/etc/ntp.confに以下の様に記述する。

restrict 192.168.55.0 mask 255.255.255.0 nomodify notrap
multicastclient 224.0.1.1
keys /etc/ntp/keys
trustedkey 10

鍵番号およびLANのIPアドレスは、環境に合うよう変更の必要がある。
変更したらservice ntpd restartを実行し、ntpdを再起動する。

確認
まず、サーバ側で時刻同期ができていることを確認する。再起動後、時刻が同期するまでにはしばらくかかる。確認はntpstatコマンドで行う。再起動直後は、以下の様な結果を得るはずだ。

$ ntpstat
unsynchronised
time server re-starting
polling server every 64 s
$

これがしばらく立つと以下のように変化する。

$ ntpstat
unsynchronised
polling server every 64 s
$

時刻同期ができたら、さらに以下の様に変化する。

$ ntpstat
synchronised to NTP server (210.173.160.87) at stratum 3
time correct to within 34 ms
polling server every 64 s
$

これでサーバの時刻同期ができたので、今度はクライアントで時刻同期を確認する。クライアント側でも、ntpstatコマンドを使えば同様に確認できる。認証が行えているかどうかは、ntpqコマンドで確認することができる。

$ ntpq
ntpq> peer
remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
LOCAL(0)        .LOCL.          10 l   59   64  377    0.000    0.000   0.002
*ntpserver.local 210.173.160.87   3 m   46   64  376    0.353   -2.665   0.752
ntpq> assoc

ind assID status  conf reach auth condition  last_event cnt
===========================================================
1 29516  9014   yes   yes  none    reject   reachable  1
2 29517  7614    no   yes   ok   sys.peer   reachable  1
ntpq>

コマンドpeer(s)の出力で、tの欄がmになっていることに注目して欲しい。これは、マルチキャストで時刻同期している、ということを表している。再起動直後は、ここがu、つまりユニキャストの表示になっている場合があるが、しばらくするとmへ変化する。
次のassoc(iations)コマンドの出力は、各行がpeer(s)の出力の各行と順に対応するので、indが2の行がマルチキャストサーバの状態を表している。この行のconfがnoになっているのは、設定ファイル/etc/ntp.confによって設定された時刻源ではないことを表す。同じくauthがokになっているのは、認証できていることを表している。

第一回:『NTP認証: ユニキャスト・共通鍵認証篇』
第二回:『NTP認証: ブロードキャスト・共通鍵認証篇』
第三回:『NTP認証: ntp-keygenコマンドとX.509証明書』
第四回:『NTP認証: ユニキャスト・公開鍵認証篇』
第五回:『NTP認証: マルチキャスト・共通鍵認証篇』

ローカルミラーレポジトリ・その5・レポジトリの利用

ローカルミラーレポジトリシリーズ第五回。ローカルミラーを使って各サーバを更新できるよう設定する。

コマンドyumやその他yum関係のユーティリティは、設定ファイル/etc/yum.confおよび、/etc/yum.repos.d/*.repoを読み込む。公開レポジトリは、/etc/yum.repos.d/CentOS-Base.repoの中で記述されている。これをローカルレポジトリに変更すればよい。

# cd /etc/yum.repos.d
# mv CentOS-Base.repo CentOS-Base.repo.dist
# cat CentOS-Base.repo.dist | sed 's/mirrorlist=/#mirrorlist=/
s/#baseurl=/baseurl=/
s/mirror.centos.org/centos.repository.localdomain/' > CentOS-Base.repo
#

ホスト名の部分centos.repository.localdomainは、各環境に合わせて変更する。
後は通常と同じようにyum update等を実行する。実際にローカルレポジトリへアクセスしているかどうかは、ローカルレポジトリサーバのHTTPサーバのアクセスログを見てみればよい。

ローカルミラーレポジトリ・その1・概要
ローカルミラーレポジトリ・その2・レポジトリの準備と公開
ローカルミラーレポジトリ・その3・Baseレポジトリ
ローカルミラーレポジトリ・その4・レポジトリの更新(reposync & createrepo)
ローカルミラーレポジトリ・その5・レポジトリの利用