apacheの最近のブログ記事

久々の更新。

最近、WordPressのindexを自分のドメインのトップページに設定している人が増えてきている模様?

そういった場合、管理者は、WordPressの構成ファイルをドキュメントルート直下に展開するか、ドキュメントルート直下の.htaccess処理で、WordPressの本体ディレクトリ内のindex.phpにリダイレクトさせる。
もしくは、apacheの設定自体を変えて、ワードプレスの本体ディレクトリ自体をドキュメントルートにしちゃう、
主流はこの3つくらいだろうか。


先日MilkyStepの初期設定代行を行おうと思い、VPSのコンパネにアクセスしようと思ったら、いきなりワードプレスのスキンで404エラーが発生。

ドキュメントルート直下の.htaccessをのぞいてみると、どうやらお客さんの方で追記したと思われる、下記のようなRewriteRuleを発見。

# BEGIN WordPress

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress


ふうむ。
どうやら最近はこういうのが流行っているのだろうか?

上記の設定だと、下位のファイルを指定せずトップページにアクセスすると、同列に置いてある「index,php」の制御により、ワードプレスのトップが表示される。
下位(ワードプレスディレクトリ内)の実在するファイルにアクセスすれば見れるが、実在しなければ「ありませんよ!」というメッセージ(多分ワードプレスの制御)が出る模様。

基本的に、RewriteRuleに書かれた以外のコンテンツ(またはそのエイリアス)が存在しない場合、
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
により、その下の
RewriteRule . /index.php [L]
が実行される。

ただし、ここで、
RewriteRule . /index.php [L]
となっている。
左辺を見ると、「.」となっているので、「.」(任意の一文字)が合致する名前のコンテンツは、基本的に「すべて」ということになる。

したがって、
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
は、基本的にははすべて「偽」となるため、
RewriteRule . /index.php [L]
の処理が実行されないことになる。
(それと、右辺は「/index.php」ではなく「index.php」ではなかろうか?)

とまあ、こう考えれば、WordPressディレクトリの外のコンテンツにアクセスするにも問題なさそうなのだが、なぜか(ワードプレス内のコンテンツが無いという)404となる。

多分、それ以前の大元のapacheのルールで、インデックスの指定のルールとかがごっちゃになって、こういう結果的にこうなっている思われる。

根本的な原因を探すのも面倒だし、もともと書いてあったRewriteRuleを消したりなんかすると、さらに被害が増えそうだ。

したがって、なるべく既存のコンテンツにあたりさわりなく行う対策としては、アクセスしたい同階層のディレクトリ名が指定された場合は、上記のRewriteRuleが適用されないようにするのが得策と考えた。

# BEGIN WordPress

RewriteEngine On
RewriteBase /

# Add -------
RewriteRule ^ControlPanel/* - [L]
RewriteRule ^mysqladmin/* - [L]
RewriteRule ^ms/* - [L]
# ------- Add

RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]


# END WordPress

これで、ControlPanel、mysqladmin、ms という名前のディレクトリには、
http://domain.com/ControlPanel/......
http://domain.com/mysqladmin/......
http://domain.com/ms/......
というURLでそのコンテンツにアクセスできる。

以上。
事業所の移転に伴って、フレッツ光の契約タイプを変更しなくてはいけなかったため、必然的に貸与されるルータも、PR200NEからPR400NE(一応最新版らしい)に変更することになった。

ついでにプロバイダもbiglobeをやめてインターリンクの固定IP付のもっと安いサービスに乗り換えた。

しかし、ルータが変わってから、LAN内ホストの名前解決(正引き)ができなくなってしまった。

うちの場合はLAN内のPCからLAN内のサーバにアクセスするとき、内部DNSを構築しているので、ルータの静的NATとサーバ側のファイアウォールを許可すれば、LAN内からでも「ホスト名+ドメイン名」でアクセスできるはず。

というか、ルータが変わる前は普通にできていた。

もちろん、「http://192.168.*.*/:80」とかやれば、当たり前だが普通にWEBサーバにつないでくれる。


ルータのソフトのファームウェアバージョンも前と変わってないし、設定も前とすべて同じにしてあるのに、なぜかLAN内のホストへ正引きできない。

仕方が無いので、現在はルータの設定で、DNSの問合せ先をすべて192.168.1.4(LAN内のDNSサーバ)に指定している。
こうするとちゃんと正引きしてくれるが、WAN側のホストにアクセスするときも、いちいち内部のDNSサーバに問合せに行くので、名前解決の時間が3秒くらいかかってイライラする。

確か、前は、ルータのDNS問合せ先を「自動的に取得する」にしておけば、WAN側・LAN側を勝手に判別してWAN側だったらプロバイダのDNSに問合せに行ってくれたと思ったのだが・・・

ルータ設定画面のメニューで、今まで使ったことがなかった「ローカルドメイン設定」というメニューがあるが、これにローカルドメインを登録しようとしても、バグってるぽくて有効にならない。

他に移転に伴って変わったことと言えば、プロバイダが変わったことだが、この現象はインターリンクに切り替える前からおこっていた現象なので、やはり怪しいのはルータということになる。


以下、私がNTT東日本に問い合わせたメールの内容。

この後、一応連絡が来て、結局他の部署のなんちゃらというところに問い合わせてみてください、といった無責任な対応だったので、めんどくさくてそのままにしている。

もし、同じような現象にある人は、下記の文面をそのままコピペして問合せ用に使っちゃってください。

もしくは、「お前の考え方が間違っている。ルータのせいではない。」という見識をお持ちの方は、ぜひぜひ解決策を教えていただけると嬉しいです。

----------------------------------------------------------------------------------------------
先日引越しを行った際に、弊社からの案内でルータをPR-200NEからPR-400NE(無線LANカード付き)に変更しました。

当方ではLAN内にサーバを構築しており、インターリンクというISPの固定IPアドレスによりWEBも公開しておりますが、LAN内のクライアントPCからLAN内のサーバにホスト名でアクセスする際に支障が出ております。

この場合、何も対策していない場合は、通常はLAN内のホストにホスト名+ドメインでアクセスすることはできませんが、その回避策として内部DNSを設置しており、引っ越し前(PR-200NE)までは正常に問合せ、閲覧ができていました。

ルータのソフトウェア(最新ファームウェアバージョンは1.11)の設定も、基本的に引っ越し前とすべて同じにしています。
静的NATの設定なども全て同じで、外部から当サーバへの各種アクセスは問題ありません。

「詳細設定」→「DNS設定」の「LAN側DNSサーバアドレス」に、当方の内部DNSアドレス(192.168.1.4)を指定しており、この設定が、LAN内ホストの名前解決をする際に使用されるDNSアドレスと認識しております。
この認識が間違っていれば申し訳ありません。

この認識から行くと、通常使用する接続設定(「基本設定」→「接続先設定→「現在利用中の接続名」」)において、「DNSサーバアドレス」で「サーバから割り当てられたアドレス」を「使用する」にしておいても、LAN内ホストにホスト名で接続するときは、上述した内部DNS(192.168.1.4)に問合せに行かなくてはならないはずなのに、そうならずに、「このページは表示できません」となります。
逆に、上記の「サーバから割り当てられたアドレス」を使用せず、問合せるDNSを強制的に内部のDNS(192.168.1.4)に指定すれば、当たり前ですがアクセスできます。
つまり、内部DNSの正引きは正しく動作していることになり、ルータのDNS問合せ先の判別がうまくいっていないのではないか、ということです。

以上よろしくお願いたします。

----------------------------------------------------------------------------------------------


システム開発上、ユーザがブラウザからメールマガジンを作成した時に、同時にエラーメール処理用のアドレスも作成されるようにする、逆にメルマガを削除したらそのアドレスも削除される必要があったためメモ。

今回のMTAはqmailを使うとのことで、アカウントの管理は必然的にvpopmailとなる。

しかし、qmailadminを使わないで新規アカウント作成(vadduser)・削除(vdeluser)を行うためには、基本的にrootでの操作となる。

単純にスクリプト内で

system("/home/vpopmail/bin/vadduser hoge@hoge.jp hogepass");

とやっただけでは、もちろんうまくいくはずがない。

というわけで、Cと連携して上手いことやってくれるモジュール様がないかと、CPANを探してみたらありました。
その名も「vpopmail.pm」。

呼び出す関数名もまさにvpopmailコマンドとほぼ同じ。

しかし、最終リリースは2001年・・・やばいんじゃないの?

かろうじてCPAN.pmをからインストールできたものの、説明も短すぎて、当然
use vpopmail;
vadduser(引数いろいろ);
とかやれば新規にアカウントを作ってくれると思いきや全然ダメ。

vpopmailのバージョンを見てきてくれる関数だけはなぜか動いた(笑)
まあ、関数名も最近のvpopmailのコマンドといまいち合ってないし。

というわけでさんざん悩んだ結果、sudoを使うことで決定。

以下手順。

1.新規バーチャルアカウントを作成する簡単なスクリプト(vadduser.cgi)を作成しCGIの動くディレクトリに置く。

vadduser.cgi
-----------------------------------------------------------------------------------------
#!/usr/bin/perl

use strict;

# コマンド発行
`sudo -u root /home/vpopmail/bin/vadduser hoge@hoge.jp hogepass`;
exit;
1
-----------------------------------------------------------------------------------------

2.sudoの設定ファイルに許可コマンドを追記

# visudo

(以下を追記)
apache ALL=(root) NOPASSWD: /home/vpopmail/bin/vadduser,/home/vpopmail/bin/vdeluser

同時に、以下の行をコメント化

Defaults requiretty
   ↓
#Defaults requiretty

※これをコメント化しないと、最近のLinuxでは、
sudo: apache : sorry, you must have a tty to run sudo ; TTY=unknown ;......
と怒られる。

このエラーは、/var/log/secure を見ればわかる。

保存して終了
:wq


3.vadduser.cgiをブラウザから実行してみる。

4.確認

popアカウント一覧に、「hoge」が追加されているのを確認

同時に、/home/vpopmail/domains/hoge@hoge.jp 内に、ディレクトリ「hoge」が作成されているのでOK!!



ああ疲れた今回も。


実務的には、このvadduser.cgiをAPIとしてドキュメントルート外に置いて、第三者からは直接アクセスされないようにし、他のCGIからシステムコールで呼んだりした方がセキュアかなと。


参考URL:
http://hibari.2ch.net/test/read.cgi/php/1024741312/l50
http://d.hatena.ne.jp/kakurasan/20100512/p1
http://old.ikoinoba.net/index.php?UID=1188143501
http://search.cpan.org/~sscanlon/vpopmail-0.08/
子プロセスに処理を渡して、親プロセスで標準出力を切るとき、

my $pid;
if($pid = fork){
 #親の処理
 close (STDOUT);
 wait;
}
elsif(defined $pid){
 close (STDOUT);
 #子の処理
}
 ・
 ・
 ・


みたいな感じで今までOKだったのだが、ロリポップ系サーバなどではこれがうまく行かない。ブラウザの出力自体は切れるのだが、子プロセスの処理を行ってくれない。

WEBサーバによって変わると聞いたことがあるので、ググってみたところ、標準出力を切る部分を、

close (STDOUT);
close (STDERR);
close (STDIN);

とやったら上手く行った。

apache2.0系(うちの環境)とapache1.3系(ロリポップ系?)でどうやら違うらしい。

ちなみに、上記3つの順番が違っても1つ足りなくてもダメだった。

close (STDIN);
close (STDOUT);
close (STDERR);

↑これだとなぜか子プロセスが終了するまでブラウザが開放されない


close (STDOUT);
close (STDERR);
close (STDIN);

↑この順番じゃないとダメみたい。

STDOUTだけだと、新しいapacheのときダメだよって聞いていたので、それとは逆の現象だが、解決したからまあいいか。
----------------------------------------------------------------------------------------------

#!/usr/bin/perl -w

use strict;
use LWP::UserAgent;
use HTTP::Request::Common;

# オブジェクト作成
my $ua = LWP::UserAgent->new();
my $url = 'http://yahoo.co.jp';
my $req = &HTTP::Request::Common::GET($url);

# レスポンスを得る
my $res = $ua->request($req);

# フィールド名を指定してヘッダを取得
my $con_type = $res->header('Content-Type');

#処理
if($con_type =~ /shift_jis/i){
  # (sjis用エンコーディング処理)
}
elsif($con_type =~ /euc-jp/i){
  # (ujis用エンコーディング処理)
}
elsif($con_type =~ /utf-8/i){
  # (utf8用エンコーディング処理)
}
  ・
  ・
  ・

----------------------------------------------------------------------------------------------


※charsetをダイレクトに返してくれるメソッドはどうやら無いらしい・・・
あったら教えてください。
DocumentRoot以外の場所にあるファイルをダウンロードさせようとして、プログラム側で「Location」させても、普通はアクセスできない。

そういった場合は前記事(http://www.igreks.jp/dev/2009/10/perlmysql2.html)の応用で、「cat」コマンドを利用するとダウンロードできるようになる。


-----------------------------------------------------------------------

#!/usr/bin/perl -w

use strict;

my $dir = '../../hoge'; #Documentroot外のディレクトリ
my $file = 'huga'; #その中にあるファイル

print "Content-Type: application/octet-stream\n";
print "Content-Type: application/download; name=$file\n";
print "Content-Disposition: attachment; filename=$file\n";
print "\n";
#### print content
system "cat $dir/$file";

exit;

-----------------------------------------------------------------------


※DocumentRoot以下に置いてBasic認証かけるよりは安全?
※LWP転送するときもOK

実行中のプロセスのCPU使用率やメモリ占有率などをリアルタイムで監視するUNIXコマンド。

-----------------------------------------------------------------

$ su (rootになる)

# top

(プロセス一覧が表示される)


"q"で終了
----------------------------------------------------------------

以上。


オプションとして便利なのは、

-d: 更新間隔を指定する: -d ss.tt (秒.10分の1秒)
-u: 指定した実効UIDかユーザ名にマッチするプロセスだけをモニターする: -u somebody


例えばWEBサーバが実効しているプロセスだけを0.5秒間隔に確認したい場合は、

--------------------------------------------
# top -d 0.5 -u apache
--------------------------------------------

でOK。

perl2exeに四苦八苦

| コメント(0) | トラックバック(0)
かねてから気になっていたperl2exe(perlスクリプトファイルを実行ファイルにしてくれるソフト)についに挑戦。

Win32環境での情報などは結構転がってるのだが、Unix版で参考になるサイトがないので、仕方なく本家のユーザーマニュアルを読みながらやってみる。

まずは本家からダウンロード。
http://www.indigostar.com/perl2exe.htm


私の場合はperl5.10.0でLinux上でコンパイル予定なので、

・Perl2Exe V9.100 for Linux (Jan 18 2008)

↑これを選んでダウンロード&解凍。



なにやらマニュアルを見ると、

・exeファイルの作り方は、コマンドにて、
 「perl2exe yourscript.pl」
とするだけ。ふむふむ。

・特別なモジュールを読み込む場合は、スクリプト中に
  #perl2exe_include "somemodule.pm";
的なことを書けばよいと・・・

まあこの辺はWin32版と同じだな。


ほんでもって、Unixホストで動かす場合は、同梱されてるインタプリタじゃなくて、動かしてるサーバのインタプリタとコア/ローカルモジュールを使用する設定にできるらしい。

後々、こっちの方が楽そうなので、切り替えてみる。

--------------------------------------------------------------------
cd ~/perl2exe
rm -rf perl5
perl ./setup_perl2exe.pl
--------------------------------------------------------------------

「切り替えました!」的なことが表示されたので、多分OK。



とりあえず試しに使ってみる。

まず最初に、
--------------------------------------------------------------------
cd ~/perl2exe
./setup
--------------------------------------------------------------------


実行ファイル生成
--------------------------------------------------------------------
cd ~/perl2exe
./perl2exe hellocgi.pl
--------------------------------------------------------------------


同じディレクトリに「hellocgi」という実行ファイル(バイナリファイル)ができた!!


とりあえず動作確認。
--------------------------------------------------------------------
cd ~/perl2exe
./hellocgi
--------------------------------------------------------------------
(あくまで実行ファイルなのでファイル名を指定するだけ)

・・・・よっしゃ成功!!



次に、WEBサーバ(ブラウザ)から実行できるか実験。

マニュアルにはtelnetを使って・・・みたいなこと書いてあったけど、面倒くさいんで、

#!/usr/bin/perl -w

system "./hellocgi";

exit;

とだけ書いたperlスクリプトを実行ファイルと同じ場所に置いて、このファイルにアクセスする。


よしよし、ちゃんと表示される。html出力もOKですな♪




じゃあいよいよ、もっと複雑なDBが絡んだスクリプトに挑戦してみようってことで、やってみたのだが、もちろん一発でうまくいくわけがなく、以下のエラーが連発。

Warning: Can't locate VMS/Stdio.pm
at /usr/lib/perl5/5.10.0/File/Temp.pm line 149
@INC = /usr/local/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi, /usr/local/lib/perl5/site_perl/5.10.0, /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi, /usr/lib/perl5/vendor_perl/5.10.0, /usr/lib/perl5/vendor_perl, /usr/lib/perl5/5.10.0/i386-linux-thread-multi, /usr/lib/perl5/5.10.0, ., .

Warning: Can't locate Compress/Bzip2.pm
at /usr/local/lib/perl5/site_perl/5.10.0/HTTP/Message.pm line 315
@INC = /usr/local/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi, /usr/local/lib/perl5/site_perl/5.10.0, /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi, /usr/lib/perl5/vendor_perl/5.10.0, /usr/lib/perl5/vendor_perl, /usr/lib/perl5/5.10.0/i386-linux-thread-multi, /usr/lib/perl5/5.10.0, ., .

Warning: Can't locate Compress/Bzip2.pm
at /usr/local/lib/perl5/site_perl/5.10.0/HTTP/Message.pm line 447
@INC = /usr/local/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi, /usr/local/lib/perl5/site_perl/5.10.0, /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi, /usr/lib/perl5/vendor_perl/5.10.0, /usr/lib/perl5/vendor_perl, /usr/lib/perl5/5.10.0/i386-linux-thread-multi, /usr/lib/perl5/5.10.0, ., .

Warning: Can't locate Compress/Bzip2.pm
at /usr/local/lib/perl5/site_perl/5.10.0/HTTP/Message.pm line 496
@INC = /usr/local/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi, /usr/local/lib/perl5/site_perl/5.10.0, /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi, /usr/lib/perl5/vendor_perl/5.10.0, /usr/lib/perl5/vendor_perl, /usr/lib/perl5/5.10.0/i386-linux-thread-multi, /usr/lib/perl5/5.10.0, ., .


(以下省略)



チーン。

まあ、エラーの言ってる意味はわかるのだが、Compress/Bzip2とか、聞いたこと無いようなモジュールまで要求してきやがる。

どうやら動作条件に関係なく、モジュール中にuseとかrequireとかの命令があったら、evalで呼ばれてても、とにかくそのモジュールはロードしなきゃならん仕様らしい。


仕方ないからインストールしてやるかと思い、cpan2rpm使おうとしたら「見つかりません!」的な。

ここまできたら、全部入れてやればいいんだろと思い、全部cpanからダウンロードしてきてmake installを実施。

しかしインストール中に今度は、

/bin/sh: gcc: command not found......

Cコンパイラまで追加すんのかよ!と思いつつ、こちらのサイト
http://memorva.jp/memo/linux/gcc_curses.php
を参考にしつつ、gccをインストール。

--------------------------------------------------------
yum install gcc*
--------------------------------------------------------

まあyumで一発だからいいけど。


これでようやく要求された全てのモジュールのmake install が完了。

インストール中に何やらいっぱい警告だのエラーだの表示されたけど、とりあえずpmファイルが入ったからいいや的な。


そしてもう一度実行ファイルを生成!

・・・お?

今度はエラーが出ない。

イエーイ!コンパイル成功〜〜〜〜!

さっそく実行〜!


あれ?

Software error:

DynaLoader object version 1.0801 does not match $DynaLoader::VERSION 1.08 at PERL2EXE_STORAGE/DynaLoader.pm line 93.
Compilation failed in require at PERL2EXE_STORAGE/DBI.pm line 157.
BEGIN failed--compilation aborted at PERL2EXE_STORAGE/DBI.pm line 157.
Compilation failed in require at ** line 15.
BEGIN failed--compilation aborted at ** line 15.


・・・うーむ・・

どうやらDBIの設定がいろいろ必要らしい。


苦戦は続く・・・



そして改めて説明をよく見ると、「Mysqlを使用する場合は、DBD::Mysql_PPを使用してください」
みたいなことが書かれている・・・

ということは、通常のCを使うデータベースドライバが使えないっつーことか。

このあたりで、ひょっとすると、これはものすごく使えないソフトなのでは・・・という不安がよぎる。


調べてみると案の定、Mysql_PPはいつまでたってもバージョンが0代だし、処理がくそ遅いという評判。


まあ全てPurePerlでやろうってんだからそうなるだろうな。

さらにMysql_PPの依存モジュールであるNet::Mysqlモジュールでもようわからんエラーが続出。




そして、ついに対応するのをあきらめた私。



結論:

データベース連携するプログラムはPerl2exeで(気軽に)使えない。
そうじゃないものなら使用する価値はまあまあある。
ただしスクリプトにモジュール名が書いてあったら必ず必要。


以上、ご参考までに。
ブラウザからのデバック中とかに、うっかり無限ループさせてCPUがフル回転に
なっちゃったときとか、Fedoraのシステムモニタ(Windowsでいう
タスクマネージャ?)で止めたいプロセスIDを探したくても、apacheユーザーで
動かしたプロセスは、1ユーザーでログインしてる場合は表示されない。
(rootでログインしないと表示されない)

そんなとき、てっとりばやく騒音をおさえたいのでメモ。


コマンドラインからSUになり、

--------------------------------------------------------
#top
--------------------------------------------------------

コマンドを実行すると、実行中のプロセスIDなどがCPU負荷の高い順に表示されるので、
停止させたいプロセスIDを見つけて、

--------------------------------------------------------
#kill -9 プロセスID
--------------------------------------------------------


これが一番早いかな。

自分がapacheのグループに入ってればシステムモニタで確認できるのかな?
まだ試してないけど。
最近yumのパッケージなどあまり更新してなかったので、久々にやるかと思って、
GUIでアップデートを行なったらいきなりperlスクリプトが500Internal Server Error。

うざーー!

最初にCGI::Carp qw(fatalsToBrowser)を呼んでいるので、このエラーの場合は
たいていヘッダー出力が間違っていることがほとんど。

しかしどこもおかしくない。

/var/log/httpd/error_log を見ても、お得意の
「Premature end of script headers」

しかしよーく見ると
「Can't locate object method "splitpath" via package "File::Spec" at /usr/lib/perl5/5.10.0/CGI/Carp.pm line 361, line 64.」

なので、試しに、同じようにCarp.pmを使用してるMTのスクリプトにアクセスしてみたら、同様のエラーコメント。


今回のyumアップデート直後のエラーだけに
/var/log/yum.log を見てみる。

Apr 25 16:01:29 Updated: httpd-2.2.11-2.fc10.i386
Apr 25 16:01:29 Updated: 4:perl-libs-5.10.0-68.fc10.i386
  ・
  ・
Apr 25 16:02:37 Updated: cpan2rpm-2.028-6.fc10.noarch

うーん、なんかこの辺が怪しい感じ。


アパッチのアップデートも入ってるけど、perlのモジュールを結構全面的に
書き換えてる感じだから、とりあえずエラーが出てるおおもとの
File::Specモジュールをとりあえずインストールしなおすかってことで・・

たしかこれはCpanのRPMパッケージだったはずだから、とりあえず、

----------------------------------------------------
# rpm -e perl-File-Spec

# rpm -q perl-File-Spec
パッケージ perl-File-Spec はインストールされていません。

----------------------------------------------------


と、ここで何となくスクリプトを実行してみたら、
あれ・・・動いた・・・。

MTにもちゃんとログインできる・・・


/usr/lib/perl5/ の中を確認すると、何か知らんけどFile::Specモジュールが
入ってる・・・
ということは、今回のアップデートでperl5.10.0の標準モジュールになった
ってこと?
いやいやそんなはずはない。Carp.pmなんてずっと昔から使ってるんだから。

rpmを削除してスクリプトがちゃんと動くってことは、今まで標準
モジュールよりRPMパッケージの方を優先して読み込んでたってこと?

てゆうか、最初からFile::Spec入ってるのになんで俺RPMでインストールしちゃって
るんだろう?

とにかく今回のモジュールアップデートでどこかダブったんだか改行コードがおかしく
なったんだかようわからんが、直ってよかった。

2日ハマったのでメモ。