3月 30
結局は基本にもどり・・・
サーバーのパーティション切り間違えの顛末気です。
/var以外の場所にログを保存する設定で、かなりの消費容量を
抑えることが出来ましたが、/varはyumやmysqlのデータベース置き場に使います。
結局1.5GBじゃ心もとないので、当初の予定通り15GBに切りなおすことに。
とりあえず稼動しているユーザーを、ユーザーの少ないサーバーに移動させ、
全く新たにインストールしなおすことにしました。
同等のスペックで、ほぼ同じ構成のサーバーに余裕があったのがラッキーです♪
まずはイーサーネットに振ってあるIPアドレスとドメインを1個だけを残し、
残りは移動先に割り振ります。
移動するユーザーを作成し、後はrsync(ssh)でファイルをバリバリ移動。
単なる移動や上書きではだめなものは、リモートマシーン上のターミナルソフトで
2台にログインして並べ、必要分だけコピってしまいます。
（ftpchrootやpostfixのvirtual関連など。）
移動先のサーバーは、元々DNSのセカンダリとして稼動しているので、名前解決には
問題は起きそうにありませんし。
全てが移動し終わった後で、2台のネットワークを再起動。
これで残したもの以外はめでたく稼動する運びとなりました。
老朽化したサーバーを更新するのなら、/etc/passwdやgroupをコピって、
ユーザー領域である/homeごと移動させますが、ユーザーごとの作業になるので、
面倒かと思いましたが、約100人のユーザー移動は、結構あっけなく終了しました。
移動したユーザーを戻すのかって？
最初はそのつもりでしたが、面倒くさがり屋本領発揮！！
マシーンのスペックも同程度なので、そのままにしておきます。
（E-2200+４GB+500GBｘ２RAID1)
で、移動し終わったサーバーにパーティションを切りなおして新たにインスコ。
今度は間違えないように/varは15GB。他のパティションも何度も確認！(笑
現在Webとメールサーバーは稼動しております。
ところでVirusScanのClamav。yumでインストールすると失敗するのは私目だけ？
本家からソースを貰ってコンパイルすると、一発で動くのですが。
最近パッケージ管理に慣れきっているので、ログ関係やらアップデート、
自動スキャン設定のスクリプトを作成したり、依存関係を確認したりするのが
結構億劫な怠け者に成り下がっています。
注意することは、Amavisd-newをyumでインストールしたとき、依存性で
くっついてくるclamd.amavisdはchkconfigでオフっておいても、アップデートの関係で
アンインストールしてはいけないとのこと。はい、仰せの通りに。。。
LAMPで稼動しているCMS。
PHP5.3になってから、エラーを吐きまくってます。
noticeも山ほどでます。
多くはdate_default_timezone_set関数に関わるもので、
date_default_timezone_set(‘Asia/Tokyo’);の1行を記述してやるか、
/etc/php.iniでdate.timezone = Asia/Tokyo のようにします。
Assigning the return value of new by reference is deprecatedもい～ぱい・・・
これは、new演算子の戻り値を参照で受け取ろうとするとき、以前は【=&new】
だったけど、【=】自体が参照渡しとなったので、オブジェクトを【=&】で
受取るのは駄目よって警告です。newの前の【&】をぶち消してめでたく終了。
他にもeregを【preg_match】やら、場合によっては【mb_ereg】に書き換えたり、
もうテンヤワンヤで、何とかエラー・告知が止まりました。
phpのバージョンがあがる度に、何らかの不具合は発生しますが、ver5.3は
結構でかい修正が必要でありました。
ユーザーの中にはphpの知識が乏しくても、フリーで落ちているphpを使って、
サイト作成に流用している場合も多いのですが、ある日突然エラー吐きまくりで
目を白黒させる？！
新バージョンに対応したものがすぐ出てくればよいのですが、フリーなものに
大きな期待はできないでしょうね。
3月 17
残務整理＠超暇＝眠い単年度事業の現在の仕事は、実質的に終了しました。
微々たる残務整理および緊急事態等に備え、事務所にはいなくてはならないのですが、
9月くらいの狂気の沙汰から比較すると、暇すぎなんですよねぇ。
愚痴るのは贅沢なのかもしれませんが、眠くなるのをこらえるって苦痛！
本当は出て歩けば他の仕事のことならやることいっぱいあるけど、
契約上お金もらっているので、そうはいかないんですよね。
てな訳で、まずはブログにポストしておきましょ。
後はネットサーフィンして、リモートでサーバーのメンテ。。。
こんなことしていていいのでしょうか。（笑笑
最近組んだサーバーでパーティションの設定ミスを発見。
Cronで実行されるdfコマンドの結果を、LogWatchからのメールで見ると、
/varの使用量が異常に高い。
/varはほとんどのLogやデータベース・キャッシュなどが使用するため、
使用容量が肥大化してゆく領域ではありますが、それを見越して15GBほど
領域を確保していたはずですが、立ち上げて間もないのに50%以上使っている。。。？？
で、よく見るとお決まりのドジ丸出しです。
15GBで切ったはずのパーティションは、実は1.5GBしか切っていなかった。。。（^^;;
このまま放っておけば100%越えは間違いなく、そうなれば原因は異なりますが、
他のサーバーで起きた現象が、まもなく起きてしまいます。
アプリの中には起動時に、/varにpidやsockファイルを書き込むものもあるので、
容量がパンパンになると、書き込めないぞぉ！エラーで起動しなくなっちゃいます。
対処の正攻法は、パーティションを切りなおすことでしょう。
他には/varを/var2などとして退避しておき、HDDを追加して、
/varとしてマウントし、退避したファイルをコピーする。。。
でも、稼動してるんですよね、もぅ。。。
おいそれと止めるわけにもいきませぬ。
一時的不具合回避策として、/varでなくてもよいものは、他のパーティションに
書き込みされるように設定を見直すことにしました。
まずは/var/log下にあるログ群。
syslogで一番容量を食うのは、messagesですね。設定ファイルでは
*.info;mail.none;news.none;authpriv.none;cron.none /var/log/messages
mail～cronまではnoneになっているので、各種インフォメーションのみがログとして
記術されるのですが、数十万行とか半端じゃない。(^^;;
/var/log/messagesのパスを変えれば、他のパーティションに作成されます。
logはlogrotateにより、定期的に新しいファイルが作成され、古いものは
OLDとか、日付が付与されたファイル名として一定期間保存され、最後は
消え行く運命というシステムなので、当然logrotateも新しいパスに書き換えます。
設定ファイルは/etc/logrotate.d/以下にあります。
ところでsyslogの設定ファイル。。。以前は/etc/syslog.confだったのですが、
最近は/etc/rsyslog.confなのですねぇ。結構探しちゃいました。
まだまだ勉強不足ですな。。。^^;;
このように/var/以下のlog以外のcacheやlibも徐々に他のパーティションに
引越し作業を行い、なんとか使用容量を40%以下に抑えこんでます。
なお引っ越し先のパーティションは余裕があることが条件です。
/引越し先/var/logというディレクトリを置き、/var/logからsymbolic linkで
対応することも考えられますが、どこかでそれは駄目よって言う記述があった
ような気がするので、今のところ試してはいません。
最終的にはパーティションを切りなおした新しいサーバーをでっちあげて、
データをバリバリ移動させるしかないでしょう。
3月 7
模様替えメンテナンス面を考慮して、今まで２か所にあったデスクのPCを
１か所にまとめました。
今までサブデスクとしてサーバーメンテ用に使っていましたが、
サーバーとデスクトップマシーンをすべて３段の棚に並べ、
液晶モニタ３台をデスクに置いて、いろいろな組み合わせで
切り替えながら使えるようにしました。
３台あるプリンタのうちのレザープリンタ１台も横に置きました。
１組のキーボードとマウスで操作できるのは、サーバー２台と
Win7・WinXP・Ubuntuマシーンの３台までですが、後のマシーンは
滅多に使用しないので、使うときだけUSBキーボード＆マウスを
利用することにします。
集約したためPCが無くなったデスクには、とりあえずノーパソ君を
１台置いておきます。
WinVistaとUbuntuのデュアルブートで、さらにVertualマシーンを組み込んで、
Ubuntu内でWindowsも使えるようになってます。
一応、Core2DuoにメモリMAXですから、普段の作業にストレスは感じないでしょう。
持って歩くノーパソ君は、それ以上のスペックのWin7マシーンがあるので、
不便はありません。
ところで、このサイトで使用しているWordPressですが、 2.9.2 が利用可能です !
アップデートしてください。とうるさいので、アップデートしてから寝ることにします。
3月 3
もう３月・・・3か月以上書いてませんね。ココ＾＾；；
今日１台のサーバーでMYSQLがらみのCMSが全滅という現象が起きました。
メールもおかしい。送信すると452 4.3.1 insufficient system storageのエラーが。
はたと思い付きdfコマンドを叩くと、やはり/varが100%でした。
十分すぎるくらいの容量でパーティションを切ってあるはずなのですが、
中をのぞくと、アクセスログの容量が膨らんでパンパン状態。
昨日のサーバーからのLogwatch （メール）によると、/varは27%の使用量。
ローテートする間に、というか1日で残りを使いきった？
こいつは予想をはるかに超える、すごい攻撃を受けましたね。
とりあえず古いlogを削除して領域を確保することで不具合を回避。
さて、ない頭しぼって対策を考えましょ。
で、logと一緒に/var内にあるmysqlのデータも、アクセスできなくなったため、
MYSQLがらみのCMSも全滅と相成ってしまったというわけです。
メール自体は/homeの各ユーザーに置かれるので、問題なくリレーしますが、
送信はできなかったでしょうねぇ。＾＾；；；；；
ネットワークがパンクしなかったのが救いです。
ちなみにエラーログも結構なもんだったなぁ。
粗方はリンクが外された（必要のない？）ページをそのままサーバーに
あげてあり、タグで指定したイメージファイルなどが削除されているので、
ないぞぉ！って騒いでます。
不必要なページにもそれだけアクセスがあるってことです。
いらないページはさっさと削除しないとね。
ユーザー数が多いといろんな方がいるものです。