mod_perlを使おう！
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん
01/11/07 17:42ID:+Gux2iOQ関連リンク等は>2
0276nobodyさん
03/10/12 09:33ID:5sejX4lfシステム領域をオーバーライドするしか方法はないだろうけど。
suexecのソースを読んでみよう
0278nobodyさん
03/10/12 09:49ID:5sejX4lfApacheは例によってapacheユーザで動作。
カーネルに関わるプログラムをsetuidして子プロセスの実行権限を動的にするしかないんじゃないだろうか。
擬似的にApacheが複数のUIDで動作すると。suexecより危険度が増すけど
0279nobodyさん
03/10/12 12:02ID:???0280nobodyさん
03/10/12 13:30ID:5sejX4lf0281nobodyさん
03/10/12 13:31ID:???0282nobodyさん
03/10/12 13:53ID:5sejX4lfCPUが追いつかない。
Apache2なら可能性はあるが
0283nobodyさん
03/10/30 15:43ID:MsIzuyZ0そうすれば普及するだろうに。
0284nobodyさん
03/10/30 15:53ID:???0286nobodyさん
03/11/04 18:16ID:???・exit();関数は利用できない。代わりに、Apache::exit();を使うそうな。
・パッケージ名を明記すると500 Internal(以下略)。（例: $main::setup)
・SuExecが有効にならない
・もし何かあったら、Apache自体を再起動しなければならない
・mod_perl用に書いたPerlScriptをCGIとして動作させたら、多分動かない。
知っている限りで。（注：正確な情報ではありません）
0287nobodyさん
03/11/04 19:42ID:???互換性の問題は速度の代償として多少は仕方ないか。
＞・もし何かあったら、Apache自体を再起動しなければならない
ここら辺はmod_phpでも同じなのでは？
0288
03/11/04 20:55ID:1kmjwkimhttp://bulknews.net/lib/doc-ja/etoys.ja.html
0289nobodyさん
03/11/04 22:08ID:???・Apache::Registry 使用時なら exit は Apache::exit でオーバーライド
されていたような。
・main パッケージを明示するようなコーディングスタイル自体が問題。
・CGI プログラムとして組まれているスクリプトは Apache::PerlRun で
動かす。mod_perl 前提のスクリプトを CGI プログラムとして使うのは
おかしい。
SuEXEC が効かないのと、httpd の肥え方が激しいのがネックだと思う。
まぁ後者はサーバ分ければいいんだけど。
あと mod_perl 入れたからといって CGI プログラムが使えなくなる
わけじゃないので、Apache::PerlRun でも動かんような糞スクリプトは
割り切って CGI プログラムとして使うのも手。
0290nobodyさん
03/11/05 00:00ID:???Apache::PerlRunで満足すんなYO!
ところでさｱ、お金貸して？
0291nobodyさん
03/11/16 07:02ID:???みたいな感じで、テキストを置換するシステム作ってたんだが
XeonMP 2.8G でさえ、30req/sがやっとこさだったのだが、
PerlRun にしたら、100req/s 程度まで向上した。
男はApache::Registryだろうということで、試してみたんだが、
案の定あちこち手を入れないとｳｺﾞｶﾅｶﾀよ。
それでも、バックエンドDBアクセスナシで700req/s
DB接続ありで200req/s行ける感触をつかんだので
かなり満足。
行き着く先はCでApacheモジュール化なのだが、そうすると
DBIのような統一インタフェイスが使えずDB依存になってしまうのが辛い。
上のカキコで PATH_INFO 云々の話が出てたが、ウチで試したときは
アクションハンドラとして呼ばれないときも
PATH_INFO=/
PATH_TRANSLATED=/path/to/www/ <- これファイルじゃネーし
とか出てきて少々面食らった。これはバグ? 実装上の都合?
0292nobodyさん
03/12/28 05:05ID:???0293nobodyさん
04/02/03 03:55ID:6SsHdaLm0294nobodyさん
04/02/10 21:22ID:YkFrJUBAmod_perl使ってる時にも通常のCGIとしてperlプログラム走るんですか？
0295nobodyさん
04/02/10 22:35ID:???0296nobodyさん
04/02/11 14:36ID:???HTML::Template使えますか。
0297nobodyさん
04/02/11 17:34ID:8Wm4X/2a皆さんは、
PerlSendHeader On
にしてますか？
mod_perlを使うなら Off だろ、とか、
漢なら Off にしとけ、とか、
なんかポリシーみたいなものってありますか？
0298nobodyさん
04/02/11 19:17ID:???/ ,――――-ミ
/ ／ ／ ＼ |
| / ,（･） （･） |
(6 つ |
| ＿＿_ | ／￣￣￣￣￣￣￣￣￣￣
| /＿＿/ ／ ＜ mod_perlを使うなら Off だろ！
／| ／＼ ＼＿＿＿＿＿＿＿＿＿＿
0300nobodyさん
04/02/14 12:13ID:???Syntax error on line 159 of C:/Program Files/Apache Group/Apache2/conf/httpd.conf:
Cannot load C:/Program Files/Apache Group/Apache2/modules/mod_perl.so into server: 指定さ
れたモジュールが見つかりません。
＿|￣|○ファイルあるのに…
0301nobodyさん
04/02/14 12:46ID:???やっぱ、スクリプトの制限がキツくなるからってことでおｋ？
0302nobodyさん
04/02/14 13:15ID:???ISP屋の立場から言うと、suExecできないのが一番痛い
0303nobodyさん
04/02/14 17:02ID:???0305nobodyさん
04/02/14 21:57ID:???0306nobodyさん
04/02/16 00:45ID:???ってことはやり方が悪いという事かな……orz
>303
設計とかテストとかやるときはローカルのWin鯖でやってますが
UNIX版と違い出るんですか。
0308nobodyさん
04/02/16 12:42ID:???0310nobodyさん
04/02/16 16:28ID:???apache はwinネイティブで mod_perl が cygnus だったら 動かないとか。
もう少し詳しく書かないとなんとも言えないんじゃないかなぁ
0311nobodyさん
04/02/16 16:37ID:???ファイルは見つかっても何らかの原因でメモリへのロードに失敗している
というケースが実際にはほとんど
原因はバージョン不整合とかいろいろ考えられるが
まあ地道に切り分けるしかないな
0312nobodyさん
04/02/16 16:53ID:1pUxS5fUそして以下のテストスクリプトを二種類の方法でちゃんと動作しているのですが、
CGIとして呼び出されてるのか、mod_perl として呼び出されているのかサッパリでして、、
確認する方法ってのはありますか？
## /home/user/perl/test
#!/usr/bin/perl -w
use strict;
print 'content-type: text/plain; charset=EUC-JP' . "\n";
print "\n";
print join("\n", map "$_ = $ENV{$_}", sort keys %ENV);
## httpd.conf
Alias /perl/ /home/user/perl/
Alias /cgi-bin/ /home/user/perl/
<Location /perl>
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
PerlSendHeader On
</Location>
<Location /cgi-bin>
SetHandler cgi-script
Options ExecCGI
</Location>
http://hoge.com/perl/test -> OK.
http://hoge.com/cgi-bin/test -> OK.
0313nobodyさん
04/02/16 17:44ID:???#!/usr/bin/perl -w
use strict;
print 'content-type: text/plain; charset=EUC-JP' . "\n";
print "\n";
print `ps aux | grep perl`;
0314nobodyさん
04/02/16 17:55ID:???>'CGI-Perl/1.1' が設定されます。（通常CGIは 'CGI/1.1'）
>また、'MOD_PERL' 環境変数が設定されます。（mod_perlのバージョンが設定される）
0315312
04/02/17 12:47ID:???返事ありがとう。
早速試してみようと思ったんですが、
なんか電源が入らない、、orz、、bios すら起動しねーーーー
出直してきます。。(つд｀;)
0316312
04/02/18 19:28ID:???試して見ました。
## /perl/test
GATEWAY_INTERFACE = CGI-Perl/1.1
MOD_PERL = mod_perl/1.29
## /cgi-bin/test
GATEWAY_INTERFACE = CGI/1.1
問題なく動作しているようです、有難うございました。
ところで別の疑問なのですが、
CGI経由で動作している時には suEXEC で動作して欲しいと思って
suEXEC 有効にしてみました。
/perl/test -> nobody権限
/cgi-bin/test -> user権限
今の所正常に動作していると思うのですが、これって問題ない、、ですか？
どこのサイト見ても suEXEC は無効にしとけー、
てな事しか書いてなかったので少し不安なのです。
0317nobodyさん
04/02/18 20:04ID:???mod_perlが組み込まれている httpd のプロセスの中で動いてしまうのでsuexecは効かない
CGI経由で別プロセスで動かすからこそsuexecが有効
0318nobodyさん
04/02/29 04:50ID:yMfKis4MというCGIを自サーバーで動作させたのですが、試してみると結構な確率で真っ白な画面が
ブラウザに表示されます。
このCGIは実績があるのでこのCGIのせいではなくて、mod_perlのせいなのだと思うのですが、
解決策が全くわかりません。 助けてください・・・。
環境は、
OS: Redhat 9.0
WebServer: Apache1.3.29
mod_perl version 1.29
perl 8.5.1
です。
OS以外は全てソースからコンパイルしてインストールしました。
0319nobodyさん
04/02/29 05:49ID:???0320nobodyさん
04/02/29 07:26ID:???0321nobodyさん
04/02/29 11:32ID:???助けてやりたいのはやまやまだが
318 に書かれた情報だけでは何とも手の差し伸べようがない
error_log に何が吐かれてるか確認する前に 318 を書いたのだとしたら
君の罪は麻原並に重い
0323nobodyさん
04/02/29 11:41ID:???XREA
0324nobodyさん
04/02/29 12:07ID:???眺めたところそのスクリプトのせいのような気が……。
0325318
04/02/29 15:21ID:yMfKis4M>324
どの辺りか教えて頂ければ幸いです・・。 お願い致します。
>321
エラーは一切吐かれていませんし、ブラウザで500番エラーが
表示されることもありません。
0326nobodyさん
04/02/29 18:41ID:???mod_perl で動くかというとそうとは限らない。
0327nobodyさん
04/02/29 21:39ID:???0328nobodyさん
04/03/01 06:28ID:???mod_perlでは、正しく動きません。または、高速動作できません。
0329nobodyさん
04/03/01 10:01ID:???0330nobodyさん
04/03/01 22:21ID:???0331nobodyさん
04/03/02 21:16ID:O+pQat/oこれってmod_perlだけじゃなく、
全てのモジュールをstaticで構成しないと駄目だったのね。
mod_perlだけだと思って何度も何度もやり直してしまいました。。
0332nobodyさん
04/03/03 00:58ID:???0333nobodyさん
04/03/04 11:23ID:???ppm install http://theoryx5.uwinnipeg.ca/ppmpackages/mod_perl.ppd
としたんですが
Error: no suitable installation target found for package mod_perl
とエラーが出ます。どうしたものでしょう
0334nobodyさん
04/03/05 19:12ID:GwB2WnjSperl-5.8.3 に変えて見ました。
mod_perlでスクリプトを出力すると
charset が間違っていないにも関わらず文字化けします。
どうやらutf-8で出力されているようなのですが、、
charset を utf-8 にすれば文字化けはしないのですが、
今度は CGI で実行した時に当然ですが文字化けします。
これは、、どうやって回避すればよいのでしょう。
## httpd.conf
<Location /perl>
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
PerlSendHeader On
</Location>
<Location /cgi-bin>
SetHandler cgi-script
Options ExecCGI
</Location>
## script
my $euc = 'あいうえお';
print "content-type: text/plain; charset=EUC-JP\n\n";
print "$euc\n";
0335334
04/03/05 21:46ID:???スクリプトが utf-8 でした。。。申し訳ありません。。
以下簡単にまとめました。
## script euc-jp
my $euc = 'あいうえお';
print "content-type: text/plain; charset=EUC-JP\n\n";
print "$euc\n";
/perl(mod_perl) も /cgi-bin(CGI) も問題無し。
## script utf-8
use utf8;
binmode(STDOUT, ':encoding(euc-jp)');
my $utf8 = 'あいうえお';
print "content-type: text/plain; charset=EUC-JP\n\n";
print "$utf8\n";
/perl(mod_perl)だと文字化け、charsetを utf-8 に変更すると問題なし
/cgi-bin(CGI) だと問題無し、charsetを utf-8 に変更すると文字化け
mod_perlの標準出力(STDOUT)は binmode では設定出来ない、のかな？
だとすると mod_perl の標準出力の文字コードを設定するにはどうすればよいのでしょう。
とりあえず euc-jp でスクリプトを書けば問題ない話なんですがちょっと↑が気になりました。
0336nobodyさん
04/03/06 10:11ID:4ILBaJdhPlease contact the server administrator, [email protected] .....
という文章がcgiを通して表示される最後に挿入されます・・・。
この文章を表示しないように設定したいのですが、httpd.confで
いじる場所もなさそうですし、どこを設定すればよいのでしょうか？
ご教授お願い致します。
0337nobodyさん
04/03/06 10:22ID:???0338nobodyさん
04/03/07 01:19ID:???printした後の処理で実行時エラーが出てるとかのような。
0339nobodyさん
04/03/07 18:30ID:???0340nobodyさん
04/03/09 05:55ID:???エスケープ無しで " が入ってると実行時エラーが出た。
注意って事で。
0341nobodyさん
04/03/09 22:03ID:???そりゃエラーになるよ
0342nobodyさん
04/03/09 23:14ID:???0343nobodyさん
04/03/14 20:00ID:???環境
Apache/2.0.40 (Red Hat Linux)
mod_perl/1.99_07-dev
perl, v5.8.0 built for i386-linux-thread-multi
A.pm------------
package A;
sub method1 {# hoge}
sub method2 {# hoge}
----------------
B.pm------------
package B;
use base qw ( A );
----------------
test.cgi----------
use B;
$o = B->new;
$o->method1;
$o->method2;
----------------
だいたいこんな感じ。
症状：
test.cgiの実行でこける。
エラーログを調べると、ModPerl::Registryさんが実行する度に「Bクラスにはmethod(1 or 2)はない」と違うことを言っている。
実際、ブラウザに状況を出力しながら動作確認をすると、確かにメソッド呼び出しのところでこけている。文法エラーでないことは途中までとは言えHTMLを吐き出していることからわかる。
なので、mod_perlさんのどこかに不具合があるのではないかと考えたのですが、そこまででした。
どんな原因が考えられますでしょうか。
0344343
04/03/14 20:48ID:???Apacheが古いバージョンのスクリプトでコンパイルした実行ファイルを、しっかり握って離していないだけでした。＿|￣|○
元ファイルを全部消しても、ブラウザでアクセスするとまだ結果が出るのです。
握りこんだ実行ファイルを手動で消す方法はないでしょうか。
0345nobodyさん
04/03/14 21:14ID:???自分でやってみたことはないので割と無責任
0346343
04/03/15 00:47ID:???現在は、動作がおかしくなったらApacheのrestartと言うあまりクールでない手でやってます。
ありがとうございます。Apach::Reloadのmanを見てみます。
0347336
04/03/15 10:40ID:heuYMXtNと出力されています。
なんじゃこのhandlerは？？？ 名前が無いです・・・。
ご教授お願い致します。
0349nobodyさん
04/03/15 22:07ID:???珍しいエラーだなあ。
ちなみに何をやろうとしてそういう状態になったんだ?
Apache::Registry? Apache::PerlRun?
それとも Movable Type だか AxKit だかを PerlHandler で組み込んだ?
0350mod_perlはじめて君
04/03/23 13:29ID:3jX1Q8fVpackageつけるとSubroutine check redefinedとゆうwarningsが沢山出ちゃうんです。
でもpackage消しても
Prototype mismatch: sub Apache::ROOT::sakura::cgi_2dbin::test::test_2ecgi::check vs ()
というwarningsが出てしまうんですが、これってmod_perlの仕様なんでしょうか？
warningsが出るのが気になるタイプの人なんです僕o(_ _)o
0351ログ補完
04/03/29 13:16ID:???もしかしてApache::Registryだとopen FH, >hoge.dat でファイルを作ってくれなくなった?
0352nobodyさん
04/03/30 14:23ID:???my $foo = { hoge => 'hoge' };
だと$fooの値は消えても無名ハッシュ内の値は消えないとか
そう言う事は無いですか。
0353nobodyさん
04/03/30 14:39ID:???http://www.kt.rim.or.jp/%7ekbk/perl5.005/perlref.html
http://pc5.2ch.net/test/read.cgi/php/1078076768/
0354nobodyさん
04/03/30 14:59ID:???CGI等で使うと終了時に全クリアされるようですが
mod_perl(Regstry)では値がキャッシュされると聞いたのでこちらで聞きました。
要は、リファレンスが変数に格納されていると、
変数が消えた瞬間に値の内容もきちんと消されると言う事ですね。
0355nobodyさん
04/03/30 15:00ID:???×値
○参照されている値
#少し語弊があるので修正
0356nobodyさん
04/04/02 13:16ID:???0357nobodyさん
04/04/08 09:32ID:???0358Perlさん
04/04/08 13:57ID:???0359nobodyさん
04/04/10 01:10ID:???世間的にどうなのかは知らない。
0360nobodyさん
04/04/10 12:24ID:???0361nobodyさん
04/04/30 13:24ID:???一応、local $self->{'HOGE'} = 'hoge'; とかやっているのですが。
0362nobodyさん
04/05/01 09:28ID:???その書き方だと $self はリファレンスだから、local する意味はない。
ってか、$self の位置づけがいまいちわからん。
mod_perl で呼び出すスクリプトで使ってるオブジェクトのリファレンス?
0363nobodyさん
04/05/01 13:35ID:???起動時に PerlRequire で読み込んでいる Apache2 モジュールの機能でした。
てっきり mod_perl を使うと %$self が勝手に用意されるのかと。
local は意味が無かったのですね……。
0365nobodyさん
04/05/02 00:24ID:???$self->{'FILEDIR'} (このキーは初めは用意されていない)に入れたいと思っただけなのですが、
そこで mod_perl でこういう予め決まったキーや値が入っている変数に勝手に追加して良いのかどうか、
不安だったのです。
どこかに何か影響が出たりするのだろうかと。
0366362
04/05/02 03:46ID:???現段階でそのキーが使われていなければ使える。
が、将来的にもそのキーが使われない保証はない。
スクリプトをオブジェクト指向で書いているなら、そのオブジェクトに入れるべき。
書いていなければそう書き直しましょう。
0367nobodyさん
04/06/14 00:54ID:UCF4wTWNの構成で、lock tableした後に
どこかのSQL実行に失敗してerrstrで処理するとunlockできないのだが、
何とかならないのだろうか。
識者の見解キボン。
失敗しなきゃ良いというのは無しでお願い。
0368nobodyさん
04/06/23 16:45ID:???# perlcc -B test2.cgi.org -o test2.cgi
*インタプリタは内蔵せずスクリプトをバイトコードに変換するだけ(たぶん)
test2.cgi.orgの内容
#!/usr/bin/perl
print "Content-type:text/plain\n\n";
print "Hello world!!\n";
@ # ./test2.cgi の結果
Hello world!!
@ mod_perlを無効にしWEBからアクセスした結果
Hello world!!
@ mod_perlを有効にしWEBからアクセスした結果
Missing right curly or square bracket at /home/hoge/public_html/mod_perl/test2.cgi line 3, at end of line
syntax error at /home/hoge/public_html/mod_perl/test2.cgi line 3, at EOF
その時のerror_log
[Wed Jun 23 16:27:32 2004] [error] 6945: ModPerl::Registry:
Missing right curly or square bracket at /home/hoge/public_html/mod_perl/test2.cgi line 3, at end of line
syntax error at /home/hoge/public_html/mod_perl/test2.cgi line 3, at EOF
環境：Fedora core1、apache 2.0.48-1.2、perl 5.8.3、mod_perl 1.99_12-2
RH7.3、apache 1.3.27-4、perl 5.6.1、mod_perl 1.26-5 でも似たような結果でした
やりたいことはPerlで高速な動作をしつつ、ある程度のソースの隠蔽をしたいのですが
perlcc+mod_perlで動かす方法、もしくはそれに変わる代替手段がございましたら
ご教授くださいませオマイら。
0369nobodyさん
04/06/23 19:49ID:???0370nobodyさん
04/06/23 20:32ID:???「原理はわかんないがとにかく CGI が高速になる魔法の箱」
と思われているのものなのだな
0371nobodyさん
04/06/23 20:39ID:???0372nobodyさん
04/06/23 20:39ID:???0373nobodyさん
04/06/23 22:44ID:GOWHNOaoｵｻｰﾝﾊｯｹｿ！
0374368
04/06/24 14:47ID:???mod_perlもバイトコードへの変換プロセスを踏むと私は何の根拠もなく推測しており
mod_perl側で通常のソースとバイトコードを判別し適切なステップを踏むように作られていれば
perlccでコンパイルしたスクリプトが動作しても理論上不思議ではないと
思うのですがどうでしょうか。
この場合、ごく単純なスクリプトでも動作しないので
mod_perl側でperlccを考慮した機構がないんだとは思いますが。
0375nobodyさん
04/06/24 19:55ID:???「CGIを高速に実行する環境」ではありません。
「apache モジュールの一つで、perl インタプリタを内蔵しており、
apache API の操作手順を perl スクリプトとして外部に切り出すことのできるもの」
などとするべきでしょう。
この違いはたいへん重要です。なぜなら mod_perl それ自体には
「CGIのプログラムファイルをロードする機構は含まれていない」からです。
mod_perl に用意されたロード機能は、apache 起動時に、
httpd.conf で指定された perl スクリプト(クラスモジュール)を読み込むこと、
だけです。CGI プログラムファイルを直接読み込むことはできません。
CGIを実行するためには当然プログラムファイルをロードしなければならず、
そのためにはローダとなる機構が別途必要です。
このために Apache::Registry という perl クラスモジュールが
mod_perl と同梱して配布されています。
httpd で Apache::Registry を指定しておくと、apache 起動時にこれが読み込まれ、
以後 CGI のローダとして動きます。
この Apache::Registry の機能は、スクリプトファイルを読み込み、
これを CGI をエミュレートした環境下で eval することです。
ところが、perlcc でコンパイルされたバイトコードは use ByteLoader されています。
この ByteLoader のようなソースフィルタが、eval と相性最悪なのです。
そのため、Apache::Registry の方法では、バイトコードを実行できません。
Apache::Registry とは異なる原理に基づくローダを自作すれば、
理論的には不可能な話でも無いと考えられます。
■ このスレッドは過去ログ倉庫に格納されています