ごまめの遠足。

11月の危機

サーバのディスクアクセスランプが点きっぱなしになる。

とりあえずハードウェアリセットから再起動はできたので、生きているうちにデータドライブのバックアップを取って(たぶん成功)、MySQLのデータを含む/varのアーカイブを取って(たぶん成功)、/etcのアーカイブを取ろうとしたところで再びアクセスランプが点いたままになる。

今回は、ディスクアクセスに関するエラーらしき表示をコンソールに出す余裕!?があるので、とりあえずPSUとかメモリとかは直接の原因ではなさそうだ。というわけで、システムドライブか、データドライブミラー(ARAID99-2000)か、マザーボードのいずれかでほぼ決まりだが(範囲広すぎ)、理想的な復旧シナリオとしては、

• 原因はシステムドライブの寿命で
• TrueImageでイメージを吸い出す間もちこたえて
• イメージ移植した新ドライブに入れ替えると復旧する

であったが、取り出した時点で過去何週間かのバックアップファイルが入ったままになっていて、本来2GBそこそこのバックアップイメージのはずが80GBを超える。わざわざシステムとデータを別ドライブに分けた意味を忘れて、システムドライブのサイズをいたずらに大きくしてしまったのは大不覚。強引にバックアップしようとしたが、80GBの空きのあるフリーのHDDがなく途方に暮れる。悪いことにメインPCの調子も悪いので、共有ディレクトリにアップロードすることもできない。

一応バックアップ保存先のパーティションを除外すれば、短時間でコンパクトなバックアップは取れた。あとは別ドライブに領域残して復元して、復旧後バックアップ保存用のパーティションを改めて作り直すという手順だが、TrueImageが想定している可能性が(フルバックアップよりは)低いイレギュラーな手順なので、いまいち不安は残る。というか最も理想的なシナリオにしてこのややこしさ(汗)。

でもって、ARAID2000のアクセスランプも点きっぱなしになったというところに、システムドライブはシロかなという予感も感じる。

ちなみに、ARAID2000の故障であれば、元手はかかるけど別のミラーユニットを買って、同じSATAポートに繋げれば、引き続きそのまま使える(はず)。

USBとかだと、lvmの再マウントという未経験な手順が必要だが、まあOSもそのぐらいのことは想定しているであろう。

最悪なのはマザーボードの交換が必要なケースだ。CPU/マザー/メモリの3点セットが必要なうえ、おそらくOSやらサービスやらの再セットアップが必要だ。

将来計算機ごと交換しなければならない場合でもスムーズに復旧できるように、仮想化でも導入するべきかもしれない。

2011/11/13 23:00 | カテゴリー：Fedora | コメント（0）

LPF10M01(オンキヨー)

何を思ったか、HDMI『入力』を持っているからPCのモニタとして使える。XGAクラスで10インチなので、フライトシムのサブモニタによさそうだ。デジタルフォトフレームは盲点であった。というかデジタルフォトフレームでも、HDMI入力を持った製品は今のところ他にない(『出力つき』はある)。

ただフォトフレームが本職なだけに、あえて幅を広くした?フレームが邪魔っぽいのが難点。よっぽど困っているのなら迷うことはないが、フライトシムを本格的に動かせるメドが立っていない状態ではブレーキの方が強い。あと「そろそろHDMI入力対応の小型モニタが出るかも?」という期待もある。

というか、某カメラ屋に入るたびに、デジタルフォトフレームのコーナーの同じ製品をガン見している(ただし、いくら睨んでもフレームが狭くなることはたぶんない)ものだから、もしかしたらスタッフの人に顔覚えられたかもしれん。となると、いよいよ同じ店では気まずくて買いにくいのだ(そうか?)。

でもって、他の店でもし売っていたら買おう、というバクチで遊べるぐらい、カメラ屋以外では売っていない。しばらく供給サイドの出方を待つ。

2011/09/07 02:24 | カテゴリー：Fedora | コメント（0）

Filezilla v. iptables

…実際は、そこそこ高機能なFTPクライアントならどれでも起こりうるかも。

FileZillaで画像ギャラリーみたいな大量のファイルをアップロードする時、途中から非常に重くなったり、最悪タイムアウトしたりする件について、原因はiptablesのポートスキャンチェインに誤認逮捕されているせいと既に明らかにはなっている。というか、ファイルごとにいちいち順繰りにパッシブポートを開くのに意味があるのかどうか? いや同じポートを使い続けても、ファイルごとにコネクションを立てている以上は、今の自サーバのiptablesのロジックではポートスキャンに引っかかるんだけど。

実際にiptablesの閾値以上にコネクションが立てられる以上、iptablesの閾値を上げるべきなのかもしれないが、こうなると本当のポートスキャンを受けてしまう可能性が高くなるので闇雲には上げたくない。

LAN側を無制限にする手も考えたが、LAN側の端末が万一感染した時に、ポートスキャンの検出を通して察知できる可能性は下げたくない。

というわけで、これまで問題が発生するたびに、SYN floodとともに閾値をジリジリと上げてきたわけだが…よく考えたらパッシブポートだけ制限解除のほうが、この際よっぽど安全そうな気がしたので、パッシブポートのみポートスキャンし放題になっている。どうぞお手柔らかに。

理想的には、ftpdがクライアントにパッシブポートを通知するタイミングで、iptablesにてそのポートだけ制限を緩くする(そして通信が終わったら元に戻す)べきなのかもしれない。

2011/04/12 23:45 | カテゴリー：Fedora, 計算機とか | コメント（0）

証明書更新

POP3sとIMAPsとFTP o. TLSの証明書が期限切れにつき更新。

更新自体は昨年まとめたとおりで、10分かからずに完了するが、有効日数が366日ということで、切れたのに気づいて更新すると、1年で1日ずつずれていく。

よく考えたら昨年も今年もたまたまオフの日だったので早めに気づいたが、来年もそうとは限らない。当然ながら、こういうのは前年と同日、すなわち期限が切れる1日前に更新するべきであろう。

となると、毎年この時期だと今回と同じように忘れているので、やっぱり正月近辺に更新するべきかもしれない。

2011/02/13 23:41 | カテゴリー：Fedora, 計算機とか | コメント（0）

六世サイトと結合

データベースをダンプして、ドメインを書き換えて、また放り込んだところ、サイトを開いたら記事の半分ぐらいが消えたので、慌てて元に戻す。

もう一度慎重にやり直したところ、「max_allowed_packetよりサイズがでかい」というエラーが出ているのを発見。これさっき出てたっけ??

問題のパラメータは、WordPressではなくMySQLのmy.cnfで設定されるグローバル変数のようで、デフォルトの1MBでは足りないことがあるそうな。参考サイトでは一気に16MBぐらいにしているが、私は弱気に、とりあえず4MBにした。まあさしあたってデータベースの更新は成功したようだ。

これで、長い間止まっていた六世サイトがやっと再始動する、かもしれない(汗)。昔の記事が一気に見えなくなってしまったが、以前見えてたものには、いずれ復活させる。

2010/12/02 01:54 | カテゴリー：Fedora, 計算機とか | コメント（0）