EV1 RHN Problems

Anyone with an EV1 server running RHE will probably find that up2date isn’t working. This is as a result of upgrades that EV1 have just performed on their RHN mirrors. There is a simple fix:

rpm -Uvh –force

More details in the EV1 Forum thread.

New mod_security v1.9.2

A new version of mod_security has been released hereChanges:

ModSecurity 1.9.2 is primarily a bug-fix release, but itincludes a few interesting new features.ModSecurity can now be compiled against PCRE regex library(Apache 1.3.x only, Apache 2.x already uses PCRE), resultingin large performance increase. It is also possible to compileModSecurity not to use suEXEC for process creation. Someconcurrent audit logging improvements. New proof-of-conceptscript for real-time audit log centralisation. Many smallerbug fixes and improvements throughout.

Problems with cPanel and the new module

When running /scripts/perlinstaller you might be seeing this error:

Undefined subroutine &CPAN::Config::commit called at /scripts/realperlinstaller line 95.

This is being caused by the renaming of a function call in which cPanel relies upon. Although there now appears to be a fix in the EDGE tree from the report I logged in bugzilla: is a new version of release at this morning that addresses the issue.To manually upgrade to this fixed version do the following:

wget -xzf CPAN*cd CPAN*perl Makefile.PLmakemake install

That should resolve the issue.

MailScanner Script v2.29 Released

Changes in this new release to the script are:v2.29 – New version of MailScanner 4.49.7Upgrades can be done by following upgrade instructions.Details of the MailScanner Changes:

The full Change Log is this:* New Features and Improvements *- Speed improvements for sendmail systems by changing the

OS Updates breaking perl and therefore MailScanner

We have had a lot of reports about MailScanner failing with perl module errors. We’re finding that this has nothing to do with MailScanner at all. It’s because clients are not excluding perl updates from their OS providers update utility (e.g. yum or up2date). There was a recent update to RH based OS’s with a new iteration of perl which fixes some security bugs. Most likely this has downgraded installed version of perl (perhaps v5.8.7) to v5.8.0 which won’t contain all the perl modules needed to run many things including MailScanner, cPanel and it will almost definitely break cPanel stats.The fix is fairly simple:

cd /usr/bin ls -la perl*

establish which version of perl you should be using:

cp -avf perl5.x.x perl

Check it’s correct with:

perl -v

Check that /usr/local/bin/perl is a symlink to /usr/bin/perl. Then stop and restart MailScanner, cPanel and any other daemons running through the perl interpreter.

mod_security v1.9.1 released

There’s a new version of mod_security that has just been released. Here are the details:

ModSecurity 1.9.1 is a bug-fix release. It fixes four minorissues discovered in 1.9.Changes (since 1.9)——————-* Variables OUTPUT and OUTPUT_STATUS are no longer silently

APF antidos

With a wide range of experience in dealing with issues and problems caused either directly or indirectly by APF, I’ve come to the conclusion that the antidos (AD) feature of APF is much more trouble than it is worth. With it enabled, it’s apparent that the iptables rules can very quickly become dangerously full. This can lead to at least two issues:

  • Ethernet traffic is slowed down due to the large number of lookup checks required
  • A server can be rendered unbootable

That last point is the most dangerous. I’ve seen several servers with around 1000 IP addresses in the firewall preventing a server from booting. IIRC, this happens because APF is taking so long to load up the iptables rules, the boot sequence basically stalls and goes no further.Details on disabling antidos if you have it enabled follow…Steps to disable AD:

  • Edit /etc/apf/conf.apf and set: USE_AD=”0″
  • Empty out the AD rules: cat /dev/null > /etc/apf/ad/ad.rules
  • Restart APF: apf -r
  • Remove the root crontab entry that mentions antidos, also check /etc/crontab
  • Make sure that antidos isn’t still running in cron: killall -9 antidos