第６１日目：【障害復旧対応】花子救出大作戦 with Mumumu
|
どうも、('A`)です。
もうね、何というか・・・先週末は色んな事が起きまして、心も体も休まりません。
先週土曜日未明に発生したPIEのネットワーク障害ですが、David社長やRobertなど
PIEのネットワーク担当者の頑張りで、現在は小康状態になっています。
が、公式発表はもうちょっと時間がかかる見込みです。。。
最終的に問題解決するにはまだ幾つか対応が必要で、早ければ火曜日未明から
行われる予定です。
今回は特定のIP(しかも、本来はどこにも使用されていない未使用のIPアドレス：
一般にBogonと呼ばれています)を使って送信元を偽装し大量(数百メガ)のデータを
一度に送信してくる、という不正なアクセスが先週土曜日未明に発生しました。
その為にPIEのネットワークが麻痺状態になりました。
David社長がルータやスイッチの設定で該当のIPからのアクセスを遮断する様に
修正をおこなったのですが、次々と違うIPで同じ様なアクセスがひっきりなしに来ます。
なので、暫定的な対応ですがBogonフィルタ対策を実施し、Bogonアドレスからの
アクセスが来ても、すぐに遮断される様になりました。
ただ、現在のPIEのネットワークのスピードは通常時よりも遅くなっています。。。
アクセスが普段多いサーバを利用されている人は「なんか重い」「繋がりにくい」と
感じるかもしれません。
この状況は現在のスイッチの設定とBogonフィルタ部分との最終調整をおこなう事で
解決される見通しです。
不便に感じる人もいらっしゃるかもしれませんが、正常化までもう少しお待ち下さい。
そして今回はこの障害の前日から発生していたbanana3000(花子)サーバのダウンと
復旧に関して、ご報告したいと思います。
悪い事は得てして重なるものですが、今回復旧作業の過程で新たな事実が発覚したり、
むむむさんのお力をお借りして幾つかサーバ設定を変更しながら解決する、という事も
あり、他の人たちにも参考にしていただければ、と思いまして。。。
(久しぶりにむむむさんとの「二人羽織」でした。)
それでは、「花子救出大作戦」の始まりですー
[第一節 -花子、七転八倒-]
banana3000(花子)が倒れたのは金曜日(6月20日)の朝でした。
緊急連絡フォームからお知らせを受けて、遠隔リブートをおこなったのですが、
戻ってきません。なので、PIEの技術スタッフにお願いしてシングルユーザモードで
起動してもらい、手動でfsckを実行してもらう様お願いしました。
花子のfsckは通常3〜4時間かかるので、その後、fsckが終わっていたら再起動して
もらう手筈になっていました。。。
んで、金曜日の昼過ぎに「fsckが終わったので、これから再起動するよ」という
連絡をもらって、待機していました。
でも、いつまで経ってもページが表示されません。「('A`)おかしいなあ・・・」と
思ってサーバの中に入ってみると・・・/homeがマウントされていません。
でもfsckプロセスは動いていないので、とりあえすApacheを一時的に停止し、
/homeをマウントしてからApacheを再起動しました。
再起動後15分くらい経ったでしょうか、突然花子に繋がらなくなりました。
また、ダウンしたようです。
何か/homeが正常に動作しない状況に陥っているのかもしれないと思い、
再びPIEの技術スタッフに手動でのfsckをお願いしました。
今度は fstab を参照しての方式ではなく、各パーティションを明示的に指定して
実行してもらう様にお願いしました。
んで、夕方が過ぎ、夜になっても連絡がないので、流石に「('A`)大丈夫か？」と
心配になり現地スタッフに聞いてみると・・・不思議な現象が起きていました。
手動でfsckを実行し、その後再起動を行うと、なぜかApacheが立ち上がりません。
スタッフがもう一度電源ボタンを押してサーバを再起動すると、今度は「手動で
fsckを実行して下さい」のメッセージが出て、途中で止まります。
「何度か繰り返したけど、同じ事の繰り返しになる」と困惑していました。
('A`)にとっても初めての経験です。
これは花子が壊れたのかもしれないと思い、Brian( ^ω^)に診てもらおうと
お願いしたら、、、ネットワークの大障害が発生して、上へ下への大騒ぎ・・・
翌日の土曜日(6月21日) 9:40頃、ネットワーク障害も小康状態になり、改めて
Brian( ^ω^)にコンソール上に何かメッセージが出ていないか確認をお願いして
いた処、、、むむむさん(以下、"む"で省略：顔文字無いんだよなあ・・・)が
オンラインになりました。
"む"：「おはようございます。banana3000の状況は、どんな感じですか？」
('A`)：「えーと、banana3000ですが、手動で/homeパーティションをfsckして
リブートすると、なぜかもう一度fsckしろ、と言われて、、、
現在原因を調べているところです。。。」
"む"：「fsck でちゃんと clean になったのに、そう言われるのですか？」
('A`)：「もしかすると 何らかの理由で/homeパーティションのfsck自体が
正常終了していない可能性があります。
今Brianにコンソール上で何かエラーのメッセージが表示されていないか
確認してもらっているところです。」
"む"：「もし可能なら、KVM(リモートコンソール)をセットアップしてもらって、
確認してみるとよいです。」
('A`)：「えーと、、、花子はKVMが利用できない環境に置かれています。。。
質問なのですが、fsckを実行中、何らかの理由でfsckの処理そのものが
続行不能になるようなケースってあるものなのでしょうか？
(例えば作業時に必要なメモリとかディスクの領域とかが取れない、とか)」
"む"：「fsckは、例えばハードウェア的にディスクが壊れたりすれば、もちろん
修復はできない(続行不能)ですね。
そういうこともありえますが、通常のオペレーションなら、ディスク領域を
そこまで使ってしまうことはありえないです。
で、メモリは仮想記憶使うので、よほどの事が無い限り普通は大丈夫かと。」
('A`)：「そうなのか、、、うーん。。。」
"む"：「もし手動でのfsckがうまくいっていないなら、一度 /etc/fstab を編集し、
起動時に/homeをマウントしない形に修正して再起動しましょう。
そうすれば、SSHでログインできますし、リモートでサーバの状況が把握
できますから。」
|
やがて、、、Brian( ^ω^)から「('A`)、変なメッセージが出ていた。KVMが使えないから
写真撮って、メールで送るね。」と返事がきました。送られてきた写真を見ると、、、
fsck_ufs: cannot alloc 11776 bytes for inoinfoの文字が・・・
何かよく判らないけど、メモリか何かで必要な領域を割り当てられなかったので、
fsckの処理ができない、と言っているなあ。。。
このままでは同じ事が繰り返されるので、Brian( ^ω^)に/etc/fstabを修正してもらって、
サーバを立ち上げなおしてもらおう。
('A`)：「えーと、やはりfsck処理で失敗していました。。。
先ほどのメッセージが表示されていました。」
"む"：「ふうむ。ちょっと、調べてみます。。。」
|
こうして花子をなんとかリモートで操作できる様に作業が始まりました。
ちょっと時間がかかるので、その間に('A`)は病院へと向かいました。
もう何もかもボロボロ・・・
[第二節 -呪文炸裂！fsck実行-]
13:00に病院から帰ってくると、banana3000が/homeなしの状態で立ち上がっていました。
"む"：「花子上がったようですね。
ちょっとプロセスを見える様にして頂けると助かります。」
('A`)：「(sysctl security.bsd.see_other_uids=1 実行)
どうでしょう、見えますか？」
"む"：「はい。ではまず状況チェックしましょう。
disklabel -r /dev/da0p1と打ってみて下さい。」
('A`)：「あ、こんな情報でてきました。」
banana3000# gpt show /dev/da0p1
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 12695041914 1 GPT part - FreeBSD UFS/UFS2
12695041948 33
banana3000#
"む"：「うん。中身は、少なくともラベルは無事か。じゃ、あせることはないですね。
では次に、read onlyでmountできるか確認しましょう。」
('A`)：「(mount -r /dev/da0p1 /home実行)
マウントできましたー」
banana3000# df
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ad12s1a 1012974 71426 860512 8% /
devfs 1 1 0 100% /dev
/dev/ad12s1d 2026030 853230 1010718 46% /usr
/dev/ad12s1e 4058062 319166 3414252 9% /var
/dev/md0 89326 8 82172 0% /md
/dev/da0p1 6147826942 2604227980 3051772808 46% /home
banana3000#
"む"：「スーパーブロック(mountのための情報)も無事みたいですね。
なら、怪我は軽いです。少なくともデータのほとんどは無事でしょう。
これで、あせることはないとわかりました。
いったん umount しましょう。」
('A`)：「(umount /home実行)
じゃあ、次は /home を書き込み可能状態にしてマウントですね？」
"む"：「あー、いやいや、fsck しなきゃだめですよ。
深呼吸、深呼吸。まずはじっくり。」
('A`)：「う、、、すー、はー・・・」
"む"：「ではfsckを動かしてみましょう。
fsck_ufs /dev/da0p1」
('A`)：「実行しましたー。プロセス番号は 8897 で動いています。」
"む"：「じゃ、鼻薬をかがせましょう。
renice -20 8897
これでfsckのプロセスはちゃんと最大優先度になります。
あと変なfindとか上がるといまいちなので、cronを切っておきましょう」
('A`)：「(cd /etc/rc.d
sh cron stop 実行)」
|
これで順調に動けばよかったのですが、、、1時間後に突然fsckのプロセスが
消えてしまいました。二人ともちょっとびっくり。
"む"：「お、fsck いなくなった？」
('A`)：「あ、fsckが・・・コマンド投入していた画面がフリーズしている。。。
で、プロセスは消えてなくなりました・・・orz」
"む"：「あらら、、、。ちょっと、調べてみましょう。mount /dev/da0p1 /home は
できますか？
WARNING: /home was not properly dismounted と言われるかどうかが
ここではポイントです。」
('A`)：「弾かれました。こんなメッセージが表示されます。」
mount: /dev/da0p1: Operation not permitted
"む"：「ふむ。。。mount -r /dev/da0p1 /home はできるんですよね？」
('A`)：「はい。コマンドを実行したら /home がちゃんと表示されます。」
/dev/da0p1 6147826942 2604227980 3051772808 46% /home
"む"：「では、umount してください。fsck に何か起きたか、あるいは一定時間
idle だと、ターミナルソフトが切ってしまうような仕様なのか、、、」
('A`)：「/home をいったんアンマウントしました。」
"む"：「ちゃんと syslog(dmesg) に出てますね。fsck は完走していません。
WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck
とにかく fsck を完走させなけれダメなので、再度、fsck_ufs ですね。
ちょっと乱暴ですが、大きく壊れていないはずなので、以下の様に
やってみてください。
cd /root
fsck_ufs -y /dev/da0p1 >& fsck.log & 」
('A`)：「(なるほど・・・バックグラウンドに動かして、ログ情報を記録するのか。)」
|
で、この時の会話は午後２時、、、その40分後にまたfsckのプロセスが消えていました。
"む"：「fsckいなくなりましたね。ログには何と入っていますか？」
('A`)：「あー、午前中にお伝えしたメッセージがはいっています。」
banana3000# cat fsck.log
fsck_ufs: cannot alloc 11776 bytes for inoinfo
** /dev/da0p1
** Last Mounted on /home
** Phase 1 - Check Blocks and Sizes
2129443632 DUP I=530043346
2129443633 DUP I=530043346
(途中 省略)
2122152119 DUP I=530307453
INCORRECT BLOCK COUNT I=578424178 (4 should be 0)
CORRECT? yes
banana3000#
"む"：「なるほど、DUP があるんですね。で、テーブルがあふれたんでしょう。
何らかの。。。ちと、対策考えて見ます。」
('A`)：「(テーブルのあふれ・・・？)」
"む"：「info = calloc((unsigned)inosused, sizeof(struct inostat));
if (info == NULL)
errx(EEXIT, "cannot alloc %u bytes for inoinfo",
(unsigned)(sizeof(struct inostat) * inosused));
なるほど、2箇所ありますが、いずれもcalloc が失敗しているのか。」
('A`)：「(亜空間に飛ばされてしまった・・・)」
"む"：「/usr/src/sbin/fsck_ffs/pass1.c
void *
calloc(size_t number, size_t size);
だから、mallocできてないってことね。」
('A`)：「(引き続き亜空間に滞在中・・・)」
"む"：「このOS、確か32bit版ですよね？」
('A`)：「(やっと帰ってこれた・・・) はい、そうです。 6.2R i386です。」
"む"：「/boot/loader.conf をいじって、リブートが必要か・・・
ちょっとこわいけど、やってみましょ。」
('A`)：「(えっ・・・ひょっとして"禁術"？)」
"む"：「/boot/loader.conf の最後に、以下を足してください。」
kern.maxdsiz="2G"
('A`)：「え、、、えーと、これって最大メモリ使用量を指定するのですか？
ちなみにbanana3000は2GBのメモリしか搭載されていません。」
"む"：「＊仮想記憶＊だから、大丈夫ですよ。
この値、デフォルトは確か512Mです。
でかいプロセスになると、おっこちちゃうわけです。
まぁ、リミッターってことですね。」
('A`)：「loader.conf 修正しました。あと /etc/fstab は /homeをマウントしない
状態のままにしています。」
"む"：「では、花子を再起動しましょう。
ちなみに2Gより大きな値は、32bitでは＊絶対＊指定してはいけません。」
('A`)：「(ブルルッ・・・)花子、リブートしましたっ！」
"む"：「了解。この設定は、花子に限り、残しておくとよいでしょう。
64bitだったら、こんな制限ないんですけどね、、、。
最近64bitにラブラブな私。」
('A`)：「(64bitには痛い目しかあっていない私・・・
A-Tigerのカーネル再構築でつまづいてもいるし。)
あ、花子戻ってきました。」
"む"：「成功ですね。
%limit
cputime unlimited
filesize unlimited
datasize 2097152 kbytes
stacksize 65536 kbytes
coredumpsize unlimited
memoryuse unlimited
vmemoryuse unlimited
descriptors 14781
memorylocked unlimited
maxproc 7390
sbsize unlimited
この datasize 2097152 kbytes という値を他のT-Bananaサーバと
比べてみて下さい。」
('A`)：「本当だ。他のサーバは512Mに設定されている・・・」
datasize 524288 kbytes
"む"：「じゃ、もう一度fsckを始めましょうか。
まず、cronを切る。
cd /etc/rc.d
sh cron stop
次に私の方でも結果が見れる様にする為、/tmpに移動してから
バックグラウンドでfsckを実行。
cd /tmp
fsck_ufs -y /dev/da0p1 >& fsck.log &
最後に優先度を上げる為、fsck_ufs プロセスをrenice -20 してください。」
('A`)：「実行しましたー」
"む"：「了解です。あとは、待ちということで。」
('A`)：「しばらく様子をみます。今まで40分後くらいに終わっちゃっていたので、
まずはそのラインを超えるか見てみます。」
"む"：「お、top でみて、(fsckプロセスの)サイズが 407M ありますね。
ここが 512M 近くなると、死んでいたんじゃないかなと推測。」
('A`)：「あ、そうです。ここが430M位になる処までは気づいていたのですが・・・
そんなからくりだったか、、、、」
"む"：「32bitのOSって、いまとなっては結構足かせが多いんですよね。。。」
|
で、再びfsckが動き出したのが午後3時10分・・・これから4時間近くかかるのかあ
「呪文」を適用してから、fsckは順調に動きました。そして判ったのです。
「デフォルトのkern.maxdsizじゃ、今の花子のデータ量に対してfsckは正常に
実行できない」事を。。。
topコマンドで見ていたら、どんどんプロセスで使用されているデータサイズが
膨らんでいきました。
(最終的にはこの値、610Mまで膨らみました。。。)
"む"：「どうやら、当たりだったのかな？」
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
961 root 1 -8 -20 520M 520M physrd 1 1:20 2.05% fsck_ufs
('A`)：「そうみたいですね。」
|
あー、そうだよなあ・・・花子は今まではスッカスカだったけど、oyster902が
「大破」した時にログをお引っ越しして、今は半分近く(2.4TB)使われているから。
ブロックのテーブルのサイズもケタ違いになっちゃうんだろうなあ。
・・・あれ？だとすると「花子」だけじゃなくて「花代(banana3001)」も同じ問題が
起きちゃうのか・・・？
[補足]
kern.maxdsiz というパラメータはdatasize (プロセスのデータ使用量)の上限となります。
FreeBSD では、1プロセスあたりのメモリサイズはデフォルトは最大512MBとなっていますが、
今回の様に増やすことができます。(なお、カーネル再構築は必要ありません)。
で、この「使用可能なメモリサイズ」は、limit コマンドで確認できます。
ちなみにkern.maxdsiz の設定値が大きすぎると、システム(OS)を起動できなくなる場合が
あります。
(理論上32bit(i386)なら仮想メモリ空間のザイズは4GBあるはずなのですが、
むむむさんが言う様に2GB以上指定するのは避けた方が良いです。)
[第三節 -復活！そして花子の秘められた"謎"-]
午後3時10分から再開したfsckの処理が午後7時15分に終わりました。
バックグラウンド実行時に指定したログファイルにも
***** FILE SYSTEM MARKED CLEAN *****
***** FILE SYSTEM WAS MODIFIED *****
と記録され、fsckが正常終了した事が確認できました。
"む"：「よかった、よかった。ではlost+found ができているかを確認しましょう。」
('A`)：「/home をマウントしました。lost+found、ありますね。」
"む"：「ではそこの下にファイルが入っているか確認できますか？」
('A`)：「データはできています。」
banana3000# ls -l /home/lost+found/
total 8
-rw-r--r-- 1 www users 56 May 29 11:52 #554557670
-rw-r--r-- 1 www users 56 May 29 11:53 #574363433
-rw-r--r-- 1 ch2comi7 users 77 Jun 19 15:13 #605922763
-rw-r--r-- 1 ch2book4 users 77 Jun 19 15:12 #606352767
banana3000#
"む"：「なるほど。comic7 のファイルの一部と、book4 のファイルの一部か。
いずれも77バイトですね。中身、見ていただけますか？
ちなみに www ユーザのほうは、たぶん、おすすめ２ちゃんねるの
ファイルですね。あまり気にしなくてよいかと。」
('A`)：「データの中身はこんな感じですね。」
banana3000# cat /home/lost+found/#605922763
banana3000# cat /home/lost+found/#606352767
banana3000#
"む"：「広告のところですね。あんまり気にしなくておｋです。
ということで、これらのファイルは消しておきましょう。
(次のfsckの時に干渉する可能性があるので)。
まず、umount /home して、改めて mount /home してみてください。」
('A`)：「(えーと、umountして、次に mount して、と・・・)マウントしました。」
|
すると、ちょっとした沈黙の後、むむむさんが「ううっ」と唸りました。
え、何かマウントの仕方がまずかったのかなあ・・・ちょっと心配していると、
次のICQのメッセージで「驚くべき事実」が判ったのです。。。
"む"：「確認しました・・・('A`)さん、softupdate フラグがオフになってますね。
これで遅かったのか、、、。アクセスが。」
('A`)：「(え、え、、、softupdateって、何？)」
"む"：「/dev/da0p1 on /home (ufs, local)
softupdate フラグをオンにしておきましょう。
いったん、umount /home してください。」
('A`)：「う、了解です。。。」
"む"：「softupdate がオフだと、ファイルシステムの破損も起こりやすいです。
いいことは何もないです。。。」
('A`)：「ア、アンマウントしましたー」
"む"：「では、
tunefs -n enable /dev/da0p1
と実行して下さい。」
('A`)：「実行しました。こんなメッセージが出ました。。。」
banana3000# tunefs -n enable /dev/da0p1
tunefs: soft updates set
banana3000#
"む"：「ＯＫです。では改めて /home をマウントして下さい。」
('A`)：「マウントしました。どうでしょう？」
"む"：「mount と打てば、自分で確認できますよ。」
('A`)：「ああっ、本当だ。」
banana3000# mount
/dev/ad12s1a on / (ufs, local)
devfs on /dev (devfs, local)
/dev/da0p1 on /home (ufs, local, nosuid, soft-updates) ← ココ注目！
/dev/ad12s1d on /usr (ufs, local, soft-updates)
/dev/ad12s1e on /var (ufs, local, soft-updates)
/dev/md0 on /md (ufs, local, soft-updates)
banana3000#
"む"：「ちゃんとセットされてますね。これで、花子の不安定とパフォーマンス
不足は、解消することでしょう。」
('A`)：「これって、fstabを直す必要がありますか？」
"む"：「その必要はありません。ファイルシステムに直接フラグが書かれるのです。
umount 状態じゃないと、softupdate のフラグは変えられないです。
では、lost+found の下のごみを掃除しておきましょう。」
('A`)：「(cd /home/lost+found rm -f * ・・・)消しましたー！」
"む"：「これまで「/homeが遅いなぁ、RAIDのせいかなぁ」と思っていたのは、
単に設定の問題だった事がわかって、私としてはちょっとうれしいです。」
('A`)：「(ぐはっ・・・そうだったのね。。。)」
"む"：「これで作業はすべて終了のはずです。リブートすれば、通常の状態に
戻るはずです。
では、いきましょう。
お祈り
sync
reboot 」
('A`)：「(1、2、3)リブートォォォォ！」
"む"：「祈りましょう、祈りましょう、、、。」
|
やがて、花子が戻ってきました。さっそくSSHでログインしてdfコマンドで/homeが
マウントされているか確認しました。
('A`)：「/home マウント確認しました。」
banana3000# df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/ad12s1a 989M 70M 840M 8% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/da0p1 5.7T 2.4T 2.8T 46% /home
/dev/ad12s1d 1.9G 833M 987M 46% /usr
/dev/ad12s1e 3.9G 312M 3.3G 9% /var
/dev/md0 87M 126K 80M 0% /md
banana3000#
"む"：「見違えるように、/home が速いですね。成功です。よかった。
ls -l /home/admin とかやれば、速いのが実感できるはずですよ。」
('A`)：「本当だ・・・凄く早くなってる。」
|
lsコマンドでディレクトリ一覧を表示する時、以前の花子だと表示前に一瞬
「止まって」いたのです。ちょうど「うーん」って踏ん張っている様に・・・
で、その一瞬の間の後に"ドーーーー"と結果が表示されていたのです。
それが、この「施術」を施して以降、スルッと表示される様になったのです。
/homeには200アカウント以上もあるのに、まったくストレスを感じません。
これが「softupdate」の威力なのか・・・
('A`)：「この softupdate はもしかして花子や花代だけじゃなく、すべての
サーバに言える事なのですか？」
"む"：「はい、そうですよ。
でも普通にFreeBSDのインストーラで作ったファイルシステムなら、
通常、softrupdateフラグは自動でつきますね。(/ 以外)
一方、花子や花代はOSインストールとは別のタイミングで個別に
パーティションをフォーマットしていたんだと思うのです。
で、newfs の時に＊オフ＊がFreeBSD標準なので(罠ですねぇ)、
newfs -U /dev/da0p1 とか、明示的にやらないとダメだめなんですよ。
インストーラはちゃんとそのへんのところをケアしてくれるんですが、
個別でやるときには、注意が必要なわけです。」
|
大変貴重な経験と知識を頂きました。
(ってかそんな罠仕込まないで下さいよ、FreeBSDの中の人。。。)
今後の事もあるので、大急ぎでBrian( ^ω^)に今回判明したフォーマット時の問題と
解決法を伝えました。
で、同じ問題が花代(banana3001)も持っていたので、花子の作業が終わった後に続けて
修正作業を行ないました。
花代の修正作業においては、「サーバをリブートしないやり方」で対応しました。
やり方は以下の通り。
1) サーバにログインする。
2) スーパーユーザになる前に、/homeパーティションにアクセスしない様に
cd(チェンジディレクトリ)する。(例えば cd / とか)
3) スーパーユーザモードになる。
4) /homeをアクセスしていると思われるプロセスを止める。
(a) httpd を止める (httpd -k stop)
(b) cron を止める (cd /etc/rc.d → sh cron stop)
(c) MySQL を止める (cd /usr/local/etc/rc.d → mysql.server stop)
(d) qmail 関連のプロセスを止める。
cd /var/service
svc -d smtpd
svc -d pop3d
svc -d qmail
5) /home をアンマウントする。 (umount /home)
6) softupdate をオンにする。 (tunefs -n enable /dev/da0p1)
7) /home をマウントする。 (mount /home)
8) 4)で止めていたプロセスを再起動する。
(a) qmail 関連のプロセスを起動する。
cd /var/service
svc -u smtpd
svc -u pop3d
svc -u qmail
(b) MySQL を再起動する (cd /usr/local/etc/rc.d → mysql.server start)
(c) cron を起動する (cd /etc/rc.d → sh cron start)
(d) httpd を起動する (httpd -k start -DSSL)
9) mount と実行して、 /home の処が以下の表示になっているか確認する。
(変更前)
/dev/da0p1 on /home (ufs, local, nosuid)
(変更後)
/dev/da0p1 on /home (ufs, local, nosuid, soft-updates)
10) /boot/loader.conf に以下の行を追加する。
kern.maxdsiz="2G"
|
上記手順で、 2) は重要です。
cd /tmp とか cd / とかをしておかないと、 /home を掴んだ状態のままになるんです。
何故か・・・それはSSHではroot以外のアカウントでログインするのですが、ログイン時に
最初 /homeに割り当てられている自分自身のディレクトリ(例えば /home/admin とか)が
カレントディレクトリとしてポイントされるからです。
(この時点で結果として /home を掴んでしまうのです。)
今回ここで一度失敗して、むむむさんを巻き込んで右往左往してしまいました。。。
で、全ての作業が終わったのが午後8時10分。
むむむさん、ありがとうございました。花子と共に('A`)も助かりました。
(もっとも、新しいDNSパッケージ(PowerDNSとか)のススメとかも受けまして、、、
また宿題ができたかな？ちょっと挑戦してみようかな？余裕があればですが・・・)
今回の日記は長編になりまして、「読みづらいなあ」と思われるかもしれませんが、
少しでも「当時の様子(二人羽織の感じ)」がイメージ化できる様、当時交わされた
会話をできるだけ再現してみました。
ユーザの皆さんには長期間ご不便をおかけして申し訳ございませんでした。
花子も花代も封印されていた「本来の力」を発揮して、今日も元気に動いています。
もう大丈夫です。ご安心下さい。
・・・って、あー、ロードバランサーの説明がまだでしたね。。。
ちょっとこれ以上書くと「長編」を通り越してしまうので、こちらは次回という事で、
お楽しみに
それでは、また
|
|
|
|
|