How it Works

SSL/TLS, the encryption protocol commonly used for securing traffic between web browsers and servers, has a feature called a “heartbeat.” Every now and then, an exchange like this happens between the client and the server:

Client: You still there? If so, send back “ALIVE,” which is five characters.

Server: ALIVE

If the heartbeat succeeds, the connection stays open. This keeps happening, over and over, with a different value being passed each time.

Now here’s what happens if someone exploits the Heartbleed bug:

Client: You still there? If so, send back “KITTEN,” which is 300 characters.

Server: KITTEN, and here’s a block of random memory from RAM!

In this manner, an attacker can get a random 64KB chunk of data from memory every time a heartbeat is sent, thanks to a lack of validation of the length parameter. (So an attacker can just repeatedly make attempts.) Eventually, they’d get lucky and find something interesting. Such as the SSL certificate or users’ passwords and data.

Exploiting this bug is trivial. (There were people posting scripts to test for the vulnerability minutes after it was announced. Just imagine how quickly malicious types got to work implementing exploits for the bug!) It’s also possible that someone knew about it months or even a couple years ago, and has been exploiting it ever since. Bloomberg even suggests that the NSA has known about it for two years, and has been exploiting it rather than disclosing the problem.

Is it Fixed?

Yes! Your Linux distro should already have patched builds in their package manager, so it’s just a simple manner of running a couple of commands to update your openssl and libssl1.0.0 packages, then restarting any services that depend on SSL. (Or just do a full reboot if you’re paranoid.) In the case of Ubuntu, you’d just do something like this to update the packages:

sudo apt-get update
sudo apt-get dist-upgrade

You should now revoke any SSL certificates and issue new ones, in case they were leaked in an exploit of the bug.

What Should I Do, as a User?

Change your passwords! For anything important—email, banking, etc.—you should consider picking a new password.

That’s the problem GoHub attempts to solve. It’s a tiny webserver (written in the Go language) that listens on a port for messages from GitHub’s WebHook API. Any time a commit is pushed to GitHub, they send a JSON notification to your GoHub listener, and it runs the shell script of your choice when the specified branch (usually “master”) changes.

The original GoHub script was created by adevan, but I made my own fork that includes some extra goodies. It includes a magical setup script that sets everything up for you, as well as an Upstart script. (Configurations and logs are also under /etc/gohub in the fork.) So if your Linux distro is still using SystemV instead of Upstart, you probably want to use the original instead of the fork. (At least until I get around to writing a SystemV script and amending the setup…) If you’re on Ubuntu, you’re good.

Assuming you already have Go installed, it’s a simple matter of cloning the repository and running the setup script.

git clone https://github.com/redwallhp/gohub.git
cd gohub
chmod +x ./setup
sudo ./setup

Then you need to add your watched repositories to /etc/gohub/config.json. Each object should specify the repository name (in the form of gohub not redwallhp/gohub), the branch (master in most cases) and the path to the shell script that should be run. The best place to keep them is in /etc/gohub/scripts, to keep everything together and save your sanity in the future.

What should one of those scripts look like? Here’s a super simple example that just takes the files checked out and copies them to the public directory the web server is looking in. This works well for PHP projects.

#!/bin/bash -l

GIT_REPO=https://github.com/me/awesomeapp.git
TMP_GIT_CLONE=~/tmp/git/awesomeapp
PUBLIC_WWW=/var/www/sites/awesomeapp

git clone $GIT_REPO $TMP_GIT_CLONE
cp $TMP_GIT_CLONE $PUBLIC_WWW
rm -rf $TMP_GIT_CLONE
exit

The README file has the script I use to build and deploy Jekyll sites.

Once you have everything set up to your liking, start the server by running service gohub start. This invokes the Upstart script and starts the server daemon.

Now all that’s left to do is add the WebHook on GitHub. Go into the settings for the repository, select Service Hooks, and then WebHook URLS. Paste in the appropriate URL, which follows this convention:

http://example.org:8392/reponame_branch

So if your repository URL is https://github.com/me/awesomeapp.git, and your domain is example.org, your WebHook URL would be http://example.org:8392/awesomeapp_master.

Save the settings on GitHub, and test out your new Git deployment system. If you make a change and push the commit, the changes should take effect momentarily.

Fast forwarding a bit to spare you the gritty details, I went looking for benchmarks to see how DigitalOcean stacks up against the major competitors. In doing so, I found a new Interesting Thing.

ServerBear provides “a no hassle all-in-one UnixBench, IO, IOPS & Network performance test for Linux Servers,” and compiles an index of benchmarks for the different price points offered by dozens of web hosts. You can look up a service, such as DigitalOcean in this case, and view benchmarks for each plan purveyed by the host.

They also rank the hosts with a “BearScore” that represents the performance and specs vs. the monetary cost. Of course, there’s more to choosing a host than just raw performance. Reliability, knowledgeable staff, and quality support when something goes wrong are also very important. Unfortunately, those things are harder to quantify statistically.

Looking at the statistics, this up-and-coming DigitalOcean seems pretty good. Their $10/month offering seems to outperform my two-node VM from VPS.net (which is currently priced at $38/month for new customers…) in most areas, except for network speed. DigitalOcean, according to other sources as well, seems to have slower internet connectivity than Linode and VPS.net. But at a fraction of the price, it’s a very attractive option.

ServerBear: Performance Benchmarking For Linux Servers [serverbear.com]

While I don’t know why it’s happening, exactly, I do have a fix. The wait goes away if you put the local entries on one line.

Instead of having something like this:

#virtual hosts
127.0.0.1 myproject.dev
127.0.0.1 wordpress.dev
127.0.0.1 somesuch.dev

You need to have this:

#virtual hosts
127.0.0.1 myproject.dev wordpress.dev somesuch.dev

Leave the lines that say “localhost” alone, of course. Messing with those could cause all manner of Bad Things.

Blitz is a configurable service that will pound your site with page requests, allowing you to specify the concurrency, timeout, and duration of the onslaught. As it goes about this, it builds statistics and plots them along timelines. You can watch response times, errors and timeouts as it slowly ramps up the number of concurrent users until it reaches the maximum. At the end, it even projects how many hits per day your setup can handle at that rate.

The service has a generous free tier, though they offer paid upgrades for higher concurrency and duration. The free tier offers 250 concurrent users over a one minute rush. (Though if you sign up with this invite link, they will add additional concurrencies to your account.)

I found Blitz very useful when I was trying to squeeze faster response times out of my WordPress setup, tweaking my caching system options and adjusting Nginx and PHP configurations. Since they use the connections at their datacenter, you get more real-world results than if you simply ran Apache Bench locally on the server, or from your residential internet connection. Both tools have their uses, of course, and Blitz is a good one to have in your arsenal.

After reading up on the protocol Minecraft uses for the in-game listing of your favorite servers, I put together a simple PHP class that makes it easy. Here’s a fancy demo that makes use of it.

The library, which you can download on GitHub, along with the aforementioned demo page, looks like this:

< ?php

class MCServerStatus {

	public $server;
	public $online, $motd, $online_players, $max_players;
	public $error = "OK";

	function __construct($url, $port = '25565') {

		$this->server = array(
			"url" => $url,
			"port" => $port
		);

		if ( $sock = @stream_socket_client('tcp://'.$url.':'.$port, $errno, $errstr, 1) ) {

			$this->online = true;

			fwrite($sock, "\xfe");
			$h = fread($sock, 2048);
			$h = str_replace("\x00", '', $h);
			$h = substr($h, 2);
			$data = explode("\xa7", $h);
			unset($h);
			fclose($sock);

			if (sizeof($data) == 3) {
				$this->motd = $data[0];
				$this->online_players = (int) $data[1];
				$this->max_players = (int) $data[2];
			}
			else {
				$this->error = "Cannot retrieve server info.";
			}

		}
		else {
			$this->online = false;
			$this->error = "Cannot connect to server.";
		}

	}

}

There are some code snippets strewn around the internet that do essentially the same thing, but without the handy wrapper class.

To query a server, you instantiate the class and pass it the IP or domain name of the server, as well as the port if it is not the default Minecraft port of 25565. (Do not include “http://” or any slashes. Just the hostname or IP.)

include "MCServerStatus.php";
$server = new MCServerStatus("s.nerd.nu", 25565); //The second argument is optional in this case

Once you have created a new instance of the object, you can use the information that it gathered.

$var = $server->online; //$server->online returns true if the server is online, and false otherwise
echo $server->motd; //Outputs the Message of the Day
echo $server->online_players; //Outputs the number of players online
echo $server->max_players; //Outputs the maximum number of players the server allows
print_r($server); //Shows an overview of the object and its contents. (For debugging.)

Now go and play some Minecraft!

Update: MCServerStatus is now on Github. Fork away!

Update 2012/11/12: The version of the library available on GitHub has been updated to work with the new protocol in Minecraft 1.4.

Your client-side JavaScript can query an API that doesn’t offer JSON-P support, by having it pass through your server first. You can even cache the results for awhile, so you don’t run into rate limit issues. And if JSON-P is a necessity, you can transform the API response from vanilla JSON to JSON-P by echoing some additional content into the request.

You can read how to do all this in an informative blog post by the founder of DuckDuckGo. It’s pretty much a matter of adding a location block that uses the proxy_pass function to pass the request along.

nginx JSON hacks [Gabriel Weinberg]

Fortunately, the solution is simple.

You just need to run sudo dpkg-reconfigure console-setup and follow the on-screen prompts. You would usually use the arrow keys to traverse the menus, but that isn’t exactly possible, is it? Pressing the first letter of the option you’re looking for until it cycles up and is selected works fine, though. (Apple Laptop, USA-style layout, etc.) The full instructions on what you should pick for MacBooks are available here.

Now, moving in and out of the VM window is a little bit annoying, so I installed an SSH server.

sudo apt-get install openssh-server

Easy enough. Now you can SSH into the server from a native Terminal session, which is easier to Command+Tab in and out of, and you can make use of the clipboard. Not being able to copy and paste sure is limiting.

Now you only have one final obstacle standing between you and easily connecting to the server. Whether you’re using SSH or accessing a web page being served by the VM, you need to figure out the local IP address of the VM on the network and input that. Or you can set up ZeroConf, which lets other machines on the network automagically find the VM when you call it by name. Instead of addressing it as 192.168.0.255, you could use Ubuntu.local. (Very handy when you’re running game servers on your LAN.)

The following command will install the required packages to enable ZeroConf on the VM.

sudo apt-get install avahi-daemon avahi-discover avahi-utils libnss-mdns service-discovery-applet mdns-scan

Now you can reach the VM at thehostname.local, which is considerably easier than figuring out what IP your router has assigned it and pasting it in whenever you need it.

Here are a few resources to help you figure things out:

• HowtoForge — All sorts of Linux tutorials. They have guides to setting up server configurations on the various Linux flavors, as well as basic  introductions to Linux.
• Slicehost Article Repository — Even if you aren’t a Slicehost customer, you will find some invaluable guides and tutorials here.
• Linode Library — Much like Slicehost, Linode maintains a collection of useful tutorials.
• Official Ubuntu Documentation — Select your version of Ubuntu and look for the “Server Guide” link.
• Google! — Search engines are your friend. If you don’t know what something means or you want to learn how to do something, search for a tutorial. The chances are good that someone else has already written something on the subject.

If you really get stuck, try leaving your question on your host’s forum or on Server Fault.

The latest PHP release includes PHP-FPM, the PHP process manager.

I’ve managed to find one decent guide to compiling and setting it up so far. It looks fairly simple. I might have to give it a try sometime, as my current setup (which doesn’t use PHP-FPM) tends to hang occasionally.