自宅サーバ宛に届いたメールの確認のために、 courier-imap + courier-imap-ssl を動かし、 自宅以外でも、imap-ssl経由でメールの確認などができていた。

しかし、なぜか今朝から、imap,imap-ssl の接続が出来ないと、 Thunderbirdが文句を言う。 imapプロセスの再起動などもしてみたけど、効果なし。 パッケージ更新の影響が考えられるので、stable パッケージに してみたりしたけど、効果無し。

色々調べたけど、よく解らない。そのうち、Dovecot なる imap サーバソフトの記事が沢山ひっかかるので、 何も考えず、”aptitude install dovecot-imapd”にて、 courier-imap を捨てる….

廃棄パソコンのメモリがあったので、サーバに移植できないかと 蓋を開けたらメモリは規格が違い使えなかった。

一番驚いたのは、ホコリが予想外に溜まっていたこと。 CPUファンの下の放熱板にホコリが溜まっていた。 筐体の吸気口は、ホコリを吸うとわかりやすいので、 それなりにマメに掃除していたつもりだけど、 約半年分のホコリ。

掃除をして起動したら、CPU温度が10℃以上温度が下がってら… 古いHDDは、掃除をしても温度変化が少なく、対比が明らか。

ドリカムのDVDをISOとm4v形式にしたものを、 ちょいとネットワーク越しに3枚コピー。
# ちゃんとDVD買ってるぞ!!

ほとんどネットワークの性能試験状態だな…

15GBを4時間だから、15*8*1024^3/4/3600=9Mbpsか…~ 丹南光のupload-maxが10Mbpsって書いてあるから、そんなもんか… scpでの転送だから、多少ながら冗長性あるし、言ってるだけの速度出てるな。

古いマシンから取り出した中途半端なサイズのHDDを組み合わせて lvm を組んでいたけど、OS更新時の再起動で、エラーが出て マウントできなくなった。

OS起動が途中で止まってびびったけど、ひとまずlvmのマウントだけ 止めて普通に起動させ、lvm のチェック。

pvdisplay やら、lvdisplay などを実行しても、HDDを認識していない ということはないので、ハードウェア的な故障ではなさそう。

しかし、mount はやっぱりできないので、２次バックアップだし、 中身を捨てて再構築させようかともおもった。

でも単純に、fsck.ext3 /dev/lvm/lvm0 を実行したら、なんどか Fix<y>と聞かれたけど、yes で答えたら、普通に修復できた。

ちなみに、再起動のきっかけとなったOS更新だけど、 Linuxのカーネルが、linux-image-3.2.0-1-amd64 となった。 lvm のトラブルで、一旦 3.1 に戻したけど、簡単に修復できたし、 改めて 3.2.0 で起動したけど、問題ナシ～。

ついでに、lvm のマウント方法を、/dev/fstab に記載する方式から、 autofs でマウントする方法に移行させた。 どうも、エラーの原因となったのが、再起動が遅いので早めに reset を 押したためと反省中。automount なら、適度に umount するし、ちょっと危険が減るかな。

最近、自宅ネットワークで新しいパソコンが、ネットワークに接続できなくなるトラブルが発生する。 再起動などがかかれば、普通にネットワークにつながるので、多少不気味ながらもそのままだった。 しかし、うちの奥さんのノートPCも、出先から帰ってきたらつながらない。 IPアドレス取得に失敗しているっぽいので、dhcpサーバの設定を疑う。

今まで、長年運用していた dhcpd.conf ファイルなので、壊したとも思えなかったが、 試しに、dhcpサーバの再起動をすると、普通に接続が回復した。 ということで、 "grep dhcpd /var/log/syslog"で履歴を眺めると、下記のようなメッセージが あったので、色々と調べてみた。

...: DHCPINFORM from 192.168.X.XX via eth0:
not authoritative for subnet 192.168.X.0
...: If this DHCP server is authoritative for that subnet,
...: please write an `authoritative;' directive either in the
...: subnet declaration or in some scope that encloses the
...: subnet declaration - for example, write it at the top
...: of the dhcpd.conf file.

DHCPサーバは、クライアントが使いたいIPアドレスを要求してきたとき、 サーバがこのセグメントでは正しくないと"DHCPNAK"を返すことで、 クライアントは新しいIPアドレスを要求する。 どうも、この辺で"威厳のない"設定だと、再取得に問題がでるみたい。 "とっとと新しいアドレスを要求してこんかぃ"と、「威厳をもって」返答するために、 subnet文の内部に"authoritative;"を書くといいみたい。 当初、"authoritative"を記載させてみたけど、端末をau回線に切り替えてから、自宅回線にもどすと、やはりDHCPでアドレスが取れなかった。逆に、"not authoritative"を記載したら、うまく繋がった。うーん、よくわからん….

subnet 192.168.X.0 netmask 255.255.255.0 {
not authoritative;
(略)
}

自宅サーバ宛のメールなんて、変なSpamにひっかからないと来ないはずなのに、 定期的にメールが飛んでいる。 確認すると、PHP5関連で以下のようなメールが出ている。

PHP Warning:  PHP Startup:
Unable to load dynamic library
'/usr/lib/php5/20090626/sqlite.so'
- /usr/lib/php5/20090626/sqlite.so:
cannot open shared object file:
No such file or directory in Unknown on line 0

色々と確認すると、/etc/cron.d/php5 の中の定時処理にて、 PHP5の設定値を参照する /usr/lib/php5/maxlifetime を動かした時に、 sqlite.so が無いとのエラー。 php5-sqlite(5.3.9-1)にて、sqlite3 中心に移行した割に、 /etc/php5/conf.d/sqlite.ini に、"extension=sqlite.so" が記載されているのが原因。 /etc/php5/conf.d/sqlite3.ini にて、"extension=sqlite3.so" があるし、 本来なら、sqlite.ini をパッケージマネージャが消すべきなんだろう。

ということで、下記を実行(sqlite.iniは後のトラブルに備え残しておく)する。

# cd /etc/php5/conf.d/
# mv sqlite.ini sqlite.ini~