Shift – 06_2014


  • Give It To Me (Original Mix) Dirty Channels
  • Diggin’ On You (Solomun Remix) Elekfantz
  • Forget (Original Mix) Patrick Topping
  • Manitox (Original Mix) German Brigante
  • Nightwalker (Original Mix) Raxon
  • Truesoul (Original Mix) Mendo, Danny Serrano
  • She Loves Me (PBR Streetgang Remix) Lula Circus
  • Ice (Original Mix) Sandeman
  • Emperor feat. Kali (Maceo Plex Last Disco Remix) Kali, Ali Love
  • Silhouette Of A Ghost (Original Mix) Ida Engberg
  • Crossfade (Maceo Plex Mix) GusGus Crossfade

Use Ubuntu 12.04 as an Airplay source

XBMC supports Airplay out of the box, but I don’t really want to run an entire media server just for one feature. Plus, I need the service to run in the background so I can do _work_.

I found a great tool called ShairPort that accomplishes what I need. It is easy enough to get started. On your Ubuntu machine you should install the following dependencies:

Now install shairport. You will need git installed if you do not already have it for some reason.

At this point you should be able to run the app.

To see a list of available parameters, run ./shairport -h.

You should see it show up on your Mac now. Go to System Preferences > Sound > Output. I named mine “roy-ubuntu ShAIRport”

airplay with shairport

I recommend moving the shairport directory someplace, like /opt.

Create a symlink to the app:

That’s it! So far it’s working out pretty well. The defaults for shairport have been fine for me.

Setup Development Environment with Vagrant & Chef


I use Chef to manage and provision new staging and production servers in our company. It takes a lot of the headache out of managing multiple servers and allows me to fire up new web & data servers for our projects with ease. I have several cookbooks that I use to configure servers and to setup/configure websites. In a nutshell, it’s rad, and website deployments have never been easier.

For my local development environment I currently run Ubuntu, with Apache, Nginx, PHP 5.3, Ruby 1.9.3, Ruby 2.0, MySQL 5.5, etc. Some of our projects use Node, Redis, MongoDB. Ideally I would offload all these different servers into virtual machines suited and designed for the task, identical in configuration ot the staging and production servers.

Enter Vagrant. Vagrant is a tool to configure development environments.

How I expect this to work:

* I want to use my native development tools (NetBeans, Sublime Text, Git, etc) on my workstation.
* I want to use the VM to serve the project files.
* I do not want to have to deploy my local code to the VM for testing and review.
* I will mount my project directory as a shared path in the VM.
* I will build the VM using my Chef cookbooks.

Ok, not so bad. Vagrant makes this really easy.

Install Vagrant.

Once installed you want to add a box to build your VM from. There are many to choose from. I prefer CentOS for my servers, and will add one from All of our production machines use CentOS or RHEL, so my development VM should use CentOS.

Now you need to create your Vagrant project. I have considered creating the Vagrant config file in my project and putting it under version control. Currently I just have a directory for Vagrant projects. Either way.

This will create a Vagrant config file. The Vagrant file describes how to build the VM. It defines the network settings, shared directories, and how to provision the machine using Chef. When creating the vagrant file you can pass the name of the box to use. I used the box we added earlier, “centos-6-4”. If you leave this parameter off you can always edit the Vagrant file to change it.

Configuration is rather minimal. Not a whole lot we need to do to get something running. Open Vagrantfile in your text editor.

I want my VM to use the local network. You could opt to use the private network, which I believe is the default. You can also setup port forwarding here. For example, if you want to forward requests to http://localhost:8080 to port 80 on the VM. I just setup a public network for my VMs because often times I have people in the office review work on my server from their

Let’s set up the shared folders. The first path is the local directory you want to share, and is relative from the Vagrantfile. The second is the mount point in the VM. Since the Vagrant file is the root of my project, I will set the share directory to the current directory. Set the mount point to someplace you will want to serve your project from. I tend to do things the Enterprise Linux way, and will put my web projects under /var/

Now, to tell Vagrant how to provision the VM using

This is pretty straight forward. We tell Vagrant where our chef data is stored, which recipes to run, and pass along any attributes we want Chef to use. I would like to explain how I organize my Chef cookbooks very briefly. I use a fat-recipe/sinny-role approach. I have a cloud server cookbook to manage AWS and Rackspace instances. I have role recipes, and site recipes. A role recipe defines how the node should act: is it an Nginx server? Or a MySQL server? Will it run PHP-FPM? And so on. Then I have a site recipe which is defines how the website will be configured. It creates an apache vhost file, sets up a PHP-FPM pool, creates an Nginx proxy to a NodeJS app. I have data bags that correspond to different environments to configure the site as well, so production uses a different hostname than staging, has a different MySQL configuration, and so on. Now when Chef runs, it detects the environment, loads the corresponding data bag, and configures the site and node.

There is one more step before we can start up our VM. We need to install the omnibus vagrant plugin.

The Omnibus Vagrant plugin automatically hooks into the Vagrant provisioning middleware. It will bootstrap the VM for us. It is required if you are going to provision the VM with chef.

Ok, when that is installed you can fire up the

And there we go. You can continue working on your project locally, but serve it using a VM configured identically to your production servers. Have fun with your kick ass new dev environment!

The resulting Vagrant file should look something like:

Troubleshooting extremely high MySQL CPU Usage

MySQL CPU usage was spiking upwards of 1000%. Load average was around 50-60. I could not SSH into the machine though, not immediately.

Since I could not actually get into the machine I had it restarted. Just as soon as the machine came back up MySQL CPU usage jumped right back up to 1000%.

Once I was able to finally shut MySQL down I had to discover _why_ the load was so ridiculously high.

MySQL slow query log showed that it was a WordPress plugin that was making a SHIT TON of queries, and MySQL could not keep up. The plugin in question was the WP Security & Audit Log. The plugin logs activity on a WordPress sites, failed logins, successful logins, new user accounts, etc. The queries in question were all related to failed logins. Checking the Apache access logs showed me that there was a massive spike in users attempting to brute force passwords. Thankfully none of them got through.

Gathered a list of offending IPs and blocked them. Also changed all user passwords, just in case. Also disabled the plugin until a resolution can be found and an alternative put in place.

A few things here..

1. MySQL is probably not tuned well, and should be tuned for this particular site.
2. The audit plugin makes too many unnecessary queries and I do not think it is meant to handle the amount of traffic the site was getting. I really should look into that further.
3. Our Nagios configuration does not monitor traffic spikes on websites. If it did I could have caught this _before_ it become so bad.

Securing Git repository from accidental exposure using Chef

It was brought to my attention at the office that a few of our recently launched websites had publicly exposed .git repository information. Unscrupulous users could use the exposed data to pull down the entire commit history, giving them unfiltered access to what is basically the blueprint for the website.

What if someone accidentally uploaded a config file to the repository with sensitive information in it? Or what if the user was able to discover a major security vulnerability in the code that would have otherwise remained “safe”? Scary.

There is definitely too much risk in allowing public access to your .git directory.

I created a Chef recipe called
gitsec.rb to deploy a very easy and quick fix to 20 web servers.

I was not sure the best way to determine if a service exists using Chef, so I just check for the appropriate init script. All of our servers are RHEL or CentOS, so I do not do any detection of platform here. It would be trivial to do so, so I will leave that to you!

You will also want to create a couple of templates:



At first I was returning a 403 status code, but realized that it was still announcing that a file did exist at that location. 404 is better, it does not expose the existence of a file.

This recipe is part of my initial web server setup now.