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 free

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

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

[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...

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

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

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

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

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

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

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:

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

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

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

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

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

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

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