Bad Behavior 2.0.35
December 15th, 2009 by Michael Hampton
Bad Behavior 2.0.35 has been released. It is a maintenance release and is strongly recommended for users of shared web hosting services.
Please note: The 2.0 series of Bad Behavior is receiving limited updates, including unblocks, bug fixes and security fixes only. Future development will be to the 2.1 development tree.
MediaWiki and WordPress users who have not updated in the last year or so should take note of special upgrade instructions below.
Who should upgrade?
Users whose sites are on shared web hosting services should upgrade to prevent “MySQL server has gone away” database errors. Users whose sites are on dedicated servers or virtual dedicated servers should review the information below before upgrading.
What’s new?
New in this release (since 2.0.34):
- In very rare circumstances, Bad Behavior users may see MySQL database errors stating “MySQL server has gone away.” This issue does not occur in Bad Behavior’s default configuration. It primarily affects shared web hosting providers using cPanel/WHM, though it may affect other shared web hosting providers or, even more rarely, people who run their own virtual dedicated servers or dedicated servers. A workaround has been placed in Bad Behavior to mitigate this issue.
In order for this issue to occur, three things must happen:
- Bad Behavior must be configured to use the http:BL DNS-based list (which is disabled by default);
- A DNS query sent to http:BL must take an unusually long time (several seconds or more); and
- The time the DNS query takes must exceed the MySQL server’s configured wait_timeout value.
In this scenario, because MySQL has not seen a database query for a long time, the server drops the database connection. Shared web hosting providers set the wait_timeout value relatively low in order to preserve resources on their typically very active databases; each open connection uses scarce memory that could be serving another user. There is nothing wrong with this, in theory, though a few hosting providers set wait_timeout so low as to be frequently unusable. For instance, cPanel/WHM based web hosts may have wait_timeout set to 10 seconds, which I feel is completely unreasonable.
The “MySQL server has gone away” error appears when the host platform under which Bad Behavior runs (e.g. WordPress, Drupal, etc.) fails to trap the error and reopen the database connection. There is nothing Bad Behavior can presently do to cause the host platform to reconnect to the database. If your host platform does this, its database code needs to be reworked so that it reconnects and resends the query when it gets the “MySQL server has gone away” error.
Another issue here is that DNS lookups typically take less than a second. When http:BL is active, Bad Behavior screens the IP address for all POST requests against it. The Internet not being 100% reliable, it’s expected that occasionally DNS queries will be slow. If DNS lookups consistently take significantly longer, (e.g. they’re slow for more than a day) this may indicate trouble with the DNS servers being used by the web server. There isn’t much that Bad Behavior can do about this.
In the meantime, the workaround released today will ask the MySQL server to temporarily raise the timeout to 90 seconds, for that connection only, whenever it does a DNS lookup. (The timeout for most requests is left alone.) This should be more than sufficient; with my own server set at 60 seconds I have never seen this error.
If you continue to see “MySQL server has gone away” messages and/or slow loading times when you log in or navigate your administrative pages, disable http:BL. If that still doesn’t help, you may have other trouble; contact me and we’ll figure it out.
Finally I want to thank Jen Lepp at DrakNet Web Hosting for providing the information which finally allowed me to track down this rare but annoying issue.
Support
Thank you to everyone who has chosen to make a financial contribution toward further development of Bad Behavior. Your contributions ensure that I can prioritize Bad Behavior development and make more frequent and timely releases, like this one.
Download
Special Upgrade Instructions
Users of MediaWiki and WordPress upgrading from version 2.0.20 or earlier should follow these special directions (from 2.0.21 or later, upgrade normally):
For MediaWiki: Before installing this version of Bad Behavior, manually remove (e.g. using FTP or ssh) any old versions you may have, including the lines added to LocalSettings.php. Then install the new version fresh, following the installation instructions for MediaWiki.
For WordPress: If updating to this version through the automatic updater fails, manually remove (e.g. using FTP or ssh) any old versions you may have installed. Then upload and install the new version fresh, following the installation instructions for WordPress. After doing so, future automatic updates should proceed normally.
For other platforms: No changes to your upgrade procedures should be necessary.
chawl Says
match_cidr() function should really consider X-Forwarded-For for reverse proxies like Varnish, Squid etc. BB always gives 403 to Googlebot, MSNBot as they seem to come from localhost.
I know there is a whitelist to allow localhost, but unfortunately this will abandon all IP checks, if a reverse proxy is present.
Am I missing something?
Jan 24th, 2010 at 6:49 am
Michael Hampton Says
If you’re running a reverse proxy on the same host as the origin server, you’re probably doing it wrong.
In this case, use something like nginx as the origin server and just pass PHP to fastcgi or php-fpm. Using varnish or squid in this case is completely unnecessary.
I will do some work in the current development cycle for better support of installations which need a reverse proxy.
Jan 24th, 2010 at 8:08 am
chawl Says
In fact, I am varnishing Apache (mod_php) for a 350MB httpd process not to serve a 25 byte gif but to do something useful instead.
I also hacked all match_cidr() calling inc.s (not the main func) to use X-Forwarded-For if defined. Nasty but more than enough for now. I am protecting Drupal by the way.
Tx for your fast consideration
Jan 24th, 2010 at 10:03 am
Michael Hampton Says
Well, you never said why you needed varnish, so I won’t try to give you any advice. But it doesn’t sound like you need it.
Jan 24th, 2010 at 5:47 pm
chawl Says
In short,
1. We have many MBs of RewriteMaps which needs Apache.
2. FCGI has shared memory problems with opcode cachers, causes some conf problems for our server setup, and slightly slower, therefore mod_php is more feasable.
3. mod_proxy+lighttpd offloading of static files has no real benefit in terms of memory, as an httpd is dedicated even for a proxy request.
4. It is impossible to use KeepAlives with our loads
5. We are mostly using Drupal and 7.x will introduce ESI technology for complex dynamic caching mechanisms.
6. Redirecting static content to other subdomains/ports of nginx,lighty etc. is an overkill especially when using complex CMS structures, and for a single server, this is again Apache offloading, not caching.
7. We have not much money for insane servers or have no labour to tweak every bit all day long.
8. Varnished response times are incredibly low in our test case, our Core i7 seems to contribute to speed at last. At least not sitting ducks for some sockets to be available as in our previous “offloading” test setup. Varnish seems more kernel level, though I am not an expert.
I know it is not geeky enough, but varnishing helps in our case, as we have a rather rough and dull underlayer and need practical solutions.
Sure there will be people or hosts using reverse proxies in the future, therefore making BB more compatible with these will be beneficial I think.
Thank you for your efforts
Jan 24th, 2010 at 7:05 pm
Gordon Says
chawl, sounds like you’ve got the static-offloading proxy idea backwards. The idea is to have lighttpd or nginx in front, serving all static requests, and proxying dynamic requests to Apache.
Feb 19th, 2010 at 2:03 am
chawl Says
Yes, but we are using many RewriteMaps each is several MBs in size. Then Apache should be hit first, or at least is transparently reached ‘including’ static files. and Varnish is good at for 301’s also.
By the way, we set up mod_rpaf and this solved every bit of issues. No need to hack something anymore.
Tx for your assistance and such a useful piece of code.
Feb 25th, 2010 at 12:04 pm