Yearly Archives: 2010

サーバ管理をしていて意外と面倒なのがssl認証設定だ。

慣れればsshで決まった操作をすればそう難しくはないのだが、日頃Webminを愛用しているため、sshを使う機会は少なくなった。というよりも、常時はsshサーバを止めている。

Webminのアドインに複数サイトを管理してくれるVirtualminという便利なアプリがある。いまやVirtualmin抜きではサイト管理がおぼつかない。

このVirtualminにSSLサイトを簡単に設置してくれるモジュールがあり、今日初めて使ってみた。

いやいやいや、便利の一言に尽きる。Apache設定はもちろんのこと、プライベートキーの発行から、CSRの発行、それに認証局からの証明書が届くとそれをコピペするだけで、あとはサーバ上のSSL設定をすべてVirtuaiminがやってくれる。

最近は認証局からの証明書発行もネットですぐにできるため、このVirtuaiminを使うとSSLサイト設定がものの５分で済んでしまう。

あまり便利すぎると基本（原理）を忘れてしまいそうで少しばかり不安はあるが、ま、いいか。

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

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

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

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

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

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

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

最近は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) ;