Re: Again, Modperl running scripts slower than non-modperl!?
At 01:29 AM 8/5/01 -0500, John Buwa wrote: 91 processes: 89 sleeping, 2 running, 0 zombie, 0 stopped CPU states: 0.0% user, 0.7% system, 0.0% nice, 99.2% idle Mem: 257408K av, 228384K used, 29024K free, 13744K shrd,5380K buff Swap: 265528K av, 184780K used, 80748K free8908K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM CTIME COMMAND 25788 nobody 0 0 126M 125M 1076 S 0.0 49.8 0:13 httpd modperl server 25787 nobody 0 0 196M 32M 1356 S 0.0 12.9 0:19 httpd -modperl server 25799 nobody 0 0 32592 30M 8 S 0.0 12.2 0:10 httpd---Non modperl server Not having read anything before this, but it seems that your machine is going into swap because there is not enough RAM available. That kills your performance always. Could you run your test on a different machine or temporarily switch off the regular server? Trying to run close to 200 Mbyte modperl Apaches on a 256 Mbyte machine is not going to work. Have you looked at MaxRequestsPerChild? But even the non-modperl servers at 30 Mbyte size seems ridiculously large: are you sure you need all the modules that you compiled into Apache? Elizabeth Mattijsen
module to hit back at default.ida atack ?
Anybody know of any module I can use to hit back at these default.ida bozos (i.e. keep them away from my IP addresses ?). I'm running apache/modperl on Win32. thanks, Rod == This email message may contain the ebola virus. The sender accepts no responsibility for any death, destruction, reflux or tinitis that may result from reading it. The sender's lawyer forces him to write this crap.
Re: Again, Modperl running scripts slower than non-modperl!?
Not having read anything before this, but it seems that your machine is going into swap because there is not enough RAM available. That kills your performance always. Could you run your test on a different machine or temporarily switch off the regular server? Trying to run close to 200 Mbyte modperl Apaches on a 256 Mbyte machine is not going to work. Have you looked at MaxRequestsPerChild? This is set at 0 But even the non-modperl servers at 30 Mbyte size seems ridiculously large: are you sure you need all the modules that you compiled into Apache? Im sorry that was a mistake the non modeperl apache is like this: 125 nobody 0 0 3960 0 SW0.0 0.0 5:58 httpd 126 nobody 0 0 2960 0 SW0.0 0.0 0:19 httpd 127 nobody 0 0 804 608 504 S 0.0 0.2 8:10 httpd 128 nobody 0 0 888 724 592 S 0.0 0.2 11:21 httpd 129 nobody 0 0 872 712 592 S 0.0 0.2 5:21 httpd John
[OT] Re: Module to catch (and warn about) Code Red
About 80% of the Code Red probes I get leave the message Client sent malformed header in my error_log. Just curious if others are seeing this?
Re: Module to catch (and warn about) Code Red
At 10:00 AM 8/5/01, Reuven M. Lerner wrote: Alessio Bragadini writes: Alessio The problem I see: is this module sending out a message Alessio every time, resulting to multiple messages to the same Alessio web/postmaster? Alessio My fear is that we substitute a virus with another... But of course, you're right -- it's probably best to send them at most one message per day. More than that won't necessarily get the message across any more effectively. I'll try to find some time later today to add this functionality. I don't think this is an issue. Someone more familiar with the virus can chime in, but the information that's out there on it seems to indicate that it's not going to pick the same IP twice, except by chance. http://www.unixwiz.net/techtips/CodeRedII.html On our main web server, I see 118 hits in the past 14 days, 117 of which are from unique addresses. cheers, Todd
src.t failure
has anyone got a clue what to do about the error i get at modules/src below? !--mod_perl 1.26, perl 5.6.1, apache_1.3.20, mac os X -- thanks allan modules/actions.ok modules/cgi.ok modules/constants...ok modules/cookie..skipped test on this platform modules/fileok modules/httpdconf...ok modules/include.ok modules/log.ok modules/module..skipped test on this platform modules/perlrun.ok modules/psections...skipped test on this platform modules/request.skipped test on this platform modules/src.Use of uninitialized value in concatenation (.) or string at modules/src.t line 27. modules/src.FAILED tests 3-5 Failed 3/6 tests, 50.00% okay modules/ssi.ok modules/stage...skipped test on this platform modules/status..ok modules/symbol..skipped test on this platform modules/uri.ok modules/utilok internal/apiok internal/auth...ok internal/croak..ok internal/dirmagic...ok internal/error..ok internal/headersok internal/hooks..ok internal/http-get...ok internal/http-post..ok internal/proxy..ok internal/redirect...ok internal/rwrite.ok internal/stackedok internal/table..ok internal/taint..ok Failed Test Status Wstat Total Fail Failed List of Failed modules/src.t 63 50.00% 3-5 6 tests skipped. httpd terminated Failed 1/34 test scripts, 97.06% okay. 3/383 subtests failed, 99.22% okay.
Re: Again, Modperl running scripts slower than non-modperl!?
Not having read anything before this, but it seems that your machine is going into swap because there is not enough RAM available. That kills your performance always. Could you run your test on a different machine or temporarily switch off the regular server? Trying to run close to 200 Mbyte modperl Apaches on a 256 Mbyte machine is not going to work. Have you looked at MaxRequestsPerChild? This is set at 0 What are you using to control process size? Apache::SizeLimit? It looks like you have some code that hogs memory, and you'll need to control it somehow. Most people have servers more in the range of 10-40MB, with a bunch of that shared. - Perrin
Re: src.t failure
On Sun, 5 Aug 2001, allan wrote: has anyone got a clue what to do about the error i get at modules/src below? !--mod_perl 1.26, perl 5.6.1, apache_1.3.20, mac os X -- http://perl.apache.org/guide/install.html#Manual_Testing please also provide the output from t/logs/error_log thanks allan modules/actions.ok modules/cgi.ok modules/constants...ok modules/cookie..skipped test on this platform modules/fileok modules/httpdconf...ok modules/include.ok modules/log.ok modules/module..skipped test on this platform modules/perlrun.ok modules/psections...skipped test on this platform modules/request.skipped test on this platform modules/src.Use of uninitialized value in concatenation (.) or string at modules/src.t line 27. modules/src.FAILED tests 3-5 Failed 3/6 tests, 50.00% okay modules/ssi.ok modules/stage...skipped test on this platform modules/status..ok modules/symbol..skipped test on this platform modules/uri.ok modules/utilok internal/apiok internal/auth...ok internal/croak..ok internal/dirmagic...ok internal/error..ok internal/headersok internal/hooks..ok internal/http-get...ok internal/http-post..ok internal/proxy..ok internal/redirect...ok internal/rwrite.ok internal/stackedok internal/table..ok internal/taint..ok Failed Test Status Wstat Total Fail Failed List of Failed modules/src.t 63 50.00% 3-5 6 tests skipped. httpd terminated Failed 1/34 test scripts, 97.06% okay. 3/383 subtests failed, 99.22% okay. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: src.t failure
Stas Bekman wrote: http://perl.apache.org/guide/install.html#Manual_Testing please also provide the output from t/logs/error_log ok then: with TEST_VERBOSE=1: modules/src.Use of uninitialized value in concatenation (.) or string at modules/src.t line 1. 1..6 ok 1 dir=../src ok 2 main= not ok 3 module_magic_number = 0 not ok 4 httpd_version = not ok 5 -I../src -I../src/modules/perl ok 6 t/logs/error_log: [Sun Aug 5 18:33:00 2001] [warn] pid file /source/apache_1.3.20/mod_perl-1.26/t/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? [notice] Destruction-DESTROY called for $global_object [Sun Aug 5 18:33:03 2001] [warn] [notice] child_init for process 666, report any problems to [no address given] [Sun Aug 5 18:33:18 2001] [warn] [client 127.0.0.1] log __ANON__ OK Use of uninitialized value in subroutine entry at /source/apache_1.3.20/mod_perl-1.26/t/net/perl/api.pl line 222, fh1b line 1. *** The following [error] is expected, no cause for alarm *** [Sun Aug 5 18:33:39 2001] [error] Missing right curly or square bracket at /source/apache_1.3.20/mod_perl-1.26/t/docs/badsyntax.pl line 9, at end of line syntax error at /source/apache_1.3.20/mod_perl-1.26/t/docs/badsyntax.pl line 9, at EOF Compilation failed in require at /source/apache_1.3.20/mod_perl-1.26/t//docs/startup.pl line 251, fh1b line 1. *** The following [error] is expected, no cause for alarm *** [Sun Aug 5 18:33:39 2001] [error] Apache::Death at PerlHandler subroutine `Apache::Death::handler' line 1 *** The following [error] is expected, no cause for alarm *** [Sun Aug 5 18:33:39 2001] [error] Missing right curly or square bracket at /source/apache_1.3.20/mod_perl-1.26/t/docs/badsyntax.pl line 9, at end of line syntax error at /source/apache_1.3.20/mod_perl-1.26/t/docs/badsyntax.pl line 9, at EOF Compilation failed in require at /source/apache_1.3.20/mod_perl-1.26/t//docs/startup.pl line 251, fh1b line 1. *** The following [error] is expected, no cause for alarm *** [Sun Aug 5 18:33:39 2001] [error] Apache::Death at PerlHandler subroutine `Apache::Death::handler' line 1 [notice] child process 666 terminating [notice] push'd PerlChildExitHandler called, pid=666 [notice] push'd PerlChildExitHandler called, pid=666 [notice] END block called for startup.pl [notice] Destruction-DESTROY called for $global_object __ On Sun, 5 Aug 2001, allan wrote: has anyone got a clue what to do about the error i get at modules/src below? !--mod_perl 1.26, perl 5.6.1, apache_1.3.20, mac os X -- thanks allan modules/actions.ok modules/cgi.ok modules/constants...ok modules/cookie..skipped test on this platform modules/fileok modules/httpdconf...ok modules/include.ok modules/log.ok modules/module..skipped test on this platform modules/perlrun.ok modules/psections...skipped test on this platform modules/request.skipped test on this platform modules/src.Use of uninitialized value in concatenation (.) or string at modules/src.t line 27. modules/src.FAILED tests 3-5 Failed 3/6 tests, 50.00% okay modules/ssi.ok modules/stage...skipped test on this platform modules/status..ok modules/symbol..skipped test on this platform modules/uri.ok modules/utilok internal/apiok internal/auth...ok internal/croak..ok internal/dirmagic...ok internal/error..ok internal/headersok internal/hooks..ok internal/http-get...ok internal/http-post..ok internal/proxy..ok internal/redirect...ok internal/rwrite.ok internal/stackedok internal/table..ok internal/taint..ok Failed Test Status Wstat Total Fail Failed List of Failed modules/src.t 63 50.00% 3-5 6 tests skipped. httpd terminated Failed 1/34 test scripts, 97.06% okay. 3/383 subtests failed, 99.22% okay. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Revised CodeRed.pm
OK, folks; I've added (thanks in part to Randal's private suggestion)
Cache::FileCache, which made it pretty trivial to ensure that we only
send a single message per 24-hour period.
I also added e-mail to administrator@ the infected host, since I've
been getting a fair number of bounces from webmaster@ and postmaster@.
And for those of you who were wondering whether multiple attacks will
come from the same IP address, I can assure you that I've received at
least 3-4 attempts from each of 2-3 addresses.
Sigh.
Reuven
# This Perl module should be invoked whenever the CodeRed or CodeRed2
# worm attacks. We don't have to worry about such attacks on Linux
# boxes, but we can be good Internet citizens, warning the webmasters
# on infected machines of the problem and how to solve it.
# On my system, I put CodeRed.pm in /usr/local/apache/lib/perl, which
# is in @ISA under mod_perl. I then added the following to my httpd.conf:
# PerlModuleCodeRed
# Location /default.ida
# SetHandler perl-script
# PerlHandler CodeRed
# /Location
# This module does require mod_perl (of course), Mail::Sendmail (which
# works fine with qmail, despite its name), and Net::DNS.
#
package CodeRed;
use vars qw($VERSION);
use Apache::Constants qw(OK DECLINED FORBIDDEN);
use Mail::Sendmail;
use Net::DNS;
use Cache::FileCache;
# What version of the module is this?
$VERSION = 1.02;
# Set this to your favorite URL describing how to fix this problem.
my $security_url =
'http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/security/topics/codealrt.asp';
# Do you want to know when one of these alerts has been sent? If so,
# put your address here.
my $cc_address = '[EMAIL PROTECTED]';
# Define whatever cache options you want to set. The
# most important for our purposes is default_expires_in.
my %cache_options = ('default_expires_in' = 86400 );
# Our handler subroutine, which deals with this.
sub handler
{
# Get Apache request/response object
my $r = shift;
# Create a DNS resolver, which we'll need no matter what.
my $res = new Net::DNS::Resolver;
my $remote_hostname;
#
# Open the cache of already-responded-to IP addresses,
# which we're going to keep in /tmp, just for simplicity.
my $file_cache = new Cache::FileCache(\%cache_options);
unless ($file_cache)
{
$r-log_error(CodeRed: Could not instantiate FileCache);
return DECLINED;
}
# Get some basic information about the request
my $remote_ip_address = $r-get_remote_host();
# If we don't have the remote IP address, then we cannot
# send mail to the remote server, can we?
return DECLINED unless (defined $remote_ip_address);
# If we have the remote IP address, then check to see if it's in
# our cache.
my $last_visited = $file_cache-get($remote_ip_address);
# If the address is in our cache, then we've already
# sent e-mail to that person, and we'll just return FORBIDDEN.
if ($last_visited)
{
$r-log_error(CodeRed: Found cached IP '$remote_ip_address');
return FORBIDDEN;
}
#
# If we only have the IP address (rather than the hostname),
# then get the hostname. (We can't look up the MX host
if ($remote_ip_address =~ /^[\d.]+$/)
{
$dns_query_response = $res-search($remote_ip_address);
if ($dns_query_response)
{
foreach $rr ($dns_query_response-answer)
{
next unless $rr-type eq A;
$remote_hostname = $rr-address;
}
}
else
{
$r-log_error(CodeRed: DNS query failed (',
$res-errorstring, '));
}
}
# If we had the hostname to begin with, then use it.
else
{
$remote_hostname = $remote_ip_address;
}
#
# Get the MX for this domain. This is trickier than you might
# think, since some DNS servers (like my ISP's) give accurate
# answers for domains, but not for hosts. So www.lerner.co.il
# doesn't have an MX, while lerner.co.il does. So we're going to
# do an MX lookup -- and if it doesn't work, we're going to break
# off everything up to and including the first . in the hostname,
# and try again. We shouldn't have to get to the top-level
# domain, but we'll try that anyway, just in case the others don't
# work.
my @mx = ();
my @hostname_components = split /\./, $remote_hostname;
my $starting_index = 0;
# Loop around until our starting index begins at the
# same location as it would end
while ($starting_index @hostname_components)
{
Re: module to hit back at default.ida atack ?
Anybody know of any module I can use to hit back at these default.ida bozos (i.e. keep them away from my IP addresses ?). I'm running apache/modperl on Win32. I remember a post on incidents or bugtraq where someone started pumping crap data back at the virus and eventually the NT system crashed. I haven't tried this, but it might be worth a shot to look in the archives and see if you can replicate this persons's results. ::grin:: In the post he mentioned about trashing the kernel on NT so this might be kinda fun... at the same time, because no one else has done something like this suggests that it may not work. YMMV. -sc -- Sean Chittenden PGP signature
Re: modperl install on osx - help
hi in case someone will face the same problem: i installed successfully modperl 1.26 on apache 1.3.20 on OS X 10.0.4 using APXS. this worked fine while all other ways of installing failed for me. thanks for the help! christian on 03.09.40 00.09, Ken Williams at [EMAIL PROTECTED] wrote: Christian, You should get the latest Apache, 1.3.20, instead of the old 1.3.14. Also try removing the 'USE_APACI=1' flag from your build line. That combo works for me under OS X 10.0.4. Perhaps it would work with USE_APACI=1 in there too, but I haven't tried. Christian Wattinger's message: im at the end of my wisdom here, i try to install on mac osx following the advice from http://perl.apache.org/guide/install.html#A_Summary_of_a_Basic_mod_perl_In i dont get very far with it and i know still little about unixy stuff. im desperate because i need this mod_perl to work quickly (i tried tenon iTools but their apache configs with EXPAT enabled = conflict! and its expensive too...) well i post below what i get, help is very welcome! thanks christian - [cable-ggar40-162:/usr/src/mod_perl-1.26] root# perl Makefile.PL APACHE_SRC=../apache_1.3.14/src DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 -Ken Williams The Math Forum [EMAIL PROTECTED]
Re: Module to catch (and warn about) Code Red
The descriptions I've seen indicate that it has a flaw in the attempt to pick random targets. It always uses the same seed so every instance runs through the same addresses in the same order. That means you will get hit by the same box if it has been rebooted and then re-infected (and that it is almost sure to be re-infected if the patch has not been applied). Les Mikesell [EMAIL PROTECTED] - Original Message - From: Todd Finney [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, August 05, 2001 9:51 AM Subject: Re: Module to catch (and warn about) Code Red I don't think this is an issue. Someone more familiar with the virus can chime in, but the information that's out there on it seems to indicate that it's not going to pick the same IP twice, except by chance.
Re: odd behavior with Cache::Cache
on 8/4/01 1:34 PM, brian moseley at [EMAIL PROTECTED] wrote: also, has there been any thought given to locking cached items? when i'm using a shared cache with multiprocess apache, the opportunity exists for multiple requests to access a single session simultaneously, which can lead to races. which i'm happy to ignore for now but would be nice to eventually prevent. Gunther's Extropia stuff includes optional support for sessions that lock in the way you're describing, but I've never seen any other session implementation that did it this way. It seems that the session pattern is generally used for transient data where last-save-wins is fine as long as the integrity of the data is protected during the actual writes. If you need fancier locking, you could try ripping the lock stuff out of Apache::Session. - Perrin
compiling troubles on Solaris 8
Hello, I am trying to build mod_perl 1.26 and Apache 1.3.20 on my Solaris 8 box. I have installed the additional CD with the developer tools including the gnu utilities and gcc. When I first started, it did not seem to be using gcc, so I renamed /usr/ucb/cc to cc.default, and make /usr/ucb/cc a link to gcc. That seemed to get me further. However, I have reached a fatal error, and don't have a clue what this means. The error messages are quoted below. I am trying to do the simplest build possible, following the INSTALL instructions. So after unzipping and untarring apache and mod_perl, from within the mod_perl distribution directory, I type perl Makefile.PL I confirm that I want it build from ../apache_1.3.20/src, and that I want to store the new httpd in that directory. Then I type make. After a bit, I get this: mkdir ../blib/arch/auto/Apache/Leak mkdir ../blib/lib/auto/Apache/Leak cp Leak.pm ../blib/lib/Apache/Leak.pm /bin/perl -I/usr/perl5/5.00503/sun4-solaris -I/usr/perl5/5.00503 /usr/perl5/5.00 503/ExtUtils/xsubpp -typemap /usr/perl5/5.00503/ExtUtils/typemap -typemap typem ap Leak.xs xstmp.c mv xstmp.c Leak.c cc -c -xO3 -xdepend -DVERSION=\1.00\ -DXS_VERSION=\1.00\ -KPIC -I/usr /perl5/5.00503/sun4-solaris/CORE -DSOLARIS2=280 -DUSE_EXPAT -I/lib/expat-lite -D NO_DL_NEEDED Leak.c cc: unrecognized option `-KPIC' cc: language depend not recognized cc: Leak.c: linker input file unused since linking not done Running Mkbootstrap for Apache::Leak () chmod 644 Leak.bs LD_RUN_PATH= cc -o ../blib/arch/auto/Apache/Leak/Leak.so -G Leak.o cc: Leak.o: No such file or directory cc: No input files *** Error code 1 make: Fatal error: Command failed for target `../blib/arch/auto/Apache/Leak/Leak .so' Current working directory /home/paul/mod_perl-1.26/Leak *** Error code 1 make: Fatal error: Command failed for target `subdirs' I have no idea what is wrong, or how to fix it, so I would appreciate any help. thanks! ___ Paul Phillips Director of Orchestral Activities, Meadows School of the Arts Southern Methodist University You must sing every note you play, sing even through the rests! Arturo Toscanini
Re: compiling troubles on Solaris 8
Sun wants to sell you it's Forte for C (formerly known as the Sun Workshop compiler). There's a hundred reasons to use the sun compiler over gcc, and one pretty big reason why you you don't want to use it. If you can get it into your budget, by all means go for the real Sun compiler. It generates code that is highly optimized for sparc hardware, particularly if you are running multiple processors. If nothing else, request a time limited demo license from Sun so you can build mod_perl (and every other module you think you'll ever need off of CPAN). On Sunday, August 5, 2001, at 04:05 PM, Paul Phillips wrote: Hello, I am trying to build mod_perl 1.26 and Apache 1.3.20 on my Solaris 8 box. I have installed the additional CD with the developer tools including the gnu utilities and gcc. When I first started, it did not seem to be using gcc, so I renamed /usr/ucb/cc to cc.default, and make /usr/ucb/cc a link to gcc. That seemed to get me further. However, I have reached a fatal error, and don't have a clue what this means. The error messages are quoted below. I am trying to do the simplest build possible, following the INSTALL instructions. So after unzipping and untarring apache and mod_perl, from within the mod_perl distribution directory, I type perl Makefile.PL I confirm that I want it build from ../apache_1.3.20/src, and that I want to store the new httpd in that directory. Then I type make. After a bit, I get this: mkdir ../blib/arch/auto/Apache/Leak mkdir ../blib/lib/auto/Apache/Leak cp Leak.pm ../blib/lib/Apache/Leak.pm /bin/perl -I/usr/perl5/5.00503/sun4-solaris -I/usr/perl5/5.00503 /usr/perl5/5.00 503/ExtUtils/xsubpp -typemap /usr/perl5/5.00503/ExtUtils/typemap -typemap typem ap Leak.xs xstmp.c mv xstmp.c Leak.c cc -c -xO3 -xdepend -DVERSION=\1.00\ -DXS_VERSION=\1.00\ -KPIC -I/usr /perl5/5.00503/sun4-solaris/CORE -DSOLARIS2=280 -DUSE_EXPAT -I/lib/expat-lite -D NO_DL_NEEDED Leak.c cc: unrecognized option `-KPIC' cc: language depend not recognized cc: Leak.c: linker input file unused since linking not done Running Mkbootstrap for Apache::Leak () chmod 644 Leak.bs LD_RUN_PATH= cc -o ../blib/arch/auto/Apache/Leak/Leak.so -G Leak.o cc: Leak.o: No such file or directory cc: No input files *** Error code 1 make: Fatal error: Command failed for target `../blib/arch/auto/Apache/Leak/Leak .so' Current working directory /home/paul/mod_perl-1.26/Leak *** Error code 1 make: Fatal error: Command failed for target `subdirs' I have no idea what is wrong, or how to fix it, so I would appreciate any help. thanks! ___ Paul Phillips Director of Orchestral Activities, Meadows School of the Arts Southern Methodist University You must sing every note you play, sing even through the rests! Arturo Toscanini
Re: odd behavior with Cache::Cache
At 05:44 PM 8/5/2001 -0400, Perrin Harkins wrote: on 8/4/01 1:34 PM, brian moseley at [EMAIL PROTECTED] wrote: also, has there been any thought given to locking cached items? when i'm using a shared cache with multiprocess apache, the opportunity exists for multiple requests to access a single session simultaneously, which can lead to races. which i'm happy to ignore for now but would be nice to eventually prevent. Gunther's Extropia stuff includes optional support for sessions that lock in the way you're describing, but I've never seen any other session implementation that did it this way. It seems that the session pattern is generally used for transient data where last-save-wins is fine as long as the integrity of the data is protected during the actual writes. If you need fancier locking, you could try ripping the lock stuff out of Apache::Session. - Perrin My impression was that the locking in Apache::Session is a one-time lock so it just fixes data integrity issues. So I am not sure if it is fancier than Cache::Cache unless Cache::Cache has no locking at all (or no concept of lock choice). I was really interested in abstracting the locking API for Extropia::Session because it was an interesting challenge and frankly at the time I *thought* that Apache::Session did it, so I wanted to match it. In addition, the motivation for Extropia::Session was to match the Java Servlet Session spec so I wanted to make sure that whatever protections were provided by Java, I would have in Perl multiprocessing environment. The latter being fairly difficult to emulate exactly. In the end, I don't think I have actually written any applications that would cause two session updates to occur at the same time, so it might have been overkill. I am lately thinking of session as a means to store very transient stuff but then real persistent application data such as cart data from a web store should be stored in a real data storage with real multi-user locking with the session id as a mere key to that database. I guess it just depends on your scenario. I would be curious to hear about some real world (as opposed to academic) scenarios about it being an issue. Later, Gunther __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: src.t failure
On Sun, 5 Aug 2001, allan wrote: Stas Bekman wrote: http://perl.apache.org/guide/install.html#Manual_Testing please also provide the output from t/logs/error_log ok then: with TEST_VERBOSE=1: modules/src.Use of uninitialized value in concatenation (.) or string at modules/src.t line 1. 1..6 ok 1 dir=../src ok 2 main= not ok 3 module_magic_number = 0 not ok 4 httpd_version = not ok 5 -I../src -I../src/modules/perl ok 6 looks like your Apache source vars get lots after the compilation. After all you did get to compile it. Seems to me like some peculiar thing that happens only on osx. I'll let folks who have osx around to chime in. These are the three tests that fail: print main=, $src-main, \n; test ++$i, -e join(/, $src-main, httpd.h); my $mmn = $src-module_magic_number; print module_magic_number = $mmn\n; test ++$i, $mmn; my $v = $src-httpd_version; print httpd_version = $v\n; test ++$i, $v; _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: module to hit back at default.ida atack ?
H I, On Sun, 5 Aug 2001, Sean Chittenden wrote: Anybody know of any module I can use to hit back at these default.ida bozos (i.e. keep them away from my IP addresses ?). I'm running apache/modperl on Win32. [snip] ::grin:: In the post he mentioned about trashing the kernel on NT so this might be kinda fun... Well you might think it's fun but there are those who'd say it's criminal. Please don't promote irresponsible ideas on the mod_perl List. 73, Ged.
