サーバ管理メモ。
2005/09/07 INNレポートにあるエラーの修正を試みる

毎日飛んでくるDaily reportを見ていると、結構な数の記事がRejectされている。
最も多いのが「Posted in the future」(未来に投稿された記事)というやつ。
どうやら、投稿者のPCか、投稿を受け付けたサーバの時計がずれているらしい。

受け付けてしまうサーバもどうかと思うが、INNの判定基準が厳しすぎるのかもしれない。
こいつの許容範囲を広げるためには、INNをコンパイルする前にヘッダをいじらなければならないようだ。

具体的には「include/acconfig.h」の「DATE_FUZZ」という許容範囲を秒数で定義している定数を変更する。
デフォルトは「24L*60L*60L」、つまり1日のようだ。
24時間のずれを許しててもあんなにエラーが出るのか・・・。

というわけで、エラーになった記事の大半は2日以内らしいので、2日まで許す設定に変えてみる。
変更したら、再コンパイルして入れなおし。


2004/03/09 INN mailpostの使い方

INNに標準で付属するMail to Newsコンバータ「mailopost」。
メーリングリストとかcronから飛んでくる定期ログなんかをニュース記事に変換するのに使える。
こいつで、延々たまり続けるsuckのログを、変換して送り込んでしまおうと考えた。
先に「local.sucklog」というグループを作った上で /etc/aliasesにmailpost用のエントリ

sucklog: "| /usr/local/news/bin/mailpost local.sucklog"

を加えて、試しにメール送信してみる。

# echo test | mail -s "suck log" sucklog

すると、

inews failed: /usr/local/news/bin/inews: Permission denied

というエラーメールが届いた。googleで調べてみると、最近のINNでは、inewsのパーミッションが異なるとのこと。
インストール時に「--enable-setid-inews」をつけるか、インストール後に「555」にせよと言うことらしい。
ということでパーミッションを変更して、再度テストしてみると、今度は

inews failed: inews: warning: What server? inews: article will be spooled inews: cannot create spool file: Permission denied

というエラーメールが届いた。「What server?」って?再度googleで調べてみると、inn.confの「server:」をちゃんと記述しないと動かないという記事を発見。
確認してみると、確かに「server:」行はコメントアウトされたままだった。
コメントアウトを外して

server: localhost

にしてから、再々テスト。
すると、今度は正常に投稿された。

2003/07/15 新品HDDに不良セクタ

だいぶ間が空いたがようやくストレージ関係が落ち着いてきたところで、まとめておくとしよう。
現在は、各RAID装置の共有をやめて、単体で使用している。
dsは、データ用ストレージとして120GB x 7のRAIDを占有。これをSambaで共有した。
以前、nsとdsで共有していた80GB x 3のRAIDは、160GB x 3のケースとして使用し、余ったIFT-3102UAでRAID5とした。
こいつはメインマシンのデータディスクとして使用。

さて、色々なデータが日々ため込まれていく現状では、RAIDですべてまかなうにも限界がある。
もともと購入した160GBは4本で、そのうち3本はRAIDとして使用しているため、1本余っていた。
(というか、ホントは4本でRAIDを組む予定だったのだが、PCIタイプのカードは全部駄目だったので、3102になった関係上、ベイ数が足りなくなったから。)
とりあえず、この160GBをメインマシンに単体で内蔵し、消えてもいいデータをまとめていたのだが、毎度のごとくこいつもいっぱいになってきた。 しかも、ほぼ同時期に160GB x 3の方も、逼迫しつつある・・・。
そんな折、オークションでIFT-2101U2を発見。こいつが有れば、外付けコントローラが要らなくなるではないか。
そして気がついたら落札していた。

んで、早速IFT-3102UAを取り外して、IFT-2101U2を接続。
ファームウェアのバージョンがIFT-3102UAの2.23から2.12にグレードダウンするので、既存のRAID構成を認識できるかどうか不安であったが、問題もなく正常に認識した。
(ここで正常に認識できないと、データをどこかに待避してRAIDを再度構成し直す必要がある)
ついでに、内蔵ディスクの容量アップも目論んで、200GBのHDD「6Y200P0」を買ってきた。
こいつに160GBのデータを移してやって、空いた160GBをRAIDにExpansionで追加しようと言う計画だ。
しかし。
このディスクはハズレだった。
新品のくせに、当初から不良セクタがあるわあるわ。しかも、ECCエラーやらCRCエラーやらを大量に吐き出し、とうとう認識しなくなってしまった。
こんなもん出荷しているようで、大丈夫なのか?Maxtorよ。
とりあえず、ディスクを交換してこなくてはならないので、それが終わってからまた追記することにしよう。


2003/02/10 サーバのブートディスク入れ替え完了

ACARDからまったく返事がないので、仕方なくExpress 200 + 7720UWの作戦はあきらめる。
とりあえずブートディスクを入れ替えて、消費電力を低減させるほうのアプローチで進めることにして、オークションを徘徊・・・。
3wareの6200が比較的安かったので、これをゲット。

予定通りDJSA-210を2台使用して、ミラーリングする。
前と同じ方法で入れ替えて作業は完了。

あとは来月あたりの予算で少し大きめのディスクを買って、ミラーリングをもう1セット作って内蔵すれば完了といったところか。
そのときはnsとdsの電源ユニットとRAIDカードを交換しなくては。
いくら低消費電力とはいえ、Micro ATXの電源ではそれだけのディスクを回すのはやや不安が残る。
nsに入っている電源はたしか300W位のやつが入っていたので、dsのと入れ替えればちょうどよいはず。
RAIDカードも、nsの方を先に組んだので、6410を使ってしまっている。dsのほうの6200と入れ替えれば、無駄がない。


2003/02/06 サーバのディスク入れ替えを目論む(実行編・3 Express 200にハマる)
計画の段階では、両方ともサーバのブートディスクをEscaladeにする予定だったのだが、考えてみたらフルサイズPCIのEscalade 6400がMicroATXのケースに入るわけがない。
あと、うちにあるMicroATXに入りそうなRAIDカードといったらAMI Express 200しかないではないか。

仕方がないので、2.5HDDを7720UWでSCSI変換して、Express 200に接続するとしよう。

・・・ハマッた。
Infortrendのコントローラでは全く問題なかったSCSI変換ブリッジが、Express 200ではまともに動かない。
Adaptecに接続すると問題ないので、Express 200と相性(?)が悪いようだ。
かならずSpinning upのところで止まるので、Express 200のSTART UNITの送り方に問題があるか、あるいは7720UWがSTART UNITの処理をミスってるか、ということになる。 とりあえず現象をACARDにメールして、反応を待つ・・・。
2003/02/06 サーバのディスク入れ替えを目論む(実行編・2 nsのブートディスクを入れ替える)

ns.artin.nuのほうは、ブートディスクの入れ替えを完了。
入れ替え方は簡単。
1.新しいディスクの領域を切る

sysinstall実施前

Filesystem    Mounted on
/dev/da0s1a   /
/dev/da00s1f  /database
/dev/da0s1d   /data
/dev/da0s1e   /data/www
/dev/da0s1g   /tmp
/dev/da0s1h   /var
「/stand/sysinstall」で、ディスクを切ってnewfs。fdiskで領域を切るときは、最初に実際のマウントポイントとサイズを決めて、割当を終えてからマウントポイントを変更するのが吉。
気をつけなければいけないのは、マウントポイントを実際にマウントする予定の状態で、領域を切ること。そうしないと、「/」の領域が「s1a」にならない。
sysinstallのfdisk(サイズの決定)
twed0s1a  /                1536MB 
twed0s1e  /database        512MB
twed0s1f  /data/www        512MB 
twed0s1b  swap             512MB SWAP
twed0s1g  /tmp             64MB 
twed0s1h  /var             1024MB 
twed0s1d  /data            33986MB 
かといって、このまま「w」でnewfsしないこと。newfsが完了した段階で、sysinstallが自動的にマウントしてしまい、sysinstallを抜けるとすっからかんの「/」になってしまう。(元の「/」データが消えたわけではないのでリブートすれば直るが)
そこで、サイズが決まってから、もう一度「m」でマウントポイントだけ変更する。
sysinstallのfdisk(マウントポイントの変更)
twed0s1a  /raid/                1536MB 
twed0s1e  /raid/database        512MB
twed0s1f  /raid/data/www        512MB 
twed0s1b  swap                  512MB SWAP
twed0s1g  /raid/tmp             64MB 
twed0s1h  /raid/var             1024MB 
twed0s1d  /raid/data            33986MB 
これで「w」すれば、newfsが始まって、終わったあとで自動的にマウントされる。
Filesystem    Mounted on
/dev/da0s1a   /
/dev/da0s1f  /database
/dev/da0s1d   /data
/dev/da0s1e   /data/www
/dev/da0s1g   /tmp
/dev/da0s1h   /var
/dev/twed0s1a /raid/
/dev/twed0s1f /raid/database
/dev/twed0s1d /raid/data
/dev/twed0s1e /raid/data/www
/dev/twed0s1g /raid/tmp
/dev/twed0s1h /raid/var

2.データをコピーする

無事マウントできていることが確認できたら、シングルユーザモードに落ちて、データをコピーする。

新しく確保した領域にカレントディレクトリを移し、対応するディスク領域からデータをダンプしてリストア。

cd /database
dump 0f - /dev/da0s1f | restore xf -

同じ事を各領域について繰り返せばいい。
最後に、新しいルートのfstabを書き換えて、作業は終了。

2003/02/05 サーバのディスク入れ替えを目論む(実行編・1 Escaladeにハマる)

とりあえずns.artin.nuのブートディスクを入れ替える。
購入してきたのはIBMの2.5inch HDD「IC25N040ATCS04」(40GB)x2。
それからM/Bを1枚。AOPEN製のMicroATX M/B「MX36LE-UN」。VIAチップセットな上にOnboard LANがカニなので、本来なら買わないところなのだが、 使いたいCPUが低消費電力の雄「VIA C3」なので、とりあえずVIAのを買っておかねばなるまい。同じくAOPENのMX3S-Tも有るんだが、こいつはC3に対応しているとか言いながら起動すらしなかったので、使用不可。

で、購入してきたMBを早速ケースに取り付け、Escaladeを組み込む・・・。が、EscaladeのBIOSが起動しない。MX3S-Tを引っぱり出してきて載っけてみると、正常に動くことからどうやらチップセットかM/Bと相性が悪いらしい。
購入してきたM/BのBIOSは最新だったので、とりあえず起動できるMX3S-Tにさして、EscaladeのファームとBIOSをあげてみる。
無事、ファームをあげ終わって、MX36LE-UNに戻してみると、あっさり起動。こういうときやはりIntelチップセットって業界標準なんだと実感。業界標準以外を使うと、こういうリスクを負うわけで。

とりあえずRAID 1に設定、イニシャライズを仕掛けていったん終了。


2003/02/04 サーバのディスク入れ替えを目論む(計画編)

ファイルサーバにキャプチャした動画がたまり始めたせいか、ディスク容量が足りなくなってきた。
とりあえずニューススプールの保存期間を短くすることで対処するも、いま部屋にあるビデオをすべてキャプチャしたらこんなもんじゃ足りない。
スプール期間も、alt.binaries.*は短くできるが、alt.freedom.*はneverになっている関係上、増えることはあっても減ることがない。最近活気がないので、以前ほどの勢いはないものの、それなりの容量。

そこで、ディスクの増設を目論む。
かといって、単純にディスクを増やすのは難しい。

まず、設置スペースの問題。
メインマシンと共有している外付けRAIDは8ベイのSCSIケースだが、RAIDコントローラと7台のディスクですでにいっぱい。
新規にケースを増設するにも、置くスペースがない。
RAIDコントローラも、外付けをまた買うには時間がかかるし、内蔵のPCIタイプはスロットの空きがないので刺せない。

次に消費電力の問題。
親に電気代を払わせているという政治的・経済的(?)都合と、接続UPSの容量という技術的都合の観点から、消費電力は極力抑えたい。

となると、現在有るディスクのリプレースになるわけだが、これがまた面倒くさい。
既存のデータを移行する作業が必要になるから、その時点では両方が同時に使えなくてはならない。
結局、接続の問題があるので、これも難しい。
さて、どうしたものか。

まずは現在の構成図。


この状態での消費電力は、データシート上の数値で行くと
コントローラ構成ディスク合計消費電力
左側のRAID
各サーバのブートディスク
IFT-3102UA
31VA
Seagate ST380020A x 3
7.5VA x 3 = 22.5VA
53.5VA
右側のRAID
データディスク
IFT-3102UA
31VA
Maxtor 4G120J6 x 7
5.17VA x 7 = 36.19VA
67.19VA
ということになる。

まずは、設置スペースの確保の観点から行くと、左側のRAIDを廃止して、各サーバのディスクをそれぞれ内蔵のものに切り替えるのが良さそうだ。
内蔵のディスクのミラーリングは、SCSIにでもしたいところだが、SCSIにすると消費電力が跳ね上がるので却下。RAIDカードが余っているので使いたいんだが、残念。
次に、各サーバに内蔵するディスクの新しい構成。
消費電力の観点から、ノートPC用のディスクがよいのではないかと考える。
IBMあたりの40GBなら1発あたりの消費電力は2.3VAと、3台使ってもSeagate1発分でお釣りが来る計算だ。
MRTGでここ数日のディスクの使用量を監視してみたが、ns.artin.nuのニュースフィード時のデータ量は、ピークで全容量の5%。つまり140GBのうち7GBほどしか使用されていない。
ブートディスク分や、dsトラブル時の予備スプールを含めても40GBなら十分まかなえそうだ。

ds.artin.nuのほうは、データディスクには別のRAIDが有り、ブートディスク分しか必要ない。
これなら10GBもあれば足りるだろうと言うことで、以前購入したDJSA-210 x 2を流用することにする。
このディスク、オークションで購入したミラーリングユニットで使用するつもりで購入したのだが、このユニット自体の使い勝手が悪く、実稼働経験がほとんどない。
今頃になって使い道が出てくるとは思わなかったが・・・。

各サーバのミラーリングについては、3wareのEscaladeが2枚ばかし余っているので、久々に登板を願うことにする。
監視機能が充実しているし、なによりまともなエラー処理がされているハードウェアRAIDだ。
秋葉原で格安の値が付いているPromiseやらHighpointやらのカードは、ディスクが完全に故障しないとエラーにならなかったり、不良セクタに当たってフリーズしたりと、まったく使い物にならない。

さて、この段階での構成図がこれ。

消費電力は
コントローラ構成ディスク合計消費電力
ns.artin.nuの内蔵RAID3ware 3W-6410
7.5VA
IBM 40GN 40GB
2.3VA x 2 = 4.6VA
12.1VA
ds.artin.nuの内蔵RAID3ware 3W-6400
7.5VA
IBM 20GN 10GB
2.3VA x 2 = 4.6VA
12.1VA
となり、ブート用RAIDの消費電力は半減できる。

さて、肝心のデータ領域の増設だが、今までブートディスクになっていたSCSI RAIDのケースが空いたので、コントローラをはずして160GBのディスクを3つ入れてRAID5にするのがよいかもしれない。
現在は、右側のRAIDのうち、240GBを割り当てているから、160GB x 3でRAID 5を組めば320GBになって、80GBの増設になる。本来なら200GBでも組み込んでやりたいところだが、価格が圧倒的に高いので、断念。

ここで問題が発覚。
現在出回っている160GBのモデルは、現在使用している120GBに比べて、消費電力が倍であることが判明。(4G120J6が5.17VAなのに対し、4R160L0が10.18VA。7200回転モデルの6Y160L0に至っては12.23VA)。
これだと、まえのブートディスクの80GBx3をそのまま流用して、データディスクにした方が消費電力的によいと言うことになる。
できれば1つのボリュームとして使用したかったので、あえて160GBの使用を検討したのだが、この状況では無理っぽい。予算にも限りがあるし、今回は妥協するか・・・。


2002/11/30 PostgreSQL 7.3

PostgreSQL 7.3がリリースされた。
7.1以来あげてなかったので、アップデートすることにする。

pg_dumpallですべてのデータベースのデータを取りだしたあと、既存verのディレクトリをリネームしてからインストールする。

インストール自体は非常に簡単。
最近のバージョンは、gmakeを指定しなくても、makeで勝手にgmakeを探してくるようになったらしい。
しかしgmakeを入れておく必要があることには変わりない。

データのリストアでハマる。
どうやらPHPから書いていたデータベースのデータが、SJISとEUC混在になってしまっていたらしい。
initdbの際、EUC_JPを指定していたので、SJISのデータを見つけると、不正なコードとしてはじいてしまう。

結局、ダンプデータのなかに、

SET CLIENT_ENCODING to 'SJIS';
と記述することで、PostgreSQLにEUC変換してもらうことにした。

忘れないうちに、今後はデータをEUCで確実に保存するようPHPコードを直しておく。
というか、同じくCLIENT_ENCODINGをEUCにするようSQLを追加しただけなんだが。