Re: [Mason] problem with RPM instalation of Apache and Mod_perl on RedHat and Mason
Must you send multiple copies of this to both the modperl and mason mailing lists? I don't use Red Hat Linux, but my first suggestion is to scrap it in favor of some other version of Linux, or maybe even FreeBSD. RedHat has a tendency to use development versions of Perl and other software in their release (without identifying it as such), and it's known to be buggy (in particular, Red Hat's version of perl 5.8.0 and mod_perl 2.0). Mason was written with Apache 1.x and mod_perl, and use with Apache 2.x/mod_perl 2.0 is not supported, and probably won't be supported until mod_perl 2.0 is finally released. parvez mohamed writes: I have RedHat 9, I have installed Apache using rpm wich comes with RedHat9 (httpd-2.0.40-21) then i haveinstalled mod_perl using rpm mod_perl-1.99_07-5 then is have installed the latest Mason files HTML-Mason-1.22) but when i try to start Apache it says Apache/Constants.pm not found. I serched CAPAN for Apache::Constents it points to mod_perl which i have already installed. for your information i have added these lines to httpd.conf: PerlModule HTML::Mason::ApacheHandler FilesMatch \.html$ SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler /FilesMatch the error i get is: Can't locate Apache/Constants.pm in @INC (@INC contains . ... /usr/lib/perl5/5.8.0 .) at /usr/lib/perl5/site_perl/HTML/Mason/ApacheHandler.pm line 13.!BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/HTML/Mason/ApacheHandler.pm line 13.!Compilation failed in require at (eval 1) line 3.! [Tue Sep 09 16:28:02 2003] [error] Can't load Perl module HTML::Mason::ApacheHandler for server 127.0.0.1:0, exiting...! To over come this problem i put in these entries : I put in these lines in my httpd.conf file PerlModule Apache2 PerlModule Apache::compat PerlModule HTML::Mason::ApacheHandler FilesMatch \.mml$ SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler
Re: NIMDA worm; MSIISProbes.pm
Nick Tonkin writes:
Now that Micro$oft has finally put out some information about their
latest trick I have posted a new version of MSIISProbes.pm.
Version 1.02 changes include putting the URL to a page containing info
about each worm into a PerlSetVar ... this means that once you have
configured MSIISProbes.pm with your e-mail and cacheing preferences, you
can add traps for new worms as Micro$oft releases them, er, discovers
them.
Available at http://www.tonkinresolutions.com/MSIISProbes.pm.tar.gz
More info at http://www.tonkinresolutions.com/MSIISProbes.pm.html
I was looking at your Apache::MSIISProbes module, and I didn't
understand the part about the nimda rewrite rules, mostly because I
haven't used the rewrite rules. Do the following rules
RewriteCond %{REQUEST_URI} !nimda
RewriteCond %{QUERY_STRING} /c.dir
RewriteRule .* /nimda? [R,L]
mean unless I've already rewritten the rule, if the query string matches
c.dir (i.e., will match c+dir found in most of the requests), rewrite
the request as /nimda? From my observation, nimbda also tries c+tftp
and tries to get /scripts/Admin.dll, /c/Admin.dll, /d/Admin.dll and
/MSADC/Admin.dll. Could I change the rewrite rules to
RewriteCond %{REQUEST_URI} !nimda
RewriteCond %{QUERY_STRING} /c.(tftp|dir)
RewriteRule .* /nimda? [R,L]
to catch either request, and then do
RewriteCond %{REQUEST_URI} /(scripts|MSADC|c|d)/Admin.dll
RewriteRule .* /nimda? [R,L]
to catch the others?
Thanks.
Re: Fast DB access
Matt Sergeant writes: On Tue, 17 Apr 2001, Differentiated Software Solutions Pvt. Ltd., wrote: H/W : Celeron 433 with 64 MB RAM, IDE HDD using RH 6.1, perl 5.005, Postgres 6.5.3 This is a very very old version of postgresql. Try it again with 7.1 for more respectable results. It's more likely you are seeing hardware bottlenecks with this configuration. For example, the Intel Celeron has half the L2 cache of a Pentium 3, or one-fourth the cache of a Pentium Xeon. Also, your Celeron has a 66 Mhz bus, compared to 100 MHz for the P3, at least with the 466 MHz Celeron. With a 600 MHz Celeron going for US $60 and a 600 MHz P3 going for US $110 (approx. lowest prices at Pricewatch.com), a faster CPU might help, and probably not break the budget. Second, 64 MB is probably not enough memory for a multitasking OS with a web server and relational database. I suspect that you are doing a lot of swapping when running all this in 64 MB. If you ran some tool to analyze disk and memory usage, you would probably find that this configuration with postgresql was thrashing, whereas the MLDBM solution might not even hit swap at all. With the recent drop in memory prices, 256MB can be found for less than US $50 (hmm, maybe I should get more), and would likely improve your webserver performance regardless of the solution you use. There's more to benchmarking than just running some wall-clock timings. While MLDBM may be the best solution for you, someone else might find that with slightly more powerful server, running an up-to-date version of Postgres accomplishes their requirements just as well.
