We’ve finished upgrading our network so that all of our customer Web hosting and mail servers have full, direct gigabit links to Internet peering points, with no 100 megabit Ethernet segments anywhere. This involved replacing old Ethernet switches and retiring old servers, and now we’re more than ready for the future.
If you use the WP Super Cache WordPress plugin (and you should, if you use WordPress), it has a settings page section titled “Expiry Time & Garbage Collection”. It sets the “Cache Timeout” to 3600 seconds by default, and warns that you should set it lower on a busy site.
That advice makes sense if you have a sudden surge of traffic to a single page. However, if your site is generally very busy across all pages (for example, if you have an archive of hundreds or thousands of posts that are constantly being indexed by search engines), we’ve found that you should do the opposite to improve performance: set it much higher. We recommend setting it to 172800 seconds (which is 48 hours). This can cut your CPU usage in half, which will speed up your site.
On Friday, a problem made our “My Account” control panel system unavailable for about three hours, and caused some other problems as well. We promised we’d follow up with more details.
If you use WordPress blog software on your site, be sure to upgrade to WordPress 2.8.6. The upgrade contains important security fixes. Upgrading is usually easy with the built-in WordPress “update now” feature.
Although all WordPress users should upgrade, 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.
We’ve updated the default version of Ruby on Rails on our servers to version 2.2.3.
Our Web hosting customers who use FastCGI have been seeing extra “500 internal server” errors in their logs and statistics since September 12.
The good news is that this is just a logging bug caused by a recent Apache Web server update. Visitors to your site are seeing exactly what they always saw, and there isn’t any problem besides the incorrect logging.
If you use WordPress blog software on your site, be sure to upgrade to WordPress 2.8.4 as soon as possible. The upgrade contains important security fixes.
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.
For the last several years, we’ve offered PHP versions 4 and 5 on our servers. This made sense when PHP 5 was new: Even though PHP 5 is faster and more secure than PHP 4, a small handful of scripts were originally incompatible with version 5, and we wanted to give customers a choice.
However, PHP 5 is now more than five years old, and the PHP developers declared version 4 obsolete in 2007. All our new customers have been using PHP 5 by default for more than a year, and we’ve received no complaints about incompatibilities.
No PHP script should require the obsolete PHP version 4 any more. Because of that, we’re beginning the process of removing it from our servers.
Zen Cart is a popular e-commerce platform that many of our customers use.
Unfortunately, the current version of Zen Cart has a bug that allows “hackers” to take control of the Zen Cart software, which includes making changes to the Zen Cart database and installing new files. “Exploits” that take advantage of the bug have started circulating widely in the last 24 hours.
An earlier blog post described how several of our customers got their personal computers infected by a new virus that has been spreading across the Internet. Initial versions of the virus spread themselves by reading a Web site’s FTP username and password stored on the PC, then downloading Web pages, inserting an “iframe” tag, and re-uploading the Web pages back to the server. As a proactive measure, we started scanning all uploaded files and stripping out any malicious “iframe” tags.
We are now seeing newer versions (commonly called “Gumblar”) which spread by inserting “script” tags with encoded JavaScript code. Because there are several variations of this approach, and because some legitimate commercial scripts use the same technique to hide their source code, we cannot perfectly identify and strip out these infections. Therefore, we will not automatically strip out the “script” tags from any upload file that looks suspicious.
