Quite a few of our customers are still using FrontPage to design and upload their Web sites, though. We’re starting to see more and more problems from customers who have upgraded to a new computer running Windows Vista or Windows 7 but can no longer run FrontPage. (Sometimes their old computer just suddenly crashes and can’t be recovered.) Their old computer probably had a copy of FrontPage installed by the manufacturer, but their new computer doesn’t.

It can be difficult or impossible to get FrontPage running on a new PC if you can’t find the original installation CDs, or you aren’t licensed to use FrontPage on the new PC. In some cases, the old FrontPage software doesn’t install or work well on the latest versions of Windows. In these situations, you can’t even open the old FrontPage files on the new computer.

If you are still using FrontPage, you should start planning for when you are going to move to a different program. You might want to move to Microsoft’s newer program, Expression Web. Or you might want to join the large number of people using Dreamweaver. If you’re looking for a free program, you might want to try Nvu. The popular (and free!) WordPress can be a good choice, too — it’s commonly known as a “blog program”, but you can also use it to create a Web site with normal pages.

We strongly encourage existing FrontPage users to start planning their move to a different program. If you don’t plan the move yourself on your own schedule, you may find yourself stuck in a situation where you’re no longer able to edit your site using the old FrontPage software.

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.

A technical explanation for why this caused trouble is that the sudden large number of disk writes caused by new eAccelerator files made the Linux kernel decide that disk “buffer” memory was so full that all disk writes needed to happen “synchronously”.

That caused the MySQL database to start writing temporary “filesort” data to the actual RAID array on the server, instead of just storing those files in memory (as Linux usually does for files that exist for less than a few seconds before being deleted). Some of our servers handle hundreds of MySQL queries a second, and the extra disk writing load overwhelmed the “/tmp” filesystem, slowing down MySQL dramatically.

We’ve made three changes to prevent this from happening again:

• We’ve modified our Debian eAccelerator package to not remove all the cached files at once during a future upgrade.
• We’ve changed where MySQL stores temporary files. It now uses “/dev/shm” shared memory instead of “/tmp”. (Ironically, “/tmp” used to be shared memory on our servers, but we had to change it to a real disk-based filesystem because it would fill up with large amounts of data if the server wasn’t restarted for months. That past experience gives us some assurance that this MySQL change won’t cause problems, though — and in fact, we’ve been testing this change on a small number of servers for some time anyway as a general performance improvement.)
• On our servers that support it, we’re now using “AMD64/Intel 64″ kernels that allow much larger disk memory buffers before the kernel switches to synchronous disk writes, avoiding the problem a different way. Some servers are already using the improved kernel (sadly, not these three servers), and all of our 64-bit-capable servers will be using it after the scheduled maintenance this coming Saturday.

We sincerely apologize for this incident. Don’t hesitate to let us know if you have any questions.

No e-mail will be lost, of course; incoming mail on those servers will just be slightly delayed.

We apologize for the inconvenience this causes. This maintenance is necessary to install an updated “kernel” on all of our servers for security reasons.

Update: The maintenance was completed by 11:10 PM with no more than three minutes of “downtime” per server.

There are many sources of missing image file references. Themes and plugins can generate them. Your site may be missing a favicon.ico file. Some RSS news readers make a lot of requests for files named apple-touch-icon.png and apple-touch-icon-precomposed.png, which most Web sites do not have. Check your Web site’s analytics report (such as AWStats) or raw log files to see what image files are missing from your site.

If you’re a Tiger Technologies customer running WordPress, you already benefit from a global rule we implemented for missing favicon.ico files (as discussed in a previous blog post). We’ve also recently updated our WordPress Performance page with extra tips on returning faster “404″ results for other missing files such as robots.txt and for all missing images.

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.

WordPress also now provides a “health check” plugin that shows you whether your hosting company is ready. If you run it on one of our servers, you’ll see:

(By the way, our versions of PHP and MySQL also include security updates from later versions.)

This isn’t an outage on our end; these visitors are also unable to reach other sites that Comcast routes through Global Crossing (and not related to us), such as www.globalcrossing.com. It’s something Comcast and Global Crossing need to address.

We’ll continue to monitor this issue closely and post an update when we’re confident that it’s been resolved.

By the way, if you ever find that you’re unable to connect to our servers (or anyone else’s), a very useful site is CheckSite.us. It shows you whether the destination servers are down, or whether the problem is just a local routing problem that isn’t affecting most other people.

Update 9 AM PDT August 13: According to our monitoring systems, Comcast resolved this shortly after our post, and the problem has not recurred in the ten hours since then.

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!

It turns out that wget has a security bug that needs to be avoided. As a result, the behavior of wget has changed in some situations. If you use wget (most of our customers don’t), you should be aware of this change.

The problem

If wget requests a file with an innocuous name from another server, but that server replies with a “redirect” to a file with a malicious name, wget will save the file with the malicious name instead.

As an example, imagine you run this command and expect wget to save a file named “feed.rss” at the top level of your site:

$ wget http://example.com/feed.rss

However, the remote server redirects the original request to a malicious file at:

$ wget http://example.com/index.html

In that situation, wget will actually save the file as “index.html” on your site, potentially changing your home page to something awful. More complex attacks that actually run malicious code are also possible.

The solution

A wget security update that we installed today changes how it handles a redirect. By default, it now saves the file under the original name (“feed.rss” in the example above) instead of a new name the server provides.

This change will not affect most people who use wget. However, if you do use wget to request URLs that redirect to a new name, and you rely on wget saving the file using that new name despite the security risks, you’ll need to start using wget’s “--use-server-file-name” option to keep it working the way you expect.

As a result, Web site service and the ability to read incoming e-mail for some customers will be unavailable for approximately five minutes at some point during this maintenance “window”.

No e-mail will be lost, of course; incoming mail on those servers will just be slightly delayed. Customers using other servers will not be affected.

We apologize for the inconvenience this causes and for the short notice. Restarting these servers now is necessary to prevent a potential issue that could cause problems with these servers if a RAID disk needs replacing in the future. (We hope to provide technical details in a future post. The problem — an issue with the GRUB bootloader — is interesting and the solution would be useful to others.)

Update: The maintenance was completed with less than 5 minutes “downtime” per server.