今までSPAM対策でNorton AntiSpam 2004を利用していて、 まあ比較的学習効果は高かったのだけど以下の点が不満でした。
と、結構使いにくい面があります。それでも8ヶ月程度使い続けてきたのですが、この度Windows用のPOPFile 0.22.2を導入しました。
POPFile自体もPerlで記述されているのでちょっと速度面で心配があり、なかなか導入に踏み込めなかったので、 最初は自宅のFreeBSDサーバに入れてWindows→FreeBSD→プロバイダ、経由でメールを受信しようと思ったのですが、 FreeBSDは既に独自ドメインのメールサーバとして運用しているのでPOPのポート110番は使えません。
POPFileのポート番号を変更して使ってみたのですが、それだとWindowsから110番以外のポートでメールを受信すると、 Norton Anti Virusが動作しないという致命的な事になってしまいました。
仕方ないのでWindowsの方にPOPFileを入れて、一時的にNorton AntiSpamを停止しました。
まだ、数通しか受信していないので学習効果と、データが増えてきた際のパフォーマンスの低下具合については分かりませんが、 とりあえず前よりは快適な環境になりました。
また受信メールが溜まってSPAM判定がどの程度かデータが出たら追記します。
少なくともNorton AntiSpamは遅くて話になりません。2005も発売しているみたいですが、 あまり素敵な機能追加はないようです。
いつの間にか、Intelのサイトから直にIntel PRO/Wireless 2200BGのドライバがダウンロード出来るようになっていました。
今まではDELLのUSサイトとか探して最新を落としていたのですが、これからは安心してダウンロードできますね。なんか、 メジャーバージョンも9になっているし…
ドライバはマルチランゲージ対応なので日本語でちゃんと表示されます。私がダウンロードした際に、Master Siteから落とした物は解凍に失敗してしまったので、Mirror Siteから落としました。なんででしょうねぇ。
http://support.intel.com/support/wireless/wlan/sb/CS-010623.htm
リンク切れしてたらコメント下さい。
■感想
Version 9はGUIは今までから一新され、結構使いやすそうなイメージを持ちました。
Version 8の最終版でも問題解決なのですが、 前はputtyでssh通信をして大量のパケット受信を行うとputtyがエラーで終了してしまう問題があったのですが、 とりあえず解決したっぽいです。
Version 9はNetstumblerはデフォルトのデバイスではアクセスポイントを探してくれないので、 Deviceメニューから「NDIS5.1」の方を選ぶと正しく動作するようです。
【後日談】
デバイスドライバのVersion 9.0.1.9
は非常に不安定だと言うことが分かりました。長時間放置していると繋がらなくなったりするみたいです(ウチの環境では)
とりあえずVersion 8系の最終版に戻して普通に使えるようになりました。
【後日談(2005/7/31)】
デバイスドライバのVersion 9.0.2.0
に上げたら安定しました。無線APも変更したのでそのせいかもしれません。
IntelのサイトではVersion 8系はもう配布していないみたいです。
FreeBSD 5.xは最小構成のインストールでもlang/perl5のパッケージがインストールされるように出来ています。
長いこと使っていると幾つものPerlモジュールを追加していくことになりますが、単純にlang/perl5を削除して、 lang/perl5.8を入れても、 後から追加した各種モジュールは/usr/local/lib/perl5/site_perl/5.6.1配下にあるため、 DBI等色々使えなくなって、例えばこのサイトで使用しているMovableTypeも動作しなくなります。
本エントリではPerlの追加モジュールはportsから全てインストールしている方向けのちょっと無理やりなperlアップグレード方法を紹介します。
pkg_delete -f perl-5.6.1_15で強制的にperl5.6.1を削除します。
次にportinstall lang/perl5.8で新しいperlを入れます。
一応入れ終わったらuse.perl portを実行して/etc/make.confを更新しましょう。
最後にpkgdb -Fでperl5.6.1を見ているパッケージ達を5.8.5に変更してあげましょう。
基本的にports/packageから入れたperlモジュールは名前に「p5-」が含まれていますので、 そのportsを再インストールします。以下のコマンドを打ち込んでください。
# setenv FORCE_PKG_REGISTER
# portupgrade -f `pkg_info | grep p5- | awk '{print $1}'`
これで、 大体のperlモジュールが/usr/local/lib/perl5/site_perl/5.6.1から5.8.5に移動するはずです。
他にもmrtgやnet-snmp、ImageMagickにもperlモジュールが含まれているので、 それらは手動でportupgrade -fしてあげます。 この辺の移行が足りないperlモジュールはsiteperl/5.6.1配下に残っているファイルから想像して手動で入れてください。
この方法は途中で止めてしまいましたが、Officialな更新の仕方みたいです。
ports/packageでperlを必要としているパッケージ全てをリビルドすれば完全に移行できますが、 その分リビルドの時間もかかりますし、perlモジュールを持たないものまでリビルドしてしまいます。
# portupgrade -f `(pkg_info -R perl-5.8.5 |tail +4; find /usr/local/lib/perl5/site_perl/5.8.5 -type f -print0 | xargs -0 pkg_which -fv | sed -e '/: ?/d' -e 's/.*: //')|sort -u`
一応上記コマンドでperlを使用しているパッケージ全てを更新するみたいです。
とりあえずMovableTypeがまともに動けばいいやーの気持ちで上記作業を行いましたが、今のところ問題なく動いています。
今後perlの5.8系が新しくなったときはsiteperl/5.8.5の内容をコピーするだけで問題ないかなと思っています。 また、新しいVersionが出たらこのエントリに追記予定です。
今現在は管理者とサーバは賃貸マンションにいるのですが、適度なタイミングで実家に引っ越そうと考えています。 実家にはインターネット回線といえば、ダイアルアップのモデムしかないので、 引っ越す際には光なりCATVなりのそれなりの回線を準備する必要があります。
それに伴い、この自宅サーバ雑記帳も引く回線によっては1、2ヶ月の間自前のサーバで運用出来ないことも考えられます。そこで、 いつでも自宅の環境をXREAのサーバに移行できる準備を事前に行っています。
このエントリではバージョンの大きく異なるMySQLのデータを移行させるためのTIPSを説明しています。
hijiki.netはValueDomainで取得していますが、 ここで取得するともれなくXREAのレンタルサーバが1ドメインにつき1アカウント無条件に取得出来ます。
追加料金を払うとページの上下に強制的に表示されるバナー広告の免除もできるほか、各種CGIも比較的緩い制限で利用できます。 XOOPSやPukiWiki、MovableType等に必要なモジュールも標準で用意されている他、DBもPostgreSQLか、 MySQLを利用できます。
基本的には以下の手順で移行できます
実際の所前述作業の中で、MySQLのexportでちょっと詰まりました。家の環境ではMySQLは4.1系を使っているのですが、 XREAでは4.0系を利用しており、 普通にmysqldumpをパラメータなしで実行しただけでは互換性がなく正常にXREA側でimportできません。 ビックリしたのはman mysqldump見ても書かれていなかったのですが、mysqldump --helpを見て解決しました。
それは--compatibleオプションで、mysqldump --compatible=mysql40… とすると出力されるSQLファイルを4.0系のものに変換して出力してくれるのです。 驚いたのがoracleやPostgreSQLへ変換するパラメータも有ることです。これは便利だ。
また、 MySQLはFreeBSDのPortsから何も手を加えずにインストールしているのでデフォルトの文字コードはlatin1になっている事です。 通常では別にlatin1でも好きな文字コードのレコードを格納しても、その文字カラムでのソートを行わない限り全く問題ないのですが、 mysqldumpがexport時に勝手にlatin1→EUCへの文字コード変換を行おうとするのか、 日本語部分が化け化けになって出力されてしまいます。
それを回避するのが--default-character-set=latin1です。 これを入れればexport時に文字コード変換を行わないで出力されます。
よって、mysqldumpを実行する時には以下の書式で行います。
mysqldump --compatible=mysql40 --default-character-set=latin1 -uユーザ名 DB名 -pパスワード > 出力ファイル名
これで、exportしたファイルはDB上に格納されている文字コードと同一のものが取得できます。 うちの場合はEUC-JPコードで取れました。
今までずっとPostgreSQLを使っていて、pg_dumpでは特に文字コードを意識したことはなかったのですが、 今回MySQLにして調べ始めたときには唖然としてしまいました。
半分意地で調べた結果、意外とMySQLは多環境に優しい優れたDBだと言うことが分かりました。 最近のVersionではSQLの副問い合わせにも対応したみたいで、もしかしてPostgreSQLよりも凄いのではと思い始めています。
とりあえず今回の調査で、いつでも自宅サーバをXREAにデータ移行できる事がわかりました。 DNSの変更をすれば利用している方々にはサーバが変わったことなど全く気づかないでスムーズに行けそうです。
さあ、引っ越し費用を稼がないと(笑)


