MySQL 4.1から5.*系に移行する時など、フィールドの文字セットがlatin1に設定されちゃって5.*系でそのまま読み込むと文字化けすることがある。 MySQL 4.1側で/etc/my.cnfをちょっと変更
[mysqld]
max_connections=30
default-character-set = binary
skip-character-set-client-handshake

(↑これはいらないかもしれない)

% mysqldump -u root -p --default-character-set=binary DBNAME > DBNAME.sql

--default-character-setを指定して書き出して

% perl -pi -e 's/latin1/utf8/' DBNAME.sql

latin1という文字をutf8に直して、あとはmysql(5.*系)からsourceで読み込むだけ。

ただし、mysqldumpでlatin1->utf8変換されちゃったダンプデータでは駄目。
mysqlのDBはファイル単位でコピーできるので、古いDBファイルをコピって
dumpしなおせばなんとかなる。

19:56 >meow< うおおおお
19:57 >meow< いま、サーバのセットアップしてるんだが
19:57 >meow< up2date -i wu-ftpd
19:57 >meow< ってやったら、持ってきて入れた！

IRCのログから、原文ママ

ようするに、RedHat Networkから最新版を勝手にダウンロードしてインストール（アップデートでないとこがキモ）してくれるってことです。

これって最初からそうだったっけかなぁ･･･
（段々と文体も乱れてきた今日この頃･･･）

古いバージョンのRedHat（8.0以前）を利用していると、up2dateを実行した時に、

Error communicating with server.
The message was: SSL_connect error

というエラーがでてupdateできなくなることがあります。

これは、Red Hat Linux 7.1,7.2, 7.3 （と、Red Hat Enterprise Linux AS, ES, WS ver2.1 ）のup2dateが使用するSSL証明書が2003/8/28に失効してしまっているためです。

https://rhn.redhat.com/help/latest-up2date.pxt

ここから対応するup2dateのパッケージをダウンロードして手動でアップデートすれば、新たな証明書がインストールされ、up2date -u できるようになります。

突如うちのsendmail君が送信メールを受け付けなくなってしまいました。

ログをみると、
Aug 23 13:38:02 mail sendmail[1989]: NOQUEUE: ****.ne.jp [***.***.***.***] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
てなメッセージが出ていました。



sendmailの設定としては
・SMTP AUTH 対応
・ハートさんを参考にRBLを使用してSPAM対策
という設定を施してあります。

このRBLとして、ORDBとSPAMCOPとOSIRUSOFTを利用していたのですが、このうちOSIRUSOFTが応答を返さなくなってしまったために、SMTPのセッション自体がタイムアウトしてしまっていました。
OSIRUSOFTを利用しないようにsendmail.cfを書き換えてsendmailのりスタートで問題なく送信できるようになりました。

以前からOSIRUSOFTのサイト自体も重く、WEBページが表示できないことが多かったのですが･･･
かなりのSPAM防御力だっただけに、惜しい感じです。

忙しさにかまけてて、ものすごい久々ですが･･･

溢れた話その１

仕事で管理しているサーバが、ある日変な挙動を起こしてとまりました。
PHP+PostgreSQLのシステムが動いていたのですが、突如PostgreSQLが止まったっきり、起動してくれなくなってしまいました。
データが壊れたかと焦りまくったのですが･･･

何のことは無い/varのパーティションが一杯になってしまってPostgreSQLがデータを書き換えられなくなって止まった（＆起動不可能になった）ようです。
原因は/var/spool/mailに山のようにメールを溜めた人がいたせいでした。
サーバまるごとをレンタル会社から借りたので、OSのインストールも当然向こうのデフォルトだったのですが、/ /usr /home /varの4つのパーティションを切るという歴史的な構成で、なおかつ/varが256M「しか」ありませんでした・・・
いや、本来は256Mもありゃ充分なんだけど・・・なんでか/usrに20Gも割り当てられてんだよね(^^;
翌日PostgreSQLのデータは隣のパーティションに引っ越しましたとさ。

教訓その１：サーバ借りたらdfしましょう

溢れた話その２

このサイトを動かしているサーバで、いつものようにup2date -uしてみると･･･
「/bootが一杯でupdateできないよ」
てなメッセージが出ました。
ありゃ？と思って
rpm -qa | grep kernel
してみると･･･

kernel-2.4.7-10
kernel-2.4.9-21
kernel-2.4.9-31
kernel-2.4.9-34
kernel-2.4.18-17.7.x
kernel-2.4.18-19.7.x
kernel-2.4.18-26.7.x
kernel-headers-2.4.9-34
kernel-2.4.18-24.7.x
kernel-2.4.20-18.7

教訓その２：たまには/bootも掃除しましょう

SlashDotでmojixさんの「国内でZopeを普及させる目的の会社設立 」という記事を読んで、昔ちょこっとだけさわったZopeをまたいじってみました。

顛末を書いたのですが、長くなりましたので、特集記事におきました。

phpにimapモジュールを組み込むと、WEB上でメールを確認するようなページを簡単に作成できます。
また、わざわざ作らずともIMP等をインストールする事でもWEBメールシステムを構築できます。

ただし、RedHat系のRPMを使っているディストリビューションでは、最近のPHPのアップデートに伴い、ちょっとしたエラーが発生します。

具体的には、ID/PWを正しく入力してもimapサーバに接続できないといった現象が発生します。
このとき、maillog（/var/log/maillog）には以下のようなメッセージが記録されます。

Oct 1 23:56:48 server imapd[17564]: Command stream end of file, while reading l
ine user=??? host=UNKNOWN

これはphp-imapモジュールがデフォルトでimap-sslを使用してサーバに接続する設定になっているためです。

これに対処するには
$mbox = imap_open( "{localhost:143}INBOX",$ID,$PASS);
↓
$mbox = imap_open( "{localhost:143/notls}INBOX",$ID,$PASS);
という風にimap_openでの接続パラメータに「/notls」を追加することで対処できます。
また、サーバ側でimapsdを起動するように設定することでも対応できると思われます。

impでの対処とRedHatへのインストールには↓が参考になります。
http://www.trustbee.com/impjp/setup_rh73.php

AMULETさんの
・Postfixフィルタリング
を参考に、ウィルスフィルタを設定してみました。

/etc/postfix/body_checksに

/name=\".*\.[Ee][Xx][Ee]\"/ REJECT
/name=\".*\.[Cc][Oo][Mm]\"/ REJECT
/name=\".*\.[Vv][Bb][Ss]\"/ REJECT
/name=\".*\.[Vv][Bb]\"/ REJECT
/name=\".*\.[Jj][Ss]\"/ REJECT
/name=\".*\.[Ul][Rr][Ll]\"/ REJECT
/name=\".*\.[Bb][Aa][Tt]\"/ REJECT
/name=\".*\.[Hh][Tt][Aa]\"/ REJECT
/name=\".*\.[Hh][Tt][Tt]\"/ REJECT
/name=\".*\.[Ii][Nn][Ff]\"/ REJECT
/name=\".*\.[Rr][Ee][Gg]\"/ REJECT
/name=\".*\.[Dd][Ll][Ll]\"/ REJECT
/name=\".*\.[Pp][Ii][Ff]\"/ REJECT

という感じです。

この設定をする際に、main.cf内にbody_checks項目が無いために、このPostfixは対応したバージョンなのかと悩みました。
そもそも、一体この機能はPostfixのどのバージョンから有効なの？と思い、調べたので、以下にそれをまとめておきます。

20000528　　　body_checks=regexp:/file/nameを実装
20000911　　　IGNOREキーワードを追加
20010116　　　REJECTキーワードに対するBUGFIX

ということで、20010116以降から対応と見たほうが良いようです

RPMでパッケージをインストールする際に、
エラー: 依存性の欠如:
(error: failed dependencies:)
といったエラーメッセージが表示されてインストール出来ない場合があります。

この場合、RPMパッケージの名前で足りないものを表示してくれれば楽なのですが、*.soといったライブラリのファイル名で表示された場合、そのライブラリがどのパッケージに入っているのかが解らず、探すのに一苦労ということが良くあります。

これはバイナリ作成時（RPMパッケージ作成時）に必要とされたライブラリが、自動的にRPMの依存対象としてリストアップされるためです。

こういう時には、/cdrom/RedHat/RPMS等の依存しているRPMが入っているであろうディレクトリで
# rpm -qp --filesbypkg * | grep ファイル名
という検索をすれば見つけ出す事が出来ます。ただし、非常に遅いので全てのRPMを検索対象にせず、例えば「*lib*」等を対象にした方がいいでしょう。

例えば、

# rpm -i --test gnorpm-0.96-1.i386.rpm
エラー: 依存性の欠如:
        usermode >= 1.13は gnorpm-0.96-1 に必要とされています
        libart_lgpl.so.2  は gnorpm-0.96-1 に必要とされています
        libaudiofile.so.0  は gnorpm-0.96-1 に必要とされています
          ：
          ： （省略）

といった感じで表示される場合があります。

この場合、usermodeはパッケージ名なので、usermode-*.i386.rpmというRPMを探してインストールすれば、依存性の問題は解決できます。
しかし、libart_lgpl.so.2は、ライブラリのファイル名なので、このライブラリがどのRPMに含まれているのかを見つけ出さなければなりません。（RedHat7.1の場合、libart*.rpmといったRPMはありません）

こういう時には、

# rpm -qp --filesbypkg *lib* | grep libart_lgpl
gnome-libs                /usr/lib/libart_lgpl.so.2
gnome-libs                /usr/lib/libart_lgpl.so.2.2.0

という具合に検索することで見つけ出す事ができます。
つまりlibart_lgpl.so.2はgnome-libs*.rpmに入っているということです。

覚え書きシリーズです。
（RedHat7.1以降の標準RPMが前提）
----
sendmail.mcを変更した後、sendmail.cfを作るには…

m4 /etc/mail/sendmail.mc > /etc/sendmail.cf

----
DB形式のファイルにする必要がある設定ファイルは…

access、 domaintable、mailertable 、 virtusertableなど

makemap hash /etc/mail/access.db < /etc/mail/access

として、DBファイルを作る
/etc/mail 内にあるMakefileに書かれているので、make all でもOK

----
SMTP AUTH対応にするには…
cyrus-saslのパッケージを入れておく必要がある。

Sendmail.mcの次の行の行頭の「dnl 」を削除して、sendmail.cfを作り直す。

Dnl TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
dnl define(`confAUTH_MECHANISMS', `DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl

----
バーチャルドメイン
sendmail.mcの次の行の先頭に「dnl 」が付いてないことを確認する

FEATURE(virtusertable, `hash /etc/mail/virtusertable')dnl

local-host-namesにメール受信を受け付けるドメインを書く。次にvirtusertableに実際のユーザー名とメールアドレスの対応を書く

例：
meow@virtual.domain meow
(meow@virtual.domain 宛に届いたメールをmeowというアカウント宛のメールとして受信する）

@virtual.domain error : 550 User unknown
(それ以外のアドレスはエラーにする)

上から順番に読み込まれるので、注意。最後のエラー行以降にいくらアドレスを書いても、それは無効になる。

最後に、make allまたは、
makemap hash virtusertable.db < virtusertable


こっちのニュースも参考にしてください。

ディストリビューションによりますが、インストールCDのイメージを丸ごと吸い出してどっかのディレクトリに置いておくと非常に楽になるケースがあります。 私はRedHat系のディストリビューションをインストールすると、まずはインストールCDの内容を吸い出して、/opt/ディレクトリにおいておきます。 そうすれば、納品後も外からCDをマウントしたのと同じように扱えて非常に楽チン:-D 吸い出し方 CDをCDドライブに入れてから・・
# dd if=/dev/cdrom of=/opt/imagename.iso
マウント方法
# mount -o loop /opt/imagename.iso /mnt/dir
という感じでOK

毎回調べちゃ、次に使う時に、忘れちゃってたりするオプションの覚え書き ディレクトリをまとめてtar.gzにかためる
# tar czf /tmp/backup.tar.gz /home/hoge

# tar cpzf /tmp/backup.tar.gz /home/hoge のように、「p」つけるとパーミッション情報も含まれます。 展開するときにも「p」つけるとパーミッションも設定も込みで展開されます。 展開の # tar zxvf backup.tar.gz は、猛烈に沢山使うので指が覚えてるんだけどね :-D

PHPのセキュリティFIXのためにRedHatからRPMのUPDATEが出ています。 [b]3/21[/b]に再度新しいものが出ましたので、必要のある方は、DL後UPDATEするか、up2date -uしましょう。 7.1用のものは、php-4.0.6-14.(i386).rpm 7.2用としては、php-4.0.6-15.(i386).rpm が最新のものになります。

[b]3/11[/b]の段階で RedHat 7.1用のものは、php-4.0.6-9.7.1 RedHat 7.2用のものは、php-4.0.6-12 でした。（なかなか、PHP-4.1.0系になりませんね ^^;） これでFIXされたと思ってたのですが、何の気になしにup2dateをかけたら、いきなりupdateが始まってびっくりしました。 なお、これに伴い、ftpで公開していたRPMは削除しました。 #でも、何でアナウンスもなかったんだろう・・パッケージングミスかな？

PHP-Users MLでAPCの実効速度の話が出てきたので、再びAPCを入れてみました :-) 現在、APC 1.1.0pl1 を extension=php_apc.so apc.mode = shm というオプションで動かしてます。 速度の体感が目的なので、apacheのmod_gzipはOFFにしました。また、XOOPSのGZIP圧縮オプションもOFFにしてあります。

--- APCのインストールメモ 以下のメモは、Redhat 7.1 に php-4.0.6-9.7.1 (RedHat配布のSRPMに --enable-mbstring --enable-mbstr-enc-trans を追加して、RPMをrebuildしたもの）をインストールした環境を想定しています。 APC自体はPHPに組み込まず、モジュールの形で組み込んでいます。 まず、APCのコンパイルの為にphpize,php-configを使いますので、php-develパッケージをインストールしておきます（上記 RedHat配布のRPMを使用している場合）。 # tar xzvf apc.tar.gz # cd apc-1.1.0pl1 # phpize # ./configure --enable-apc --with-php-config=/usr/bin/php-config # cp modules/php_apc.so /usr/lib/php4/ /etc/php.ini に extension=php_apc.so apc.mode = shm を追加し、httpd を再起動すればAPCが有効になります。 phpinfo();などで確認できます。 で、実際の体感速度ですが・・・・どうっすか？

panic-net.org宛てのメールがちゃんと届いてなかったので、調べて見ました。 ここにある公式ドキュメントを参考に/etc/mailの中とか調べたのですが全然問題なし。 そもそも、外部からのSMTP接続を、全部rejectしているので、ipchains/iptablesの設定を、調べまくったのですが、これも全く問題無し・・・ 散々検索しまくって発見した、このページによると、RedHat 7.1に標準でインストールされるsendmail.cfは、localhostからの接続しか受け付けないそうです^^;

具体的には、/etc/mail/sendmail.mc のDAEMON_OPTIONS で指定されているaddr=127.0.0.1,を消すか、SMTPを受け付けたいインターフェースのアドレスに書き換えればOK 最近だとインストールするだけで、sendmail.cfとかいじらなくても動くパターンが多かったので油断してた・・ メールサーバとして運用するなら、sendmail.cfくらいちゃんと自分で作らないと駄目か・・、と、思った反面、「メールサーバ」としてインストールしたんだから、最初から外部からのメールをちゃんと受け取ってくれよ^^;と思うナリ とほほ

dengaku.org/yasu/ を参考に、ircd 2.10.3+jp6をRedHat7.1向けのRPMにしました。 ここの「ダウンロード」に置いておきます

RPMs built by Troels Arvinで待望のPHP4.0.6（RedHat7.1版）が公開されましたが、残念ながらマルチバイト関数についてはdisableの状態でBuildされたもののようです。 というわけで、'--enable-mbstring --enable-mbstr-enc-trans'をつけてRebuildしたものを「ダウンロード」に登録しておきました。 いくつかのモジュールについては、途中で登録に飽きちゃったため登録してありませんが、ftp://ftp.panic-net.org/pub/ に置いてあります。

PHP4.0.6では、apcというPHPのキャッシュが利用できます。 http://apc.communityconnect.com/ これは、PHPのスクリプトの、読み込み・解析・実行のプロセスのうち、読み込み・解析まで済んだものを、mmapもしくは共有メモリ上にキャッシュしておくことで、PHPスクリプトの実行を高速化するものです。 呼び出しから2回目以降では、個別のスクリプトファイルの読み込みと解析までの処理が要らなくなるため、かなりの高速化が見込めます。 FAQによると50～400%の高速化が見込めるそうです。 （スクリプトによっては、遅くなる場合もあることに注意） しかし、これにもちょっとした罠が・・・

デフォルトの設定のままだと、apcはPHPのファイルを変更しても自動で再読み込みしてくれません。 つまり、ちょこっと修正してはテスト、といった開発中によくあるパターンの作業とか、ちょっとしたバグ修正などが反映されないのです。 これを避けるには ・PHPファイルを変更後にはApacheをリスタートする 　これによって、全てのキャッシュが破棄され、再読み込みされます。 ・apc.check_mtime = 1 をphp.iniに追加する 　apcエンジンが毎回ファイルの変更を確認するようになります。 　当然オーバーヘッドが大きくなり、遅くなる場合も多くなります。 　また、共有メモリモードでしか使用できません。 ・ちょこちょこいじっている間はapcを使わない(笑) といった方法があります。 このサイトでは、とりあえず、apcはOFFにしてあります。 また、apcをonの場合だけエラーになるスクリプトというものもあります。 apcではglobal変数の扱いに厳しいため（phpはgloban変数の扱いを間違っていてもある程度見逃してしまう）このような現象がおこるようです。 どのみち、このような場合は、スクリプトに潜在的なバグが潜んでいることになりますので、見直しが必要でしょう。 モジュールの場合に、apcを有効にするphp.iniへの追加項目 extension=php_apc.so apc.mode = shm （共有メモリモードでの利用の場合) 最後に、apcの別の使い方として、解析まで完了したPHPのバイトコードを保存し、配布するといったことができます。 これをうまくつかうと、「ソースを見せたくないけどPHPは使いたい」場合に、Zend Encoder Unlimited等を購入しなくてもある程度は対応できそうです。 （逆コンパイルが簡単そうなので、相手の技術レベルにもよりますが・・・）

---

Contents

• Linux
• XOOPS
• その他