Bad-Behavior MediaWiki Plugin Fix

If you use MediaWiki to power your wiki, you’ve probably heard of the Bad-Behavior plugin to help fight spam.

Bad Behavior is a set of PHP scripts which prevents spambots from accessing your site by analyzing their actual HTTP requests and comparing them to profiles from known spambots. It goes far beyond User-Agent and Referer, however. Bad Behavior is available for several PHP-based software packages, and also can be integrated in seconds into any PHP script.

I was all for it after I read the description as well as the functions it adds to one’s wiki.  So, I did the following:

1.   Downloaded it like so:

wget http://www.bad-behavior.ioerror.us/download/bad-be…

2.   Unzipped it with the -a option (for ASCII mode):

unzip -a bad-behavior-2.0.10.zip

3.   Copied the whole folder to /path-to-wiki/extensions

cp -R /path-to-wiki/extensions

4.   Edited LocalSettings.php an added the following line at the end of the file:

include( ‘./extensions/Bad-Behavior/bad-behavior-mediawiki.php’ );

The include statement above should’ve worked where a new table would’ve been added in my MediaWiki DB, but this did not happen, and when clicking on any link, I would just get a blank page.

My HTTPD logs also showed “undefined variable” errors, so after searching for fixes, I found that the following line had to be added just below the require_once(“includes/DefaultSettings.php”) line to resolve the issues. 

Apparently, you’ll need this if you’re using a certain combination of Apache-PHP-MediaWiki versions:

require_once( “includes/DatabaseFunctions.php” );

I restarted Apache and all worked fine.  You can also add the Bad-Behavior 2 Extended extension if you’d like, which I did.

Use another SMTP server with Postfix

Over the weekend, I finally installed and configured my own e-mail server. What a challenge that was!

I’m successfully running Postfix, Dovecot, Spamassassin, Amavisd-new, ClamAV, SQLgrey, and Squirrelmail. I, however, encountered problems sending to Gmail.

It returned with the following message:

host gmail-smtp-in.l.google.com[64.233.163.27] said:
550-5.7.1 [76.170.212.236] Our system has detected an unusual amount of unsolicited 550-5.7.1 mail originating from your IP address. To protect our
550-5.7.1 users from spam, mail sent from your IP address has been 550-5.7.1 rejected. Please visit 550-5.7.1
http://www.google.com/mail/help/bulk_mail.html to review 550 5.7.1 our Bulk Email Senders Guidelines. 39si20019987nzk (in reply to end of DATA command)

Rejected? Huh? Apparently, my IP address has been blacklisted because Google couldn’t identify my server; also because I don’t have a static IP.

They said:

To ensure that Gmail can identify you:

  • Use a consistent IP address to send bulk mail.
  • Keep valid reverse DNS records for the IP address(es) from which you send mail, pointing to your domain.
  • Use the same address in the ‘From:’ header on every bulk mail you send.

We also recommend publishing an SPF record, and signing with DomainKeys.

At this point, I don’t really want to run and maintain my own DNS server nor obtain a static IP (everything works fine and it’s cheaper!), so I found a way around it: Set Postfix to use another SMTP server.

Here’s how:

1. Edit /etc/postfix/main.cf, and add or edit this line:

relayhost = smtp.servertouse.com

2. Restart the Postfix service (I run FC6), so:

sudo service postfix restart

That’s it! Your server will now send to the SMTP server specified above rather than sending directly to the destination, which as a result, will not be “rejected” by Gmail or the like. ;0)

Yoggie, a miniature security firewall appliance solution

A friend and coworker of mine, Arthur Freyman, told me about a miniature device that provides all the security you’ll ever need out-of-the-box. It’s called Yoggie.

Reading the specs and services it provides is so far pretty good – and not surprising, it runs Linux under the covers.

Just think how cool it would be taking this device/gadget along with you when you’re on a road trip or working/surfing at a Starbucks…I think it’s an excellent idea and product from a bird’s eye view. Unfortunately, neither of us has tried it yet, but one of us will soon.

Here’s a screenshot of the architecture.

If you have one, let me know, and watch out for a future blog post on this in the not so distant future. =0)

Where’s the disk monitoring?

I was doing research on a development project I’m currently working on and encountered this error on a developer-resource website (anonymous to prevent any legal action):

Fig. 1.1 – ASP.NET 2.0 Error: Not enough disk space

ASP.NET 2.0 error

Googling for “disk monitoring tools” came up with a TON of results. The lesson to learn from this:

Monitor the back and frontend servers that is the bedrock and foundation of your website/business.

Use systems like MOM (if a Windows shop), Nagios for open-source, or if unsure try external monitoring providers.

I personally use mon.itor.us. It’s still in beta, but it’s free and easy to use.

Yumex to the rescue!

Yumex is a yum extender that provides a GUI for package management.

So why am I writing about it, well, read on…

I had written recently about my upgrading from Fedora Core 1 to Fedora Core 6, and one major, annoying issue I encountered was with the yum updates.

I encountered approximately 5 conflicts and about 2 dependency errors.  I believe it was with php-do and php and some elib libraries.  I know, I know.  You’re thinking, “if it ain’t broke, don’t fix it,” right?  Well, unfortunately, I can only take so much of that.

So, with the mission at hand, I started googling for fixes and finally found a thread about yumex.  I yum installed it, went into init 5 (I run init 3 by default), vnc‘ed into my box and run it.

After having used it, I strongly recommend you give it a try, especially if you have problems updating via a terminal window.

What yumex gives you is the freedom to update only certain packages via a click-and-process method; for example to fix my problem, I updated 15-20 packages at a time, continuously went through the list until I came across the offending package.  I then took care of problematic ones one-by-one.

Pretty cool, ey…All you need to complete this process is patience and a book.  =0)