vertner.net

Switching Hosts

So between random hiccups with my ISP, the struggles of de-conflicting my VPN server with my web server, and a desire for more robust uptime, I finally decided to bite the bullet and get a real web host. I searched around a bit, and I narrowed down what I really needed:

  1. SSH access.
  2. A static IP address.
  3. Nothing else.

Making it even easier, I didn’t need complex hardware. One of the joys of running a blog off of Octopress is that it doesn’t require very powerful hardware. After researching many of the possibilities, there was one that really struck me as exactly what I needed: Digital Ocean.

Why?

So here’s the dirty side of all of this: I’m not really that great with all of this computer and networking stuff and I’m basically teaching myself on the side. For whatever reason, I decided to only leave SSH access to my server open on the LAN. This means that I needed to get on the VPN before I could manage anything… but somehow my last round of updates on 11 June stopped my VPN from working… and my blog. Pretty much everything. So it was just all broken and stuff for about a week and a half. Unsat. Amusingly, uninstalling nginx let the VPN start working again. I suspect that it had something to do with the updated SSL library and some conflict between OpenVPN and nginx and the port-sharing function that I recently set up.

How?

Digital Ocean specializes in low-cost virtual servers using quick solid-state drives. Since I’m not running PHP or SQL, my hardware requirements are insanely low. I also don’t attract enough traffic to worry about my bandwidth, so I want with their simple $5/month plan, which gives me 512 MB of RAM, a single-core processor, 20 GB SSD, and 1 TB of bandwidth. Best of all, I get to pick my OS, root access, SSH access, and the ability to do pretty much whatever I want with it. That’s a pretty sharp contrast to your typical web host. Best of all, the virtual host was online and ready for me to work with in about one minute.

So, sticking with what I know, I went with Ubuntu 14.04 Server. First, I determined my host’s IP address from Digital Ocean’s easy account management interface, headed over to my domain and DNS provider, DynDNS, and redirected my domains over to the new IP address. Afterwards, I logged in using the following command:

1
ssh root@domain.com

Obviously, I used vertner.net instead of domain.com. I didn’t want to log in as root every time, so just like every new system, I created a new user account and gave it the ability to perform administrative functions as needed by using the following commands:

1
2
3
4
5
addusr new_user_name

# Answer some questions and give this guy a great password...

gpasswd -a new_user_name sudo

Now my new user, new_user_name has a password-protected account and the ability to execute commands as an administrator as needed. I tightened up my connection by generating a public key for SSH. At my local machine, I generated an SSH keypair by entering using the ssh-keygen command, then outputing to my home .ssh directory, and finally giving it a password. To copy it over to my new server while still logged in as root, I entered the following to switch to my new user:

1
2
3
4
5
6
su - new_user_name

mkdir .ssh
chmod 700 .ssh

nano .ssh/authorized_keys

Coming back over to my local machine, I opened up the .pub file generated by ssh-keygen and copied its contents into my server’s newly-created authorized_keys file. After saving my changes and closing my text editor, nano (using Ctrl+x, y, then enter) then I wanted to restrict permissions to the authorized_keys file by typing chmod 600 .ssh/authorized_keys and then exit to return to root.

One last thing to do with my old root login was to plug it up.

1
nano /etc/ssh/sshd_config

I found the line where it says, PermitRootLogin yes and changed it to PermitRootLogin no, saved my changes (as above), and restarted SSH by entering the following:

1
service ssh restart

Before logging out, I opened a new terminal window to start a fresh SSH session to test the new user login while still logged in as root in the old window. This way I wouldn’t have to start from scratch if I messed up. Luckily, I was successful and able to run sudo commands with my new user account! After logging out of and closing up the root terminal I had been using, it was time to get to work.

1
2
sudo add-apt-repository ppa:nginx/$nginx
sudo aptitude update && sudo aptitude safe-upgrade

… just to make sure I add the nginx repository and make sure that everything is up-to-date before I start installing packages. Next:

1
sudo aptitude install nginx

After that, it was as simple as copying over my /etc/nginx/ssl/ directory from my previous efforts, copying over the contents of my configuration files, and restarting nginx. In the process, there was an error because of how I copied/pasted my preferred cipher list, but it was pretty easy to find using the nginx -t command to test the configuration and return which line had the problem.

Finally, it I just need to update my Octopress Rakefile with the updated SSH username and server IP address (or domain name) before executing my deployment command, bundle exec rake generate && bundle exec rake deploy (which of course I just have a shell script for; I’m lazy). Have I mentioned recently how much I love Octopress?

IT’S ALIVE!IT’S ALIVE!

If you’re feeling saucy and want to use Digital Ocean for any virtual hosting, please feel free to follow any of the Digital Ocean links in this article; we’ll both get referral credit. Digital Ocean links. Did I mention Digital Ocean?

Comments