Apcheのエラーログで
Fatal error: Allowed memory size of 16777216 bytes exhausted
が時々はき出される。

phpのmemory_limitが標準のままでは不十分らしい。

対処療法ではあるが、php.iniの記述で、
memory_limit = 256M
として、しばらく様子を見てみよう。

くどいが
/etc/init.d/httpd restart
を忘れずに。

同じようにBINDで「lame server resolving」をはき出している場合の対処法。

IPアドレスからホスト名を逆引きできなかった場合に出力されるらしい。
エラ－ではないのだけど気になるのでこれも対処した。

/etc/named.conf　に
logging {
category lame-servers { null; };
};
と追記すればいい。。
（すでにlogging { };　はあるので、その中に記述。
/etc/init.d/named restart　も忘れずに。）

BINDが「network unreachable resolving」というログを頻繁に出していた。

ちょっと気になったのでぐぐってみると、IPv6に関係しているらしい。
それもyum で Centos5.3 から 5.4 にupdateした場合の症状のようだ。

そこで、明示的にIPv6を使用しない設定をしてみた。

/etc/sysconfig/named の末尾に OPTIONS=”-4″ を追記
（/etc/init.d/named restart　も忘れずに ）

これで「network unreachable resolving」をはき出さなくなった。
当面IPv6 を使う予定はないのでしばらくこのままにしておこう。

最近のガンブラー(gumblar)の影響もあり、ftpサーバのセキュリティを考えてみる。sftp,scpという手もあったが、sshのchroot化が面倒なんで、ftpsに取り組むこととした。

ただ、どれにしても、クライアントがウィルスに感染していればid、パスワードを抜かれる場合があるので、あんまり意味はないような気もする。

で、サーバ（vsftpd）側の設定は、
1. オレオレサーバ証明書（金がないので自己証明）を作成する。
# cd /etc/pki/tls/certs
# make vsftpd.pem
2. /etc/vsftpd/vsftpd.conf に以下を追記
ssl_enable = yes
force_local_data_ssl = no
force_local_logins_ssl = no
rsa_cert_file=/etc/pki/tls/certs/vsftpd.pem

次にクライアントだが、ftpsに対応しているfilezillaを使う。

filezillaには、
ftps：ftp over implicit ssl (implicitモード：暗黙的にtls/sslを使う)
ftpes：ftp over explicit ssl (explicitモード：明示的にtls/sslを使う)
の２つの設定方式があるが、centos標準インストールではポート990が使えないみたいで、前者のftpsでは接続できなかった。

それで、ポート7600を使っている後者のftpesで試したところ、問題なく接続できた。

気休めかもしれないが、ftpのssl化で、少しは安心したような。

追記：
オレオレサーバ証明書の有効期限は標準で1年(365日)なので、これを10年に延ばしておく。
/etc/pki/tls/certs/Makefile　で下記の通り書き換える。
#/usr/bin/openssl req $(UTF8) -newkey rsa:1024 -keyout $$PEM1 -nodes -x509 -days 365 -out $$PEM2 -set_serial $(SERIAL) ;
/usr/bin/openssl req $(UTF8) -newkey rsa:1024 -keyout $$PEM1 -nodes -x509 -days 3650 -out $$PEM2 -set_serial $(SERIAL) ;

今度は、centos標準squirrelmailの、件名の文字化け対処法。

/usr/share/squirrelmail/class/deliver/Deliver.class.php　で、
$hdr_s .= $sLine;
break;
case ‘Subject’:
case ‘To’:
case ‘Cc’:
case ‘Bcc’:
case ‘From’:
$hdr_s .= $header[$i];
break;
default: $hdr_s .= $this->foldLine($header[$i], 78, str_pad(”,4)); break;
というように、case ‘Subject’:を追加。

しばらく検証してみよう。

centos標準のsquirrelmailで、日本語の添付ファイルが文字化けする報告があった。

いろいろぐぐって解決策を見ると、日本語パッチを当てて再コンパイルすることが紹介されている。
面倒だなあ、、、。

それで、完全ではないかもしれないが、簡単な方法を見つけたので記録する。

/usr/share/squirrelmail/functions/i18n.php　で、
case ‘downloadfilename’:
$useragent = func_get_arg(2);
if (strstr($useragent, ‘Windows’) !== false ||
strstr($useragent, ‘Mac_’) !== false) {
$ret = mb_convert_encoding($ret, ‘SJIS’, ‘AUTO’);
} else {
$ret = mb_convert_encoding($ret, ‘EUC-JP’, ‘AUTO’);
のSJISとなっているところを、
$ret = mb_convert_encoding($ret, ‘UTF-8’, ‘AUTO’);
というようにUTF-8に書き換える。

これで検証したところ、IEでまだ少し文字化けするようなので下記を追加した。

/usr/share/squirrelmail/functions/mime.php　で、
if (preg_match(‘/compatible; MSIE ([0-9]+)/’, $HTTP_USER_AGENT, $match) &&
((int)$match[1]) >= 6 && strstr($HTTP_USER_AGENT, ‘Opera’) === false) {
$isIE6plus = true;
}
のうち
if (preg_match(‘/compatible; MSIE\s?([0-9]+)/’, $HTTP_USER_AGENT, $match) &&
に修正。

再び検証したところ、今のところ添付ファイルの文字化けなし、、、。

いくつかのNPO関連サーバの管理のお手伝いをしている関係で、ときどき同じような連絡をいただく。

たとえば、「サイトが文字化けしているから直してほしい」

残念ながら、症状だけいわれても対応のしようがない。
文字化けしているurlはどこ？
いつから？　いつ気づいたの？
再現性は？　規則性はある？
等々、原因を探るための情報が１つでも多くほしい。
サーバの設定に原因があるのか、サイトの設定に原因があるのかで対処方法は全く違う。

今までの鯖缶経験から、原因を特定するには「消去法」しかないと考えている。
まず最初に「症状」から想定される原因を１０～２０ぐらい考えてみる。
あとは、様々な状況証拠から、論理的に原因でないものを消去していく。

延々とその作業を繰り返すことで、最後に２，３の原因と思われるものが残る。そこから原因を特定するのであれば意外と容易である。

時たまひらめきで原因が特定できることもあるが、大半は地道な作業の繰り返しである。いったん坩堝にはまれば、数日間原因探しに没頭することもある。（年をとるとこの作業が偉いしんどい。）

原因が特定できれば、対処方法は必然的に決まってくる。

同じxoopsの話題。

centos4（php4+mysql4.1）上で作成したxoopsサイトをcentos5（php5+mysql5.0）に移動したところ、newsモジュールでページファイルがあるのに「ページがありません」とエラーメッセージが出る。

なぜ、なぜ、なぜ？　３日はまってやっと解決策を探し出す。

php.iniで、デフォルトで
register_long_arrays = Off
になっているところを
register_long_arrays = On
に変更する。
このあとapacheのreloadを忘れずに。

これでようやくnewsページが表示された。
えらい疲れた。

xoopsのサーバ移設ではずいぶんと泣かされた。
正確に言うと、mysqlの環境が変わっただけで、簡単に文字化けやエラーに見舞われる。

そんななかで、今回は「picoで～（波形）を投稿すると文字化けする」ことの対処法について。

同じcentos5同士でサイトを移動したのに、picoモジュールで～（波形）を投稿すると文字化けする事態が発生した。ともにmysql5.0の同じバージョンなのになぜ？？？

いろいろ調べてみると、dbの文字セットと生成されるtableの文字コードがそれぞれ異なっていたのが原因だった。

解決策は、
1. SHOW VARIABLES LIKE “char%” で文字セットを調べてみる。
2. character_set_database ujis となっていたら、ALTER DATABASEでutf8に変更する。
3. 既存のpicoのコンテンツテーブルなどは
ALTER TABLE ***_pico_contents CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
で文字コードを変更する。

これで、再度 ～ を投稿してみたところ文字化けしなくなった。
これはほかの投稿用モジュールでも共通して言えるようである。

んんん、毎度のことながらdbの文字セットは奥深い。