perl-base 5.18 を入れたら postgrey が動かなくなっていた
自宅外から、自宅へのメールが届いていないことが判明。 原因を調べてみると、どうも postgrey が起動していない。 なんで起動しないのと、手作業で postgrey を起動していると、pid ファイルが原因ぽいことが 分ってきた。手作業で起動スクリプトを治そうとしたけど、 動いたり動かなかったり。改めて、"postgrey pidfile debian" で調べていたら、 perl 起動時の "-T" オプションあたりが関係していて、 その根本原因は、perl-base 5.18 になっているため。
作者がパッチを提供しているというけど、パッケージには反映されていないようなので、 パッチの差分を /usr/sbin/postfix に手作業で修正した。
if($opt{dbdir}) {
$opt{dbdir} =~ /^(.*)$/; $opt{dbdir} = $1;
}
+ # untaint what is given on --pidfile. It is not security sensitive since
+ # it is provided by the admin
+ if($opt{pidfile}) {
+ $opt{pidfile} =~ /^(.*)$/; $opt{pidfile} = $1;
+ }
+ # untaint what is given on --inet. It is not security sensitive since
+ # it is provided by the admin
+ if($opt{inet}) {
+ $opt{inet} =~ /^(.*)$/; $opt{inet} = $1;
+ }
# determine proper "logsock" for Sys::Syslog
my $syslog_logsock;
perl 5.18.1-4 に更新
以前、perl 5.18 に更新したら、ことごとくパッケージ更新に トラブルになったので、 perl 5.14 に hold していた。 しかし、ある程度時間が経って競合などのトラブルも 無くなったみたいなので、”aptitude unhold perl”してみた。
以前なら、大量の競合パッケージ削除が発生していたけど、 無事に更新ができた。
ただ、munin-cron が、下記のようなメッセージを吐くように なってしまった。
defined(@array) is deprecated at /usr/share/perl5/Log/Log4perl /Config.pm line 864. (Maybe you should just omit the defined()?)
perlで、配列未定義チェックで、defined( @array ) で書いてあるけど、 defined では正しく動かないし、if ( @array ) で十分ということらしい。
ということで、該当ファイルの defined を消す。
メール添付の音声3gpをmp3に変更
子どもにsoftbankの見守り携帯を持たせてみた。 だけど、音声メールを送る機能があるんだけど、 添付ファイルが 3gp 形式。 iPhoneで見ようと思っても、かなり面倒くさい。
ということで、自宅サーバの特設メールアドレスに送らせて、 添付ファイルのデータ形式を変更して再送させるプログラムを作ってみた。
気まぐれで書いたから、節操無く統一性もなく perl module 呼び出している汚いコードだな。 処理内容は、添付ファイルを分解し、".3gp"の添付だけ、".mp3"を作って、 改めて添付ファイルを作成して送信。 ただし、音声添付無しのメールも飛ぶので、単純テキストはそのまま送る。
試しに動かしてみたが、自宅に見守り携帯が届く段階で、graylist にひっかかり、 一旦受付拒否されてやんの。softbank.ne.jp だし whitelist には入れられないしなぁ。 まあ、メールが届くのが数分遅れるだけだけどさ。
libperl5.18のインストールでトラブル
いつものように、Debianのパッケージ更新をかけていたら、 munin-cron の中で動かなくなるアプリがチラホラ。 さらに、MovableType も記事のPostができなくなる。
両方ともPerl関連のパッケージなので、Perlが原因と思われる。 /var/log/aptitude で今日入れたパッケージを確認したら、 全般に絡みそうなものは、libperl5.18 であった。 試しに、"aptitude install libperl5.14"を実行させ、 関連パッケージもまとめて、ダウングレードさせたら、 ひとまず動かなくなったものが動き出す。
当面は、libperl5.18 が入らないように、"aptitude hold libperl5.14"を実行しておく。
メール送信が動いてなかった
ハードディスクの故障からの復帰明け、ノートパソコンから メールを出そうとするが認証に失敗する。色々確かめたら、 SMTP-AUTH の設定がしてなかった。 Web記事をみて、sasl2-bin などを入れたけど、相変わらず認証に失敗するので、 色々調べて設定を書き加えるために、Web記事を探せば探すほど、 「この設定、前回絶対つまずいて同じこと調べてたよなぁ…」という状態。 調べるにしても、自前である程度解決できるようにメモを残す。 (といっても他の記事のコピペ)
postfix で 465 の SMTP-AUTH でメールを受け取るには、 sasl 認証が必要。
(( sasl関係をインストール)) # aptitude install sasl2-bin libsasl2-modules
これで動くかと思ったけど、動き出さない。 postfix と saslauthd の設定を触る。
(( /etc/postfix/main.cf )) smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = $mydomain smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service inet:127.0.0.1:10023 smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service inet:127.0.0.1:10023 (( smtp が chroot で動いているか確認 )) /etc/postfix/master.cf で "smtp inet n - y - - smtpd" とか"smtp inet n - - - - smtpd"と書いてあるならchroot (( /etc/default/saslauthd )) START=yes MECHANISMS="pam" OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd" # 元々の OPTIONS="-c -m /var/run/saslauthd" は、 # 非 chroot の設定用だった。
サーバで入れたパッケージ
(( セキュリティ系 )) ferm iptables ipset geoip-bin libapache2-mod-geoip php5-geoip (( システム監視系 )) nagios3 munin munin-node lua50 libcgi-fast-perl ntpdate ntp (( メール関連 )) postfix postgrey clamav spamassassin sasl2-bin libsasl2-modules dovecot-imapd dovecot-pop3d (( web関係 )) movabletype-opensource movabletype-plugin-core roundcube roundcube-sqlite3 roundcube-plugins sqlite3 (( perlモジュール )) libdatetime-format-w3cdtf-perl libnet-google-calendar-perl libnet-google-perl libemail-sender-simple-perl libemail-sender-perl libjcode-perl libjcode-pm-perl libdevice-serialport-perl (( その他 )) php-elisp anthy anthy-el jhead
サーバHDD故障
サーバの root パーティションのHDDが故障して、 ディスクの入れ替え。
データはバックアップがとってあって、特に問題はないけど、 新しくサーバのOSを入れ替えたもんだから、設定ファイルを ボチボチコピー。そのまままるコピーすると、 設定のバージョン違いやら、ファイルのUID違いやらで、 そのままでは動かない。
PHP Opcacheで高速化?
Webの記事を見ていたら、PHP5.5でOpcacheなる 機能が組み込まれているというので、早々に 設定してみた。
PHPはインタプリタだけど、Apacheに寄生することで、 インタプリタの起動負荷を削減しているが、 PHPコードを読んで内部コードに変換する手間は、 毎回発生している。
しかし、PHP5.5では、Opcode Cache なる機能が組み込まれ、 内部コードを次回起動に備えキャッシングしてくれるらしい。
設定は、apacheのモジュールみたいなので設定するのかと 思ったけど、/etc/php5/apache2/php.ini で設定するだけか…
(( /etc/php5/apache2/php.ini )) [opcache] ; Determines if Zend OPCache is enabled opcache.enable=1
んで、効果のほどは… うーん、自宅サーバ程度の負荷じゃ、利点が解からん…
この2週間の間に、OS再入替えになるとは…
Debian/unstable で運用していたら、パッケージのコンフリクト解消処理が 止まらず、全部最新にしちゃえと"aptitude full-upgrade"を実行したら、 なんか perl のパッケージの衝突が発生し、それなりに管理してきた perl モジュールがごっそり消えた。
さらに、linux-image も最新が、現行バージョンと衝突し、 「現行kernelを消す?」ってぇのも疑心暗鬼のパッケージ修正中に あやまって yes しちゃったようで、kernel が変な状態のなか、reboot を実行して、kernel が見つからず、OSが立ち上がらなくなった。
boot CDイメージのRescueも試したけど、設定の知識不足もあって まるっきりダメ。2週間前に同じことやってるし、まだ覚えている だろうからと OS 再インストールを決意。
今度は、Debian/testing にしておこう…(x_x;

