Atomicorp

faris wrote:I don't think it is an FD limit issue.

Also VZ here, and have also had the same problems.

If you reduce the size of the malware blacklist and domain blacklist you'll find the problem will also go away (or at least not happen very often). [ note -- you have to copy your reduced files to /var/asl/rules/modsec or some similar place as they get copied from there into /etc/httpd/modsecurity.d every so often, overwriting any modifications you might make]

Interestingly, since ASL 3.x seems to have improved the situation in some mysterious way. I've not seen a single one since I updated (but I still reduce the malware/domain blacklists).

It appears to therefore be the amount of data in memory that triggers the "bug" - the more there is, the more likely it is to trigger.

In the past I had been looking for some way to use a dnsbl instead of those files, thus removing them from memory, but unfortunately it isn't possible since mod_sec basically has to lookup every single domain in both lists against an url in the request, and this can't be done using adnsbl.

I thought the bug had been narrowed down to APR, anyway? I can't update it on my systems (all Centos 4)

Yeah, it's a memset operation that apr is doing that's failing though - a memory mapped file being created while approaching your FD limit could explain it (but it's a longshot).

Further up this thread it was reported that there is a bug report in the apache bugtracker for this, but I can't find it anywhere. Does anyone know where this is?

In the past I had been looking for some way to use a dnsbl instead of those files, thus removing them from memory, but unfortunately it isn't possible since mod_sec basically has to lookup every single domain in both lists against an url in the request, and this can't be done using adnsbl.

Actually, we added in that capability into this weekends updates. We'll be pushing that this week. The first DNSBL to be supported is urirbl.com.

And the spam parallel search blocklists will be forked into their own ruleset this week too, so if you dont want to use them you can just disable the entire set. Keep in mind that the parallel search blocklists will always be faster than any DNS lookup and memory is cheap. So always use a cached option over a network lookup options if you can.

All DNSBLs implementations (spamassassin, etc.) suffer from DNS performance and throughput bottlenecks. A DNS lookup will always be much slower than an in memory lookup. Speed of the DNS lookup will be dependent on your DNS servers location and performance (how fast it replies to a query), how fast it asks for information from the authoritative server(s), and of course how quickly the RBL operators system replies.

Therefore, as always, if you use an RBL keep in mind the DNS performance penalty. And make sure you have a fast local DNS server, and if possible a mirror of the zone locally.

These rules will be disabled by default.

We are also working on an RBL for all the malware and spam domains in our blocklists. In our case though we will likely bundle an rbldnsd setup to host the zones locally so you can do rapid lookups on your own system (although not as fast as the current parallel lookup system, theres nothing we can do about that as a network stack is always slower than memory on the system).

We already have an rbldnsd installation locally, which we use in conjunction with mod_sec (and spamassassin).

All this sounds extremely exciting! I can't wait to fiddle with some of this, especially if I can just rsync some of the data into our own dnsbl to avoid having multiple installs.

Faris.

All this sounds extremely exciting! I can't wait to fiddle with some of this, especially if I can just rsync some of the data into our own dnsbl to avoid having multiple installs.

We're going to push the new rule DNSBL rules tomorrow, but they wont be active in the GUI yet. The new rule file is:

31_asl_urispam.conf

If you want to try it before the rule manager and GUI support it, you'll need to manually install it.

mikeshinn wrote:The art builds all have the debug-info, I seem to recall the centos project was missing theirs.

Only just now did I notice /etc/yum.repos.d/CentOS-Debuginfo.repo where one can enable the repository with *-debuginfo packages.

If you install the yum-utils repository you should also be able to run debuginfo-install httpd to install all required *-debuginfo packages, but because of a bug this command does not automatically enable the correct repository (since its name doesn't end in '-debuginfo', I'll report this to CentOS), so that's why you'll need to enable the repository in /etc/yum.repos.d/CentOS-Debuginfo.repo manually for now.

breun wrote:I'll report this to CentOS

For those interested: http://bugs.centos.org/view.php?id=5768

There's no php-debuginfo package in atomic?

I dont normally do the debuginfo packages for space reasons