システム奮闘記：その9

知ったかぶりディスクパーティション

(2002年1月30日に掲載)

はじめに


 「システム奮闘記：その2」(自力でリナックス(Linux)サーバー構築)で
Linuxをインストールした時に、ディスク・パーティションの分け方を
次のようにしていた。

ディスクパーティションの様子
Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda1 6048320 1121536 4619544 20% /


  スワップ領域は100M、残りは「/」という単純な分け方をしていた。
  なぜ、複数にパーティションをするのか、理由が、わからなかったからだった。

  さて、このまま何も知らない方が「知らぬが仏」で良かったのかもしれないが、
どっかで入れた知識か覚えていないが、パーティションを1つにしてしまうと
セキュリティーに問題があるという情報を仕入れた。
  そこで。セキュリティーホールならば、塞ぐ必要があると思った。
  その上、格好良くディスク・パーティションをしていると

  私の知識もアップした!

　という自己満足になれる (^^)

  自己満足のためにシステム管理をしている、トンデモ管理者だった (^^;

  「システム奮闘記：その8」(セキュリティーてんやわんや)で、
OSを入れ替えを書きましたが、その時に、ディスクパーティションを行なった。

   何も考えず、パーティションを行なったため問題が生じた！

 そこで、生半可な知識のために、生じた問題を披露いたします。

 その物語のはじまりはじまりパチパチパチ


Linuxのディスクパーティション変更

  OSを入れ替えた時、ディスクパーティションを行なった。
  パーティションの割り当ては、本を見て、そのまま丸写しのように行なった。

  その当時のディスクパーティションは次のような感じだった。

ディスクパーティションの様子
Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda1 248895 212041 24004 90% / /dev/hda6 3684236 836740 2660344 24% /home /dev/hda5 3684236 850064 2647020 24% /usr /dev/hda7 350021 240319 91631 72% /var

ディスクパーティションの様子

Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda1               248895    212041     24004  90% /
/dev/hda6              3684236    836740   2660344  24% /home
/dev/hda5              3684236    850064   2647020  24% /usr
/dev/hda7               350021    240319     91631  72% /var


  OSの入れ替えの時は何ともなかったし、その後、しばらく問題もなかった。

  しかし、2001年7月、事件が起こった！

  その日、私は用事で大阪に出ていた。
  用事が終わり会社に電話を入れると、上司から

　メールができへんようになった

　Webも使えへんようになった

　どないしたら、ええねん!!

　だった。
  その時、私はデーモンがコケたのかなぁと思い、上司に、psコマンドを説明して
操作してもらい結果を言ってもらったが、デーモンは生きていた。

  さすがに、会社に戻ると20時近くになる。
  システム管理者は、どんな時でも駆け付けるというのが鉄則なのだが、
その当時は、メールもWebも、あまり使われていなかったため、
すぐに支障が出るわけでもない。
  上司から「次の日で、かまへんで」と言われたので、直帰する事にして
次の日に原因を調べることになった。

サーバー停止の原因を探る

  次の日、サーバーの前で原因を調べはじめた。
  確かに、メールとWebが使えない。
  しかし、デーモンは生きている！

  デーモンを立ち上げ直したが、Webとメールは使えないままだった。
  原因がわからないと気味が悪い。その上、悪い方向に考える。
  クラッキング、DoS攻撃...etc
  しかし、そういう報告例も聞かない。ますます、わからないため困惑した (@o@)

  同僚からは「まだ、復旧できへんのか」と言ってくる。
  「そんな簡単に言うなよなぁ～」という感じだった。
でも、その当時は、あまり使われていないため、のんびり普及作業ができた。

  片っ端からLinuxの本を見ても、デーモンが生きているが、
メールなどの各種サービスが停止する場合のトラブル対策などが書いていない。
  そのため、全く打つ手なし。一度、再起動してみたが、結果は同じだった。
  全く見当すらつかず、とうとう追い詰められた気分になり、こういう決断した。

私が選んだ解決法
原因不明の不気味な状態なので、解決不能。クラッキングされた可能性があるので、OSを入れ替える。


  そして、OS入れ替えの作業に取り掛かり、バックアップをとる。
  rootのディレクトリーで tar cvf - *** を使って、
1つにまとめようとしていたら、ディスクがパンクした表示がでた。
  おやっと思い、dfで見ると・・・

　/rootディレクトリーがパンクしていた!

  それだけではなかった！！

  なんと、/varも溢れていた！

dfコマンドを打った結果
Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda1 248895 248895 0 100% / /dev/hda6 3684236 836740 2660344 24% /home /dev/hda5 3684236 850064 2647020 24% /usr /dev/hda7 350021 350021 0 100% /var

dfコマンドを打った結果

Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda1               248895    248895         0  100% /
/dev/hda6              3684236    836740   2660344   24% /home
/dev/hda5              3684236    850064   2647020   24% /usr
/dev/hda7               350021    350021         0  100% /var


  /varディレクトリーが溢れたから支障が出たのではと思った。
  du /var  で、巨大なファイルの原因を見ることにした。
  そうすると、/var/spool/mailが凄まじいことになっていた。
  何人かのメール・ファイルが10Mを越えていた。
  しかも、/var/spool/mqueueに送信できなかったメールが溜っていた。

  送信できなかったメールの送り主を見ると、別の部署の部長だった。

   部長に「巨大なメールを送りませんでしたでしょうか？」と尋ねると
「昨日、画像付きのエクセルのファイルを全営業所と本社全員に送ろうとしたけど、
うまくいかへんかったなぁ」と言い出した。
  そのエクセル・ファイルを見ると、なんと10Mを越えていた！！

  なんで巨大なメールを送るねん (TT)

　と思った。
 
  普段、自宅からダイヤルアップしている人達は、ダウンロードに時間がかかるため
巨大なメールは迷惑だと知っている。
  また、ネットワーク管理をしている人なら誰でも、公共のインターネットの回線に
巨大なデータで回線を占有するのも迷惑をかけるのも知っている。
  しかし、社内LANしか使わない人は、そういう感覚がない。
  そのため、平気で巨大なメールを送ってしまう (--;)


 /var/spool/mqueueの中身を消して、少しディスク容量に余裕が出た。
 そして、デーモンを立ち上げ直すと、Webのメールも復旧した。

 原因は、/varが満杯になったため、サーバーソフトのログや
プロキシーのキャッシュデータが書き込めずに、ストップしたのだった。

  全く人騒がせな事件だと思った (--;;


  しかし、数週間後、埼玉の課長から

　メール、コケたけど、原因は何?

　という電話がかかってきた。

  もしやと思い、dfで見ると、/varが満杯になっていた。

課長と私のやりとり
私	巨大なメール、送りませんでしたか?
課長	10Mくらいのファイルを添付して送ろうとしたけどそれが原因?
私	はい、そうです。
課長	ごめん、ごめん。小さくして送るね


  2度あることは3度ある。対策を立てねばと思った。
  しかし、今更、もう一度、OSを入れ替える面倒な事はやりたくない。

  そこで、届いたメールが溜る/var/spool/mailのディレクトリーを
余裕のあるパーティションの所に、シンボリックリンクをして、ゴマ化した。

  だが、根本的な原因を取り除かないと意味がない。
  そこで、巨大なメールを送らないようにと通達を流した。 
  もし、巨大なメールをお客さんに送って、お客さんから苦情が来たら
大変なので、教育が大事だと思った  ←　これだから疲れるのら  (--;)

  それ以来、巨大なメールを送る事件はなくなった。

カーネルの更新でディスクがパンク

  しかし、一難去って、また一難。
  ある日のこと、カーネルのバージョンをアップさせようとした。
  kernel-2.2.19-6.2.12.src.rpmをインストール。
  RPMS形式なのでコンパイルをさせる。
  コンパイル中、画面を見ていても仕方がないので、別の用事をしていた。
  そして、メールを送ろうとしたら、エラーが発生した。
  コンパイル中の画面を見るとディスクが溢れ、コンパイルがコケていた。
  今回は冷静に「/varが溢れたのかなぁ」と思い、落ち着いてdfコマンドで見ると、

df コマンドの結果
Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda1 248895 221845 14200 94% / /dev/hda6 3684236 1038260 2458824 30% /home /dev/hda5 3684236 1033476 2463608 30% /usr /dev/hda7 350021 348674 0 100% /var

df コマンドの結果

Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda1               248895    221845     14200  94% /
/dev/hda6              3684236   1038260   2458824  30% /home
/dev/hda5              3684236   1033476   2463608  30% /usr
/dev/hda7               350021    348674         0 100% /var


  で、やはり/varが溢れていた。
  そこで、du /varで見てみると、今度は、/var/tmpに巨大なファイルがあった。

/var/tmpの様子
[root@jimu tmp]# cd /var/tmp [root@jimu tmp]# ls -l 合計 18 drwxr-xr-x 9 root root 1024 Jan 28 16:18 kernel-2.2.19-6.2.12-root -rw-r--r-- 1 root root 5255 Jan 21 19:48 rpm-tmp.12064 -rw-r--r-- 1 root root 6232 Jan 21 18:00 rpm-tmp.35994 -rw-r--r-- 1 root root 3689 Jan 28 16:18 rpm-tmp.49096

/var/tmpの様子

[root@jimu tmp]# cd /var/tmp
[root@jimu tmp]# ls -l
合計 18
drwxr-xr-x    9 root     root         1024 Jan 28 16:18 kernel-2.2.19-6.2.12-root
-rw-r--r--    1 root     root         5255 Jan 21 19:48 rpm-tmp.12064
-rw-r--r--    1 root     root         6232 Jan 21 18:00 rpm-tmp.35994
-rw-r--r--    1 root     root         3689 Jan 28 16:18 rpm-tmp.49096


  なんと、コンパイル中のファイルが/var/tmpに保管されることを発見した！！
  もちろん、RedHat6.2でSRPMファイルのコンパイルの場合だけど・・・。

  ということは、カーネルのような巨大なファイルをコンパイルする際には、
/varの容量をとらないとマズいことになる。

  新しい発見でルンルン気分  ♪　♪　♪

　と能天気な事を思ってしまった (^^)   ←　おい、喜んでいる場合か！

ディスクパーティションを行なう理由

  さて、ディスク・パーティションをする理由。
  これを調べないと、今後の管理に支障が出るかもしれない。

  しかし、手元にあるLinuxの本には、何も載っていない。
  そこで、ネットで調べたが、ディスク・パーティションの方法などがあっても、
理由まで書いているページが見つからなかった。

  調査が行き詰まった感じがした (--;


  2001年12月、ある部長の家で、Windows98の入れ替えの設定を行った。
ディスク・パーティションで2G以上割り当てられなかった。
  最初、なぜかと思った。
  説明書を読むとファイルシステムが2つある。FAT16とFAT32。
  FAT16は、2Gまでしか認識できないため、最初に2G作って、
あと、2Gづつ論理パーティションを作って追加する。
　なぜFAT16が2Gバイトまでしか認識できなかについては、詳しくは
「システム奮闘記:その31」(ファイルシステム入門)をご覧下さい。

　この事は、初めて知った。勉強不足と突っ込まれたら、そう言います！
  「知らなかったよ～、そんなシステムがあったとは～♪」（どっかの歌の替え歌）


  そこで、パーティションをする理由は、ファイルシステムによって
認識できるハードディスクの容量が違うためだと考えた。
  そこで、Linuxのファイルシステム（ext2）を調べてみたのだが、
2Tバイトまで認識できる。これでもないなぁと思った。


  困った挙げ句、ふと、パラパラと本をめくるとmountのオプションにsuidがある。
  実行ファイルの権限で、どのユーザーが実行しても、
そのファイルの所有者の権限で実行できるファイル

  よくわからんなぁと思いつつ、本を見ていくと「なるほど」という例があった。
パスワード変更に使うpasswdコマンドだった。
 早速、ls -lで見てみる。

「ls -l」の結果
-r-s--x--x 1 root root 22312 Sep 26 1999 passwd


  ファイルの所有者はrootである。どのユーザーが実行しても、
所有者であるrootの権限で実行されるため、rootが管理する/etc/passwdファイル
（シャドウ・パスワードの場合は/etc/shadow）の変更が一般のユーザーでもできる！
  ついでに、sgidは、そのファイルの所有グループの実行権限で動く。
 
  ここで、生まれて初めて、suidとsgidの意味がわかった！！
  万歳  V(^o^)V   ←　逆に言えば、よくこれで管理をやっていたと思う・・・ (^^;

  そして、どっかの本に、ディスク・パーティションを分ける理由に
「セキュリティーに問題があるから」というの意味がわかった！！
  ディスク・パーティションをしないでいると、全てのディレクトリーで
suidとsgidの存在を許可してしまうからだ。
  もし、怪しげな奴が侵入してきて、それを利用すると恐い。
  そこで、ディスク・パーティションをして、mountのオプションを使って、
suidとsgidを不許可にしてしまえば安全性が高くなる。


  これでディスク・パーティションの意味が理解できた上、/varが溢れる原因もわかった。
  思わず「私って賢くなった♪」というルンルン気分  ←　そんな管理者で良いのか！


まとめ


  何も考えずに、ディスクパーティションを行なったために、
メールやWebの閲覧ができなくなるトラブルに見舞われました。
  生兵法は怪我の元の良い例です (^^;;

  でも、そのお陰で巨大メールの配信がなくなった上、suidとsgidの意味まで理解できた
  そこで、メールを送る時の注意で、巨大メールの事を取り上げましょう！
  そして、ディスク・パーティションをされる時は、/varには最低１Ｇは割り当てましょう。
でないとディスクがパンクする場合があります。

  ディスクパーティションについては、他にも理由があります。
詳しくは「システム奮闘記：その31」(ファイルシステム入門)をご覧ください。


  それにしても、2001年当時は、ホントに、のんびりしていました。
サーバーが止まっても、支障が出ないので、翌日に復旧すれば良い感じでした。
  2004年現在だと、1時間でもサーバーを止めると支障が出るため、
3年の差は大きいと感じました。

次章：「携帯3社のコンテンツ作成の物語」を読む
前章：「セキュリティーてんやわんや」を読む
目次：システム奮闘記戻る