メモリ効率の上がった FreeBSD 7系

 すでに FreeBSD は8系がメインとなっていますが、安定版を愛する我がサーバーでは FreeBSD 7.3 を使用しています。

 今更ながらの話しですが、メモリの使用効率が FreeBSD 6系よりも向上していることを日々 top コマンドを叩く度に実感しています。着実に FreeBSD は向上しているようです。

 これはサーバーをリブートしてから7日めの様子です。

 もうとにかく swap の使用が僅少なのです。このサーバーには1.6GBのメモリを搭載していますが、swap をほとんど使用していないのです。以前のFreeBSD 6.3 では 1MB 程度をオーバーライドしていたものですが、現在は 4kB しか使用していません。いかにメモリを効率よく使用しているかが判ります。

 気分的には FreeBSD 8系へアップグレードしたい気持ちがあるのですが、せっかく調子よく動いているものを触って面倒なことになる危険性(リスク)を背負ってまでする必要はないと常々考えているため、まだまだ FreeBSD 7系にとどまっている予定です。

canna-server の再アップデート

昨日に引き続き今日も canna-server のアップデートがありました。

小さな変更がばたばたと訪れることは意外とよくあることで、毎日の更新を心がけている人にとっては辛いときもあります。

 ja-canna-lib-3.7p3_7 < needs updating (port has 3.7p3_8)
 ja-canna-server-3.7p3_8 < needs updating (port has 3.7p3_9)

いつものように portupgrade -a で処理しました。

portupgrade で更新が終了したら canna-server の再起動を忘れずに。

 # /usr/local/etc/rc.d/canna restart
  Stopping canna.
  Starting canna.

php5.3の困ったこと … OpenPNE で

昨日 FreeeBSD で動いているサーバーの php を 5.2 から 5.3 へアップグレードしたのですが、いろいろと困った症状が出てきました。

マイナーアップグレードだと甘く見ていました。しょんぼりです。

ネット上でもいろいろ情報が出回っていて、php のエラーレベルの変更が原因でした。キーワードは、 error_reporting です。

2chビューアの rep2 や pukiwiki には目立った問題はありませんでした。症状が大きく出たのは OpenPNE でした。

OpenPNE は昔インストールしたままの状態でアップデートを行っていませんでした。バージョンは 2.4 でした。最新は 2.14 まで進んでいるようです。2.14 だと php5.3 へ対応しているかもしれません。

Deprecated: Assigning the return value of new by reference is deprecated

〜な感じとなっています。

Warning: Directive ‘register_globals’ is deprecated in PHP 5.3 and greater in Unknown

のように php5.3 以上では対応しないディレクティブと出ているものもありました。

取り合えず、当該ページをアクセスしたとき、エラーや警告の文字で埋め尽くされることを防ぐために、openpne の設定ファイルの config.php 内の error_reporting0 ゼロに設定して取り合えず、対応しました。このままでは根本的な解決となっていないため、何とかしなければと思っているところです。

  結局 error_reporting はこれで解決しました。
  error_reporting(E_ALL & ~E_DEPRECATED & ~E_NOTICE);

それから php.ini の ‘register_globals‘ と ‘magic_quotes_gpc‘ を On から Off へ切り替えて crontab でいろいろ動作する度にエラーや警告がメールで送られてくるのを停止させました。

それから「it is not safe to rely on the system’s timezone settings. please use the date.timezone setting」と出てくるものについても php.ini へ次の [Date] の項目を追加して対応しました。古くから php.ini を使い回しているとこの様な項目が不足しているようです。

[Date]
; Defines the default timezone used by the date functions
date.timezone = Asia/Tokyo

php5 のアップグレード

FReeBSDでは連日のようにphp5のportsが更新されています。

今回はアップデートではなくアップグレードとなるようです。5.2系から5.3系へ移行。
‘php5-5.2.12_2’ to ‘php5-5.3.2’ (lang/php5)

いつものようにportupgrade -aで処理しました。

以下の三つが更新できませんでした。
php5-filter < needs updating (port has 5.3.2)
php5-pcre < needs updating (port has 5.3.2)
php5-spl < needs updating (port has 5.3.2)

/usr/ports/UPDATINGを確認すると

1) Delete the following packages (if installed):
– php5-dbase
– php5-ncurses
– php5-pcre
– php5-spl
– php5-ming
– php5-mhash
以上のportsはすでにphp5の本体(core)に含まれてしまったのだそうです。だからアンインストールして、アップグレードをするようにとの指示でした。

2) Rebuild php5 and all ports depending on it.

とありました。とほほなことをしてしまいました。安易にportupgrade -aをやってしまったつけが回ってきてしまった感じです。

php5-pcreとphp5-splをpkg_deleteでアンインストールしたあと、関連したphp5以外のportsを更新する意味を込めてportupgrade -afで総再インストールをしました。

FreeBSD 7.3 sendmail の smtp-auth エラー

先日のシステムのアップグレード(FreeBSD 7.2 -> 7.3)で初めての大きな障害が発生しました。

というか、アップグレードして今まで気づいていませんでした。しょんぼりです。

メールサーバーとして使用しているFreeBSDのサーバーマシンを経由してメールを送信しようすると、認証エラーが出てメールを送信できなくなっていました。FreeBSD 7.2 の時には問題のなかった設定のままです。

もう何年も前に設定した sendmail の smtp-auth 関係のことはすっかり記憶の彼方を飛び越えてどこかにいってしまっていました。

再度勉強がてらに設定の見直しをしてみることとしました。

格闘すること1時間、原因を見つけました。

/usr/local/lib/sasl2/Sendmail.conf が見当たりません。

参考にしていたFreeBSDの公式ハンドブックの情報では
” pwcheck_method: passwd ” と書き込めばよいとあったので、早速実行してみましたが、結果は認証エラーでした。余計に症状が悪くなったようにも感じました。

仕方なく、古いメモをいろいろ漁ってみると Sendmail.conf の内容はこれだと判明しました。
” pwcheck_method: saslauthd “

内容を修正して、sasl-auth を再起動させました。
/usr/local/etc/rc.d/saslauthd restart

さらに sendmail も再起動させました。
cd /etc/mail
make restart

これで周辺のパソコンからFreeBSDのsendmailを経由してメールを送信テストしてみましたが、無事送信することができました。

いつもメールは Windows パソコンの上から秀丸メールで直接プロバイダの smtp サーバーにアクセスしていたので異常に気づいていませんでした。
システムのアップグレードを行った時には、メールの送信テストも含めるようにしなければならないようです。

しかしこの消えてしまった Sendmail.conf はどうした原因なのでしょうか?未だに不明です。

2010-04-10追加です。
Sendmail.conf は sasl 関連を再インストールしたら消えていました。