サーバ管理

refused to talk to me: 421 REJECTED

「韓国の特定の知人からのメールが遅配するが原因はわからないか?」と1か月ほど前に友人から質問を受けた。

たぶんそれは先方のメールサーバが原因だろうと安易に答えてそのままにしていたが、先日同じ状況に自分が見舞われた。

共通して言えることは、どちらも受信側でniftyメールを使っている。

エラーログを調べてみると、
refused to talk to me: 421 REJECTED
という表示が出ている。
これでググってみると、原因はどうやらDNS逆引き設定にあるようだ。

自サーバの存在をあまり表に出したくなかったため先日DNS逆引き設定をはずしておいた。niftyに対するメール遅配は確かにこの頃から始まっている。メールキューに配信できずにいるメールがたまったままだ。

早速DNS逆引きを再設定したところ、メールキューが空になった。

大手プロバイダでは、spamメール防止を理由の1つとして、DNS逆引きができないサーバからのメールを受け付けない設定をしているようである。

16 11月 2010

cgiエラー Premature end of script headers:

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

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

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

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

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

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

14 11月 2010

apacheが起動できない

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

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

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

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

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

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

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

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

28 2月 2010

Allowed memory size of 16777216 bytes exhausted

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

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

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

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

27 2月 2010

lame server resolving

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

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

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

27 2月 2010

network unreachable resolving

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 を使う予定はないのでしばらくこのままにしておこう。

27 2月 2010

FTPのSSL化

最近のガンブラー(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を使う)
の2つの設定方式があるが、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) ;

16 2月 2010

SquirrelMailの件名の文字化け

今度は、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’:を追加。

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

13 2月 2010

SquirrelMailの添付ファイルの文字化け

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) &&
に修正。

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

12 2月 2010

エラーの原因特定は「消去法」で!

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

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

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

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

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

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

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

07 2月 2010