Preventing FTP Connection Issues

A common issue we see in our web hosting support tickets and calls is clients accidentally triggering our anti-DoS attack prevention technology, triggering a 5 minute IP ban on their computer.

This technology helps prevent both small and large-scale attacks on our network by limiting the number of simultaneous connections from one IP address to a reasonable amount generally encountered during normal web, e-mail, and FTP traffic.

Unfortunately, the default settings on many FTP clients cause a large download or upload to make too many active connections, far more than is usually encountered in a regular FTP session, thus triggering the ban accidentally.  This guide will show you how to configure your FTP client to avoid this.  The examples below assume you’re using FileZilla, but the settings should be similar in other FTP clients.

In FileZilla, go to the Edit menu and click Settings, then click the Transfers section on the left hand side to bring up the following menu.  In this, make sure that the maximum simultaneous transfers is set to no higher than 2, and concurrent uploads and downloads are set to 2 as well.

Filezilla Connection Settings

You’ll need to adjust one other setting in FileZilla.  In the site profile you use to connect to your site, click on the Transfer Settings tab and adjust the number of simultaneous connections to no more than 2 and save the profile.

FileZilla Connection Settings

Using these settings you should not accidentally trigger our anti-DoS protection measures.

If you have any questions, please let us know.

Website Protection Scanner

I’d like to take a moment to introduce a new service that we’re proud to roll out.  Our new Website Protection Scanner service scans your website daily for security vulnerabilities and displays a secure seal that lets your visitors know that you take your website security very seriously.

The OCS Website Protection Scanner performs an initial scan on your site and checks for vulnerabilities and security issues.  Once our scan is done (typically within 24 hours), we present you with a full report highlighting any issues that need attention with specific help on fixing them.  If you need assistance with any particular issue, our security support team is available via phone or e-mail to give you the advice you need to fix it.

You might expect a service like this to be expensive, but the OCS Website Protection Scanner service is only $4.99 per month.

To learn more or to get started securing your site today, please contact us or visit our Website Protection Scanner page.

Your Domain Name Should Be Your Own

Every month or two I help a client out with reclaiming their domain name from a previous hosting company, a disgruntled employee, or an uncooperative previous webmaster. It’s an uphill challenge that isn’t necessary to go through, and rarely has a happy ending.

I am blogging about domain registration today because I helped a client today try to get their domain transfered from their previous hosting company, but was ultimately unsuccessful. They went through months of trying to get an approval on the transfer from the previous host.  They ended up registering another domain name to avoid the problem. It is a very unfortunate situation, but is completely preventable.

You can protect yourself from this hassle quite easily. Simply have your domain registered in your name, under your control. All OCS Solutions hosting customers enjoy this, and if you order your domain name from OCS Domains, you can fully control your domain – including changing your registration information (WHOIS), nameservers, DNS, and other vital data concerning your domain name anytime you wish.  It’s under your complete control.

If you are an OCS hosting customer and had us register your domain for you, we’ll be glad to make changes for you at any time – just contact us.  However, we can also put your domain in your own domain registration account that allows you to fully control nameservers, DNS, WHOIS info, and even transfer the domain to another registrar.  If you’d like us to enable this domain registration control center for your domain(s), just let us know.  We’ll be glad to do it at no charge!

If you don’t host with us, please make sure you’re in full control of your domain.  If you can’t change your own nameservers or WHOIS information, contact your hosting company to see how you can do that if you wanted to.  It’s an important piece of information you need to know to manage your internet property address.

OCS Announces Django and WSGI Support

We are delighted to announce our support for hosting Django applications on our shared hosting servers, effective immediately.

Our initial demand for Django was very low, and since we have a strong focus in hosting Ruby on Rails and PHP, our Python/Django support was limited.  However, we have recently developed a deployment procedure for Django applications and have documented it in our wiki article titled Deploying a Django Site.

As an added benefit, we also now support the WSGI module for Apache, allowing the hosting of non-Django applications, such as Zope, CherryPy, and TurboGears, to name a few.  Our documentation only covers Django currently, but we look forward to adding more documentation on other Python-oriented frameworks soon.  In  the meantime, we’ll be glad to help with any issues you have deploying non-Django Python framework-based applications.

SEO Dedicated IP Myth Still Around

I’d like to take a moment to address a very common misconception that is very old, but still around today.  Essentially, the myth is that a site with a dedicated IP address will do better than one with a shared IP address with other site in search engine result pages (SERPs) because search engines associate sites by IP address and not by domain name.

Well, this post is about busting this myth, although a bit of history first explains why it used to be true.

I remember (unfortunately) the days before virtual hosting, where every web site had its own server.  In fact, the www prefix before most URL’s now (i.e. www.ocssolutions.com) comes from the fact that sites used to have a server handle the website, www, and then have other servers that handled things like FTP, E-mail, etc.  The reason for this was twofold – primarily the software and configuration techniques weren’t around to virtualize these things, but the speed of computers at that time meant that a web server could easily overload a mail or FTP server, thus the need to separate them into different physical machines.

This was quite some time ago.  About 10 years ago, search engines became smarter as to how sites were hosted, because IP addresses were running short and hosting companies out of necessity and out of providing a reasonably priced shared hosting package started hosting multiple sites on the same IP using Apache’s virtual hosting technology.

When I say search engines, I mean Google primarily, because they have by far the largest market share.  That said, other search engines like Yahoo, Bing (previously known as Live, then MSN search before that), and Teoma (powering Ask, among others), refer to sites by domain name and not IP address as well.

In a Slashdot interview with Google Director of Technology Craig Silverstein, Craig states:

“Actually, Google handles virtually hosted domains and their links just the same as domains on unique IP addresses. If your ISP does virtual hosting correctly, you’ll never see a difference between the two cases. We do see a small percentage of ISPs every month that misconfigure their virtual hosting, which might account for this persistent misperception–thanks for giving me the chance to dispel a myth!”

That’s about as authoritative as it gets on the subject, directly from a Google management-level employee.

The misconfiguration of virtual hosting that Craig is referring to is very rare nowadays, because technologies like cPanel, Webmin, and others prevent this sort of misconfiguration in most cases.  Sites hosted by OCS Solutions are configured correctly, and we have many sites hosted on our shared hosting that enjoy high search engine rankings and good SERP coverage.

So why does this myth persist?  Well, in a subject as un-documented as SEO, it’s an easy place for myths like this to flourish and persist.  Even though Google has published guidelines on SEO and website content, people still insist that doing certain things that haven’t been proven or were once true but aren’t help.  It’s easy to see how this still goes on, but myths like this are fortunately becoming less popular.

I still see this myth from time to time pop up still though, and I wanted to make a post for everyone on the subject.  Don’t just take my word on this though, examine the interviews and documentation that Google provides on the subject.  Check out the long thread on SEO Watch Forums and read it throughly, not just the first few replies.

There’s only one situation where sharing your site with others would potentially (and that’s potentially with strong emphasis) harm your rankings, and that would be if there were many sites on that IP that performed unethical techniques like cloaking, link farming, and other nefarious tactics.  You don’t have to worry about that with our hosting though, because we routinely check for this.  Hosting a site at OCS Solutions (along with many other web hosts) that engages in deceptive SEO tactics is not allowed and actually against our TOS.  We enforce this because we want to ensure you have the best possible environment to succeed without being potentially harmed by anyone else on the same machine.

I hope this helps clear this issue up.  If you have any questions about this topic, please feel free to contact us, or leave a comment.  Like I said, don’t take my word on the subject, do some independent research on it if you’re concerned.  When searching though, try to find more recent articles and posts over older ones, and stick to more authoritative sources, such as Google themselves, or top SEO experts that use approved and above-board positioning techniques.

Bandwidth Upgrades to All Shared Hosting Plans

I’m delighted to announce that we have increased the bandwidth allotments on all shared hosting plans, effective October 20, 2009.  On some plans, the bandwidth limit has been nearly doubled, and on others it has increased by at least 50%.

You can find the new bandwidth limits on our shared hosting page.

We are applying these changes to all servers, but some servers will be upgraded before others. We intend to have all upgrades complete by November 1st, 2009.  If you find your account hasn’t been upgraded yet and its after November 1st, 2009, please open a ticket and we’ll be glad to perform the upgrade.

New Git Documentation

We have created a new guide on using Git with your OCS Solutions hosting account on our support wiki.  This guide gives assistance with creating, managing, and updating Git repositories on your hosting account.

It provides a practical example on how to use Git to manage your website hosting files.  You can use Git to manage the files in your ~/public_html folder for PHP and HTML-based sites, or your ~/rails_apps/yourapp folder if you have a Rails-based site.  Also included are instructions on hiding your .git folder from prying eyes if you use it to manage your website, enhancing your site security.

The advantages that Git has over Subversion are that it is typically faster to use, uses less network bandwidth when transferring data from one repository to another, and its decentralized, meaning branching is easier and you don’t have to rely on a central server for updates.  I personally find Git a better overall experience than Subversion because of the way the entire repository sits on your computer and on other locations your code exists, providing complete redundancy and easier portability for coding on the go.

If you haven’t given our Git support a try, we encourage you to.  You can learn more about Git at the official Git website.

Using Ruby 1.9

If you’d like to use Ruby 1.9.x in your OCS hosting account, you can follow the guide we have put together on the OCS Support Wiki called Installing Your Own Ruby Stack.  It shows you how to install the entire Ruby stack, including your own set of Rubygems.  The only downside to this is that you must use Mongrel, you cannot use Passenger.

We are however working on a setup that will allow you to run Nginx+Passenger both on our cPanel and Webmin servers.  We’ll announce it here when complete (hopefully very soon), and if you’re interested in beta testing please contact us.

Passenger 2.2.2 Upgrade

On select production cPanel servers, we have upgraded to Passenger 2.2.2.  This new release offers a variety of new features and substantial performance improvements, but we’ve had to make one slight change to our Passenger deployment routine.  Due to this, you’ll have to add a line to your .htaccess file in your public folder in your Rails app with the contents:

PassengerAppRoot /home/user/rails_apps/yourapp

Replace “user” with your username and “rails_apps/yourapp”  with the path to your Rails application. 

On the servers we have deployed the upgrade to we have added this to any existing .htaccess file or created a new one with that line in it.  However, if you use Subversion or Git repository, you’ll need to add this change to it so that the next time you do an update this change will be preserved. 

You have not made this change already, please do so as soon as you can.  This will ensure upgrades on the rest of our shared hosting cluster will go smoothly.

On the off chance that your Rails application isn’t functioning correctly, make sure the above line is in your .htaccess file in the public folder of your Rails application.

RAM Upgraded on Shared Hosting Plans

Effective March 1st, 2009, we are upgrading our shared hosting plans to include more RAM.  This really applies only to customers who use Ruby on Rails, Django, or another long-running user-created process.  This extra RAM will make more room for your application and give you more breathing room to avoid running over on your plan.

Many have asked our policy on RAM usage and how we enforce the limits.  All of the RAM limits on shared hosting are soft, with a high hard limit to prevent a runaway process with a memory leak to cause problems for other accounts.  If your Rails application goes over your limit by 5 or 10% we do not typically mind.  Since we don’t oversell, the limits are there to help keep resources free for all users on shared hosting plans.  If you start to use too much RAM over the buffer zone we allow for all accounts, we will notify you with options on how to proceed.

These new limits will take effect both on new and existing accounts.