4. 正確な世界時に同期する
管理しているすべてのマシンの時刻を正確に保つことは、 しっかりしたネットワークセキュリティの方針を立てる (「ファイアウォールを置くだけ」よりずっと先のレベル) のと同じくらい重要なことです。 システムを機能的かつ安全に、正しく管理していく上で、 時刻の同期は主要な要素のひとつと言えます。 特に分散型のアプリケーションや web サービス、あるいは分散型の セキュリティ監視ツールを管理する場合には、 正確な時刻は必要不可欠です。
4.1. NTP: ネットワークタイムプロトコル
ここではプロトコルについては触れませんが、 このすばらしい発明とインターネットの普及とが、 私たちにどのように役立ってくれるかは説明しましょう。 NTP に関するより詳しい情報は www.ntp.org から得られるでしょう。
一度システムを設定すると、 NTP は (動作しているアプリケーションには影響を及ぼさないような) 非常に小さな修正を行いながら、 その正確な時刻を保持しようとし続けます。
原子に含まれる電子の振動数やサイクロトロンを利用したハードウェアを用いると、 非常に正確な時刻が取得できます。 また GPS (Global Positioning System) を用いる方法もあります。 前者のほうがより正確ですが、後者も充分優れています。 両者とも特殊で高価な装置を必要としますが、 これらの装置の所有者 (たいてい大学か研究所) は、 その装置をコンピュータに接続し、そのコンピュータで NTP デーモンを走らせ、インターネットにつなぎ、 我々が無料でアクセスすることを許可してくれているのです。 そして我々は、これを使って自分のシステムの時刻同期をしようというわけです。
4.2. 簡単な時刻同期構造を構築する
必要なものは:
直接または間接 (ファイアウォール経由) のインターネット接続。
NTP サーバを選択します。 公開サーバである pool.ntp.org を利用することもできますし、 NTP の web サイトにある stratum 2 公開タイムサーバ から選ぶこともできます。 インターネットへ接続されていない場合は、 あなたの WAN の管理者が適切な内部アドレスを教えてくれるでしょう (腕のいい管理者なら、ですけど)。
同期させたいシステムすべてに NTP パッケージをインストールすること。 自分の使っている Linux ディストリビューションの CD に RPM があるでしょうし、なければ rpmfind.net で 検索 してみましょう。
良い構成の例を次に示します。
同期させたいマシンが複数ある場合、 それらすべてを選択したリモートの NTP サーバに接続しては いけません。 自分の管理しているサーバたちから 2 台だけを選び、 リモートの NTP サーバへアクセスするマシンは この 2 台に限るのです。 そして他のマシンは、この 2 台に対して同期させるのです。 この 2 台のことを、 これ以降ではリレーサーバと呼ぶことにしましょう。
リレーサーバはネットワークにつながっているマシンのどれでもかまいません。 NTP の使うメモリや CPU はわずかですから、 専用のマシンを用意する必要はありません。
Tip: これらのローカルなリレーサーバには、ntp1.my.com や ntp2.my.com のように、ホスト名のエイリアスをつけておくといいでしょう。 こうしておけば、 NTP の機能を (IP アドレスとホスト名の違う) 別のリレーサーバに移動しても、 クライアントでは変更を行わずにすみます。 DNS の管理者に、これらのエイリアスを作成するよう頼んでみましょう。
4.3. NTP の設定
- リレーサーバでは
/etc/ntp.conf を編集して、 選択したリモートサーバを追加します。
Example 5. リレーサーバの /etc/ntp.conf
. . server otherntp.server.org # A stratum 1 server at server.org server ntp.research.gov # A stratum 2 server at research.gov . .
前にも述べましたが、 公開サーバ pool.ntp.org も使えますし、 NTP の web サイトから 公開タイムサーバ のリストを取り寄せることもできます。
- クライアントでは
/etc/ntp.conf を編集して、 リレーサーバの (NTP サーバであることを意味する方の) ホスト名を追加します。
Example 6. クライアントマシンの /etc/ntp.conf
. . server ntp1.my.com # My first local relay server ntp2.my.com # My second local relay . .
もしマシンの UTC 時刻が NTP サーバに対して数分以上ずれていると、 NTP は動作しません。 従って最初に完全同期 (full sync) を行わなければなりません (システムで仕事が行われていない時間帯を選びましょう)。 この作業は NTP の初期設定を行う時だけ必要とされます。 それ以降は全く不要です。
Example 7. 最初の同期
bash# ntpdate otherntp.research.gov |
- 最初の完全同期では、我々のシステムが 15 秒遅れていました。
- 二度目の完全同期は、単に確認のために行いました。 ほとんどずれはゼロで、これで OK です。
最終段階は、各マシンでの NTP デーモンの起動 (または再起動) です。
bash# service ntpd restart |
4.4. 時刻同期の確認
以上で設定はすべて終わりです。 NTP はそっとあなたのマシンの時刻を 同期し続けてくれているはずです。 この様子は、NTP Query コマンド (ntpq) で見ることができます。
Example 8. 時刻同期の状態
bash# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
-jj.cs.umb.edu gandalf.sigmaso 3 u 95 1024 377 31.681 -18.549 1.572
milo.mcs.anl.go ntp0.mcs.anl.go 2 u 818 1024 125 41.993 -15.264 1.392
-mailer1.psc.edu ntp1.usno.navy. 2 u 972 1024 377 38.206 19.589 28.028
-dr-zaius.cs.wis ben.cs.wisc.edu 2 u 502 1024 357 55.098 3.979 0.333
+taylor.cs.wisc. ben.cs.wisc.edu 2 u 454 1024 347 54.127 3.379 0.047
-ntp0.cis.strath harris.cc.strat 3 u 507 1024 377 115.274 -5.025 1.642
*clock.via.net .GPS. 1 u 426 1024 377 107.424 -3.018 2.534
ntp1.conectiv.c 0.0.0.0 16 u - 1024 0 0.000 0.000 4000.00
+bonehed.lcs.mit .GPS. 1 u 984 1024 377 25.126 0.131 30.939
-world.std.com 204.34.198.40 2 u 119 1024 377 24.229 -6.884 0.421 |
各列の意味
- remote
リモートの NTP サーバの名前です。 -n スイッチを用いると、 ホスト名の代わりに IP アドレスが表示されます。
- refid
各サーバが現在どこから時刻を取得しているかを示します。 サーバのホスト名や .GPS. のようなものが表示されます。 後者は Global Positioning System から時刻を取得していることを示します。
- st
Stratum は 1 から 16 までの数値で、 リモートサーバの正確さ (precision) を示しています。 1 は最も正確で、16 はサーバに接続できないことを意味します。 あなたのマシンの Stratum は、 最も正確なリモートサーバの Stratum に 1 を加えたものになります。 [訳注: GPS 時計などの時刻基準を備えたマシンに対する 「接続段数」と考えるとよいと思います。]
- poll
ポーリングを行う時間間隔を秒単位で表したものです。 値は許されている最小値・最大値の間になります。 当初は高速に同期ができるよう、この値は小さくなっています。 時計が同期状態になったら、ポーリング値はだんだん長くなっていき、 ネットワークの通信量や、 人気のある time サーバの負荷を減らすようになっています。
- reach
8 ビット分のビット列を 8 進数で表現したもので、 ローカルのマシンがサーバへの接続を試みた、最後の 8 回分の結果を示しています。 サーバに到達した場合はビットが立ちます。 [訳注: 従って全部成功していれば 377 となります。]
- delay
「いま何時?」要求に対する返答が返されるまでに必要とされた時間 (秒単位) です。
- offset
最も重要な値です。 ローカルマシンとリモートサーバの時刻の違いです。 同期している最中は、offset は小さくなっていきます。 つまりローカルのマシンの時刻がだんだん正確になっていくわけです。
- jitter
分散 (dispersion) とか揺らぎ (jitter) と呼ばれるものは、 何回か要求・応答を行った際の、オフセット値の統計的な揺らぎを与えるものです。 この値は低い方が好ましいです。 値が低い方が、正確な時刻同期が可能になります。
サーバのホスト名の前に置かれる符号の意味
- -
ローカルの NTP サービスはこのサーバをあまり好んでいない
- +
ローカルの NTP サービスはこのサーバを好んで利用している
- x
不良ホスト
- *
現在利用している
4.5. NTP がブート時に自動起動するよう設定する
NTP はずっと動作させておきたいことが多いでしょう。 マシンを再起動した場合でもそうですね。 各マシンで以下の作業を行いましょう。
bash# chkconfig --level 2345 ntpd on |
これで自動起動が確実になります。
マシンを再起動しないまま長いこと (何ヶ月も何年も) 動かし続けると、 本来正確でないハードウェアクロックと、(今や非常に正確となった) システム時刻との間には、大きなずれが生じるでしょう。 最近の Linux ディストリビューションでは、 システムをシャットダウンする際に、 setclock コマンドに 似た仕組みを使って OS 時刻を HC 時刻にコピーします。 このようにして、次に OS を起動する際にも、 シャットダウンの時とだいたい同じくらい、 ほぼ正確な日付と時刻が得られるようになっているのです。