The next thing you should do is enable automatic security updates. No sense in having your server get hacked because you were too busy to update it. Luckily, in most systems, this is pretty easy.

First, install unattended-upgrades like this: apt-get install unattended-upgrades Then configure your settings with nano /etc/apt/apt.conf.d/50unattended-upgrades. Depending on the system, I usually only enable automatic security updates, but on development systems, its nice to have everything update as well. Debian Stable doesn’t change all that much, but there’s always the risk of breaking things. The configuration file below only has security updates enabled.

APT::Periodic::Enable "1";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::AutocleanInterval "7";
APT::Periodic::Unattended-Upgrade "1";

// Automatically upgrade packages from these (origin, archive) pairs
Unattended-Upgrade::Allowed-Origins {
        "${distro_id} stable";
        "${distro_id} ${distro_codename}-security";
//      "${distro_id} ${distro_codename}-updates";
//      "${distro_id} ${distro_codename}-proposed-updates";
};

// List of packages to not update
Unattended-Upgrade::Package-Blacklist {
//      "vim";
//      "libc6";
//      "libc6-dev";
//      "libc6-i686";
};

// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. The package 'mailx'
// must be installed or anything that provides /usr/bin/mail.
//Unattended-Upgrade::Mail "root@localhost";

// Do automatic removal of new unused dependencies after the upgrade
// (equivalent to apt-get autoremove)
//Unattended-Upgrade::Remove-Unused-Dependencies "false";

// Automatically reboot *WITHOUT CONFIRMATION* if a
// the file /var/run/reboot-required is found after the upgrade
//Unattended-Upgrade::Automatic-Reboot "false";


// Use apt bandwidth limit feature, this example limits the download
// speed to 70kb/sec
//Acquire::http::Dl-Limit "70";

Go ahead and run apt-get update and apt-get upgrade to bring your system completely up to date as of this moment. So far, we’ve just done some system maintainence tasks, nothing really fun, don’t have much to show for our work, until next time. In the next article, I’ll walk you through Apache configuration and we’ll get to hosting real websites.

Other posts in this series:

1. Getting a Server
2. Getting a Domain Name
3. Automatic Updates - You are here
4. Apache2 Setup
5. PHP and MySQL Setup
6. ProFTPd Setup
7. WordPress Setup
8. RVM Setup
9. Git Setup
10. OctoPress Setup
11. Rackspace Backups

There is a small caveat to virtual hosting: You will need a domain name, and here’s why:

Apache, Nginx, and other popular pieces of webserver software are capable of hosting multiple websites from one IP address. Its what allows hosting companies to serve multiple websites off of one IP address. Without this technology, if sites required a dedicated IP address, the internet would have quickly run out of room for websites, especially on IPv4. What the webserver software does is look at the domain requested in the http request. Based on this data, the web server is able to route you to the appropriate place. So, in essence the rest will not work well without a domain name. You can host a single site by IP address, but this is expensive and fairly wasteful, depending on the amount of traffic you’re expecting. Do youself a favor, spend some cash, get a hostname (or three!).

You can buy a domain for a specific period of time from a Domain Registrar, of which, there are several. Tons. A whole truckload of them. My personal recommendation is Hover. Hover is a different type of domain registrar, they have a very clean interface, buying is easy, canceling is one click, and they don’t bug you to upgrade or buy fancy add-ons. Hover respects their customers, unlike some registrars. A .com will run you $15 a year, but you can use this coupon code to take 10% off the final price: twig. I would like to thank This Week In Google for the promo code (and if you don’t watch, you really should.

Now that you have a domain name, we have to start configuring our server, then move on to Apache configuration. The expensive part is over with, now we’re onto the time-consuming part.

Other posts in this series:

1. Getting a Server
2. Getting a Domain Name - You are here
3. Automatic Updates
4. Apache2 Setup
5. PHP and MySQL Setup
6. ProFTPd Setup
7. WordPress Setup
8. RVM Setup
9. Git Setup
10. OctoPress Setup
11. Rackspace Backups

Today I’ll start a series of posts on how I’ve set my virtual web server up and walk you through how to do the same. You should be comfortable using the command line, Linux systems, and SSH.

Getting a Server

I work on a lot of web projects, and I needed a way to centrally host them without needed to configure a server each time. I wanted something that could host static sites, rails sites, and PHP/MySQL sites. I could have gone with a combination of hosting platforms, but I really wanted something that I had more control over, without running the server out of my home. The power in my apartment fluctuates enough that I can’t really be comfortable with hosting public projects here, even with a battery backup.

I decided on Rackspace for a few different reasons, not the least of which was their awesome ‘fanatical’ support. I started out by launching a new Debian Cloud Server. I chose Debian because of the ease-of-use of Debian systems, my familiarity, and my general move away from Ubuntu. Debian tends to be a stable, secure distribution for web hosting. Combine that with good backups and you’ve got a professional setup. Rackspace is cheap, but isn’t free, so you’ll need to pay monthly for the service. My server runs me about $20 a month, so find a few buddies and split the cost up.

The first step is to get yourself a username over at Rackspace.com. Next, start up a new cloud server by clicking the Create Server button:

For this server, we’re going to use Debian 6 (or 7 if its out now) and 512MB of RAM. Honestly, I’m running a very thin server, it isn’t very powerful, and it works just fine. If your site has a million hits an hour, you probably shouldn’t be following this tutorial. For everyone else, this works just fine.

Go ahead and copy the password that’s shown and log in via SSH. You’ll need to log in as root@ip-address-here. Use the command passwd to set a new password. Make this long, complicated, and memorable, these are your keys to the castle, it would be a shame if something happened to it.

And now you have a public server, ready to build things on. In the next posts of this series, I’ll walk you through virtual hosting, WordPress, OctoPress, and other essentials.

Other posts in this series:

1. Getting a Server - You are here
2. Getting a Domain Name
3. Automatic Updates
4. Apache2 Setup
5. PHP and MySQL Setup
6. ProFTPd Setup
7. WordPress Setup
8. RVM Setup
9. Git Setup
10. OctoPress Setup
11. Rackspace Backups

One of the things I love the most about Linux environments is Compiz-Fusion. Even though the majority of plugins are pure eye-candy, I find that zooming around the desktop environment in a pretty environment is helpful to my productivity. And seriously, who wouldn’t want their desktop to do this?

What I needed to do is get this installed on my new Debian system, but it does take a little bit of work to get installed. This post over on the Debian forums told me exactly what to do. It looks like Compiz-Fusion is in the sid repository, so you need to add a new line to your /etc/apt/sources.list file:

## SID: to get compiz
deb http://ftp.us.debian.org/debian/ sid main non-free contrib

After you do that, run these commands to set your default release channel, update the repository listings, and install compiz-fusion and some common compiz add-ons:

sudo su
echo 'APT::Default-Release "testing";' >> /etc/apt/apt.conf
apt-get update
apt-get install fusion-icon compiz* compizconfig-settings-manager

This should install Compiz, the fusion-icon program, a suite of stable and unstable plugins, and the graphical settings manager.

Update: This script by GitHub is a bit more automatic than my method below. My method still works, it’s just less clean.

Ever accidentally made a commit… or a few commits… or a lot of commits with the wrong author or name set? Now you’ve pushed the branch to GitHub and all the pictures are screwed up? Yea… me too.. I do that quite a bit. Luckily, I found the most noob-friendly way to fix it, thanks to this post on Stack Overflow.

Just a warning up front, this will require a forced-push, since you’re altering history, it will break other people if they have forked your repository, just let them know you’re fixing things and they’ll need manual intervention to start re-tracking your branch again.

Look through your commit log with git log or, in the case of repositories where you’re the main author and haven’t merged too many pull requests, head over to your GitLab commit listing and look for the pictures that don’t match. Make a note of the commit IDs you need to fix up and sit it off to the side, like so:

Commits to fix:

fd481a0
53113e3
3a4a67f

Now, take a look at about how many commits you’ve made, then rebase a stupidly-high number of commits, like this: git rebase -i HEAD~120. Now you’ll see a big list of commits and one-line messages. Search through and find the commits you need to fix. Under each need-to-fix commit, put this line exec git commit --amend --author="New Author Name <email@address.com>" -C HEAD, but change that line to your correct name and email address. It should look something like this:

pick 8388019 Resized favicon to 16x16
pick 243eab2 Added PGP key. Still need style.
pick 4a85014 Added two posts from blogger.
pick a55b911 added c9revisions to git ignore
pick fd481a0 Removed bad markdown file
exec git commit --amend --author="Tom Webster <samurailink3@gmail.com>" -C HEAD
pick da4fe69 Fixed mixed up posts.
pick df6f740 Ejectable core post, attempted iFrame embed.
pick a600981 Add link to reflect original post
pick 53113e3 Fix size of slideshow
exec git commit --amend --author="Tom Webster <samurailink3@gmail.com>" -C HEAD
pick 220497c Added TrueCrypt Tutorial historic post.
pick 3a4a67f Added two historical posts.
exec git commit --amend --author="Tom Webster <samurailink3@gmail.com>" -C HEAD
pick e2092ec Change date for historic post.

You will need to put that line under each wrong commit, as it only works on one at a time. This allows you to specify which commits you’d like to change and what changes you’d like to make, very powerful, very awesome. Save and exit, then git will run through each line, doing exactly what you told it to do, changing the author at each point you put that new exec line.

Next, check out your log again with git log and make sure you didn’t miss anything. If it all looks good, go ahead and make a forced update with git push -f origin branchnamehere (make sure you use the right branch name, of course). Your remote branch will update with the corrected name and author strings.