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

MovableType って、ImageMagick の Perl モジュールが入ってなきゃ、GD モジュール使うのかと思ってたけど、初期ログイン時に、

Image::Magickがインストールされていないかまたは正しく設定されていないため、Movable Typeのユーザー画像機能を利用できません

って怒られた。

そうですか。仕方ないので入れましょう。ま、CPAN モジュール使ってインストールすりゃ一発じゃけえね・・・と思ったんだけど、いきなり、

...
make: *** [Magick.o] エラー 1
  /usr/bin/make  -- NOT OK
Running make test
  Can't test without successful make
Running make install
  make had returned bad status, install seems impossible

と、エラーで終わっちゃいましたよ、インストール。

入ってる ImageMagick 本体のバージョンが 6.2.8 で、Perl モジュールは 6.5.9 狙いなので、そのせいかねえ・・・
今の ImageMagick は RPM パッケージでインストールされているようなので、

yum info ImageMagick

で、現行バージョン調べてみたら、このサーバ OS 用の最新バージョンは 6.2.8.0 だった。つまり、最新パッケージのバージョンが更新されてないわけだ。

仕方無いので、

yum remove ImageMagick

でパッケージを削除して、ソースから Perl モジュールに合ったバージョンのものをインストールすることにした。

ftp://ftp.kddlabs.co.jp/graphics/ImageMagick/ImageMagick-6.5.9-10.tar.gz

を取ってきて、configure して make & make install。
問題なく本体のインストールは終了。ldconfig 実行してライブラリのパスを通したら、もう一度 CPAN モジュールでインストール実行。

# perl -MCPAN -e shell
Terminal does not support AddHistory.

cpan shell -- CPAN exploration and modules installation (v1.7602)
ReadLine support available (try 'install Bundle::CPAN')

cpan> install Image::Magick
CPAN: Storable loaded ok
Going to read /root/.cpan/Metadata
  Database was generated on Tue, 20 Apr 2010 17:27:01 GMT
Image::Magick is up to date.

あれれ？何か、ものすごくあっけなく終わっちゃったんですけど？(^^;
ホンマに大丈夫かいな？

心配だったので、簡単なプログラム作って実験。

# cat > image_magic_test.pl
use Image::Magick;

{

        my $new_path    = "new_file.gif";

        my $path        = <STDIN>;
        chomp $path;

        my $image = Image::Magick->new;
        $image->Read("$path");

        my($now_x, $now_y) = $image->Get('width', 'height');

        print "SIZE X=$now_x Y=$now_y\n";

        my $max_x       = 1000;
        my $max_y       = 1000;

        $image->Resize(
                width  => $max_x,
                height => $max_y,
                blur   => 1.2
        );

        $image->Write("$new_path");

}
^D
# perl image_magic_test.pl
/var/www/icons/image2.gif
SIZE X=20 Y=22
# ls -la new_file.gif
-rw-r--r-- 1 root root 321404  4月 22 12:30 new_file.gif
# perl image_magic_test.pl
new_file.gif
SIZE X=1000 Y=1000

うむ。20x22 の大きさのアイコンを指定して、1000x1000 の大きさにサイズ変更して出力するプログラムなんだが、ちゃんと動いたな。

これで大丈夫でありましょう。

某ホスティングサーバはコントロールパネルで BASIC 認証用の .htaccess と .htpasswd を生成するようになっているが、cgi-bin 以下のディレクトリは生成先として指定出来ない。
どうしても cgi-bin 以下に BASIC 認証をかけたいので、手動でどうにかしてくれという依頼がお客さんよりあったので対応したが、ちょっとハマってしまった。

うちのサーバ（CentOS）上で、

$ htpasswd -cb .htpasswd hogehoge hogepass
Adding password for user hogehoge
$ cat .htpasswd
hogehoge:ZUb5junE4ayDa

みたいに作った .htpasswd を使って設定したのだが、正しくパスワードを入れても Authorization Required と認証エラーとなる。

元々、手動で BASIC 認証の設定を行うのを推奨してないというか、情報が少ないサーバなので調査にも時間がかかったんだけど、結局、コントロールパネルで作った .htpasswd を見つけて中を見てみると・・・

へえ、珍しく MD5 で暗号化してるなあ・・・（俺は UNIX 系のサーバに触れたのは FreeBSD が最初なので、DES より MD5 の方が好き・・・というかしっくりくるが:-P）

・・・ん？・・・もしかして、.htpasswd の暗号化は、MD5 でなきゃ駄目なの？

大概のホスティングサーバが DES（国際化 DES）でも MD5 でもＯＫなんだけど、このサーバは MD5 でなきゃ駄目なのかも。

ということで、

$ htpasswd -cb -m .htpasswd hogehoge hogepass
Adding password for user hogehoge
$ cat .htpasswd
hogehoge:$apr1$K3QPv/T9$KMU3gDebRA0R0fdHddjwX1

と、明示的に MD5 encryption を指定して作成した .htpasswd ファイルを使用したところ問題なく BASIC 認証が行われた。

いやあ、ほんとに、世の中色々なホスティングサーバがあるので大変だわ。(^^;

ビジネスがらみで使うサーバは、月数千円の差額なんかケチケチせずに、ssh 接続でターミナルとか使えるサーバを選んでほしいわ(^^;
そしたらトラブルの原因究明なんか一発なのに。大概ね。

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

うちのサーバで週明けに突然 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