Subscribe via

Project Honey Pot Http:BL is Going Back Home

It is my pleasure to announce that I will be joining my development efforts of Project Honey Pot Http:BL plugin with Jan Stepien (the original developer of Http:BL). Jan has already merged my changes onto the Http:BL plugin which can be found here. I will no longer be updating Project Honey Pot Http:BL. I have been spread a bit thin lately so I welcome this partnership. I have a long features list for the Http:BL plugin, but just haven’t had to time to implement them. Make sure you stay tuned to see how well this plugin turns out!

Project Honey Pot Http:BL WordPress Plugin

This plugin is no longer supported/updated. Please see Project Honey Pot Http:BL is going back home.


Today I would like to announce the release of “Project Honey Pot Http:BL” WordPress Plugin.

Description

This plugin allows you to verify all visitors’ IP address against the Project Honey Pot database. Using the Http:BL API, this plugin flags, logs, and blocks visitors with a high threat score, helping you prevent harvesters, spammers, or other suspicious bots from abusing your blog. I’ve been talking a lot about LoJack anti-spam measures lately and this is one of them.
This plugin requires you to sign up for a free account at Project Honey Pot so that you can use their Http:BL API to verify your visitors.
This plugin is based on Jan Stepien’s http:BL version 1.4 which is no longer being supported. This version of the plugin fixes a lot of database bugs and usability issues that the original plugin had. Here are the key benefits of having this plugin enabled.

  1. LoJack anti-spam solution with collective intelligence
  2. Easy Project Honey Pot integration. No need to mess with Apache mod_httpbl, which means that this will work on shared hosts.
  3. Ability to redirect malicious bots to a bot trap.
  4. Logging capabilities

Read on…

Completed OMNINOGGIN Server Migration

Server Migration
I apologize if you have visited earlier today and found the Maintenance-Mode screen. I was moving this blog from a self-hosted dedicated server to a shared-hosting server. In this post, I will discuss the reasons for my decision and the switching experience.
Here are some reasons why I made the switch (Pros):

  1. I’ve been getting more readers lately so my bandwidth was almost reaching capacity. Shared-hosting is the cheapest way to get decent burstable bandwidth.
  2. I wanted to start focusing more on WordPress and less on FreeBSD. Making this switch will alleviate me from having to maintain/troubleshoot low-level system things, leaving me with more time to focus on WordPress development & discussion.
  3. Read on…

Block Unwanted Spam Bots Using Varnish VCL


Every time I search the web for information on how to block spam bots, scrapers, and harvesters, I always see an Apache .htaccess file or some code to dump into httpd.conf to achieve this. I’m a bit against using this method for blocking evil bots. I do respect Apache for being a flexible & modular web server (that’s why I still use it), but I do not have much to boast about Apache’s speed and efficiency.
To achieve the same purpose on my server with greater efficiency, I made use of my Varnish reverse proxy configurations (located under /usr/local/etc/varnish/default.vcl).
In this post, I will only be discussing about vcl_recv subroutine, which gets called when a client request is received.
Read on…

Creating a Staging WordPress Blog for Testing

Over the past few months, I’ve been meaning to create a staging WordPress blog that is an exact replica of my production OMNINOGGIN blog so I can test major feature changes before releasing them to my production site.  I have to admit that there are many other interesting things to spend time on (see also: Make Popularity Contest Work with WP-Super-Cache and NowThen Photo Display WordPress Plugin) so I have been lagging at getting this task done.  Fortunately the WordPress 2.5 released was enough to motivate me to get this done.  My goal in this post is to provide a step-by-step set of instructions (or checklist) for getting this task done.  I run Apache 2.2.8, MySQL 5.0.51a, and PHP 5.2.5 on a FreeBSD 7.0 machine that I have complete control over.  Keep in mind that these steps will vary depending on how your blog is configured.  It is a good checklist nonetheless so without further ado:

Read on…

Make Your WordPress 10X faster During Traffic Storms


This tutorial will augment the technique of automatically enabling WP-Cache during heavy load with the ability to switch to a low-bandwidth WordPress theme at the same time.

Few reasons to do this

1. WP-Cache messes with your site statistics, so you do not want to leave it on when your site is not being hammered.
2. You don’t want to use a bandwidth efficient theme all the time because it’s not pretty-lookin’.
3. During traffic storms (e.g. Digg Effect), every 1/100 second optimization tweak counts.
4. If you host your site on a shared host, you will most likely have a bandwidth quota. Switching to a leaner theme conserves your bandwidth (duh!)
5. If you host your site on a home connection, your upload is not up to par with most hosting services, so you need to use that small pipe efficiently.
6. Each “IMG” tag, even if it’s a 1×1 pixel gif, requires an HTTP request to your web server. If you have 10 images on your page, and 10 users are loading your page, that’s 100 simultaneous calls to your server already. Leaner themes usually means less/no images, giving Apache some break.
7. If you’re server is non-uber, you don’t deserve to administer it.
Read on…

Automatically Turn on WP-Cache During Traffic Storms


I am a semi-fan of WP-Cache. On the good side, it reduces strain on apache by staticising WordPress pages. On the bad side, it messes with my site statistics and makes development hard (I always forget that the page I’m working on is being cached). I like my statistics, but what if I suddenly get a traffic storm? If my site gets dugg, there is no time to worry about statistics. I would need all the help I can get to serve pages efficiently. This is why WP-Cache should be off by default and automatically turned on during traffic storms. Read on…

WP-Cache, the Untold Way to Set It Up

WP-Cache is a WordPress plugin that improves your WordPress speed by caching a static version of each dynamic page request and deliverying that static version for subsequent requests to that page. This in combination with WordPress internal cache, Apache cache, eAccelerator op code cache, and Varnish proxy cache provides the ultimate setup to combat traffic storms if your article gets dugg. *Note* that there is also a method that helps you turn on WP-Cache on demand (only during traffic storms), but I will discuss that in a later article.

If you’ve ever tried to install the WP-Cache plugin for WordPress just by uploading to the wp-content/plugins directory and activating it via WordPress Plugins administration, then you know that 99% of the time that method will not work because of some file permission problems.

Here is the proper way to do it: Read on…

Recapping: Setting up a FreeBSD 6.2 Web Server

I hope I can get some part-time consulting jobs to do this optimization for small businesses. All in all, it doesn’t seem too hard to do and I enjoyed doing it. If you run into a problem just google it for the answer. Anyway, here is the recap of the steps I took to set up my FreeBSD 6.2 Web Server.

  1. Installing OS
  2. Setting Up Apache, MySQL, and Other Services
  3. Migrating WordPress from WinXP to FreeBSD
  4. Optimizing Apache
  5. Optimizing MySQL
  6. Optimizing PHP
  7. Proxy Caching
  8. Optimizing WordPress with WP-Cache
  9. Keeping Your FreeBSD Ports Up-to-Date Effortlessly
  10. Setting Up Sendmail on FreeBSD 6.2

Setting up a FreeBSD 6.2 Web Server: Proxy Caching (Part 7)

Okay I lied, eAccelerator gives a pretty darn high ROI, but setting up a proxy cache gives a comparable or higher ROI. I chose to use Varnish as my proxy cache.

Once installed, Varnish will keep a cache of all objects requested by internet users (e.g. post-generated PHP pages, CSS, javascripts, images) with the goal of off-loading some work from your web server (remember: we won’t want big Apache to do the work only if it has to). Also Varnish takes full advantage of the OS’s virtual memory and advanced I/O features on FreeBSD 6.x making it the optimal choice for my setup.

There were many confusing instructions on the web about how to configure Varnish. Here are the steps I took to setting up Varnish for a signal machine running both Varnish and the web server: Read on…