「Linux」カテゴリーアーカイブ

古いマシンから取り出した中途半端なサイズの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~

Perl でプログラムを書いていると、ぼちぼちとパッケージが足りなくって、 CPANでライブラリをインストールしている。 んで、古いCPANパッケージで動かないというトラブルもあって、 "perl -MCPAN -e shell あんど upgrade" を実行したら、 大量のパッケージが入ってしまっていた。 ただ、Debianでも lib*-perl にて、同じライブラリの多くは提供されている。 このままいくと、パッケージの競合もおこりそうだし、CPANで入れるものは必要最小限にしたい。

ということで、CPANでインストールしたモジュールは？ を参考に、cpan-list.pl と cpan-uninstall.pl を作成し、lib*-perl で提供されているモジュールを 次々と消していく。 当初107個のモジュールが入っていたけど、32個にまで減らした。

でも、モジュールのバージョンの違いによる警告を出すプログラムがありそうだなぁ…

サーバの更新後、メールサーバを qmail から postfix に変更し、 ひとまず自宅ドメインへのメール送信もできるようにしていたつもりだけど、 設定に間違いがあった。 基本、自宅ドメインへのメールなんて、自分だけしか使わない。 だから、トラブルに気付かなかった。 でも、自宅blog(movable-type)への書き込みに、たまーに使っている。

トラブルの状況は、送ったメールが451エラーで送り返される。

Delivery to the following recipient failed permanently:
ユーザ名@自宅ドメイン
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 451 451 4.3.5 Server configuration problem (state 14).

メールのエラーログを見ると、以下のように、10023ポートへの接続エラー。 これより、postgrey への接続でエラーが出ていることがわかる。

... connect from localhost[127.0.0.1]
... disconnect from localhost[127.0.0.1]
... connect from mail-pz0-f44.google.com[209.85.210.44]
... warning: connect to 127.0.0.1:10023: Connection refused
... warning: problem talking to server 127.0.0.1:10023: Connection refused
... warning: connect to 127.0.0.1:10023: Connection refused
... warning: problem talking to server 127.0.0.1:10023: Connection refused
... NOQUEUE: reject: RCPT from mail-pz0-f44.google.com[209.85.210.44]: 451 4.3.5 Server configuration problem; from=<xxxx@gmail.com> to=<xxxx@xxxxxx> proto=ESMTP helo=<mail-pz0-f44.google.com>
... disconnect from mail-pz0-f44.google.com[209.85.210.44]

いろいろ説明を調べてみると、この記事が該当しているようだ。 設定時に、古い postgrey の記事を見たため、以下のような間違いがあった。

(( /etc/default/postgrey ))
# POSTGREY_OPTS="--inet=10023" は間違い。
POSTGREY_OPTS="--inet=127.0.0.1:10023"

参照記事によれば、"–inet=10023"では、IPv6接続に勘違いされてしまうらしい。 だめだこりゃ…