Top Nav

Redirect With Query String

Let’s say you have URL like this:

that you want to redirect to a new url:

This is easily accomplished with a rewrite rule:

But what if the source URL has a url parameter like:

In this case we need to use  RewriteCond to match the url parameter:

Notice the question mark (?) at the end of “/new-url?”. This causes the query string to be discarded. If the question mark is not included then the redirect will go to:

If you want to keep the query string then you can explicitly add it with the QSA option like:

Also in Apache 2.4 and latter the QSD option can be used to exclude the query string with the same effect at the trailing question mark:




XFS Requires “inode64″ On Large Filesystems

Recently ran into a problem with a large distributed GlusterFS filesystem. All of a sudden we started getting errors about no free space on device when trying to write files. The individual bricks on the distributed GlusterFS filesystem were hosted on XFS formatted partitions. After some investigation we found that when the size of the brick’s XFS filesystem exceeded 16TB the “no free space” errors started.

The solution was to add “inode64″ to the mount options for the XFS partition. The XFS FAQ states the following:

By default, with 32bit inodes, XFS places inodes only in the first 1TB of a disk. If you have a disk with 100TB, all inodes will be stuck in the first TB. This can lead to strange things like “disk full” when you still have plenty space free, but there’s no more place in the first TB to create a new inode. Also, performance sucks.
To come around this, use the inode64 mount options for filesystems >1TB. Inodes will then be placed in the location where their data is, minimizing disk seeks.

After adding “inode64″ to /etc/fstab, we mounted and unmounted the filesystem and restarted Glusterd. Now the distributed partition is working correctly.


How-to Mitigate Bittorrent DDOS Attacks

You’ll know that you’re getting hit with a Bittorrent attack when the server slows down and you see log entries referencing:

Here’s a good article about one sysadmin’s struggle with this type of attack:

There are a number of possible strategies to mitigate this attack:

1. CloudFlare will block but it can take time to move DNS to CloudFlare and activate.

2. Create an announce.php file that returns an error like this:

This will use fewer resources then letting WordPress or other CMS return a 404.

3. Block in iptables with a rule like this:

Not sure how efficient this is on a high traffic web server.

4. Block in Apache config:

5. Block with fail2ban as described here:

Note that Plesk 12 has fail2ban built-in so this fix is easy to implement.

6. If traffic is limited to a range of IP addresses then block that range in any available firewall. For example we’ve defeated this attack in one case by blocking a class B range from China.

Other suggestions on blocking this type of attack are welcomed. Comment below and let us know if you’ve seen this attack and how you handled it.


Magento – List Applied Patches

You can view a list of patches that have been applied to a Magento site with:

You’ll get something like this:



How To Clear btmp File

Running low on storage. Check the /etc/btmp file where failed login attempts are logged. This file may be very large:

The file can be cleared like this:

Credit for this goes to Tournas Dimitrios who has a great article on btmp: