システム奮闘記：その15

システム時間のズレの問題

はじめ

  未来からのメール。
　なんと、うちの会社は超光速粒子「タキオン」を使った
通信システムを開発して、未来の情報を事前に受け取れるようになった！
  開発した私は・・・

　次期ノーベル賞の候補者に!

  と、アホな前置きは置いといて、本題に入ります。


  さてさて、うちの会社がインターネット接続されて
もうすぐ3年を迎える。月日が経つのは、早いものだなぁと感じる。
  しかし、3年前から解決していない問題があった。
それはメールの着信時間だった。なんと14時間ほど進んでいた。
  そのため、メールの受信時間が14時間進んでいた。

  そのズレは3年近く続いていた!!

  そこで今日は、時間がズレた理由と、なぜ、3年間も放置されてきたを
書くことにしました。
  題して「未来からのメール」の始まり始めり (^^)

サーバーの時間が狂っていた

  3年前、必死になって自力でサーバーを構築していた。
  さて、必死の思いでサーバーが立ち上がった際、
時間の正確さを見るため、dateコマンドを叩いた。

[root@kaisha]# date
Tue Jan 28 05:07:35 EST 2003
[root@kaisha]#

  よく見ると、本来、JSTのはずなのに、ESTになっている。
  これはアメリカ東部地域（ニューヨークなど）の時間を表す。
  しかし、サーバー立ち上げ当時、そんな知識がなかった！
  そのため、dateコマンドで表示された時間が日本時間と思い込んでしまった。

  dateコマンドでサーバーの時間を見て、腕時計との時間が合わなかったら
date MM:DD:hh:mmという感じで、時間を入力していた。
  もちろん、入力した時間がニューヨークの時間になっているとは知る由もなかった。

  この時、時間の同期の事を知っていれば、良かったのだが、知らなかった。
というより、メール、DNS、プロキシーなど重要部分ばかりに気をとられ、
入門書には時間同期の欄があったのにも関わらず、読み飛ばしていた。

  2つの事が原因で、時間のズレの解決が遅れることになった。


  この時間のズレは、最初の頃は全く問題にならなかった。
メールの利用が皆無に近く、相変わらず、電話とFAXが多かったからだった。
  しかし、時間が経つにつれ、社内でメールの活用が少しづつ増えていくと、
メールの整理をする人が出てくるため、着信時間は大事になってくる。
  そうなると・・・

　着信時間がおかしい!

 という声が上がってくる。

  もちろん、おかしいと指摘されたら修正しないといけない。
しかし、dateコマンドで出た時間が日本時間と信じていたため、
表示された時間が自分の腕時計と変わりなかったら、おかしいと思わないし、
クライアントのWindowsの時間を見ても、おかしな点は見つからなかった。
  思いつく原因がわからず、何も出来なかった。

  困ったなぁと思いつつ、しばらく時間が経つと忘れてしまう私。
  社内でも「まぁ、いいか」という感じだったので、私は重要視してなかった。
  そして、時間の問題は封印されることになった。


  2001年のある日、Linuxの入門書を読んでいると時間同期をとる
NTPサーバーの話が出ていた。
  これで解決できると思い本の通りに xntp3のソフトをインストールした。
  そして、 設定ファイルにNTPサーバーを指定して xntpをスタートさせた。
  NTPサーバーの状態を見るために、ntptraceコマンドを使ってみた。

  なんと、Timeoutのエラーを吐き出した （ＴＴ）

  これは、NTPサーバーにつながっていない証拠。思わず「何故？」と頭を抱える。
  もしかして、うちの会社のサーバーと、インターネットの間にある
ルーターのフィルター設定の問題かなぁと考えた。
  そこで、ルーターの設定を見る。

  しかし、設定方法がわかんない （ＴＴ）

  しかし、諦めてはいけないので、他の設定を参考に見よう見まねで設定を行なう。

  しかし、うまくいかへん （ＴＴ）

  試行錯誤していると、社内から「ネットが使えへんで」という声が出てきた。
  なんと通信できなくしてしまっていた！！
  実は、この時、ルーターの設定は、ほとんど、わかっていなかった。
そのため、下手に触ると大変な事になると思い、設定を元に戻した。

失敗談が豊富という事で、ルーター設定の話も書こうかなぁと思いましたが
これだけでも、かなりの分量になりそうなので、別の機会にまとめます。

(2011/10/20追加)
当時使っていたルーターの話は「システム奮闘記:その18」をご覧下さい。
(ヤマハルーターRTA52とRTA55iの設定)

  それから再び時間の問題は、長期間、封印されることになった。
  まさに、「時間の問題」がパンドラの箱になっていた。


  そのパンドラの箱を開けたのは、2003年1月だった。
私が会社で、ISDNからADSLに変更する話を提案し、稟議が通った。
  そこで、ADSL対応のルーターを購入。一から説明書を読むことになった。
  この時は、既に、ネットワーク関係の入門書などを読んだりしていて
全く無知な状態でルーターを設定しているわけでなかった。
  そのため、フィルターの設定で、NTPサーバーに接続する方法がわかった。

  フィルターの設定変更を行なった。
  そして、時間を合わせるため、次のコマンドを使った。
  ntpdate -b ntp1.jst.mfeed.ad.jp

  そうすると、一瞬、画面が白くなった。フラッシュした感じだった。
  dateコマンドを見ると、時間がズレていた。
  「なんでや」と思いながら、同じコマンドを叩いたが結果は同じだった。
  dateコマンドで、時間を腕時計の時間に戻そうと思った時だった。

  丁度、その時、同僚がメールを取り込んでいた。
同僚が声を上げた。

　メールの着信時間が急に正確になったで!!

  何か触ったか?

　だった。
  私は「サーバーの時間を触りました」と答えた。

  私もメールを取り込んだら、着信時間が正確になっていた。
  dateコマンドの時間と、腕時計の時間は14時間ズレているのにと不思議に思った。
そこで、調べてみると、ここでやっと謎が解けた。

  今まで、dateコマンドで出た時間がESTで、アメリカ東部時間。
  そのため、dateコマンドと腕時計の時間とを合わせると、未来に時間が設定される。

  最後に、表示のESTから、JSTに変更する方法を探した。
  そして、timeconfigコマンドを使えば、変更できる事が本に書いていた。
  家のLinux端末でtimeconfigコマンドを使えば、変更できた。

変更画面の様子

  しかし、会社のLinuxサーバーでtimeconfigコマンドを使うと

  なんとエラーが出る (TT)

  エラーの内容は
  Your terminal lacks the ability to clear the screen or position the cursor.だった。

  しかし、これでめげない私。manコマンドを使ってtimeconfigコマンドを調べた。
  そして、timeconfig JSTとコマンドを入力したら

  それでもエラーが出る (TT)

  エラーの内容は
  cp: /usr/share/zoneinfo/JST: No such file or directory
timeconfig: failed to make /etc/localtime: Successだった。
  でも、エラーの内容は解決のヒントになることがある。
  そこで、/usr/share/zoneinfoディレクトリーを見てみることにしたら、
世界の場所がファイル名になっているファイルや、ディレクトリーがあった。
  AsiaというディレクトリーにはTokyoというファイルがある。

  そこで、timeconfig Asia/Tokyoとコマンドを入力したら

  3度目の正直。うまくいった V(^^)V

  一応、timeconfig Japanもやってみたら、OKだった

  これで、3年近く前から、おかしくなっていた時間を修正できた (^^)

  思わず万歳大合唱  V(^^)V  


システム時間が狂った際に発生する問題点

  さて、日付が正常になった翌日、メルマガの記事に、こんな物があった。

  うちは、時間は正確なのだ (^^)

　と、涼しい顔をしながら読むことにした　←　ベンダー勤務ならクビが飛んでる!


  株式会社ラックJSOC事業本部の川口洋氏が日経IT-PROに書かれた記事だった。
  内容には、時間の重要性について4点が書かれていた。

 私が認識していたのは(1)と(2)だった。
というより、この2つは誰でも、わかる現象だ (^^;;

　(3)について考えてみる

  そこで、まずは(3)の現象が起こるかどうか確認してみることにした。

(3)の確認実験
まず、端末からSAMBAへデータを書き込む。 その時、端末とSAMBAの時間は正しくする そして、SAMBAの時間を半年くらい進める。 わざとSAMBAの時間を大幅に進ませることにより、 後で接続する端末の時間が大幅に遅れている状態にできる。 そして、端末からSAMBAにあるデータを書き換える。

  実験結果は・・・

　データの内容は書き換わっていた

  うーん、書き換えができなかれば、「時間を合わせるのは大事だぞ〜」と
説得力が増すのだが、うまくいかず残念 (^^;;

  普段。ファイルサーバーを使っていないだけに、なかなか重要性の実感がわかないが、
でも、よく考えれば、重要な事は理解できる。
  みんなで共有しているデータが、ある端末から書き換えができなければ
支障が起こるのは間違いない。
  将来、うちの会社でファイルサーバー導入時には気をつけねば・・・。

  閑話休題。

　(4)について考えてみる

  (4)の実験を行なってみようと考えたが・・・

   どういう実験をすれば良いのか、わかんない （ＴＴ）

  というわけで、実験はしないことにした。

  ここで手抜きするな！ 調べて実験しろ！という声があると思いますが、
そういう声には堂々と反論します。
  そこまで知識や技術があれば、今頃、こんな失敗談は書いてませ〜ん (^^)

  もう一つオマケに書きます。
  そこまでできたら、事務員を辞めて、技術者として転職していま〜す (^^)

  さて、忍法「言い訳の術」を使った所で、(4)が現実に起こった場合を想定してみた。

あるAというソフトがあったとする。インストールのためAをコンパイルする。
ある日、ソフトAにセキュリティー・ホールが発見される。
そのため、ユーザーは、バージョンアップされたソフトAをコンパイルする。
しかし、システムの時間が狂っているため、肝心のセキュリティー処理が
されている部分がコンパイルされずに、折角、ソフトのバージョンを上げても
セキュリティー・ホールが残っているのに気づかず、クラッキングされる。

  うーん、そう考えると、時間が狂っているのは、恐い話だなぁと思う。

  さて、ここまでで、私が、ラックの川口さんの記事の内容を理解して
奮闘記を書いているかどうか、わからない。
  もしかしたら、誤解したまま間違えた事を書いているかもしれない。
  そこで、日経IT-PROのサイトに川口さんのメールアドレスが書かれていたので、
大胆(?)にも内容検査をお願いしました所、快く内容検査してくださいました。

  内容については、問題ないというお返事を頂きました。
  専門家の太鼓判が押されたので、ホッとする私 (^^)

  補足として、次の事を書いていただきました。

補足としては「その3」の場合は手動ではなく
ファイルの最終更新時刻を、元にしてバックアップするソフトを
使っている際にはまります。以前、自作のスクリプトで
バックアップを行っていたのですが、その際にも
この問題にぶちあたり難儀しました。

  これを読んで、専門家の方も、四苦八苦しながら、色々な経験を積まれて
おられるんだなぁと思いました。

  快く内容検査してくださった川口さんに、この場を借りてお礼を申し上げます m(--)m

ここでまとめ！

  システムの時間。単にメールの発着時間が狂うだけでなく、
ファイルの書き換えができなくなったり、ソフトのコンパイルにまで影響が出るため
安易に考えてはいけないことが、わかった。
  それにしても、3年近く時間を修正しなかった私は、とんでもない管理者だと
我ながら感心してしまう (^^;;

  でも、ここで忍法「言い訳の術」を使う。
  放置していたのではなく、修正の方法がわからなかったのらー！！
  修正できるだけの技術や知識を身につけるには時間がかかるのらー！！

  というわけで、時の問題は、時が解決してくれます (^^)  ←　おい！
  最後に、この歌を歌って締めくくります！

  時の流れに身を任せ〜♪(テレサ・テン)