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.

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.

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.

Installing the Latest Binary Release

The solution is relatively simple though.  To start, uninstall any copy of Ruby you may have already.  This will reduce confusion as to what version is installed and where.  In this guide we’ll focus on 1.9.1 but  the instructions are the same for 1.8.7.

Go to the Ruby downloads page and select the 1.8.7 or 1.9.1 binary.

Unzip the file to C:\Ruby.  Then you’ll need to add C:\Ruby\bin to your path by following these directions:

1. Click on the Start Menu then right click on Computer and click Properties
2. Click Advanced System Settings
3. Click Environment Variables
4. Under System Variables, double click on the line with PATH in it and add ;C:\Ruby\bin to the end of it.  The semicolon is very important and must be before C:\Ruby\bin
5. Click OK and restart any command prompt windows

You’re now ready to run Ruby for Windows! You can install most gems in the usual way you would on Linux or MacOS with the gem command.

UPDATE – Missing DLL Files

There are some missing DLL’s for some necessary Ruby gems (including built-in ones), such as readline, sqlite3, and gzip.  I’ve compiled a ZIP file containing them, just put them in your C:\Ruby\bin folder, available here.  If you aren’t comfortable using it, just go to the various sites for each library that is missing and grab the DLL from there (this is what I did).

Create a Cartoon Face

This app allows you to create a character portrait from classic illustrations by New York Times Bestselling illustrator and author Steve Bjorkman.

Digit Defenders

Digit Defenders is an entertaining game that helps develop math skills by presenting a series of increasingly difficult waves of falling math problems.  Difficulty ranges from preschool to college level.

iLOLZ

Ever wanted to make a lolcat, fail, or any other kind of funny picture on the go?  If so, this easy and intuitive photo captioning iPhone app is for you!

R.Cloud Software offers a selection of other iPhone applications as well, so check them out.

Most applications are priced at $1.99, and some are even free.  Where else can you get hours of fun for you and your family for just pennies?

We are proud to help promote our clients projects.  If you have a project you’d like us to post about, please let us know.

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.

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.

On June 9th, 2009 a vulnerability was disclosed that causes Ruby to crash when an very large (we’re talking astronomical proportions) decimals are converted to strings.  This is a serious issue, but we feel that the exposure surface to most Rails sites may not be as large as initially thought.

Rails seems to convert decminals into big decimals when fetched from the database, and possibily a few other instances.  Since values in the database can very easily be user input, any Rails application that has decimals of any kind either stored in the database or at any time retrieved from the user is potentially at risk.  We can’t say for certain that if you don’t use decimals or big decimals you’re not at risk, but it does appear to be that way.

Our Recommendation

If your Rails app in any way uses decimals (either stored in the database or requested from the user), we recommend you update Ruby ASAP.  If you do not use this, we still recommend you upgrade, but its not as critical.

In either case, you can patch the issue by installing the gem by running:

gem sources -a http://gems.github.com
sudo gem install NZKoz-bigdecimal-segfault-fix

Then add the lines:

gem 'NZKoz-bigdecimal-segfault-fix'
require 'bigdecimal-segfault-fix'

to your application (for Rails, put this in config/environment.rb).  Once you install this, you’ll need to restart your Rails application.

The best long term solution though is to upgrade Ruby.  Here’s how to proceed:

• If you’re on shared hosting we will be automatically updating Ruby over the next few days.  If you use Mongrel, your application will need to be restarted, so we recommend you do this within the next 72 hours.  If you’re using your own install of  Ruby in your account, in which case you’ll have to upgrade it yourself.  If you don’t know how, we can do this for you as part of managed shared hosting or on a one-time-fee basis.
• If you have a managed server or VDS we’ll be glad to do that, just open a ticket and we’ll get that scheduled.
• If you have an unmanaged server or VDS and would like us to perform this for you, we can do it on a one-time-fee basis.  Just open a ticket and we’ll start the process for you.

If you have any questions about this, please let us know and we’ll be glad to assist you.

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.