雑記

◆ 寝込み正月

帰省直後に発熱。そのまま治らず3日に飛行機に乗ったのが決め手になって寝込んでしまい、第1週は使い物にならず。いまだに咳が止まりません。ここのところ、初期症状を抑えるのに失敗すると39度越えというのがパターン化してきたなぁ。

◆ TXチャレンジ結果

私もなんとか成功したのですが、その時見かけた別の挑戦者の話を。私が乗った前方車両のボックス席の隣に、幼稚園ぐらいの娘さんと赤ちゃんをつれた4人家族が座りました。やや小さめですがキャスター付きの旅行かばんの他に、お父さんはリュックを背負っているというほぼフル装備状態です。これから飛行機に乗るとか言っているので、私と同じく羽田に向かっているのは間違いありません。この家族構成と荷物では、6分での乗り換えは到底無理なので、ゆっくり行くんだろうと思っていました。秋葉原の駅に着くと、家族は近くのエレベータの方に向かい、そこでいったんお別れ。予行練習の経験を踏まえ、終始早歩きで通路とエスカレータを抜け、JR秋葉原駅の中央改札口に着くころには私の息は絶え絶え。その時、目の前に到着したエレベータの中から、さっき別れた4人家族が飛び出してきて猛ダッシュ。哀れな徒歩挑戦者はついて行けず置き去りになりましたとさ。いまさらながら構内図を見るとさもありなんという感じですが、秋葉原駅の連絡通路はものすごく遠回りさせられるんですね。次があれば私もエレベータを使うようにしよう。

ちなみに、浜松町駅ではエスカレータ前にうまく降りたおかげで、6:18発(乗り換え3分)に乗ることができました。

ちょっと記憶があやふやですが、TXでは2両目に乗り、秋葉原ではエレベータを乗り継ぐ。京浜東北線に乗ったら4,5両目(収納席タイプの先頭車両)に移動して、浜松町で目の前のエスカレータを使って乗り換え。がベストかな。

◆ 大雪

南国育ちの身としては、十分な大雪でした。気のせいかもしれませんが、結構ふわふわとしためずらしい雪質。昼食を食べるついでに夕食の買い込みをして、引き篭もることに。とか言いつつ、昼食を食べた店の駐車場で会心のアクセルターンが決まってちょっとご機嫌。

◆ ad hoc

明日、NTTの工事が入る予定だったのをすっかり忘れていて、あわてて部屋の片付け。割いてる時間はあまりないので、見せる区画と隠す区画を決めて、ひたすら物の移動でごまかすことに。なんかそれなりになりましたよ。

◆ ＿|￣|○

NTTから電話。「本日午前の工事予定ということでしたが、路面凍結のため作業車が出せない状況でして…。再度日程を調整するということで、ご了承いただけますでしょうか。」

◆ サーバ障害

周りでバタバタとしたせいか、昨日になって、サーバラックから30分おきぐらいに、靴底に画鋲が張り付いた靴で廊下を歩いたときのような、カツーンという音が聞こえてくるようになりました。音源をたどるとこのサーバです。明らかにまずい兆候なので、まずは設定ファイルをバックアップ。続いてデータをバックアップしようとしたら、しばらくしてHDDがtimeoutを起こしてOSごとハングアップ。連続アクセスなどの高い負荷を長時間かけなければとりあえずは動くので、起動したままHDDを購入にお店に走りました。うちの会社のサーバもかねているので、5時まで待ってデータの移動開始。

◆ [FreeBSD] 障害復旧・データサルベージ編

HDDを近所のPCショップで\1980で投げ売りされていた変換アダプター(IDE-3525)を使って正常なPCに接続して作業開始。案の定というか、いったんディスクへのアクセスができなくなると、コピーコマンドはもとより、sync や shutdown も機能しません。活線挿抜に望みをかけますが、OSがpanicして再起動しました。しょうがないので機械的にリセットをかけると、再起動時のfsckでコピー先の大量のファイルが消えます。被害を最小限に抑えるために編み出したノウハウは、次のようなものです。

1. コピー中にHDD止まる。
2. 別のコンソールでshutdownコマンド実行。プロセスの終了処理が実行され、sync処理前で止まる
3. HDDをUSBコネクタから抜く。
4. syncが始まる。retryを繰り返すが当然失敗。しばらくするとあきらめてリブートがかかる

先にshutdownコマンドを実行するのがミソで、バックアップ以外のプロセスにまつわるfsckエラーが無くなります。

止める方法が確立したので、いよいよデータのサルベージ。I/Oエラーが出る場所はまちまちなので、円盤上には正しいデータが残っていることが期待されます。ただし、dumpコマンドでバックアップを取ろうとすると最後まで行かないので、細かいディレクトリ単位でバックアップしました。

• 1回目はtarを使ってできるところまでコピー
  

  # cd /src/usr
  # tar cf - local/etc | tar xvpfC - /dst/usr/

• tarが運悪く途中で止まった場合、再起動した後、rsyncを使って残りをコピー

  # rsync -acut /src/usr/local/etc/xxx/ /dst/usr/local/etc/xxx

2回目以降にrsyncを使うのは、チェックサムオプションによりデータの完全性を保証するためです。

しばらく上記方法でちまちまとコピーを取っていたのですが、何回かやっているうちに、アクセスが止まった直後にHDDをちょっと動かすと復帰することを発見。HDDから聞こえる音から、円盤の回転が落ちるか止まるかした結果timeoutしているようで、HDDを傾けることによって止まった円盤の回転が再開している感じでした。これで状況は一変し、tarで一気にバックアップ、その間、HDDを持ってひたすらゆっくりと揺らすという、はたからみると危ない人モードに。動作中に揺らすというのはちょっと怖いですが、壊れるような衝撃を加えるわけではないので、まあ大丈夫だろうと判断しました。

◆ [FreeBSD] 障害復旧・リカバリ(失敗)編

成功した方法から書くと、新しいHDDにOSをインストールした後、サルベージしたデータをコピーして終了です。で、以下にはうまく行かなかった方法を後学のためにメモ。

1. IDE-3525に新しいHDDをつないで、バックアップマシンに接続
2. /stand/sysinstallを起動してFdiskでスライスを作成し、wで書き込んでからいったん終了
3. 再度/stand/sysinstallを起動してDisklabelでパーティションを作成
4. バックアップしたデータを各パーティションにコピーし、/etc/fstabを新しいHDDのパーティションにあわせて変更
5. HDDを繋ぎ直して起動
6. Missing operating system で起動せず
7. 上書きインストールを使ってMinimum構成インストール。状況変わらず。
8. /パーティションだけnewfs yesとしてMinimumインストール。状況変わらず
9. 通常インストール(newfs no)。状況変わらず
10. 通常インストール(newfs yes)。状況変わらず
11. HDDを取り外してバックアップマシンに繋ぎ直し、MBR消去
    

    # dd if=/dev/zero of=/dev/da0 bs=1024 count=1

12. HDDを再び接続してクリーンインストール。MBRにはStandard MBRを選択。HDDにアクセスした瞬間にリセット、再起動を繰り返す。
13. MBRを再消去して、FreeBSD

    Boot Managerを選択してクリーンインストール。正常起動

14. すべてのデーモンを止めて、/ パーティション以外のバックアップデータをコピー。/ パーティションについては、いったん/var/tmp/root以下にコピー
15. シングルユーザモードに移行して/パーティションのデータをコピー。/etc/fstabを編集して再起動
16. 元の状態に戻っていることを確認

2.で書き込んだMBRが悪かったようなのですが、止めてもう一度確認する余裕は無いのでとりあえずはこれで作業完了ということにしました。作業終了時刻は24日11:00。

◆ とくダネ！

復旧作業のBGに流していたんですが、小倉氏が中立の立場を守るために、これまではライブドアに対してネガティブなコメントができなかったとか、ライブドアを散々非難していました。ところが、その直後に伝えられたヤマハの事件に対して、「ヤマハと検察の認識の違いだったんだろう」「あんな立派な企業が不正と分かっててあんなことをするはずが無い」「なぜ、政府(経産省)は告発する前に照会や確認をしなかったんだ。そうすればヤマハも問題に気づいて行動を改めることができたはずだ」とか何とかやけに張り切って擁護していました。で、ふとそれって主語をヤマハからライブドアに替えても成り立つよなぁと思ったり。小倉氏に限らず、中立という言葉を擁護はいくらやってもok、非難はタブーという意味だと(わざと？)勘違いしている人が多いような気がします。

あと、フジに限らず、堀江氏は一連の行動に対して不正だったとは思っていないと言い、他の幹部は、一連の行動をやった事実を認めていることに関して、堀江氏は不正への関与を否認、他の幹部は不正を認めているというミスリーディングしているのには、明らかな悪意を感じます。ライブドアが行っていた株価の引き上げ手法がえげつないのは解説報道をみると良く分かるので、へんな情報操作に走らずに事実関係を正しく伝えてくれれば十分だと思うのですが。

◆ Red Hat Enterprise Linuxの情報が無い

RHELサーバのセットアップをする機会に恵まれたのですが、インストールはまあ簡単だからよいとして、インストール後の基本的な設定をするための情報が見つからず、非常に苦労しました。「アプリケーション」メニューのヘルプはデスクトップ環境のもので、しかもすぐに英語に切り替わる。メーカのWebページを探してもドキュメントは見当たらず。googleで検索するとフリー時代のドキュメントばかり。本屋に行ってもFedraとかフリー系の情報しかない。と、まるで総スカンをくらっているみたいです。私の探し方が悪いだけかもしれませんが、本当にまともなドキュメントがほとんど無いような状況だとしたら、Redhatって正直ジリ貧では？

普段なら/etc以下等を直接書き換えてしまうのですが、GUI管理メニューのあるOSでそれをやるとひどい目にあうというのをSolarisで経験済みなので、ちょっと怖い。結局「アプリケーション」メニューの中を片っ端から探してそれっぽいものを実行しては、試行錯誤で設定を進めていく羽目に。これならL-CardAの開発のときに使ったVine Linuxの方がましだったなあと思いました。

◆ [SSL] SSLの問題に対する包括的な対策

証明書発行機関やブラウザの開発者の協力の元、対策が始まっているようです。ただ、記事を読む限り、証明書拡張ポリシーは無かったことにされているような。別にこれで十分じゃないかという気もしますが。

◆ [Windows][IE][SSL] Snake Oil CAなページにInternet Exprlorerからアクセスできない

正式な証明書が間に合わなかったので、apache標準のSnake Oil CAで署名した証明書をでっち上げ、動作確認しようとしたところ、IEエンジンを利用したブラウザでは、証明書に関する警告等は一切無く、

検索中のページは現在、利用できません。Web サイトに技術的な問題が発生しているか、ブラウザの設定を調整する必要があります。(中略)サーバーが見つからないか、DNS エラーです。
Internet Explorer

というものすごく不親切なエラーメッセージが表示されます。さんざん悩んでも問題は解決せず、ふと同じページにFirefoxでアクセスすると、通常のSSL証明書に関する警告が表示され、OKしていけば、正しくページが表示されました。SSL証明書管理メニューの「信頼されない発行元」には登録されていないようですが、Snake Oil CAだけなんか特別な処理しているのでしょうか。それとも、一般的ではないポート番号を使っているので、この辺が影響してるのかなぁ。