If you use WordPress blog software on your site, be sure to upgrade to WordPress 3.0.2 as soon as possible. The upgrade contains an important security fix for a vulnerability that allows any WordPress “author” to become an “administrator”.
Although all WordPress users should upgrade right away, we’ve added security rules to our servers to protect our Web hosting customers who haven’t yet upgraded. Other people may find the rules useful if they use mod_security on Apache Web servers. The rest of this post contains more technical details.
Read the rest of this entry »
A recently published Firefox add-in named “Firesheep” can be used by “hackers” to easily hijack the connection of any nearby WiFi users visiting many popular Web sites such as Facebook, Twitter, or Hotmail. This vulnerability is a basic artifact of the way the Internet works. In order to prevent this problem, these sites will need to properly implement SSL (https) security.
Read the rest of this entry »
Google has announced that they’ve created a nifty new Apache Web server module called mod_pagespeed that can speed up some Web sites.
We’ve been asked if we’re going to offer it, and the answer is “probably, but not yet”.
Read the rest of this entry »
We’ve fixed a bug in our Webmail system that could, in rare cases, make Japanese language symbols display incorrectly. This change shouldn’t affect anything else, but as always, feel free to contact us if you have any trouble.
Read the rest of this entry »
When we store older Apache Web server access logs for your site — those that are more than two months old — we re-compress the original logs into single monthly files. These take up less disk space for your account when you have a lot of them. (We have some customers with log files going back more than ten years!)
Until now, we’ve re-compressed these files using gzip compression. However, we’re going to switch to a different modern compression format, bzip2 compression, which reduces the size even more. The resulting files are about half the size of gzip.
Read the rest of this entry »
Even if a Web site hosted with us doesn’t have an SSL certificate, our servers used to accept improper secure SSL connection attempts that start with “https://” instead of “http://” in the beginning of the URL (note the extra “s”). We’re changing that.
Read the rest of this entry »
Three of our Web hosting servers (amy, flexo, and leela) experienced high load earlier today that caused some customers to see “503 errors” on their Web sites for a few minutes.
This was caused by an upgrade to the eAccelerator PHP caching system that removed all the cached files at once, which doesn’t normally happen.
The problem has been permanently resolved and will not recur.
Read the rest of this entry »
WordPress installations handle missing image files very inefficiently by default, running the entire WordPress script to build a custom “404 Page Not Found” page rather than simply letting Apache return an immediate default “404” response. Running the WordPress script when not necessary is a huge waste of processor time. For example, WordPress might be able to only process 8 requests per second for a missing image when WordPress generates a custom “404” page, but Apache can return process over 1,000 raw “404” responses per second. If your Web site contains references to missing files, this default WordPress behavior can be driving up your CPU usage unnecessarily. We’ve seen poorly-configured Web sites spend a significant portion of their CPU time processing missing images.
Read the rest of this entry »
The WordPress folks recently announced that next year’s planned WordPress 3.2 will require at least PHP version 5.2 and MySQL database version 5.0.15. If you use WordPress, you might be wondering if this will be a problem.
Well, “Good news, everyone!” If you use Tiger Technologies to host your WordPress blog, you’re all set: we already use later versions of PHP and MySQL than that.
Read the rest of this entry »
Google FeedBurner is still hammering several of our customer sites with over 5,000 requests for the same URL per hour. We’ve blogged about this before. We’ve also reported it on the FeedBurner Help Group and seen similar reports from others going back to 2008.
Here’s the relevant log entries from a site that FeedBurner hit 5,836 times in one hour this morning (up to 8 times a second). There’s nothing unusual about the site: it’s on a single IP address with a single hostname, and the feed doesn’t change often.
Some sites run a PHP script for every request, so this FeedBurner problem generates high load for no useful purpose at all.
Google: Please fix this. Thanks!
