Combining ScriptAlias with Perl handler in VirtualHosts
Is it ok to run a /cgi-bin/ ScriptAlias directory for mod_cgi in the same VirtualHost that ModPerl::Registry is also handling a /perl/ directory for? It seems to work ok for the first 10 or 20 vhosts, but mod_perl breaks after 30 or 40 entries. This is an example of what I'm doing: VirtualHost ###.###.##.## ServerAdmin [EMAIL PROTECTED] DocumentRoot /web/webname/htdocs ServerName webname.domain.com Directory /web/webname/htdocs Options FollowSymLinks Includes Indexes /Directory # Will use mod_perl Alias /perl/ /web/webname/perl/ Location /perl/ SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI /Location ScriptAlias /cgi-bin/ /web/webname/cgi-bin/ ErrorLog |/apps/cronolog/1.6.2/sbin/cronolog -S /web/webname/logs/error _log -P /web/webname/logs/error_log.previous /web/webname/logs/error_log.%Y.wk%W CustomLog |/apps/cronolog/1.6.2/sbin/cronolog -S /web/webname/logs/acce ss_log -P /web/webname/logs/access_log.previous /web/webname/logs/access_log.%Y.wk %W common CustomLog |/apps/cronolog/1.6.2/sbin/cronolog -S /web/webname/logs/refe rer_log -P /web/webname/logs/referer_log.previous /web/webname/logs/referer_log.%Y .wk%W referer CustomLog |/apps/cronolog/1.6.2/sbin/cronolog -S /web/webname/logs/agen t_log -P /web/webname/logs/agent_log.previous /web/webname/logs/agent_log.%Y.wk%W agent /VirtualHost
Re: mod_perl in others webservers
"Jesús Mª Lasso Sánchez" wrote: Hi everybody, I'd like to know if there is mod_perl, or any perl tool like mod_perl, to others webservers such as Enterprise, IIS ... There is WAI for Enterprise -- it enables you to write services (read persistant cgis) for Enterprise in java or c/c++ -- Eugene Miretskiy [EMAIL PROTECTED] InVision, INC. (516) 543-1000x219 http://www.invision.net
mod_proxy mod_perl
Hello, I have configured 2 apache servers: 1 light with mod_proxy, and another mod_perl server. I would like mod_proxy to cache the content generated by mod_perl server. All of mod_perl programs output correct Content-Length, Expires, and Last-Modified headers. When I access mod_perl program for the first time, the output is cached. If I tried to go back to the same program (with the same query string) by RETYPING the url, I get back cached copy (mod_perl server is not contacted). However, if I RELOAD the page, cached copy is not returned, and instead mod_perl server is contacted (even though there is still a valid cached copy on mod_proxy server). Is this normal? Any ideas? Thanks. -- Eugene Miretskiy [EMAIL PROTECTED] InVision, INC. (516) 543-1000x219 http://www.invision.net
Re: mod_proxy mod_perl
Ask Bjoern Hansen wrote: On Thu, 23 Dec 1999, Eugene Miretskiy wrote: [...] Is this normal? Any ideas? When you reload your browser tells that to the cache which in turn will reload too. I thought it was only when you used shift-reload, but I have worked with that for a while. It's not even shift-reload. Just plain reload causes mod_proxy to contact mod_perl server. -- Eugene Miretskiy [EMAIL PROTECTED] InVision, INC. (516) 543-1000x219 http://www.invision.net
Re: Problems with dynamically-loaded perl modules under Solaris2.5.1
Dan Rench wrote: On Tue, 21 Dec 1999, Doug MacEachern wrote: this sounds an awful lot like the common solaris linker vs. gnu linker problem. what does 'perl -V:ld' say your linker is? make sure it's gnu (gcc) and that Apache is using the same. $ perl -V:ld ld='gcc'; What I don't understand is that when I "./Configure" perl it always says: NOTE: You are using GNU ld(1). GNU ld(1) will not build Perl. I'm arranging to use /usr/ccs/bin/ld by including -B/usr/ccs/bin/ in your gcc -B/usr/ccs/bin/ command. (Note that the trailing "/" is required.) This is exactly the same problem I experienced before I got libperl.so solution to work. ...so it tells me that it can't use GNU ld, and then does it anyway, apparently. Perl's Configure script also warns me that my GNU make has its set-GID bit set and I should remove it. So I "chmod 755 make". Then I get: *** WHOA THERE!!! *** Your C compiler "gcc -B/usr/ccs/bin/ -B/usr/ccs/bin/" doesn't seem to be working! You'd better start hunting for one and let me know about it. This topic is veering away from mod_perl (though the problem only manifests itself under mod_perl for me), so I'm going back to the libperl.so solution suggested earlier since that seems to work. Whatever the problem is, it appears to be fixed in the development version of Perl at least. -- Eugene Miretskiy [EMAIL PROTECTED] InVision, INC. (516) 543-1000x219 http://www.invision.net
Re: Problems with dynamically-loaded perl modules under Solaris2.5.1
Recently I experienced similar problems on Solaris. I had to rebuild perl as shared libperl.so Perl library for mod_perl to work -- see perl intall manpages. Dan Rench wrote: On Mon, 13 Dec 1999, Doug MacEachern wrote: are you still stuck on this? Yes. To reiterate: Solaris 2.5.1 sparc, gcc 2.95, perl 5.005_03 (configured with Solaris hints), mod_perl 1.21, apache 1.3.9, mod_fastcgi 2.2.2. Everything works fine EXCEPT when I try to "use" a dynamically loaded module (Data::Dumper or Storable, for example) inside a mod_perl handler. I have no trouble using these modules in regular perl scripts, mod_cgi scripts, or mod_fastcgi scripts. did you link mod_perl static or dso? if dso, try static. All of my Apache modules are compiled statically. you can also try configuring Perl with -Dusemymalloc=n, but that comes with a large performance hit. I've tried it both ways, using perl's malloc or Solaris', and both give me the same result in my error logs: [Tue Dec 14 08:36:01 1999] [error] Can't load '/usr/local/lib/perl5/5.00503/sun4-solaris/auto/Data/Dumper/Dumper.so' for module Data::Dumper: ld.so.1: /usr/local/web/bin/httpd: fatal: relocation error: symbol not found: main: referenced in /usr/local/lib/perl5/5.00503/sun4-solaris/auto/Data/Dumper/Dumper.so at /usr/local/lib/perl5/5.00503/sun4-solaris/DynaLoader.pm line 169. All I need to do is add "use Data::Dumper;" in a handler to trigger this. And as I mentioned in my previous messages, this same setup works fine under Linux and FreeBSD. I can also get the problem to go away on Solaris by downgrading perl to 5.004_05 or upgrading it to 5.005_62. A co-worker who understands Perl internals better than I do seems to have tracked it down to a problem with Dynaloader's dlopen() call, though looking at ext/Dynaloader/dl_dlopen.xs in the various Perl sources there have apparently been no changes to it since 1994(?!). So maybe the problem lies elsewhere. Perl has caused my C skills to atrophy so we're getting into territory I don't really understand. Would something like gdb help diagnose the problem? -- Eugene Miretskiy [EMAIL PROTECTED] InVision, INC. (516) 543-1000x219 http://www.invision.net
Compilation Problem
Hello, I'm having problem compiling mod_perl_1.21 on SunOS 5.7 I followed instuctions in INSTALL.simple (just to see if i can compile modperl). I got the following error message when I tried to make modperl: === main gcc -c -I../os/unix -I../include -DSOLARIS2=270 -DMOD_PERL -DUSE_EXPAT -I../lib/expat-lite -DMOD_PERL gen_test_char.c gcc -DSOLARIS2=270 -DMOD_PERL -DUSE_EXPAT -I../lib/expat-lite -DMOD_PERL -o gen_test_char gen_test_char.o `perl /usr/local/tmp/mod_perl-1.21/src/modules/perl/ldopts ` -lsocket -lnsl-L/usr/local/lib /usr/local/lib/perl5/5.00503/sun4-solaris/auto/DynaLoader/DynaLoader.a -L/usr/local/lib/perl5/5.00503/sun4-solaris/CORE -lperl -lsocket -lnsl -lgdbm -ldb -ldl -lm -lc -lcrypt ./gen_test_char test_char.h ld.so.1: ./gen_test_char: fatal: libgdbm.so.2: open failed: No such file or directory Killed make[2]: *** [test_char.h] Error 137 make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/usr/local/tmp/apache_1.3.9/src' make: *** [apache_httpd] Error 2 I have latest libgdbm installed (in /usr/local/lib), and have the latest version of ld. What could be causing this problem? Thanks in advance. -- Eugene Miretskiy [EMAIL PROTECTED] InVision, INC. (516) 543-1000x219 http://www.invision.net
Re: Compilation Problem
Stas Bekman wrote: Do you have a symlink from /usr/local/lib/libgdbm.so.2 to /usr/local/lib/libgdbm.so.2.x.x? replace x.x with the version that you have. Thanks. This is exactly what was wrong. I was able to 'make' modperl, BUT make test failed: /usr/local/etc/apache_1.3.9.orig/src//httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...[Thu Dec 9 18:56:21 1999] [error] Can't load '/usr/local/lib/perl5/5.00503/sun4-solaris/auto/IO/IO.so' for module IO: ld.so.1: /usr/local/etc/apache_1.3.9.orig/src//httpd: fatal: relocation error: file /usr/local/lib/perl5/5.00503/sun4-solaris/auto/IO/IO.so: symbol main: referenced symbol not found at /usr/local/lib/perl5/5.00503/sun4-solaris/DynaLoader.pm line 169. at /usr/local/lib/perl5/5.00503/sun4-solaris/IO/Handle.pm line 241 BEGIN failed--compilation aborted at /usr/local/lib/perl5/5.00503/sun4-solaris/IO/Handle.pm line 241. BEGIN failed--compilation aborted at /usr/local/lib/perl5/5.00503/sun4-solaris/IO/Seekable.pm line 51. BEGIN failed--compilation aborted at /usr/local/lib/perl5/5.00503/sun4-solaris/IO/File.pm line 112. BEGIN failed--compilation aborted at /usr/local/tmp/mod_perl-1.21/t//docs/startup.pl line 33. ... What could be causing this? -- Eugene Miretskiy [EMAIL PROTECTED] InVision, INC. (516) 543-1000x219 http://www.invision.net
Re: weird mod_perl startup problems
"Young, Geoffrey S." wrote:
That sounds weird...
Anyway, did you try adding
use DBI;
Yes I did try that...
in your startup.perl script (after Apache::DBI, that is)?
Also, I think I remember reading someone say that any time they upgrade
their system, perl, or whatever, they re-compile all their modules. I
haven't gone through that yet (and I'm on Linux), but maybe that will help
if you were getting the startup script to work before?
That script was working fine before...
As to other associated weirdness, I dunno...
hope this helps some
Thank for reply...
--Geoff
-Original Message-
From: Eugene Miretskiy [SMTP:[EMAIL PROTECTED]]
Sent: Thursday, October 07, 1999 3:33 PM
To: [EMAIL PROTECTED]
Subject: weird mod_perl startup problems
Hello,
After upgrading my machine to FreeBSD3.3, I ran into the problems loading
modules
at startup time...
I would like to load the following modules at start up (I have them in
startup.perl file
loaded from httpd.conf):
use Apache::Registry;
use Apache::Request;
use Apache::DBI ();
use MIME::Body;
The server does not start -- instead I get this in my error_log:
Can't locate object method "trace_msg" via package "DBI" at
/usr/local/lib/perl5/site_perl/5.005/i386-freebsd/DBI.pm line 311.
END failed--cleanup aborted.
run: Operation not supported by device
An interesting thing is that if I comment out MIME::Body (leave
Apache::DBI) the server starts ok.
If I comment out Apache::DBI (leave MIME::Body) the server also starts ok.
Only when both of these modules are loaded I gen into a problem.
Here is a snipplet of code from DBI that causes the problem:
END {
DBI-trace_msg("- DBI::END\n", 2);
##LINE 311
# Let drivers know why we are calling disconnect_all:
$DBI::PERL_ENDING = $DBI::PERL_ENDING = 1; # avoid typo warning
DBI-disconnect_all() if %DBI::installed_drh;
DBI-trace_msg("- DBI::END complete\n", 2);
}
Finally, If I comment out DBI-trace_msg, the server starts fine with both
Apache::DBI and
MIME::Body loaded.
Any ideas to this weirdness?
All modules are latest version.
Thank you very much.
P.S.: please reply to my email address as well ([EMAIL PROTECTED])
--
Eugene Miretskiy [EMAIL PROTECTED]
InVision, INC. (516) 543-1000x219
http://www.invision.net
--
Eugene Miretskiy [EMAIL PROTECTED]
InVision, INC. (516) 543-1000x219
http://www.invision.net
weird mod_perl startup problems
Hello,
After upgrading my machine to FreeBSD3.3, I ran into the problems loading modules
at startup time...
I would like to load the following modules at start up (I have them in startup.perl
file
loaded from httpd.conf):
use Apache::Registry;
use Apache::Request;
use Apache::DBI ();
use MIME::Body;
The server does not start -- instead I get this in my error_log:
Can't locate object method "trace_msg" via package "DBI" at
/usr/local/lib/perl5/site_perl/5.005/i386-freebsd/DBI.pm line 311.
END failed--cleanup aborted.
run: Operation not supported by device
An interesting thing is that if I comment out MIME::Body (leave Apache::DBI) the
server starts ok.
If I comment out Apache::DBI (leave MIME::Body) the server also starts ok.
Only when both of these modules are loaded I gen into a problem.
Here is a snipplet of code from DBI that causes the problem:
END {
DBI-trace_msg("- DBI::END\n", 2); ##LINE 311
# Let drivers know why we are calling disconnect_all:
$DBI::PERL_ENDING = $DBI::PERL_ENDING = 1; # avoid typo warning
DBI-disconnect_all() if %DBI::installed_drh;
DBI-trace_msg("- DBI::END complete\n", 2);
}
Finally, If I comment out DBI-trace_msg, the server starts fine with both Apache::DBI
and
MIME::Body loaded.
Any ideas to this weirdness?
All modules are latest version.
Thank you very much.
P.S.: please reply to my email address as well ([EMAIL PROTECTED])
--
Eugene Miretskiy [EMAIL PROTECTED]
InVision, INC. (516) 543-1000x219
http://www.invision.net
