FileZilla 3.5.3
FileZillaの現在の最新バージョン3.5.3は、うちのサーバにFTPSで入れない。
ごみ箱の3.5.2を掘り起こしてダウングレードしたら復旧。やれやれ。
しかし、WordPressを動かして以来、FTPの接続頻度が非常に低くなっていることもあって、原因が特定するまで、年末に更新したサイト証明書でヘマしたものとばっかり思っていた。よく考えたら、更新時にテストぐらいはしているよねえ(^^;
というわけで、やっぱりFTPS(Explicit)は動いている。
Fedora
lvmスナップショット
サーバのホームディレクトリのバックアップは、毎日lvcreateでスナップショットを作ってdumpしている。
このスナップショットが、Fedora16になってから、週に1～2回のペースでnot deactivatingを出してlvremoveに失敗するようになった。カーネルが変わったせいなのか、外付けになったせいなのかは不明。
最も疑わしいのは、RAID1に作った論理ボリュームを、今回は物理的には同じRAID1にdumpしているので、lvremoveする時にはおそらく忙しく書き込んでいる最中であろうということ。管理者向けメールで気づきさえすれば、手動でならlvremoveできるので、とりあえず時間を置けば成功するらしい。
というわけで、lvremoveの前にsyncしてみた。が、ダメなときはやっぱりダメ。考えたら、umountとかlvremoveとかって内部でsyncに相当する処理は実行しているはずだもんね。
結局、lvremoveを10回ループで囲んで、リザルトコードが0以外ならsleep(とりあえず3秒)置いてから再実行するようにしてみる。といっても、lvremoveのリザルトコードが、正常時だけ0を返してくれるものかどうかは未確認。こればっかりは、実際にlvremoveに失敗するのを待つしかない。
やっぱりcrond
anacronを初めて3日以上運用中。
anacronをremoveすると、cronばかりかamavised-newまで削られる(まさかこの間にメール来てへんやろな)。cronieをinstallすると、頼みもしないのにanacronがついてくる。
これは、anacronを軸に使えというお告げと思ってしばらく使っていたら、日次バックアップの開始が5～15分ずつずれてきた(汗)。やっぱり決まった時刻に実行するのは苦手なようだ。
結局、cron.d/とcron.hourlyの0anacronを外して、改めてcrontabをセット。Fedoraで常時運転しようなんて考える 酔狂な チャレンジングな 人間は、この程度の不親切は何事もなくフォローできなければならない、ということかもしれない。
復旧完了
前日は何もできずに寝てしまったので、本日総仕上げ。
clamav&amavisd-newは、先代と同様、yum insallした後でclamavだけmake install。
設定ファイルは先代のをそのまま使って起動成功するが(落ち着いたら他のサービスの設定共々差分取らねば)、messagesに/var/lock/subsys/clamdという設定した覚えのないPIDを見に行ってこけるログが1行出てくる。
これを消すために、セットアップ直後からあれこれいじったり、問題のPIDファイルをでっち上げたりしてきたが、サービス自体はちゃんと動いているみたいなので、とりあえずほっとく。
そういえば/var/run/amavisd/amavisd.pidもパーミッションのせいで削除できないとかとも言っている。まあsystemctl絡みだと思うけど、Fedora8からどこがどう変わったのか、これから勉強しないといけない。
最後に定期バックアップを復活。スナップショット作成用のlvcreate/lvremoveは、Fedora8の時の/usr/local/sbin/から/sbin/に移動している。あと、スナップショット作成のためにFedora8標準カーネルで必要だったmodprobe dm_snapshotは、Fedora16標準カーネルでは必要ないらしい。
これでどうにか環境的には先代と同等に戻ってやっとひと安心。やり残しとしては、先代が壊れる前から検討していた、ローカルファイルサーバとしての運用の追加と、先代が壊れる前から牛歩戦術で整理中の(オイ)自分のサイトのWordPress導入前のコンテンツのフォローだ。しかしとりあえず、ずっと停まっていた自宅の整理を再開する。
BINDのchrootのこと
「サーバ再セットアップ時に残しておきたいデータは/varに置かない」との方針のもと、BINDのchrootは一般ユーザと同等なホームディレクトリ上で運用している(まあしょっちゅう内容が変わるセットでもないので、/varでもセットアップ後にコピーすりゃ済むけど)が、今頃になって一部ファイルディレクトリがシステムドライブをマウントして動いていることを発見。
「(SSDである)システムドライブへの書き込みは極力避ける」とも決めているので、これはちょっと見過ごせない。
/etc/sysconfig/namedを読んだら(誤訳の可能性あり)「chrootにファイルが無かったら、足りないディレクトリやファイルが自動的にマウントされる」らしいので、そんな手間をかけさせないために、BIND停止後(自動的にアンマウントされる)必要なファイルをchrootの本当の領域にコピーしたり、マウントポイントそのままのディレクトリを作ったりしてみたところ、ファイルについては落ち着いたが、ディレクトリ2個
- chroot/etc/named
- chroot/usr/lib64/bind
については、パーミッションとか揃えているにもかかわらず、やっぱりマウントされる。中身も空だし、この辺の挙動は謎。
謎を解明するために、ドキュメントをさらによく読むと(誤訳の可能性あり)「管理の手間を省くために自動マウントされます」だって。ならその意を酌んでほっとくか(^^; ファイルもよく見たら、書き込むためのファイルではなさそうだし。逆に、こちらが勝手に動いたせいで、もし将来BINDのバージョンが上がったときに新しいkeyファイルその他をコピーし直さないといけないかもしれない!?
