タイムゾーンの設定
タイムスタンプのトラブルとして、もう1つ注意すべき点がある。それは、タイムゾーンだ(画面9)。
PCの時刻管理は、協定世界時UTC(Coordinated Universal Time)とローカルタイムの2種類がある。UTCは、いわゆるグリニッジ標準時GMT(Greenwich Mean Time)に相当し、国際電気通信連合ITU(International Telecommunication Union)が管理している世界共通の基準となる時刻だ。日本標準時JST(Japan Standard Time)との時差は9時間となる。
Linuxのhwclockコマンドで説明した通り、PCにはシステムクロックとハードウェアクロックの2種類の時計があり、電源オン時に、ハードウェアクロックからシステムクロックを決定する。その際、ハードウェアクロックにUTCを設定している場合は、時差を加えてシステムクロックを決定する。ハードウェアクロックをローカルタイムに設定している場合は、そのままシステムクロックになる。
アメリカのように、国内に複数の時間があったり夏時間がある場合、ハードウェアクロックをUTC基準にし、システムクロックは時差で管理するほうが便利だろう。一方、日本は時差も夏時間もないから、ハードウェアクロックもシステムクロックも同じローカルタイムで管理するのがよい。
これらはBIOSで確認できる。BIOSのCMOS時計が日本時間になっていれば、後者に設定されている。Windowsはもちろん、FedoraやCentOSも、標準的なインストールではこのようになっているはずだ。
また、インストール時にタイムゾーンを設定したはずなので、念のため確認しよう。もし間違っていたら、前掲の画面9(Windows Server 2008の場合)ですぐに再設定する。
Linuxは、dateコマンドで「JST」と表示されれば、タイムゾーンが正しく設定されていることになる(画面10)。間違っている場合は、/etc/sysconfig/clockファイルを修正する(画面11)。もっとも、FedoraやCentOSなら直接ファイルを修正しなくても、system-config-dateコマンドを使うのが簡単だ。忘れずに/etc/localtimeファイルが、/usr/share/zoneinfo/Asia/Tokyoファイルと同じかどうかもチェックしておこう。
Active Directory下での注意
WindowsのActive Directoryを使う場合、時計が合っていないとログオンできないなど、タイムスタンプとは別の問題が発生する。これは、Active Directoryの認証でKerberosを使っているからだ。サーバとクライアント間での認証プロセスにおいて、両者の時刻に5分以上の差異があると不正とみなすようになっている。
この連載の記事
-
第8回
サーバー・ストレージ
メールサーバからメールが送信されない -
第7回
サーバー・ストレージ
DHCPサーバからIPアドレスが発行されない -
第6回
サーバー・ストレージ
RAIDのエラー対策をしていますか? -
第5回
サーバー・ストレージ
ファイルサーバのファイルが操作できない -
第3回
ネットワーク
ハードディスクのクラッシュに備えよう -
第2回
サーバー・ストレージ
まずはリモートでトラブルの原因を切り分けよう -
第1回
サーバー・ストレージ
管理者の心構えはできていますか? -
ネットワーク
サーバトラブル解決のセオリー<目次> - この連載の一覧へ