Spammers Clobbering the Blog (Killing the server...)
Written by
on
in
Snaking.
Zope really isn't intended for extremely write-heavy applications. With the comment spammers dumping hundreds to thousands of spams per hour on the blog now, the blog is now officially a write-heavy application.
If I've done this right, then the spams should now be moderated, so they shouldn't have any benefit for the spammers. Still, it's half a day of work wasted to deal with the slimy little bleepards instead of working on PyOpenGL.
CoreBlog does, it turns out, have a hook to deal with pre-comment-insertion operations... it's just a pretty anaemic little thing that just lets you set moderation. I'd prefer it just let me drop the comment entirely, since I can see that it's a spam already. Anyway, at some point I guess I need to move the blog... it always seems like such a huge hassel, though.
Anyway, we'll see how bad the spamming is tomorrow, may need to take it offline while I'm at work.
Comments
Comments are closed.
Pingbacks
Pingbacks are closed.
Mike C. Fletcher, the VRPlumber, is a philosopher of design turned computer programmer based in Toronto, Canada. He works primarily in the Python programming language, and maintains a large number of Open Source software packages. You can reach him at: mcfletch@vrplumber.com.
Mike Fletcher on 04/13/2008 11:13 p.m. #
Well, the first 30 minutes or so and the blog doesn't seem to have keeled over just yet. I suppose I'll consider it pseudo-stable and call it a night...
William Ferrell on 04/14/2008 1:10 a.m. #
Apologies if this is out-of-place but since I've recently started diving into Zope a bit more (I've wanted to learn it for years now, and sadly I've only recently gotten a real chance to do so), this topic is of interest to me :)<br />
<br />
I'm curious about your description of Zope as being not well suited to "write-heavy" applications. Does this just mean it tends to curl up into fetal position when lots of new nodes/objects/whatevers get created/updated all at once (or within a few seconds of each other), or is it a function of caching breaking down, or some other symptom?<br />
<br />
I guess I'm asking because I'm interested to know what Zope does as its load gets heavier. Is it silently dropping records, or is it throwing errors, or is it just slowing down unacceptably? One of the ideas for an application (I guess Zope calls these "products?") I have might see instances where a single action might cause hundreds (or thousands) of updates (think "applying a tag to hundreds of photos" or "marking all items, even if they number in the thousands, in a tree as 'needs update' so its thumbnails/search index/etc. get rebuilt on the next maintenance run," etc.).<br />
<br />
One idea I had to cope with that kind of crazy-heavy load is to store tasks like that in a queue that a maintenance/worker bot can run through in chunks. That also prevents several types of denial-of-service attack, too. Of course, since I'm a Zope newbie, this is all theory :)<br />
<br />
Sorry for getting rambling on you a bit; I thought more detail would be better than less in this case. Still, I'd love more detail on the kind of failure/pain you're seeing from Zope given the spamming going on.<br />
<br />
If it makes you feel any better, my blog (running on Drupal for now) got hit with a similar attack early this year, to the point that my webhost noticed and banned the offending IPs because they were generating hundreds of thousands of hits a day (trying to submit spam to every form they could find). Installing a development/beta version of the "Bad Behavior" module fixed a lot of that; adding captcha helped too. Sadly, the banning-by-IP approach was the most effective solution for me. It may be worth skimming your logs to find the biggest offenders and stick them in a simple Apache Deny block in .htaccess.
Mike Fletcher on 04/14/2008 6:29 a.m. #
Zope is well understood to be non-write-heavy suitable when using the ZODB. CoreBlog uses the ZODB. When you want a Zope app to be heavily write oriented you use Zope as a front-end to a relational DB. So in your photo case you'd store the photos (or at lest their meta-data) in a DB.