Review: Slicehost Virtual Private Servers

It was almost a year ago that I was in search for a VPS solution provider. I had been hosting a dedicated server of my own on a co-location rack with my employer. However, I was changing jobs, and wasn’t wanting to pay for dedicated server hosting. So I searched for a bit, and came across Slicehost.

Slicehost ( is a fully owned subsidiary of Rackspace Hosting Inc. The first feature that attracted me was the price – A “256 Slice” (256Mb Ram, 10Gb Storage, 150Gb of bandwidth per month) is only $20 per month (See all of their pricing plans).  Every slice also is provisioned with a private IP address to allow inter-slice communication that is completely un-metered, can be provisioned with a huge list of 64 or 32-bit Linux distributions, and can be upgraded or downgraded in-place at any time.  I will say this, despite the features, slicehost slices are not for everyone – when you purchase a slice, you are provided full root access.  No fancy cPanel/Plesk to manage the different services on your box, just a good, old-fashioned shell.  Quite honestly, this is what ultimately reeled me in.

With that being said, slicehost does have a pretty slick, simple interface for managing your slice.  Once you log in, you’re presented with a list of all of your slices, and right on this list you can view both public and private IP addresses for each of your slices, the size of the slice, your current bandwidth usage (available bandwidth is also pooled across all purchased slices. )  After selecting a slice, you can re-provision, re-boot, configure backups, and even gain console access to your slice should you not be able to get in via SSH.  You can also view various statistics and troubleshoot your slices from the control panel.

Management Interface:

Slicehost Slice List

The slice management page:

Slicehost Management Interface

Another important aspect of any hosting provider is its support team.  Slicehost offers email support (as well as forums and other online methods), and I’ve never had any complaints about the response time on a submitted ticket.  Actually, I’ve only ever put in one ticket – to request permission to review the services.  In almost a year, I’ve never had to interact with Slicehost’s support team.  My slice has never been down (other than my own mishaps, of which I was able to log in via the web console and correct the issue.)  I’ve never had any performance issues.  I simply have not had the need for support – and that’s saying something for a hosting provider.


Without a doubt, if you’re looking for a flexible VPS solution – Slicehost is the way to go.  Ease of use, flexibility, pricing, support, features – They are truly a unique service.  You truly cannot go wrong with Slicehost… so give them a try.

Google application notifications in Ubuntu

I use pretty much all of Google’s applications, and want to get an easy way to be notified of new alerts…  And there’s a couple apps out there to get notifications through Ubuntu’s Messaging menu.  Awesome:

First we need to add some repositories.  The first is for gvoice-notifier, the second is for cloudsn

sudo add-apt-repository ppa:ken-vandine/notifiers

sudo add-apt-repository ppa:chuchiperriman/cloudsn

Then, we update and install:

sudo apt-get update && sudo apt-get install gvoice-notifier cloudsn

First, we go to Applications->Internet->Cloud Service Notifications

Then go to Edit->Preferences

Modify your check interval, and here’s the key: The “Indicate Status With” dropdown should have “Indicator Applet”.  Select it, click close, and then click the “New” button to add your accounts. Once your accounts are added, select File->Quit, and then re-open Cloud Services Notifications from Applications->Internet.  You’ll now have a Cloud Services Notifications item in your Messaging Menu, with the accounts you just added listed.  Right now, it appears that it only notifies of new messages/feed items, and you would still have to open the service in your web browser.

Now, in the messaging menu, you should also see a Google Voice line – click on it, configure your credentials, and you’re ready to receive your Google Voice notifications.

sudo apt-get install gvoice-notifier cloudsn

Setting up key-based authentication for SSH

So you’ve got yourself a nice fancy server running Linux, but you want to make sure access to your server is secure as possible.  What do you do?  Easy – configure your server to use key-based authentication.

First off, you need to generate yourself a keypair.  Each computer that you will use to access your server should have it’s own keypair – this makes it easy to limit access should your computer be compromised at some point.  Fire up a terminal and type the following:

ssh-keygen -t rsa -b 2048

This will generate an RSA based key with 2048 bit encryption.  For the most simple operation, accept the defaults through the generation process.  When you are asked for a passphrase, you should input a highly secure password – no common words, patterns, names, etc.

This will create two files in the .ssh directory in your home folder: id_rsa and  id_rsa must be kept secret – do not distribute this file.

Once the files are generated, you will need to copy your public key to the remote server.  The SCP binary is awesome for this:

scp ~/.ssh/ [email protected]:~/.ssh

This will copy the public key file to your remote server’s user account in the .ssh directory under your home folder.  You should be prompted for a password before the transfer is complete.

Once the transfer is complete, you will want to add the key to your authorized_keys file.  Most distributions will not have this file in the .ssh directory by default, so we will need to add it after we log in:

ssh [email protected]

cd ~/.ssh

First, we want to see if the authorized_keys file exists:

ls authorized_keys*

If you do not see authorized_keys or authorized_keys2, then let’s create them.  Which file you need depends on your operating system and many other factors, so we’ll account for both here.  If you already have an authorized_keys file, skip to line 3:

touch authorized_keys

ln -s authorized_keys authorized_keys2

chmod 600 authorized_keys

cat >> authorized_keys

We now need to configure the SSH server to allow key based authentication.  Debian-based distros have the configuration file at /etc/ssh/sshd_config.  Your distro may be different, so you may need to consult documentation.  I use vi myself, you can substitute vi for your favorite text editor:

sudo vi /etc/ssh/sshd_config

Find the following lines and ensure they say Yes:

RSAAuthentication yes

PubkeyAuthentication yes

Save the file, exit your editor, and then restart the sshd service:

sudo /etc/init.d/ssh restart (OR sudo service ssh restart)

Fire up another shell, and attempt to SSH to your server again:

ssh [email protected]

You should be prompted for your passphrase, but not your account password on the remote server.  If you are not prompted for your account password, make sure you modify the following line in your ssh configuration file to disable clear-text password logins:

PasswordAuthentication no

Restart ssh again, and you’re good to go!