Deerfield Hosting, Inc.

High Performance Web Hosting

Your Domain and Google Search

by

We are often asked about the results when a domain name is typed directly into a Google search box. It’s helpful to understand a little bit about how Google searches work. It’s a gigantic topic and we’re only dealing with one small corner of it here.

What Google tries to do first is find things other people have searched for. When you click on a particular result, they record the click. The idea is that since you clicked on it, the description probably was a match for what you wanted. Next time a similar search is done, your click tends to move that result up to a higher position.

Next, people often make typing mistakes and Google attempts to correct them. In theory, this saves the customer from wasting time and needing to re-type and saves Google from wasting resources on bad searches.

It gets a lot more complicated than that, but that’s the beginning of how it works.

When you type a domain name into a search box, Google is likely to recognize it as a domain name. But the same logic will be applied, with results you may or may not like. I was just asked about the domain name miniatureangels.com. Google returned, “Showing results for miniature-angel.com” – NOT what was wanted. Apparently that’s a popular site.

Unfortunately there is nothing to be done about this. We sometimes hear from customers who are upset that something like this is happening to them. There isn’t anything magical or mystical going on and it wouldn’t matter where or how your site is being hosted. Website content may have some effect. It has nothing to do with hosting at all.

I tend to regard typing a domain name into a search box as a dumb thing to do. After all, if you are looking for the web site for a domain there is no need for a search. Just go there. The trouble is, huge numbers of people where introduced to the Internet by simply sitting down at a computer with a Google search box in front of them. They typed in what they wanted and found it and that is the end of that. The principles of least thought and least resistance have coincided and that is what they will do evermore.

Our customer who owns miniatureangels.com wants to replace that with miniatureangelsfarm.com. Probably a good idea.

“Secure” Email

by

The content of your emails is not as secure as you may think it is.

When you set up an email account on your computer (or tablet or phone) you have the opportunity to specify encrypted connections. The trouble is, email is a store and forward system. Unless you know every server your mail will traverse, you can’t know that it will be transmitted encrypted from server to server.

You are also subject to trusting the mail server administrator of each server it traverses, sometimes as many as 4 or 5. While the transmission from your machine to the first server may be encrypted, subsequent transmissions may not be.  What is more, at each server it will be stored in plain text format.  It is trivial for any mail server administrator to retain a copy of your emails.  It is also trivial to scan plain text files looking for key words such as the word, “password”.

If you want what is in your email to be secure, what you need to do is encrypt the content, not just the connection.

One commonly used tool for this purpose is PGP. That stands for “pretty good protection”.  Encryption is a huge subject, but there tools in the cPanel control panel to help you get this done.  More information about PGP and this subject in general can be found HERE.

Having said all that, there is still 1 good reason to set up secure (encrypted) connections from your email client to your hosting server: passwords.  Secure connections are established before your password is sent and that means it is sent encrypted and not as plain text.

High Alert

by

This morning, February 19, 2013 at about 3 AM an email arrived which set off alarms. Monitoring software on one of our servers had discovered a suspicious file: /lib64/libkeyutils.so.1.9.

Investigation revealed that this file is part of a server compromise. How the attacker is able to put this file in place is as yet unknown. What we do know at this point:

  • RedHat Enterprise servers including CentOS and Scientific Linux are affected.
  • Logins via SSH are recorded, including login name and passwords.
  • Other logins, such as to email and cPanel are not affected
  • Only 1 IP address has yet been recorded as the recipient of information
  • More than 10,000 servers have been affected so far
  • The goal of the attacker has so far been limited to sending spam email

To mitigate the threat we have set up scanning to find and remove suspicious files at 5 minute intervals and send alert emails when any suspicious file is found. This will trigger further investigation.

Since the source of the infection is unknown, the only prudent course is to assume the worst. We have set up firewall rules to prevent communication with the single IP address known to be receiving information. However, it would be naive to assume that this walls off the problem.

If you notice that your service is running more slowly than usual, the likely cause is actions we are taking to deal with this threat. It is possible that your service will be interrupted. Some counter measures are disruptive. For example, when server load becomes very high it can appear that a server is down because response is so slow. The fastest way to regain control in this case is a reboot.

If you call or email and do not get an immediate response, the reason is apt to be that we are working on a problem. We sometimes need to choose between solving a problem and explaining to 20 or 30 people that we are working on a problem. Frankly, it makes more sense to fix now and explain later.

If you observe problems with your service while this threat remains active, please be patient. We are all over it.

Automated Email Checking

by

Setting your email client (MS-Outlook, Windows mail, Thunderbird, etc.) to check email too often is abuse. Sometimes it’s accidental abuse. It’s common for unstable programs like Microsoft Outlook to become corrupted and go wild, checking incessantly.

Recently we implemented a system to track (among many other things) email logins. When too many logins to a specific email account exceed limits, the IP address the logins are coming from is temporarily blocked. The reason for doing this is performance. Our servers typically have 5,000 or more email accounts on them. 20 or 30 abusive accounts is not a large percentage of the total, but can significantly reduce performance for everyone using a server.

If your ability to send and receive email is experiencing intermittent problems, this may be the reason. We can check this for you if you submit a trouble ticket. Our ticketing system automatically includes your public IP address which we need to do this. Click on “Orders – Tickets” above left, then “Submit Ticket”.

All this begs the question, why you are doing this in the first place. All you really need to do is click on the send/receive button in your email client and you will have your email. If you have a broadband connection, which is most often the case, you will almost certainly have your email within 2 seconds. Most people who have automatic checking turned on will do this anyway! If you have a slow connection, by all means do automated checking to save yourself some time.

Otherwise, wouldn’t you rather see faster performance of your server? If you actually think you have another reason for automated checking, let’s hear it!

Hard Drive Failure !

by

100% uptime is impossible. All we can do is get close.

Last week 2 hard disks failed (simultaneously !) in node 2 of cluster 2. Besides being backed up in real time on a second cluster node, each node is running RAID-5 with hot swap drives. A single drive can fail and be replaced with no down time. But if a second drive fails, it’s fatal.

It wasn’t a clean failure and the performance of the fail-over system and failure reporting was less than perfect. Initial symptoms seemed to point at network card failure. The cluster software did fail over properly, but we had to clean up some databases. Some sites were not in good shape for 2 or 3 hours.

The next day, the remaining node was bombarding us with emails about the failed node. I had to shut everything down and power it back up outside the cluster. Total down time with this was probably 10 minutes. This was necessary because otherwise we could easily miss emails about failures of which we are not yet aware. The signal to noise ratio was way too high.

Monday we replaced all the hard drives in the failed node, re-installed the operating system and all the cluster software and began the process of manually syncing the drives from the node which was still in operation. Synchronization completed overnight last night, Tuesday night.

This morning at 5 AM I began the task of moving services back into the cluster. I will spare you the details, but it’s a nasty and error prone process. All the safeguards, checks and balances in the cluster software really get in the way while doing this. Sites were up and down several times. My guess at total down time today was something like 30 minutes.

Everything is completely back to normal now.

This was the first major real world test of the clustered live fail-over system we put in place 18 months ago. I’m not totally happy with it. Previous tests were done by pulling plugs – total failures. In that situation, performance was flawless. Down time was so short no one noticed. Real world failures are usually messy like this one was. The fail-over system worked, but it needed a little help. It was still a big win compared to re-installing a server and restoring backups. That could take a day or more.

There is a recurring pattern with problems like these. There is a period of a few days or a week during which problems come up and quickly or gradually get ironed out. These periods in retrospect feel like they are much longer than they really are because the worry and frustration when a server is down is intense. An hour is remembered as half a day. Related problems recurring a few times over several days is remembered as lasting a week or more. It’s human nature. Problem periods are followed by long periods, many months or a year during which everything runs smoothly.

If you look at our up time in longer periods it’s actually very good. It’s something over 99.99%. My perfectionist nature often makes me lose site of that. But nobody does any better so it’s worth a reminder.

10 YEARS !!

by

The domain names deerfieldhosting.com and deerfieldhosting.net were registered on November 16th, 2002.

A lot has changed since then.

We had a reseller account on a server which was overloaded and provided terrible service.  BUT, the pay per click advertising was working.  The initial $300 was getting recycled over and over.  The revenue from new signups was slightly more than the advertising cost.  Since it was clear that the business model was working we took the plunge and rented our first dedicated server.

We were running a control panel called Ensim, having taken a cue from the former account.  It was (is?) so bad that the number of accounts you could add to a server was constrained not by how busy the sites were, but by the overhead imposed by the control panel itself.  And I mean by a factor of 10.  The control panel hogged up server resources at a rate easily 10 times the sites.

We limped along with Ensim for several years, adding server after server to get good performance.  What a relief it was to ditch it and move to cPanel and FreeBSD.  It felt like I’d gone to heaven.

Of the first 5 customers to sign up, we still have 3.  The other 2 are no longer on the Internet.  I like to think that means we are doing something right.

Anyway, Happy Birthday Deerfield Hosting !!