サーバ管理

最近はphpスクリプトばかりでperlスクリプトはほとんど使わなくなったが、今日必要に迫られてperlを使ったらエラーが出た。
Premature end of script headers:

あれ？　perlを使ったのがおおよそ５年ぶりなんで、基本を間違えたかな？
エラーログからいろいろ調べていくと原因がわかった。

先頭の
#! /usr/bin/perl
のあとに、見えないけれども改行コード(CRLF)が入っており、CRがパス名にくっついて “/usr/bin/perl\r” などとなってしまっている。

教科書的な対処方法としては、改行コードをDOS(CRLF)からUnix(LF)にして再度アップすればいいのだが、ちょっと面倒だ。
それで、#! /usr/bin/perl のあとにおまじないとして– を入れてみた。とすると、\rが離れるのでエラーがなくなった。

めったに使わないが、次回忘れていると悪いので記録しておこう。

それにしても、いつからこの現象が出るようになったんだろう。定かではないが、ftpクライアントをfilezillaに変えてからだろうか？

毎週日曜日04：02にapacheが停止する。

この時間帯、別サーバに自動バックアップしている。これが原因か。
でもなぜapacheだけが停止するのか。もう少し詳しく調べてみよう。

ところで、今朝は冷や汗ものだった。
いつもはapacheの起動で問題ないのであるが、今回は起動時にエラーになる。

内心はらはらしながらも、深呼吸して10分間ログを冷静に見てみる。

使えるsoketがないというメッセージ。
ここでひらめき。プロセスをチェックしてみよう。

なあんだ。apacheの子プロセスが残っているじゃん。親だけが寝てしまった状態。
apache関連のプロセスをkillして、もう一度
/etc/init.d/httpd start

無事起動。　ああ、よかった。

いつもこのひらめきでなんとかしのいでいる。
ひらめきがなくなったら、迷わず鯖缶を引退しよう。

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ページが表示された。
えらい疲れた。