dump uしておいてincremental dumpしなかったことを後悔。
まぁでもincremental dumpしても、消したファイルは反映されないからまぁいいのかもしれないけど。
dumpを今から始めた訳じゃなくて、1st PCの筐体解放作業前から始めている。
やっぱり、時間かかることは並列処理するのが基本でしょう。
でも、実は、cableの類を間違って抜いてしまったりした場合のdamageが大きくなる可能性も孕んでいるので若干はriskが増えるのだが。
/usrのdumpが終了。
shutdown -p。
んで掃除器を準備して開けてみる。
shutdown -p。
せっかくなので、motherboardだけではなく、他もserial#を控える。
ただ、部品を外してまでの記録は面倒なので省略。
大体こういうことをすると、次の機会に控えていないのが必要になったりするモノんだが。
□●□ 上 □□□ □□□ 下の位置を使ったんだが、そのあと一人入ってきて風呂から出たら
□□● 上 ●●□ □□□ 下の位置が使われていた。 一人で3箇所も使うのも謎だが、さらに謎なのは占有箇所。
ad0のbackup:/stand/sysinstallでfdiskする。
でbsdlabelは、partition名を指定したいんだけどどうしたらいいんだろう。
実は今まで直接bsdlabelを起動したこと無いのだった。
/stand/sysinstallでpartition名を気にせず作ってから名前をいじることを検討。
んで、書き込んだら…
しまった。
swapが割り当てられてしまったぞ。
swapoff /dev/da0s1b」でとりあえず外せてほっとした。
bsdlabel -e da0s1」して、dをa
に変更。
あれ？
「bsdlabel da0s1」しても変わってないのだが。
うーむ。
あ、分かった。
/stand/sysinstallが勝手にmountするのを忘れていた。
umountして再挑戦。
うまくいったようだ。
ad0と若干partition sizeを変えたってのもあるけどbps/cpgが違うのはどうなんだろう。
というか、ここの意味、online manualを読んでも分からん。
newfsしてfsckするか。
dump 0Lf - /dev/ad0s1?|restore xf -」。
/usrを/var用のpartitionにコピー始めてしまったので、ctrl-cで止めたら何か変だぞ。# dump 0Lf - /dev/ad0s1e | restore xf - DUMP: WARNING: Cannot use -L on an unmounted filesystem. dump: Cannot open /dev/rad0s1e: No such file or directory Tape is not a dump tapeなんかLの意味が逆の気がするんだが。 いや、やりたかったのに出来なかったということかな？ とか何かいじっているうちにkernel panicを起こしたみたいだ。
fsckが終るまでしばらく待つか。
ad0: FAILURE - READ_DMA status=51<READY,DSC,ERROR> error=40<UNCORRECTABLE> LBA=31751263が数回出た。 前回と同じ場所だな。 が、一度は読めた場所だから、まだデータは救える可能性は高いと思うのだが、どうかなぁ。 まぁとにかくbackupを取って購入店に連絡だな。
fsck。
fsckは何度か「y」と答えて通った。
念のためもう一度「fsck -f」でfsck。
reboot。
newfsしてやり直し。
/usr以外は終った。
このエラーが混じっているpartition、どれくらいうまくいくか。
というか、なんかそれ以前にdf -h出力を見ると利用量が減っている気がするぞ。
なんか失われたファイルがあるかも。
dump 0aLf - /dev/ad0s1f | restore xf -」のPass IVまでいってfirewire HDの書き込み開始。
どれくらいかかるのかなぁ。
65GBだからなぁ。
そのうち予測表示は出るとは思うけど。
iostat出力からすると5MB/sぐらいは出ていそうだから4時間弱か？
とりあえず待っている間に修理はどんな感じになるか、購入店に問い合わせてみよう。
DUMP: 1.92% done, finished in 4:15 at Sat Dec 24 18:03:18 2005まぁ最初の出力だから結構誤差は含んでいるんだろうけどそんなものか。
1:55, 1:31, 1:20, 1:11思ったよりかなり早く終りそうだ。 これが終ったら当分の間、人間が意図していない書き込みが起こる
/varを自動で別PCにコピーでもしておけば安心かな。
もちろん、人間が意図する書き込みはそれはそれでbackupを取るということで。
1:03, 0:56, 0:50, 0:43, 0:37, 0:32, 0:25, 0:20, 0:14, 0:08, 0:02なにもエラーとか出なくて助かった。 結局12.6MB/sぐらいで複写できたみたい。
/varをもう一度複写して作業終了。
ad1以上が遅い現象とかも嫌なことから、せっかくならSATAにしようかと思って使えるかどうか確認。
実は、一昨日まで、SATA HDの電源cableもPATAと同じだと思っていたんだけど念のためと調べると何か違うようだ。
(ja.wikipedia://シリアルATA)
信号線が違うのは知っていたんだけど。
んで、世の中の電源装置を見ると「SATA×4」とかいう表記とかあって、確かに違うみたい。
PATA電源cableからの変換もあるけど、元の電源が対応しているにこしたことはないので確認。
ssh辞書攻撃対策、[FreeBSD-users-jp 88538]に触発されてはじめたのだった。
syslogdからscriptが起動できるとはつゆ知らず。
昔使っていたSunOS4.xではそんなこと出来なかったことからの思い込みだな。
MLでの本件に関する一連のthreadではswatchなるものを使った対策例のlinkも紹介されていたけど、たかがipfwのrule追加ごときに設定ファイルの文法を覚えるのとかも面倒で、やる気が起きず。
実質的には10行、wcでは25行のshell scriptを書いて解決。
やっていることはswatchな解決と、rule 8つで回すことを除けばほぼ同じなんだけど。
最初はsyslogdから1行来る度にscriptが呼ばれるのかと思い込んでいたところでミス。
それを期待するなら、scriptの方で1行毎にstdinをcloseしてやらないとダメだったのだった。
ということで、現在こんな感じ00600 26 1520 deny ip from xx.xx.xxx.x to any 00601 26 2040 deny ip from xxx.xxx.xxx.xxx to any 00602 26 1340 deny ip from xxx.xxx.xxx.xxx to any 00604 26 2040 deny ip from xx.xx.xxx.xx to any 00605 1 40 deny ip from xx.xxx.xxx.xxx to any 00606 26 1952 deny ip from xxx.xxx.x.xx to any 00607 25 1776 deny ip from xx.xxx.xx.xxx to anyなんか、攻撃元のIP addressまで伏せる必要がある気もしないけどまぁ一応。 次に604番のruleが更新される予定。 つまり現604番が一番古いrule。
sshの辞書攻撃対策、ipfwのrule番号を8つで回すように設定したのだが間違って、新たなのを設定する時に、一番古いのではなくて最新のを消すようにしていて常に有効なruleが1つしかなかった。
ちょっと間抜け。
2つ以上のサイトから同時に攻撃ということは殆んど無いので事実上問題無いんだけど、早速直して様子を見たところいい感じ。
sshの辞書攻撃対処でipfwの動的ルール生成を作ってみたのになかなか攻撃が来ない。
online中に来てくれると問題が起きた時の対処が出来ていいんだが…
ad0: FAILURE - READ_DMA status=51<READY,DSC,ERROR> error=40<UNCORRECTABLE> LBA=31751263
fwohci0: IR DMA overrun (0x40008011)
dd if=/dev/ad0 skip=31751262 of=/dev/null count=10」とかしても再現しないぞ。
さて、どうしようかなぁ。
kill -STOPして、batchでkill -CONTするのがいい感じ。
ただ、defaultではatrunが5分毎というのがちょっと間隔が長い気がするが、まぁいいか。
またdefaultではat周りの命令は不許可なので、/var/at以下にファイル追加。
でもcronは実行させてくれるのにatを実行させてくれないっていうのはなぜなんだろうか。
mencoderがずっと動いているのにaviがファイルさえ存在していないという現象を見た。
何故か悩んでいたがmplayer DVしたらEncrypted VOB file! Read DOCS/HTML/en/dvd.html.と言われて納得。 でも、今までこれ食らったら、暴走じゃなくて異常終了していたので、そういう意味では、新現象。
mencoderのバージョンが変わったからかなぁ。
そういえばこれ食らったの数カ月ぶりだなぁ。
逆に何でこれまで問題なかったんだろうか？
思い当たることといえば、fwcontrol -R中になるべくチャンネル変更が入らないよう努力しているぐらいだが。
http://www.be.asahi.com/20051210/W16/20051201TBEH0006A.html)
asahi.comのlink policyに気がついてしまい、また届出をする気もないことから、向うが期待していることに反することをする気はないのでlinkは張ってないです。
options MAXDSIZ=(2016UL*1024*1024) options MAXSSIZ=(512UL*1024*1024)にした。 いや、大体原因は分かっているので、kernelの方の修正もそれほど大変じゃないとは思っているんだけど、それでも半日仕事ぐらいにはなりそうなので、pending。
GETの回数はこんな感じ。12/8(木) 262回、12/7(水) 269回、12/6(火) 339回、12/5(月) 361回、 12/4(日) 235回、12/3(土) 165回、12/2(金) 309回、12/1(木) 309回みんなのエンジンがかかるのは、締め切り3日前ぐらいと言うことだろうか。 :-)
cronでやっているのはうまくいっているんだよな。
標準出力を捨てているので、全然原因不明。
気になるなぁ。
もう一度起きたりしなければいいんだけど。
とりあえずGV-MVP/IDVの電源off-onするか。
最近、入れっぱなし…
じゃ、ないか、停電とかあったからな。
本ページの主張等は著者の所属組織に全く関係なく、個人としてのものです。