We’ve added a new feature to hosting accounts: Live, realtime access to the Apache Web server “error log”, both in the “My Account” control panel and as raw files you can access through FTP/ssh/etc.
To view the most recent 200 lines of the error log, login to the control panel (having trouble?), click “Statistics and Logs”, and look at the new “Web site error logs” section.
To download the full raw error log files, see this page.
We hope you find this useful!
Recently, several customers have told us that pages on their Web sites have been modified without their knowledge. Upon investigation, the customers found their computers had been infected with a virus that steals saved FTP passwords, such as the “Gumblar” or Trojan.PWS.Tupai.A virus.
We’ve taken a step to protect you against this problem (described below), but it’s wise to protect yourself, too.
We recently had a server that twice “crashed” and needed manually restarting. We’ve identified the cause of that problem — an apparent bug in Linux kernel version 2.6.26 — and made some changes to ensure that it doesn’t affect our customers again.
However, we didn’t find any information about this problem when searching the Internet, so we’re describing the details here in the hope that it helps someone else.
We host some pretty high-volume WordPress sites, and one of the questions that occasionally comes up is “How can I make WordPress faster?”. That’s really just another way of saying “What part of my WordPress site is slow?”, which translates to “What requests are using a lot of CPU time?”
This question is surprisingly difficult to answer, particularly because we encourage customers who run busy WordPress sites to use FastCGI and caching. A single FastCGI process can handle lots of different PHP requests, so it’s hard to break down which individual request used what amount of server resources.
To solve this problem, we recently patched our version of PHP to optionally log the CPU time used by each request, even under FastCGI, so we could see what was really happening (patch available here).
What we found was unexpected. On some busy WordPress sites, 20–30% of the CPU time was being used to handle requests for “favicon.ico”. What the deuce?!
We’ve made a technical change to the way our servers handle SSL connections (we’ve disabled 40 bit and 56 encryption ciphers). The change shouldn’t affect anyone, but we’re describing it here just for the record.
We’ve updated our servers with a Perl security bug fix and a Ruby security update.
The updates fix only security bugs, and customers should not notice any changes in how the Perl or Ruby programming languages work.
Between 10:30 PM and 11:59 PM Pacific time this Saturday night (December 6), all Tiger Technologies servers will be restarted. As a result, customer Web sites and e-mail service will be unavailable for about five minutes at some point during this period.
No e-mail will be lost, of course; incoming mail will just be delayed for a few minutes.
This brief maintenance is necessary to upgrade the operating system “Linux kernel” to a newer version for security reasons. We apologize for the inconvenience this causes.
Update: the maintenance was completed with less than five minutes of downtime.
We’ve updated the Perl programming language on our servers with a security update.
The update only fixes one security bug, and customers should not notice any changes in how Perl works.
We’ve enhanced our e-mail service with support for manual “reject” and “allow” lists.
The reject list lets you add individual e-mail addresses, entire domains or IP addresses from which incoming e-mail should always be rejected. The allow list lets you add senders from which e-mail should always be accepted.
We’ve upgraded our Apache Web server and MySQL database server software to cover recent minor security updates. Customers should not notice any changes.
