UNIXやLinuxの最近のブログ記事

いやあ、まいった、まいった。

うちのサーバで週明けに突然 PHP 関係のプログラムの誤動作が発生して、調べてみたらセッションファイルを置くディレクトリの所有者が root:apache に変更され、パーミッションも root ユーザか apache グループの所属ユーザにしか読み書き出来ない形になっていた。

「うへぇ～？クラッキング？」と一瞬焦ったが、調べて見ると yum-updatesd（yum-cron）による自動更新で PHP の RPM パッケージが更新されたタイミングで発生しているみたい。

・・・Linux 界では、プログラムの自動更新でデータを置くディレクトリのユーザやパーミッションを変更するのかよ！？・・・絶句。
まさか、セキュリティのためなんて寝言は言わんよな？(^^;

どうも、こういう Linux 文化って、ほんま好きになれんわ。
そもそも、Apache の実行グループを apache にしているユーザが、この世にどれほどいるのやら。root:apache はないやろ・・・とほほ・・・

Apache の RPM パッケージ更新でも、DocumentRoot のパーミッションなどを勝手に変えてしまうことを知った。
うちのサーバはディフォルトの DocumentRoot は使ってないので問題ないが、お客さんところのサーバで時々発生していた「DocumentRoot のパーミッションがいつの間にか変わってて更新でけん！！」事件の犯人がやっとわかったわ。(^^;

ま、サーバで yum-updatesd を on にしてた俺も悪いけどな・・・ということで、速攻 chkconfig で off に。もちろん、 service yum-updatesd stop だ！（笑）

なんか、Linux のセキュリティ対策って、前も書いたけど完全に「実装をミスってる」よなあ・・・

chroot しない FTP ユーザが、自分の所有するディレクトリにファイルの PUT やディレクトリの作成が出来ない・・・

「553 Could not create file.」エラーで・・・

chroot しない FTP ユーザ作るのも久しぶりだったので一瞬 FTP サーバの設定を疑ったが、結局原因は SELinux の「悪さ」。
chroot しないユーザアカウントが乗っ取られたら危険だから、chroot しないとファイルの作成は許さない！・・・ということなのだろうが、大きなお世話だ。

VPN の中でしっかり守られたサーバに SELinux は不要じゃ！・・・と、/etc/sysconfig/selinux を、

SELINUX=disabled

に修正してサーバ再起動。
これで、「553 Could not create file.」エラーは出なくなる。

しかし、Linux 系 OS って、ホントにディフォルト設定で「絞ってる」よねえ(^^;
かつての Windows のような「だだ通し」も問題だけど、これほどディフォルトできつきつのセキュリティ設定しなくてもなあ。(^^;

ま、こんなことを言うと、SELinux 信者は狂ったように「セキュリティに対する認識が甘い！」とかわめき出すんだけど。

甘くないよ。

けっこうメジャーな会社のインターネットサーバを何台も構築してきたけど、SELinux も iptables も無かった FreeBSD 機で、クラッキング被害にあったことなんかないよ！

もし、Linux は SELinux と iptables をディフォルトでガチガチにかけてなければ危険というのなら、それは OS の設計か実装の問題でしょ？

いやぁ、今週は忙しかった。

年末の挨拶回りでバタバタした上に、サーバのセットアップも複数台重なっちゃって。
suEXEC やら sftp やら、セキュアなややこしい設定山盛りの内容だったし。今日、取りあえずこれらのサーバ間にかます Firewall Box の設定を外注さんにやってもらう予定になってたんで、それまでに一通り動くようにしとかないとテストにならんし・・・と。

最近、（IT不況で仕事少ないので(^^;）わりとサーバセットアップの仕事は余裕あるスケジュールのパターンが多かったのだが、今回は時間に追われたなあ。(^^;

いやあ、しかし、インターネットサーバの構築は FreeBSD 2.0.5-R あたりの時代からずっと仕事にしてるんだけど、長いこと FreeBSD ばかり使ってたんで、Linux 系 OS のセットアップでは未だにつまらないことでハマっちゃう。

帯域制限機能付の bridge とかも FreeBSD で作ってたもんなあ。Intel PRO/100 を 4枚挿して。今なら既製品を買うけど。（笑）

今回も、セットアップしたサーバで動かしている Web にアクセスしたら 403 エラーが発生。
suEXEC を有効にしてたんで、DocumentRoot ディレクトリやファイルのパーミッションに問題があるんじゃないかと調べてたら・・・

上位ディレクトリのパーミッションが 700 になってるじゃん・・・(^^;

ああ・・・そうか・・・
Web コンテンツの管理者を useradd した時に、DocumentRoot の上位ディレクトリを Home ディレクトリに指定して、-m オプションで自動作成したから・・・

FreeBSD だと Home ディレクトリが 755 の権限で作られるけど、Linux 系は 700 で作るんだよなあ・・・
suEXEC の方にばかり目がいって、そんなこと忘れてたよ・・・
これで数十分の時間を無駄に・・・

・・・というようなことがちょくちょく(^^;

あと、普通にインストールしたら、標準で iptables がガチガチに効いてるところなんかもハマり易いところなんだよなあ・・・(^^;

開いているところから閉めていく BSD UNIX と、閉めてるのを開けていく Linux 系 OS の違いは、サーバ指向とクライアント指向の違いなのか。
BSD 使いだった頃は、Fedora なんてどう見てもクライアント OS で、あんなもん、わざわざサーバとして使う人がいるのが信じられなかったもんなあ・・・

FreeBSD 8 なんか Jail もえらく強力になってるし、インターネットサーバにするには最高だと思うが。Dell あたりが正式サポートしてくれたら、巻き返せんかなあ、FreeBSD。

うちで運営している地域 SNS のお知らせメール（デイリーニュース）が今朝は配信されてなかった。

サーバに入って maillog を見てみると、

Sep 30 08:01:32 snsserv postfix/qmgr[58514]: 94EE75096C: from=<sns@snsserv.exsample.com>, size=4796, nrcpt=1 (queue active)
Sep 30 08:01:32 snsserv postfix/qmgr[58514]: 94EE75096C: to=<hogehoge@xxx.xxxx.ne.jp>, relay=none, delay=7268, status=deferred (delivery temporarily suspended: connect to mail2.exsample.com[202.XXX.XXX.XXX]: Connection refused)

なんてログが山のように・・・

ああ・・・そうだ・・・以前、この地域 SNS サーバを非固定 IP で運用していたとき、怪しいサーバと判断してメールを受け取ってくれないサーバがあったので、固定 IP の mail2.exsample.com を経由（RELAY）するよう設定してたんだった。

で、実は、昨夜、mail2.exsample.com は SMTP を止めたのよ。
以前、ここでも書いたように、このサーバを預けていたデータセンターがハウジングのサービスを止められるもんで。今日、実際にサーバを撤去したんでね。前夜に SMTP サービス自体は止めてたって話。

ということで、Postfix の設定を変更を。

/usr/local/etc/postfix/main.cf の中に、

relayhost = mail2.exsample.com

という記述があるのでコメントにして、

# /usr/local/sbin/postfix reload

で設定ファイルを再読込させる。これでＯＫ！

後は、queue に溜まっているメールを、

# postqueue -f

で、強制排出。

ま、こんなことせずにほっておいても、そのうち配送されるんだけどねえ。

いやあ、しかし、Postfix を使っているのはこの SNS サーバだけなので、毎度コマンドを思い出すのに時間がかかるよ。（メモしとけって話だけど(^^;）

ま、そのうちこの地域 SNS もサーバを移すので、その時には Postfix ではなく、qmail の利用に変更しようてえ。

これも移行したサーバでの話。

tDiary を動かしているサーバを別の場所に動かしたんだけど、そしたら

env: ruby: No such file or directory

というエラーが出て、tDiary が動かなくなってしまった。
どうも、Ruby のパスが取れてない様子。

tDiary のスクリプトは、シェル宣言で直接 /usr/local/bin/ruby という Ruby のパスを指定せず、

#!/usr/bin/env ruby

という具合に、env コマンドで ruby のパスを指定している。（ruby のインストールディレクトリがどこになってもいいようにだろう）

で、/usr/local/bin にある ruby が No such file or directory になるということは、プログラムファイルを探す経路情報である環境変数 PATH に、/usr/local/bin が含まれていないということだ。

実際、CGI で取得出来る環境変数を調べてみると、PATH は、

/sbin:/bin:/usr/sbin:/usr/bin

となっている。/usr/local/bin は確かに含まれていない。

これに関しては、Apache の起動スクリプトで、apachectl を実行する前に、環境変数 PATH に /usr/local/bin を足し込んでやればいい。
こんな感じ。

#!/bin/sh

export PATH=$PATH:/usr/local/bin
/usr/local/apache2/bin/apachectl startssl

しかし、マシンを再起動するまでは、問題なく動いていたのに何故？

同じ OS（FreeBSD 5.X-R）で、マイナーバージョン違いの Apache を動かしているうちのサーバで調べてみると、Apache の環境変数 PATH に、/usr/local/bin は含まれている。

/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/root/bin

あれれ、これ、.cshrc 内で指定しているパスじゃん。

set path = (/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin /usr/X11R6/bin $HOME/bin)

そうか・・・
以前、tDiary をインストールした時、こういう問題が発生せずにすんなり動いたのは、自動起動された Apache ではなく、ユーザが apachectl コマンドをシェル上から実行した Apache だったからかぁ。
謎が解けた。

つまり、/usr/local/etc/rc.d 以下の自動起動スクリプトで起動された時は、PATH には /etc/rc で指定されている

PATH=/sbin:/bin:/usr/sbin:/usr/bin

この値がセットされるのだろう。
で、ユーザが起動した時は、そのシェル上の環境変数 PATH の値がセットされるというわけだろう。

このサーバ、既に４年近くノンストップで動いてて、再起動したことなかったもんな。
それまでに、Apache は何度か STOP/START してるんで、/usr/local/bin へのパスも通っており、tDiary でもエラーが出なかったんだな。

つーことは、/etc/rc の PATH に /usr/local/bin を追加しておけばいいということか。
システムファイルを編集するのは少々気持ち悪いが、/usr/local/bin は追加しても全然問題無い気はするがな。
ま、取りあえず tDiary 以外で問題は発生していないので、暇が出来たら実験してみるということでよかろうてえ。

ちなみに、FreeBSD だと /etc/rc だが、Linux なら /etc/init.d/functions の中でディフォルトの PATH は設定されているようだ。

ああ、原因が分かってすっきりした。寝よ。

新しいサーバにうちのメールサーバを移したら、なんと特定のアカウントだけメールが届かない現象が・・・

どういう基準で「届く／届かない」状況になっているのかよくわからなかったのだが、やっと先ほど判明した。

ちなみに、qmail-1.03 + ucspi-tcp-0.88 + vpopmail-5.4.28 という環境である。

で、どうも、VirtualDomain のユーザディレクトリの下に置いた .qmail ファイルに、配送先として Maildir を書いた場合に、

delivery 3: deferral: client_connect:_warning:_config_begin_failed/Aack,_child_crashed._(#4.3.0)/

というエラーが出て（warning って出てるけど、実際にメールが配送されないんで、これはエラーだ）、メールの配送に失敗してしまうのだ。（Maildir/new にも入っていないし、その下に書いていた転送先にも転送されていない）

で、.qmail を置かなければ問題なく Maildir/new にメールデータは書き込まれる。
.qmail を置いた場合も、転送先が書いてあるだけなら（Maildir が書かれていなければ）、問題なくその転送先に転送される。
つまり、他のアドレスに転送するだけなら、そのアドレスだけを書いた .qmail を置けば問題なく動作するし、転送をしないのなら .qmail を置く必要もないので、これまた何の問題もない。
問題になるのは、他のアドレスに転送しつつ、Maildir にもデータを置きたいという場合である。

ちなみに、Maildir の指定方法は、

./Maildir/
/home/vpopmail/domains/exsample.com/hogehoge/Maildir/

のように、相対パスでも絶対パスでも、どちらでも駄目。

一応、解決策も見つけてて、ドメインのディレクトリ直下に、

.qmail-hogehoge

というファイルを作って、そこに、

/home/vpopmail/domains/exsample.com/hogehoge/Maildir/

と絶対パスで書いてやれば正常に配送されることが確認出来た。
何か気持ち悪いけど、取りあえずはこれで行くしかないなあ。何せ、古いサーバは 9月いっぱいしか使えないので。

ググってみても、同じ現象に遭ってる人はいないなあ。
この話が一番近いくらい？多分。
　↓
http://search.luky.org/linux-users.9/msg04669.html

取りあえず、ユーザディレクトリの下に置いてある .qmail をチェックして、Maildir が指定されているものはドメインディレクトリ直下に .qmail-XXXX を作成していこうてえ。

めんどくさ・・・

 

あり？

CentOS 5.3 64ビット版の DVD ISOイメージって壊れて伝播してる？

どこのサイトに言っても、サイズは 4.2GB って出てるのに、実際にダウンロードすると 250MB って・・・
DVD の ISO イメージが 250MB なんてこと、あるかーーーー！(^^;

本家が壊れたファイルをアップしたのが伝播したって感じ？
ようわからんなあ。

ということで、CentOS 5.3 って、インストールディスクが 7枚あって、ディスク交換が面倒なので DVD にしたかったのだけど、しかたないので CD の ISO イメージを地道にダウンロードしてインストールディスクを作成。

やっと、あと少しで 4台目のサーバのインストール終了。
たかが OS のインストール 4台だけで、１日かかってしまったぜ。(^^;

あとは、sshd 起動して、家からリモートでセットアップしよ。
観音の秘密基地、暑すぎ(^^;

室内で熱射病になりそう。（笑）

他サーバのWebサイト（PHP）から結果を取得して、それを編集・表示させる CGI を組まないといけない。
こういう時は Perl で LWP モジュール使って作っちゃうんだけど、調べてみると、実行予定のサーバに SSLeay モジュールが入ってない・・・

アクセス先が、https プロトコルなのですよ。なので SSLeay 必須。

ということで、Crypt::SSLeay モジュールをインストールしようとしたんだけど、include する OpenSSL の header ファイルとかも入ってないので、それも用意しないといけませんぜ。

OS が CentOS なので、RPM で openssl-devel とかを入れるのが「Linux 使い」の王道なのでしょうが、わしは FreeBSD の人なので、最新の OpenSSL をソースから make することに。
つか、FreeBSD なら、標準で header ファイルも入ってるよなあ。(^^; やっぱ、Linux 系OS は「クライアント OS」なんだよなあ。
ま、いいけど。

# wget http://www.openssl.org/source/openssl-0.9.8k.tar.gz
# tar xvfz openssl-0.9.8k.tar.gz
# cd openssl-0.9.8k
# ./config -fPIC shared
# make
# make test
# make install

これでインストールは終了。

この後、/usr/local/ssl/lib/ を共有ライブラリのパスに追加しておくこと。
これを忘れてたので、この後の Crypt::SSLeay モジュールのインストール時にバタバタしてしまった。(^^;

まず、/etc/ld.so.conf.d/openssl_0.9.8.conf という名前で、中に、
/usr/local/ssl/lib
とパスを書いたファイルを作成。

で、ldconfig コマンドを実行すれば、このパスが共有ライブラリのパスに追加されると。

これで、OpenSSL のインストールはばっちり終了。
もとからインストールされている OpenSSL 0.9.7a とも共存問題無し。

# /usr/bin/openssl version
OpenSSL 0.9.7a Feb 19 2003
# /usr/local/ssl/bin/openssl version
OpenSSL 0.9.8k 25 Mar 2009

いや、大した話ではないんだけど。

Tools/sequencer を使うと、メーリングリストに投稿したメールの本文に、

Message for test-ml
Sender: owner-test-ml
Precedence: bulk

みたいなものが付いてしまう。

設定で出す出さないが出来ると思うのだが調べている時間がなかったので、Tools/sequencer の該当箇所をコメントにして対応。

199行　print OUT $subject, "\n";
202行　print OUT "Sender: $sender\n";
204行　print OUT "Precedence: $opt_p\n";

あたりね。

Perl で書かれているので楽勝。

ところで、唐突に話は変わるが、UNIX の世界では Perl で書かれたツールも多いので、やっぱ、Perl の習得はインターネットの世界を商売のネタにしている者には必須条件だろう。

よく、「Perl vs PHP」みたいな図式で話をしたがる人もいるが、そもそもそれは同列に並べて比較することが間違っているだろう。

Perl を「普通自動車」とすれば、PHP は「小型自動二輪」じゃないか？
どっちが良いとか悪いとかじゃなく、「やっぱ、普通免許は取っておいたほうが良いよな」の世界ってことだ。
その上で、「二輪免許もあると便利だよな」ということだと思う。

ただ、PHP は「普通二輪」や「大型二輪」ではないと思うけどね。（笑）

まあ、もし、単なる「Web プログラマ」の世界から一歩踏みだしたいと思っているのなら、「俺は Perl なんか嫌いじゃけんね。Perl 覚えるのなら Java 勉強するよ」なんて言ってないで、素直に「Perl を習得することを次のステップに進むための最初の一歩にする」と考えたほうがいいよ。

Majordomo のセットアップなんか、ほんまに10数年ぶりだ。確か、1997年頃だったか、一度だけ自社サーバにセットアップしたことがあって、それも入れてはみたけどあまり使わなかったので、どういう設定をしたかなどもまったく記憶にない。(^^;

某社のレンタルサーバは、Majordomo を使ったメーリングリストのサービスが標準で（メニュー化されて）用意されているのだが、既に諸々の事情で、MTA を sendmail から qmail に変更したり、Virtual Domain な環境でのメール運用であったりして、標準のサービスは使えない状況になっている。

ということで、標準セットアップされている Majordomo とは別に、手動によるインストールを行ったのである。

何せ、Majordomo は設計の古いシステムなので、手作業で作ったり直したりするファイルがたくさんある。
当初、セットアップだけの作業で工数を見積もっていたのだが、別のサーバで運用されている既存のメーリングリストを移行しないといけなくて、「その工数でついでにやりますよお」と軽く回答してたら、その作業こそ大変だった。(^^;

特に、qmail 環境で Majordomo を使おうとすると、Permission 関係はけっこう引っかかるねえ。

が、Majordomo は Log ファイルに分かり易いログを吐いてくれているので、そこを見て対処療法していけば解決する。

例えば、subscribe のメール送ったら

>>>> approve password subscribe test_ml hogehoge@exsample.jp
>>> Sorry, an error has occurred while processing your request
>>> The caretaker of Majordomo ( Majordomo-Owner@exsample.jp ) has been notified
>>> of the problem.

なエラーが返ってきちゃった・・・というときも、Log ファイルに

Jul 01 11:20:16 exsample.jp majordomo[22441] {ML Master<ml_admin@exsample.com>} approve PASSWORD subscribe test_ml hogehoge@exsample.jp
Jul 01 11:20:16 exsample.jp majordomo[22441] {ML Master<ml_admin@exsample.com>} ABORT Can't append to /var/majordomo/lists/mltest: Permission denied

なんてログが残っているので、「ああ、さっきファイルを FTP で PUT するときに、一時的にファイルオーナーを変更してたんだった」とか思い当たる。
Log ファイルの場所も、Majordomo をインストールしたディレクトリ直下なので分かり易い。

設計が古いなんて言ってごめん。
さすが歴史あるソフトは、こういう基本的なところがちゃんと作ってあるなあ。

ログファイルが分かり易い場所にあると「セキュリティ的にまずい」と思ってる低脳技術者も結構いるからなあ。そういう考え方は MS-Windows のものであって、UNIX の世界には持ち込まないでほしいな。設定ファイルもログファイルも分かり易い場所に置く。そして、適切な Permission 設定をすればいいのだ。

（Permission 管理機能が脆弱で、触られたくないファイルは隠すしかなかった）MS-Windows 文化に（のみ）どっぷり浸かった技術者は、その辺のところがなかなか理解できないのだろうなあ。