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:
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:
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.
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
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:
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
told me exactly what to do. It looks like Compiz-Fusion is in the
repository, so you need to add a new line to your
## 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
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@example.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 <firstname.lastname@example.org>" -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 <email@example.com>" -C HEAD pick 220497c Added TrueCrypt Tutorial historic post. pick 3a4a67f Added two historical posts. exec git commit --amend --author="Tom Webster <firstname.lastname@example.org>" -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
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
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.
With new OS installs comes the need to redo my development environment. Instead of running through and manually installing what I need, I created a quick-and-dirty bash script to do it for me. Check it out:
Ruby 1.9.3 and
Rails 3.2.1. Make sure to run this as a
# Thanks to http://xyzpub.com/en/ruby-on-rails/3.2/rails3-install-debian.html sudo apt-get -y install build-essential openssl libreadline6 libreadline6-dev curl git-core zlib1g zlib1g-dev libssl-dev libyaml-dev libsqlite3-dev sqlite3 libxml2-dev libxslt-dev autoconf libc6-dev ncurses-dev automake libtool bison subversion python curl -L https://get.rvm.io | bash -s stable source ~/.rvm/scripts/rvm rvm autolibs enable rvm install 1.9.3 gem update gem install rails --version '~> 3.2.1' echo "source \$(rvm 1.9.3 do rvm env --path)" >> $HOME/.bashrc echo "Complete (Ruby 1.9.3 - Rails 3.2.1)"