すでに FreeBSD は8系がメインとなっていますが、安定版を愛する我がサーバーでは FreeBSD 7.3 を使用しています。
今更ながらの話しですが、メモリの使用効率が FreeBSD 6系よりも向上していることを日々 top コマンドを叩く度に実感しています。着実に FreeBSD は向上しているようです。
これはサーバーをリブートしてから7日めの様子です。
もうとにかく swap の使用が僅少なのです。このサーバーには1.6GBのメモリを搭載していますが、swap をほとんど使用していないのです。以前のFreeBSD 6.3 では 1MB 程度をオーバーライドしていたものですが、現在は 4kB しか使用していません。いかにメモリを効率よく使用しているかが判ります。
気分的には FreeBSD 8系へアップグレードしたい気持ちがあるのですが、せっかく調子よく動いているものを触って面倒なことになる危険性(リスク)を背負ってまでする必要はないと常々考えているため、まだまだ FreeBSD 7系にとどまっている予定です。
2010年4月18日日曜日
2010年4月13日火曜日
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.
小さな変更がばたばたと訪れることは意外とよくあることで、毎日の更新を心がけている人にとっては辛いときもあります。
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.
2010年4月12日月曜日
canna-serverのアップデート
しばらく ports が壊れていた canna-server ですが、ようやく復旧したようです。そして新しいアップデートも着ていました。
ja-canna-lib-3.7p3_6 -> 3.7p3_7
ja-canna-server-3.7p3_7 -> 3.7p3_8
いつものように portupgrade -a でアップデートの処理をしました。
ja-canna-lib-3.7p3_6 -> 3.7p3_7
ja-canna-server-3.7p3_7 -> 3.7p3_8
いつものように portupgrade -a でアップデートの処理をしました。
2010年4月11日日曜日
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_reporting を 0 ゼロに設定して取り合えず、対応しました。このままでは根本的な解決となっていないため、何とかしなければと思っているところです。
結局 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
マイナーアップグレードだと甘く見ていました。しょんぼりです。
ネット上でもいろいろ情報が出回っていて、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_reporting を 0 ゼロに設定して取り合えず、対応しました。このままでは根本的な解決となっていないため、何とかしなければと思っているところです。
結局 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
2010年4月10日土曜日
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で総再インストールをしました。
今回はアップデートではなくアップグレードとなるようです。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で総再インストールをしました。
2010年4月8日木曜日
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 関連を再インストールしたら消えていました。
というか、アップグレードして今まで気づいていませんでした。しょんぼりです。
メールサーバーとして使用している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 関連を再インストールしたら消えていました。
FreeBSD cups関連のアップデート
cups 関係のアップデートもやってきました。
cups-base < needs updating (port has 1.4.3)
cups-client < needs updating (port has 1.4.3)
cups-image < needs updating (port has 1.4.3)
メールの自動処理のためにインストールしてあるfetchmailもアップデートでした。
fetchmail < needs updating (port has 6.3.16)
cups-base < needs updating (port has 1.4.3)
cups-client < needs updating (port has 1.4.3)
cups-image < needs updating (port has 1.4.3)
メールの自動処理のためにインストールしてあるfetchmailもアップデートでした。
fetchmail < needs updating (port has 6.3.16)
php5 のアップデート
このところ立て続けに php5 のアップデートが入っています。
php5 < needs updating (port has 5.2.12_2)
いつものように関連 ports と一緒に portupgrade -a で処理しました。
php5 < needs updating (port has 5.2.12_2)
いつものように関連 ports と一緒に portupgrade -a で処理しました。
2010年4月4日日曜日
FreeBSD 7.2 -> 7.3 アップグレード
ようやく FreeBSD の 7.2 から 7.3 へアップグレードしました。
手順はマニュアル通りにしました。
csup でソースコードのアップグレード。
make buildworld && make buildkernel でシステムのビルド、と、インストール
mergemaster -Ui で一気に /etc の更新を行いました。もちろん /etc のバックアップをとってからです。
インストールしてあるアプリケーションソフトも portupgrade -af --batch で再ビルドを行ってライブラリなどの依存関係をクリアにしておきました。
システムやアプリケーションのビルドに際しては、/etc/make.conf に CPUTYPE?=pentium4 のようなアーキテクチャを指定して最適化を行っています。指定なしとの比較を行ったことがありませんが、気分的に「最適化」というビルドを行ったプラシーボ効果で満足しています。
それからアップグレードして快適になったなどのメリットはありません。しかし安定版の最新バージョンということでの安心感を得たことは大きいと思っています。
手順はマニュアル通りにしました。
csup でソースコードのアップグレード。
make buildworld && make buildkernel でシステムのビルド、と、インストール
mergemaster -Ui で一気に /etc の更新を行いました。もちろん /etc のバックアップをとってからです。
インストールしてあるアプリケーションソフトも portupgrade -af --batch で再ビルドを行ってライブラリなどの依存関係をクリアにしておきました。
システムやアプリケーションのビルドに際しては、/etc/make.conf に CPUTYPE?=pentium4 のようなアーキテクチャを指定して最適化を行っています。指定なしとの比較を行ったことがありませんが、気分的に「最適化」というビルドを行ったプラシーボ効果で満足しています。
それからアップグレードして快適になったなどのメリットはありません。しかし安定版の最新バージョンということでの安心感を得たことは大きいと思っています。
登録:
投稿 (Atom)