« 2005年11月 | メイン | 2007年03月 »

2007年02月27日

掲示板スパム対策

何年もHPを運営していて、BBSを設置していると、掲示板のURLがボットによって収集されているらしく、嫌になるほどスパムな書き込みが繰り返される。LQによるアクセス制限など細工をしてみたが、完全には対処しきれないし、結局はイタチごっこになるのは避けられない。

しかし、もっと根本的なところで対策出来るのではないかと思いつき、実際やってみたら非常に効果がある事が分かった。敵の立場になってみれば簡単な答えだったと思うのだが、まっとうに運営している人ほど、スパマーの気持ちなどに気づかないと思う。

さて、具体的にスパムに対して有効な対策をまず記述しよう。手っ取り早いのは掲示板のURLを変更してしまうことだ。多くの場合はCGIで掲示板を動かしていると思う。この掲示板CGIのスクリプトファイル名を変更するなり、ディレクトリ名を変更するなりすれば良いのだ。

もちろんこの変更に伴って、HPに設置してある掲示板へのリンクボタンなどに設定してあるハイパーリンクも変更しなくてはならない。しかしそれほどの手間はかからないのではないかと思う。一日に10以上のスパム書き込みが有る人は、試しにURLを変更してみて欲しい。 

ではなぜBBSのURLを変更するだけで効果があるのだろうか。これはスパマーの気持ちになって考えれば答えが出てくる。なぜなら奴らは、「楽して儲けたい」と考え、「効率の良い方法を常に求めている」のだ。ある意味「極道」である。そういう人種が、Webブラウザを使って、いちいちHPにアクセスし、BBSへのリンクボタンをクリックしてBBSへ書き込んでいるハズが無いのである。

一年以上前は、まだそれほどスパムの被害も深刻ではなかった。恐らくお気に入りなどから直接アクセスされているのだろうと思っていたのだが、現在、私のHPに設置してあるBBSは、明らかに異常なアクセス頻度である。連続書き込みも後を絶たない。現在はLQによってアクセス制限をかけているので、9割以上のスパムを弾いているのだが、そのログを見るだけでもうんざりする程である。絶対に奴らは手作業ではなく、自動化した「スクリプト」や「巡回ツール」でスパムな書き込みを行っているに違いないと気づいたのだ。

私は現時点ではプログラミングと呼べるような大層な事は出来ないのだが、理屈からすれば大した技術が無くても作れてしまうという事は想像出来る。そんな人様の迷惑を考えないツールを作って販売し、懐に金をしまい込んでいる輩もきっと存在するに違いない。また、活きているBBSのURL情報、使われている掲示板CGIの種類の情報などを収集して売買している輩も居るに違いないと思う。そうでなければこの異常なまでの書き込み、そしてBBSのURLを変更しただけでアクセスが無くなる事の説明がつかない。

BBSへのスパム書き込みに日々悩まされている管理者には、駄目元でURLを変更してみることをお勧めしたい。この方法は極めて原始的な方法だが、いくらプログラミング技術が進んだとしても、追従するのは困難だし、仮に追従してくるツールを開発するにしても、プログラマーにかなりの労務を強いることになるからして、現状はかなり効果的だと思う。(恐らく当面は巡回リストから除外され嘘の様にスパムが減るだろう。)

己を守るためには敵を知る事も重要」だということは以前から知識として持っていたが、まさかこんなに身近なところに答えが有ったとは驚きである。個人的には定期的にURLを変更していこうと思う。URLを変更すると欠点もあるが、BBSへ直接お気に入りからアクセスしてくる人の中にまっとうな人は、まず居ないと考えても良いと思う。私も人様のBBSへのダイレクトアクセスは極力避けようと思う次第である。 

投稿者 sasapurin : 16:22 | コメント (0) | トラックバック

2007年02月20日

Live CD で distcc 出来そうな気配

先日、distccKNOPPIXの入手を断念したばかりだが、そんな難しいことを考えなくても良いことがだんだんわかってきた。素のKNOPPIXにもdistccが装備されているのである。そしてなんともっと身近なGentoo Live CDにもdistccが実装されているらしい事がわかった。

考えてみれば、私がGentooのインストールに使ってみたのは、50MB程度のminiインストールCDだったから、必要最低限のツールしか入ってなかったのだ。一時は諦めかけたBootable CDによる一時的なdistcc分散コンパイル計画は、現実味を帯びてきた。 

さて、遠回りした結果ようやく思いついた、KNOPPIX、もしくはGentooのLiveCDを使ってdistccを行おうという計画だが、確認しておかなければならないことがある。

まず第一はgccのバージョンについてだ。 これについてはGoogleで検索してみたりしたのだが、そんな手間をかけずとも、一目瞭然でわかる有名なサイトがあった。DistroWatch.comである。

ありがたいことに、Gentoo 2006.1のgccバージョンは4.1.1であり、KNOPPIX 5.1.1のgccも4.1.1という事が直ぐに比較できる。これでgccのバージョンについての課題はクリアだ。

次の課題はdistccがKNOPPIXに入っているかどうかだ。これは実際にKNOPPIX 5.1.1をダウンロードして、CD-Rに焼いてBootして確認してみた。distccはインストールされており、コマンドで操作できることが確認できた。これでGentoo 2006.1 のLiveCDが無理だった場合でも、KNOPPIXという最終手段があることが分かった。

いよいよ本題の、Gentoo 2006.1 LiveCDについての検証だ。 KNOPPIXと同様にBootableになっているので、CDブートできる。そのまま放置しておくと、Gentooのデスクトップ環境が表示される。どうやら"gentoo"というユーザー名でオートログインしている様だ。デスクトップ上には、コマンドラインのインストーラー、及びグラフィカルなインストーラーを起動するアイコンがある。

ただしこのgentooユーザーでログインした状態では、管理者権限がないため設定の変更などは出来ない。つまりdistccの設定なども出来ないのだ。これは非常に困った。しかし回避方法を見つけたので安心して欲しい。

CTRL + ATL + F1キー押下で、仮想コンソールTTY1を表示させる。rootでログインした状態にあるので、rootのパスワードを変更(設定)してしまえばよいのだ。

#passwd 

 ついでにgentooのパスワードも変更しておこう

#passwd gentoo 

更についでに、gentooをwheelグループに登録してしまおう。

#gpasswd -a gentoo wheel

パスワード等の変更が反映されたか確認してみる。
まずは、CTRL + ALT + F7キーを押して仮想コンソールTTY1を抜け、X-Windowのデスクトップ画面に戻ろう。

各種root権限が必要な機能にアクセスし、rootパスワードにて設定変更等が行なえるか確認する。ネットワーク設定等は、root権限が無いと行なえないので確認してみて欲しい。

ターミナルでユーザー:gentooからsuできることを確認しよう。同様にsudo出来ることを確認してみて欲しい。これらが出来るようになったら、gentoo Live CDは自分の支配下に置いたと同じだ。

distccに関わる設定ファイルを、suになってからviで開いて編集し保存(RAM上なので電源を切れば戻る)してみる。うまく出来る事が確認できた。distccをサービスとして登録したりしてみたが問題無さそうだ。どうやらGentoo Live CDでdistccの分散コンパイルマシンを一時的に準備することが出来そうだ。最近はCD-Rも安くなった(というよりもDVD-Rの方が断然安いが)ので、マシンの分焼いても良いだろう。まぁ取り合えず一台で試してみてからの方が無駄が無いかな。700MBのCD-RWが安く手に入ればそちらの方が後々便利かも知れない。エコロジーという観点からも。

取り合えず今回は、CDブートでdistcc環境が作れそうだという話まで。また余裕が出来た時に実際の分散コンパイル作業を行なってインプレしてみたいと思う。 ちょっと心が躍ってきた感じがする。

投稿者 sasapurin : 14:34 | コメント (0) | トラックバック

2007年02月19日

distccKNOPPIX

一体どこにカテゴライズしたらいいのかわからなくなったけれど、素直にKNOPPIXを作っちゃおう。Gentoo Linuxのコンパイル環境をより効率的に行うために、distccという分散コンパイルの仕組みがあるのを知ったが、問題はdistccをどこで動かすかである。LAN内にGentooマシンがゴロゴロ転がっていれば、emergeしてしまえば直ぐに分散コンパイル環境は整うが、実際はそうは行かない。Windowsマシンありの、BSDマシンありの、Gentoo以外のLinuxありのでしょう。

Windowsマシン上ならば、cygwinを入れて、その上にdistccを入れて分散コンパイルに参加させると言う方法もある。はたまた他のLinuxマシンでも、例えばDebianならaptでdistccを導入出来る。FreeBSDならばPortsで導入可能なことも確認した。

しかし課題は、gccのバージョン揃えである。distccの為に安定稼動している他のマシンのgccを入れ替えるとか言うのもかなり無茶だし手間とも言える。ならば一台Gentoo Baseにvimとdistccをemergeした状態で、Ghotstを取ってそれを複数台のマシンに復元して回るか。不可能ではないが現実的ではない。現状のシステムに変更を加えずに一時的に分散コンパイルに参加させたいのだ。

そうなれば、やっぱりここは1CD Linuxなディストリビューションの出番だろう。例えばKNOPPIXならば、必要な時だけCDブートして使用すれば良い。作業が終わればCDを取り出してリブートすれば、元通りに戻る。KNOPPIXをカスタマイズしてdistccを組み込むことも、gccを入れ替えることも、要らないパッケージを削除して自分流を作り出すことも技術的には可能である。普段はWindowsで稼動しているマシンを、Gentooのインストールの時にだけ、Linuxマシンとして稼動させることが可能だ。やっぱりこれしかない。

もしかしたら既にdistccを目的にKNOPPIXを作っている人が要るんじゃないかと思ったり。Googleで"distcc KNOPPIX"を検索してみた。そしたら「もしかして:distccKNOPPIX」と言われた。distccKNOOPPIXという単語がGoogleのキャッシュにある様だ。かなり期待できる。

行き着いたのは、distccKNOPPIXのHPだったが残念ながら英語である。gccのバージョンを選んでからISOファイルもダウンロードできる様だ。それ以外はGoogleでも日本語の情報はほとんど見つからない。どうやらここからは試行錯誤が必要になりそうだ。もしくは苦手な英語との格闘かな。

distccKNOPPIX is a directly bootable and self-configuring Linux system on a small iso (~55MB) running adistccddaemon. It is a simple remastering ofDamn Small Linuxrunning a distccd daemon and some general cleaning up/removal of unneeded packages/apps. It's obvious target is for those who have other machines at their hands, and for some reason or an other can not get a distccd daemon running on it. Damn Small Linux is a remastering ofKNOPPIX

distccKNOPPIXはdistccdデーモンを走らせる小さいiso(~55MB)の上の直接ブート可能な、自己を構成するリナックスシステムです。 それは、distccdデーモンを走らせるDamn Smallリナックスの簡単な再習得と不要なパッケージ/アプリケーションの何らかの一般的な掃除/取り外しです。 目標が彼らの手においてある理由で他のマシンを持っている人々のためのものであることが明白であるか、またはdistccdデーモンはもう一方でそれで動くことができません。 Damn SmallリナックスはKNOPPIXのリマスタリングです。

なるほど期待できそうだからダウンロードしてみるか、と思いきや、カートに追加とか、まるでネット通販みたいな仕組みだぞ?ががーん、出てきた。4.99CADってカナダドルって意味か?金払って買うにしても海外だと、やっぱり怖いから買えない。せめて日本語でちゃんとしたところが決済処理してくれないと。

残念ながら自分で作るしかなくなったのでは無いだろうか。KNOPPIXのカスタマイズを学習しないといけなさそうだ。ゴールが見えたと思いきや、それは全然違うゴールであった。だれか日本人の知識ある人が作ってくれないかなぁ。 KNOPPIXについてはもう少し詳しく調べてみるつもり。

とりあえず後で必要となりそうなソースの配布元を備忘録。

投稿者 sasapurin : 01:29 | コメント (0) | トラックバック

2007年02月18日

クロスコンパイリング

distccを知って、同一ネットワーク上にある速いマシンにコンパイルを助けてもらえば、しょぼいマシンでもGentoo使えるじゃん!と思った訳ですが、distccを使うにも色々と環境整備しなくてはならないし、gccのバージョンを整えたりとなれない作業が必要そうです。

そこでふと思ったのは、純粋に速いマシンでコンパイルして、出来上がったのをコピーしてインストールという訳にはいかんのか?という事です。CPUの種類は違うけれど基本的にx86系(i486,i586,i686)のDOS/Vがほとんどだし、なんとかならんのかあと思うのです。

そんな事を調べていたら、クロスコンパイリングという言葉が出てきました。過去に目にしたことのある言葉ですが、意味は全然知りません。この際に学習して しまおうと情報を探したら、またしてもGentooのドキュメントがわかりやすいというところに行き着きました。もしかしたらGentooって凄く勉強に なるかも。

クロスコンパイリングの意味するところは、早い話、 あるアーキテクチャで他のアーキテクチャ用にプログラムをビルドするために使うことです。 極端な話、例えばAthlon(i686)でK6-2(i586)用のプログラムをビルドしたり、Sparcでppc用のプログラムをビルドするなんて事も出来るのだそうです。かなり驚きました。そんな事が出来るんだ。

もっとも、クロスコンパイリング環境を整えるってのもまた別な課題が出てくるから、本当に必要に迫られたら、計画的に行わないとどつぼにはまりそうな気配ぷんぷん。でも面白そうな技術ではある。頭の良い人が便利な事を次々と考えているんだな。


参考サイト
DistCC クロスコンパイルガイド
Gentoo distcc ドキュメント 

投稿者 sasapurin : 01:52 | コメント (0) | トラックバック

ccacheのインストール

distccと併せて、ccacheも入れてみることにした。
これでコンパイル処理が分散化され速くなればかなりうれしい。

portinstallでccacheをインストール

# cd /usr/ports
# portinstall devel/ccache devel/distcc

# mkdir -p /.ccache
# setenv CCACHE_DIR /.ccache
# printenv

/etc/make.confに追記

.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) && !defined(NOCCACHE)
CC=/usr/local/libexec/ccache/world-cc
CXX=/usr/local/libexec/ccache/world-c++
.endif

/etc/csh.cshrcに追記

setenv PATH /usr/local/libexec/ccache/:$PATH
setenv CCACHE_PATH /usr/bin:/usr/local/bin
setenv CCACHE_DIR /.ccache
setenv CCACHE_LOGFILE /var/log/ccache.log
#To use distcc
setenv CCACHE_PREFIX /usr/local/bin/distcc
setenv DISTCC_HOSTS 'localhost vine gentoo redhat'

参考URL
otsune's FreeBSD memo

投稿者 sasapurin : 00:41 | コメント (0) | トラックバック

distccのインストール:その1

Gentoo Linuxに寄り道したおかげで、面白い事を覚えた。distccによる分散コンパイルである。

FreeBSDのPortsにもdistccがある事を「FreeBSD Ports Search」で確認したので、インストールしてみることにした。もう4.11は余命短いと言うか、早く6.x系に移行しなくてはならないので、色々むちゃな事をやっていたりする。

distccのPortsは、Category develにあった。つまり/usr/ports/devel/distcc である。

# cd /usr/ports
# portinstall devel/distcc
# rehash
# /usr/local/etc/rc.d/distccd.sh start
Starting distccd.

とりあえずはこれだけである。もちろん各種設定はエディタで行わなくてはならない。
後心配なのはコンパイラのバージョン違いとか..である。このあたりは徐々に検証していかないと訳がわからない。何しろコンパイラなんて意味不明のまま使いつづけてきたのだから。

但し、分散コンパイルが実現すれば、古いマシンでも速いマシンに助けてもらえるので、コンパイル処理がかなり速くなるという、よだれものの技術だからやってみる価値は十分にあると思うのだ。


参考サイト

投稿者 sasapurin : 00:15 | コメント (0) | トラックバック

2007年02月17日

Vine Linux 4.0 のxorg.conf

何年ぶりだか、Gentoo Linuxをインストールしてみた。知人が最近UNIX系の知識を使う会社に転職したそうで、しきりにGentooはいいよと電話でいわれるからだ。たしかにGentooはBSDっぽいところがあって、個人的には使い易いと感じる。

ただし、問題はインストールにかかる手間と時間だ。手間は多少かかっても許せるが、時間が異常にかかるのはなんとも言えない弱点だ。基本的にコンパイル処理が発生する頻度が高く、マシンスペックが低いと数日がかりである。とりあえずCPUのクロックが2GHz位で、メモリーが512MB以上あれば、一日位で何とかなるかも知れない。 非常に見通しの良いシステムを作れる仕組だが、現実的なことを考えると、マシンスペックが必要異常に欲しくなる。本来は型遅れなマシンでも動く軽さという魅力を備えているというのに。

と、悲観的なことを書いたけれど、Gentooには美味しい機能というか仕組を簡単に実装することが出来るので、処理の速いGentooマシンを持っていれば、同一ネットワーク上で分散コンパイルすることが出来るのです。この仕組さえ仕込んでしまえば、emergeの時にかかるコンパイル処理を他のマシンに助けてもらえるので、比較的古いマシンでも再利用することが出来そうです。詳しくは"distcc"や"Gentoo 分散コンパイル"等のキーワードで検索してみてください。

実際、GentooでWebサーバを組んだら、かなり無駄なものを削ぎ落とした環境が作れるなとマジに思った。それ位Gentooのemergeは魅力的なパッケージ管理ツールである。


それはさておき、興味本位というか、以前はマシンがしょぼ過ぎて途中で断念したX-Windowをいれてみようと、ThinkPad X31 にGentooのベースシステムをインストールした後で、emerge xorg-x11を実行してみた。おそらく3時間かからない位でコンパイルが終わっていた。さすがにPentium-Mだけあって、計算速度は桁違いである。(最近のCore Duoなんかだともっと速いんだろうな)

しかし、肝心のXorgのコンフィグが上手く設定出来ない。なんか5年以上前にFreeBSDでXFree86と格闘したのを思い出した。一週間位かかってXの立ち上げに成功した時の達成感。でも今はそれほど固執する理由もないので、てっとり早く同じXorgを使っているVine Linux 4.0のxorg.confを参考にすることにした。

ベースシステムを入れ終わったら、とにかくまずvimをインストールして(nanoはめちゃ使いづらい)、sshを有効にしちゃえば、X-Windowが動いているUNIXマシン、若しくはWindows上でPuttyやTeraTermPro辺りから設定すれば、コピペも出来るからかなり作業効率が上がる筈だ。急がば回れとはこのことだなと思ったり。

という訳で自分の為に、Vine Linux 4.0(by ThinkPad X31)のxorg.confをテキストファイルで上げておく。xorg.conf.txtをダウンロード

投稿者 sasapurin : 23:50 | コメント (0) | トラックバック

ブートローダー:grub

Vine Linux 4.0 からブートローダーが、liloからgrubに変更になったと言う話は、Vineユーザーならたぶん知っている話。初めて4.0の起動画面を見た時に、なんか質素だなぁと感じたと思います。はい私も同じでした。

たまたま昨日からGentoo Linuxと戯れていたので、grubの設定も自分でやらなくてはならず、/boot/grub/grub.confも作ったのですが、その時に "splashimage"と言うものの存在というか、要するに画像ファイルをgrub.confで指定してあるだけなんだという事に気づいたのでありま す。

という訳で早速リサーチして、Vine Linux 4.0のブートローダーをカラフルにしてみたいと思います。

検索してみたところ、Vine Linux ではliloが標準のころ、Vine PlusのGRUBパッケージを使いたい人向けのメーリングリストログを発見しました。書いてある内容は、私がGentooを入れる時にGentooのインストールハンドブックに書いてあった事を、噛み砕いて更にわかり易く説明しています。

情報が消えてしまうと悲しいので、要約して抜き出しておきます。

スプラッシュイメージを用意していない場合は、 menu.lst ファイルで
splashimage=…
の行を記述しない(記述してあればコメントアウトするか消す)ようにすればOK。


ファイル名は /boot/grub/splash.xpm.gz 固定ではない。
/dev/hda5 パーティションに /home/hoge/img/bike_gua.xpm.gz というファイル名で置いたら、
splashimage=(hd0,4)/home/hoge/img/bike_gua.xpm.gz
と書けば良い。
# 但し、(hd0,4)がGRUBが認識できるファイルシステムでないと読めない。

画像のサイズは640×480ピクセル、14色、 .xpm 限定。
gzip で圧縮している必要はなく、 .xpm ファイルでも読めるが、圧縮しておいた方が処理は速いらしい。

さらに、 splashimage 使用時の文字色と背景色も指定できる。
foreground=ff0000
background=333333
画像によって調整すると文字が読み易くセンスが良いと思われるだろう。
記述しなければデフォルトの白黒表示される。

ソース元は、英語だけど正式なドキュメントっぽいので信憑性を確認したい人はどうぞ。
GRUB Splash Image Howto


さて使いかたが分かったら、肝心のSplashimageをどうするかだ。14色というのはかなり少ない色数だけに、風景写真なんかだとザラザラした質感になってしまうのは見えている。そうなるとアニメ画像とかの方が無難な様な気もする。

とりあえず画像はなんとかするとして、どうやって、14色で640x480の、xpm.gzファイルを作るのかという事を調べてみたら、あっさり見付けることが出来た。

# convert -resize 640x480 -colors 14 myphoto.jpg splashimage.xpm
# gzip splashimage.xpm
# mv splashimage.xpm.gz /boot/grub/

convertコマンドはImagemagickに入っているらしいので、aptで調べてみたら、Vine Linux 4.0のデスクトップ環境でインストールした場合、既にImagemagickはインストールされていて、即使うことが出来た。とりあえず上記の様にして、myphoto.jpgから作ってみたところ、出来上がった画像は予想通りのザラザラ状態。これはちょっと使うには寂しいな。コマンドだけで処理出来るから楽っちゃあ楽なんだけど、他に良い方法はないのかな?

見付けました、Gimpを使った減色方法(画像キャプチャ付き)の解説ページです。
あんまり詳しい解説じゃないけど(苦笑)画像があるので真似は出来ると思います。
写真や画像をginmpで14色の画像に変更する方法

という感じでgrubに表示される画像や表示の色をカスタマイズ出来る事が分かったので、暇な時にやってみようと思う。

投稿者 sasapurin : 20:52 | コメント (0) | トラックバック

2007年02月15日

Perlモジュールの容易な設置方法

先日以来、Perlのモジュールには苦戦させられっぱなしなのだが、ちょっと興味深いテクニックを見付けたので備忘録。未検証なのだが、モジュールをインストールせず、Perlスクリプトを設置するフォルダに階層的に設置すれば動くらしいのだ。

基本的にわが家の場合は自宅サーバ、及びテスト用のマシンがあるので、モジュールをCPANコンソールからインストールすれば良いのだが、次々とモジュールを入れると訳が分からなくなる。実際素手に私のテストマシンは、Perlモジュールがわんさかと入っている。

さて、情報元となったページは「指定したディレクトリ中のファイル一覧をRSSにするCGI」である。ここに興味深いテクニックがさりげなく書かれているのだ。

モジュール「XML::RSS」が必要です。ない場合はCPANから入手して下さい。サーバにインストールすることが不可能な場合は、このCGIと同じディレクトリ内に ./XML/RSS/ というディレクトリを掘って、そこに格納すればOKです。

ようするに、ファイル一覧をRSSにするCGIを配布して下さっているのだが、XML::RSSモジュールが必要なCGIなので、それがないと動かない訳である。しかし、レンタルサーバ等の場合は、必ずしも必要としているPerlモジュールがサーバにインストールされているとは限らない。

そこでこのテクニックである。hogehoge.cgiを設置したディレクトリに、XMLというフォルダを作成し、その中に更にRSSというフォルダを作成して、CPANから入手したXMR::RSSモジュールいに該当する"RSS.pm"を入れておけば良いということである。

まだ検証できていないのだが、CGIを作っている人が書いているのだから間違いないだろう。検証の為に何か他のモジュールを要求するCGIで試してみようかな。なぜならaptでXML::RSSをインストールしちゃったから既に入っているんです。てな訳で一応備忘録でした。

投稿者 sasapurin : 17:26 | コメント (0) | トラックバック

2007年02月13日

Perlライブラリの検索PATHを格納した配列@INC

io氏から昨日のエントリにコメントを頂いた。
私が適当にPerlがモジュールを認識しそうなPATHへ、頂いたurl_get.pmを置いたのだが、あながち間違っていないということであった。

そして、Perlがモジュール等のライブラリを認識するPATHは、INCという配列に記録されているとの情報も頂いた。これを手がかりにGoogle先生に聞いてみると色々な情報が見付かった。

まず、手っ取り早くシェルから確認する方法である。Vine Linux 3.2 のbashから操作した。

perl -V

最後の方に@INCというところがあり、検索PATHが表示される。

もうひとつの方法は下記の通りだ。こっちの方がシンプルな結果が得られる

perl -le 'print for @INC'

 更に興味深い情報も見付けた。

KMsWiki:Perl/@INC

ここでは、環境変数PERL5LIBに環境変数としてPATHを追加して置けば、標準ライブラリよりも先に捜し出してくれるとの記述がある。PERL5LIBで検索すれば、まだ詳しい情報が出てくるがきりがないので割愛します。まだまだ勉強しなくては太刀打できない。

投稿者 sasapurin : 23:04 | コメント (0) | トラックバック

Perlモジュールの一覧を取るCGI

ここ数日、Perlのモジュールのことで四苦八苦しとります。
Googleで捜し出した情報の中から、今知りたいことを少しずつ学習中。
ふと目に止まったのが、サーバーにインストールされているPerlモジュールの一覧を取れるCGIを無償で公開して下さっているサイトを発見したので、早速試してみると動作成功しましたので、記しておきます。

Perl専門サイト - futomi's CGI Cafe

サーバーアナライザーと言うページから、CGIスクリプト一個と、REAEMEファイルがダウンロード出来ます。こいつをサーバーにアップして、パーミッション変更で実行権をあたえて、ブラウザでアクセスすると、綺麗に整理された情報が表示されます。

こいつは便利だけど、情報的にやばい様な気もするので、URLが分からない場所、もしくはアクセス制限をかけておいた方がよろしいかと思います。

なんか、Perlモジュールがいっぱいリストされるんだけど、こんなにいっぱい入れた覚えはないぞ。もしやCPANコンソールで一括更新した際に入ったのかな。なんとか整理しないと。

投稿者 sasapurin : 21:13 | コメント (0) | トラックバック

Vine Linux 3.2で快適な日本語入力を

このブログは、いちおう自宅サーバーのことについて書いているのだが、検証用にX-Windowも入れたVine Linux 3.2 環境を使っていると、Webブラウザが使用できて結構便利だったりして、そのままブログを編集できて更に快適だったりする。しかし、cannaとkinput2による日本語入力の効率の悪さ に嫌気がさしてきた。

そこで、Vine Linux 4.0 から採用された、anthyを使えないものかとaptリポジトリを検索してみたところ、scim-anthyがあるではないか。という訳でサーバー用途で もX-Windowを必要とする人が居るかもしれないと言う理由付けで、scim -anthyを入れてみることにした。なお、scim-anthyは、PC-BSDで使用していたので快適さは体験済みなので、インストール成功すれば日本語入力がかなり改善されるハズである。

まず念のために、apt-cacheして本当にあるか確認してみる。

#  apt-cache search anthy
anthy - Anthy - 日本語入力システムおよび辞書
anthy-devel - libanthy を使ったアプリケーションを開発するためのファイル
anthy-el - Emacs-lisp frontend for Anthy
jmode - X Input Method Server for Japanese conversion system of Anthy
scim-anthy - anthy のための SCIM IMEngine モジュール
sumika - a utility for managing user customized dictionary
kasumi - Anthy 個人辞書管理ツール

 

aptは依存関係を自動で処理してくれるので、目的のパッケージをインストールすれば、依存パッケージは気にしなくてよいのが楽だ。下記のようにインストールしてみる。

apt-get install scim-anthy
apt-get install kasumi

確か、Vineではsetimeがscimに対応したらしいので、下記のようにしてIMEを切替えてみる。

setime scim

おそらく右下に、SCIMのツールバーが表示されると思う。
これでATOKに匹敵する、とまでは言えないものの、かなり快適な日本語入力が可能となる。

ちなみにSCIMのON/OFFは、[SHIFT]+[SPACE]もしくは、[半角/全角]キーだ。この辺りもカスタマイズできたと思うので、戯れてみ ようと思う人は試してみてほしい。画期的な発見があったら是非篭コメントで教えていただきたい。私は使い慣れたATOK風にカスタマイズしてみようかなと 思ったりしている。

ちょっとBlogの趣旨とは逸れたが、日本語入力の快適さを求めるのは当然なので御了承頂きたい。

投稿者 sasapurin : 19:00 | コメント (0) | トラックバック

rss_stock.cgi ( io 氏作) その2

多分でたらめなやり方なのでしょうが、我流でrss_stock.cgiが動きました。
やはり躓いていたのは、Perlのモジュールについての理解が足りないという事に尽きます。もちろん私にはコードが書けないのですが、誰かが作ったスクリプトを設置するしても、モジュールの理解は必須だなと痛感したのであります。

取り合えず手がかりとなるのは、Apacheが吐き出すエラーメッセージだけです。これを手がかりにどうやって対処して(無理矢理)動くようにした か備忘録です。実際かなり地味な作業でした。しかし動いたという結果には満足しています。(出来れば詳しい方から指導を受けて裏付けをとりたいものです ね)

下記のエラーが /var/log/httpd/error.log に記されていました。
少しずつ対処していきます。


Can't locate XML/RSS.pm in @INC (@INC contains: /usr/lib/perl5/5.8.2/i386-linux-thread-multi /usr/lib/perl5/5.8.2 /usr/lib/perl5/site_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.2 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.2 /usr/lib/perl5/vendor_perl /usr/local/lib/site_perl/5.8.2/i386-linux-thread-multi /usr/local/lib/site_perl/5.8.2 /usr/local/lib/site_perl .) at /home/sasakis/public_html/rss_stock/rss_stock.cgi line 3.

早い話、XML/RSS.pmというモジュールがないというエラーだ。
このモジュールは、Vine Linux 3.2の場合、aptでインストール出来ることがわかった。

apt-cache search XML::RSS
perl-XML-RSS - creates and updates RSS files with Perl
apt-get install perl-XML-RSS

これで、XML/RSS.pmが見付からないというエラーは出なくなった。


Can't locate url_get.pm in @INC (@INC contains: /usr/lib/perl5/5.8.2/i386-linux-thread-multi /usr/lib/perl5/5.8.2 /usr/lib/perl5/site_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.2 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.2 /usr/lib/perl5/vendor_perl /usr/local/lib/site_perl/5.8.2/i386-linux-thread-multi /usr/local/lib/site_perl/5.8.2
/usr/local/lib/site_perl.) at /home/sasakis/public_html/rss_stock/rss_stock.cgi line 4.

url_get.pmというモジュールがないと言うエラーである。
昨日のエントリーに記したよう、このモジュールは io 氏の自家製モジュールだと分かったので、ソースをそのままダウンロードして、url_get.pmとして保存した。
問題は保存場所だ。どこに保存したらPerlがモジュールとして認識してくれるのだろうか?
冷静に考えてみたら答えらしきものが、Apacheのエラーメッセージにあるではないか!おそらくこれがPerlが認識している、環境変数らしきものだと推測し、一番最後に書かれているPATHに保存してみた。結果はOK!、このエラーメッセージも出なくなった。


Can't locate LWP/Simple.pm in @INC (@INC contains: /usr/lib/perl5/5.8.2/i386-linux-thread-multi /usr/lib/perl5/5.8.2 /usr/lib/perl5/site_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.2 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.2 /usr/lib/perl5/vendor_perl /usr/local/lib/site_perl/5.8.2/i386-linux-thread-multi /usr/local/lib/site_perl/5.8.2 /usr/local/lib/site_perl .) at /usr/local/lib/site_perl/url_get.pm line 21.

LWP/Simple.pmというモジュールがないというメッセージだ。

apt-cache search LWP::Simple
perl-libwww-perl - libwww-perl module for perl
apt-get install perl-libwww-perl

これでLWP/Simple.pmのエラーも記録されなくなった。


Can't locate Template/Extract.pm in @INC (@INC contains: /usr/lib/perl5/5.8.2/i386-linux-thread-multi /usr/lib/perl5/5.8.2 /usr/lib/perl5/site_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.2 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.2 /usr/lib/perl5/vendor_perl /usr/local/lib/site_perl/5.8.2/i386-linux-thread-multi /usr/local/lib/site_perl/5.8.2 /usr/local/lib/site_perl .) at /home/sasakis/public_html/rss_stock/rss_stock.cgi line 5.

Template/Extract.pmというモジュールがないというエラーメッセージだ。
残念ながらaptでは見付けられなかった。あんまりやりたくないのだがCPANコンソールからインストールするしか無さそうだ。

perl -MCPAN -e shell

cpan> install Template::Extract
cpan> quit

おおー、なんとかインストール出来たみたい。Template/Extract.pmのエラーも記録されなくなったぞ。


Can't locate Jcode.pm in @INC (@INC contains: /usr/lib/perl5/5.8.2/i386-linux-thread-multi /usr/lib/perl5/5.8.2 /usr/lib/perl5/site_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.2 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.2 /usr/lib/perl5/vendor_perl /usr/local/lib/site_perl/5.8.2/i386-linux-thread-multi /usr/local/lib/site_perl/5.8.2 /usr/local/lib/site_perl .) at /home/sasakis/public_html/rss_stock/rss_stock.cgi line 6.

Jcode.pmというモジュールがないと言うエラーだ。Jcode.plってのは、KENTさんのCGIでもよく見掛けた覚えがある。これのモジュールはaptで手に入るのだろうか?

apt-cache search jcode
jcode.pl - 日本語コード変換用Perlライブラリ
perl-Jcode - さまざまな日本語文字コードを Perl で扱うための Module
perlftlib - Perlftlib は、fonts.dir を作成するツールです。
apt-get install perl-Jcode
パッケージリストを読みこんでいます... 完了
依存情報ツリーを作成しています... 完了
以下のパッケージが新たにインストールされます:
  perl-Jcode
アップグレード: 0 個, 新規インストール: 1 個, 削除: 0 個, 保留: 0 個
165kB のアーカイブを取得する必要があります。
展開後に 546kB のディスク容量が追加消費されます。
取得:1 http://updates.vinelinux.org 3.2/i386/plus perl-Jcode 0.83-0vl4 [165kB]
165kB を 0s 秒で取得しました (379kB/s)
変更を適用しています...
準備中...                    ########################################### [100%]
   1:perl-Jcode             ########################################### [100%]
完了

見事にaptでインストール出来ちゃいました。もちろん Jcode.pmのエラーもこれで解消。


てな訳でかなり強引な手順?で、解決させたのですが、url_get.pmの設置方法については、全く根拠が無いというか思い付きなので、本来はどうすべきか調べなくてはと思っています。

そもそも、Perlがモジュールを認識するPATHがどこかに定義されていると思うのですが(シェルの環境変数と同じように)、それが何処で定義されているか全く不明です。持ってるPerl本にはそんな解説無かったしなぁ。

投稿者 sasapurin : 18:17 | コメント (0) | トラックバック

2007年02月12日

rss_stock.cgi ( io 氏作)

昨日に引き続きPerlと戯れてみる。正直言って昨日一日頑張ったが無理だと投げてしまっていた。しかし嬉しい事に、rss_stock.cgiの作者であるio氏からコメントをいただけた。今の私の知識ではどう頑張っても無理だったという理由が分かったからもう一頑張りしてみた。

io氏が作ったrss_stock.cgiは、日本株式の銘柄番号を指定すれば、その株価情報をRSSで返してくれるというCGIだ。氏のサイトに解説が3ステップに分けて書かれている。

恐らく氏にとってはPerlでスクリプトを書く事は簡単な事なのだろう。しかし私にとってはかなり高い壁である。Perl使いにしてみれば当然の事さえも知らないであろう。(Perl本は数冊買って読んだがちんぷんかんぷんである..orz)

後は、Googleで初心者に分かりやすく、かつ簡潔にまとめてくれているサイトと出会えるかどうかだ。今の時代にはむしろその方が、出会える確率が高いと思う。本を何冊買っても自分にしっくり来ないという事は多々あるが、ネット上の様々な性格の人の説明を読み比べると、自分の思考にピッタリ来る人が大抵見つかるものだ。但しニッチなジャンルでは絶対数が少ないので出会える確率も当然低い。

Perlから話が逸れたので軌道修正する。rss_stock.cgiは、Perlモジュールを必用とするuse記述があり、そこでurl_getを要求すると定義している。その存在の有無を把握せずに自前のサーバでrss_stock.cgiを実行してみたところ、WebブラウザにはInternal Server Errorが表示された。Webサーバプログラム(Apache)のログには、url_get.pmが見つからんと言う意味合いのエラーメッセージが記録されていた。そこで"url_get"というモジュールについてGoogle先生に相談してみたのだが、どうもこのケースに該当する情報が見つからない。"url_get.pm"とすると一件も見つからないのだ。これは抜け出る事が出来ない迷路にはまったのではないかと、昨夜ようやく気づいたのだ。

それで、ダメもとでio氏のBlogにトラックバック&コメントをしておいたのだが、今日、嬉しい事にコメントをいただき、"url_get"というスクリプトが、io氏の自家製だという事を知る事が出来たのだ。ご厚意で"url_get"のソースも早速公開して下さっている。

そう言う流れで、早速昨夜の続きを、と思いソースをコピペしつつ眺めてみたが、やはり良く分からない。分かるのはuse記述で何というモジュールが必用なのかだけだ。ぶっちゃけ私の現時点のスキルはその程度である。ファイル名は"url_get.pm"として、"rss_stock.cgi"と同じディレクトリに置いた。

動作環境は、Vine Linux 3.2 FTP版でフルインストール状態だ。普段は最小インストールにするのだが、Perlモジュールが足りないとかで躓くのを恐れて全て入れてみた。とにかく自前の鯖で動くのを確認するのが一番急ぐ改題だ。ちなみにマシンは我が家で最速のCPUを実装したThinkPad X31である。Linuxカーネル2.4系のVine Linux 3.2は流石にこのハードウェア環境では小気味良く動く。これでコンパイル処理なんかもイイ感じで進められるはずだ。

しかし、昨夜と状況は変わらない。WebブラウザにはInternal Server Errorが表示され、Apacheのログには、"url_get.pm"が見つからんうんぬんという意味合いと取れる英語が記録されている。

だめもとで、"url_get.pm"を"url_get.pl"としてみたが変化は無い。Apacheのログから推測すると、Perlは明らかに"url_get.pm"を探しており、それが見つからないとApacheに報告しているんだと思う。なので"url_get.pl"ではなく、"url_get.pm"としなくてはならないのだろうという想像は私にもつく。

さて一体、どこにその"url_get.pm"というPerlモジュールを配置すれば良いのだろうか?どうしたらPerlが"url_get.pm"の在処を認識してくれるのだろうか?この観点からGoogle先生に聞いてみたのだが、有力な情報は見つけられない。

という事で9割方愚痴の様な内容になったが、今日やってみた事、疑問に思った事を記してみた。出来ればio氏にも初心者が落ちる落とし穴を知って頂きたいので、今日もトラックバックを打たせていただくことにする。余りにも低レベルで恥ずかしい限りだが..

ああ、自分にはプログラミングは無理なんだなぁと、つくづく感じる。モノクロMacの時代から何度プログラミングで挫折しただろう。どうもプログラミングとなると、苦手意識が出てくる。どうやらトラウマになっているようだ。何とかして克服したい。あんまり思い詰めると憂鬱になりそうだから今日はこれまでにしようっと。

投稿者 sasapurin : 21:01 | コメント (0) | トラックバック

Perl モジュールの一括更新

Perlには正直手を焼いています。必要なモジュールが無い。

それはさておき、PerlモジュールのインストールにCPANコンソールが使えるという事を覚えたので、それなら一気にモジュールを更新するすべは無いのか?と普通に疑問に思った。無いはずは無いやろと、調べてみたらあったので備忘録。

まずはバージョンの現状と最新の比較コマンドのおさらい。

# perl -MCPAN -e "CPAN::Shell->r"

次に覚えたての、モジュール一括バージョンアップ。

perl -MCPAN -e "CPAN::Shell->install(CPAN::Shell->r)"

放置しておけば終わるかと思ったら甘かった。一々オプションをどうするか聞いてくる。
まぁ、一個ずつ更新する事を考えたらかなり楽だから良しとしましょう。

投稿者 sasapurin : 06:27 | コメント (0) | トラックバック

2007年02月11日

Perl のモジュールを追加する方法

訳あってPerlのモジュールを自宅サーバに追加インストールしたい。
まぁ早い話、他人の作ったCGIを動かしたいのだ。しかし特定のモジュールに依存している為に動作しないからモジュールを入れないといけないんだと思う。

ことの発端は、x Laboratory-株価のRSSである。株価をRSSで表示出来ると面白いなと思ってGoogleで検索したら、CGI構造とかを解説してくれているので読み入ってしまったのだ。しかし私は現時点プログラミングが出来ない。だけど言語は何でも良いから頑張って役立つものを作れる技術を身につけたい。

株価のRSS
株価のRSS(その2)
株価のRSS(その3)

とりあえず三話完結っぽい。

最初はFreeBSD上で行おうとしたが、XML::RSSのインストールが上手くできないので、Vine Linux 3.2上で行う事にした。

$ su -
# apt-cache  search  XML::RSS
perl-XML-RSS - creates and updates RSS files with Perl
# apt-get install perl-XML-RSS

XML::RSSはインストール出来たが、困った事にインターナル・サーバー・エラーとなってしまう。調べてみたら、"url_get.pm"が見つからないと言うエラーがApacheのログに記されていた。

なんだかよく分からないのだが、せっかくソースを公開しているのだから、読めよと言われそうだから覚悟を決めてエディタで開いてみたら、一番最初に下記の様な記述を発見。

#!/usr/bin/perl -w
use XML::RSS;
use url_get;
use Template::Extract;
use Jcode;

検索してみたら、どうやらこのuse宣言は、モジュールを要求している(多分)という事が分かった。
残念ながら"url_get.pm"なんてモジュールは持ってないし、aptでも見つけられない。(Googleでさえ見つけられない)。それに、"Template::Extract"も多分入って無さそうだ。

どうやらこの辺りの、Perlモジュール環境を整えてやらないといけないらしい。 知っている人にしてみれは簡単な事なんだろうが、プログラミングビギナーにはかなり辛い試練。

FreeBSDのPortsでダメ、Vineのaptでダメとなると、一体どうしたら良いものか..

諦めずに検索してみたら、CPANを使ってモジュールをインストールする方法を解説してくれているページを発見。CPANってモジュールのバージョンを確認する為に、今日使ったばかりだ。CPANのコンソールからインストール出来るのか。 

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

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

cpan>install url_get
CPAN: Storable loaded ok
Going to read /root/.cpan/Metadata
  Database was generated on Sun, 11 Feb 2007 05:09:24 GMT
Warning: Cannot install url_get, don't know what it is.
Try the command

    i /url_get/

to find objects with matching identifiers.

cpan>i /url_get/
No objects found of any type for argument /url_get/

だめじゃ~、そんなもんは知らんと怒られてしまう。一体どこに"url_get.pm"が有るんだろうか? 検索エンジン色々使っても見つからないとなると、初心者にはどうしようもないよなぁ。

 


追記

 

レンタルサーバーでモジュールをインストール出来ない場合、CGIファイルを編集して、インクルード記述を書き変えてしまうと言う方法も発見。なるほどというか、色々勉強になりますね。

レンタルサーバーでWWW::Mechanize使う方法

 

投稿者 sasapurin : 20:25 | コメント (0) | トラックバック

Perl モジュールのバージョンチェック

私は現時点、プログラミングが出来ないので、正直言ってPerlなんて苦手なのだが、多くのCGIスクリプトがPerlで書かれているので、自宅サーバで、それらを使う為には否応なしに最低限の知識は身につけておかなければならない。

Perlには膨大なモジュールがあり、それらはCPAN(Comprehensive Perl Archive Network)と呼ばれるライブラリからインストールする事が出来るらしい。これはこれで使い方を覚えるのが厄介なのだが、とりあえずインストールされているモジュール、バージョンの新旧、位はチェック出来る様になっていた方が良いと思われる。

IBMのサイトに、「Perlモジュールの展開を自動化する」という記事を見つけた。良く読むと主旨は全然違ってもっと高いレベルにあるのだが、インストールされているモジュールのバージョンチェックは出来るので、備忘録に記しておこうと思う。

具体的には、シェルを起動して下記の様にコマンドを投入すれば良いだけだ。

$ perl -MCPAN -e 'CPAN::Shell->r'

ズラズラとモジュールが表示されて、現在のバージョンと最新のバージョン番号が表示される。
しかしどうやって最新に更新するのだろう?まだまだ勉強が足りないと実感する。

投稿者 sasapurin : 20:05 | コメント (0) | トラックバック