Using ssh-argv0

I'm pretty lazy. I discovered a little ssh trick today that other lazy folks might find useful. However, it's the type of trick that is mostly worthless in comparison to a properly built .ssh/config file. In fact, the only real thing this particular trick has going for it is that it's really easy to implement and remember.

Intro ssh-argv0...

ssh-argv0 is a simple wrapper that runs ssh and appends the current program name (as well as any arguments). It's installed as a part of the openssh-client package. Using it is pretty straightforward. Just make a sim-link called the hostname of the server you frequently connect to. Be sure to point it towards ssh-argv0
sudo ln -sf /usr/bin/ssh-argv0 /usr/local/bin/boomer.riley
Now you can simply call the sim-link to connect. You've got tab completion and it saves you a whole 4 keystrokes!
boomer.riley echo 'Just saved some time connecting to $HOSTNAME'
mriley@boomer.riley's password:
Just saved some time connecting to boomer
Instead of passing the login_name argument, you can roll that into the sim-link you create as well.
sudo ln -sf /usr/bin/ssh-argv0 /usr/local/bin/totallynotroot@boomer.riley
totallynotroot@boomer.riley
totallynotroot@boomer.riley's password:
Maybe you've got a lot of machines and you'd like to programmatically create a bunch of these. You can do that...
for i in {1..50}; do sudo ln -sf /usr/bin/ssh-argv0 /usr/local/bin/host$i.riley; done
Matt, that's just crazy. What will I do with all the time I've saved with this trick?
Good question. You've probably wasted more time reading this post than you'll ever get back with this trick... mwahahaha.

~MJ

Cutting power costs with Raspberry Pi

Much of my free time the past few months has been dedicated to moving various services and infrastructure out of my apartment. Where possible I've also been in search of solutions that are free (or at least really cheap).

I've known for a while my initial goal of removing all local infrastructure just wasn't feasible. For services that just weren't practical to host elsewhere, my goal was to find a way to reduce cost, noise, and maintenance. Let me set the stage...

The Old Set Up

Galactica in all its glory.
My old set up is a combination of old gaming rigs I had built over the years. There actually isn't anything special about it. It's not particularly powerful or reliable, and it's really loud.

It runs KVM with a fancy WebVirtMgr interface for easy administration. At this point, however, I've removed all services from it with the exception of a proxy server, Plex media server, and web server.

The Idea

While the KVM box isn't super powerful it does consume a non-trivial amount of electricity. I don't have any plans to change my internet subscription so the only real way I can reduce the cost of hosting services is to focus on power.

Services like my proxy and web server get little to no traffic but are things that I like to keep active at all times. Keeping in mind their lack of use they seemed like good candidates to move to a platform that draws less power. Having recently started playing with a Raspberry Pi B+ this was a natural place to start. The real question was whether or not I could get a Plex media server up and running on a Pi.

The Investment

While the ultimate goal was to save money on my electric bills I also didn't want to come up with a solution that cost more than I could re-coop within a year(ish). With that being said here's the bill for my new set up:

*I had one sitting around

All in all I'm in ~$120 for this particular project. There are a number of factors that could make this number lower. For example, Pi cases aren't necessary, you could find smaller/cheaper MicroSD cards, and the Pi 2 B is the top of the offerings (you could get a Pi 1 B+ for at least the proxy/web stuff). I expect you could produce similar results on a tighter budget (~$80).

The Results

I've now got two Pis up and running. One is handling my proxy and web traffic while the other is a Plex media server (which I'll probably do a separate post on). Now for the fun stuff.

Galactica (KVM)

State Power Consumption
Boot 149W (Peak)
Idle 91.5-95W

PlexPi

State Power Consumption
Boot 5.9W (Peak)
Idle 4.9-5.3W
Load 6.5W (Peak)

WebPi

State Power Consumption
Boot 2.4W (Peak)
Idle 1.7-1.9W
Load 2.3W (Peak)

For a more conservative estimate of my savings I based my calculations on the lower idle consumption of Galactica and split the difference between the higher idle consumption and load consumption of each Pi. My last electricity bill came back at $.113 per kWh. Going on those assumptions here are the cost break downs:

Device Average Consumption kWh Per Year Cost Per Year
Galactica 91.5W 801.54 $90.57
PlexPi 5.9W 51.684 $5.84
WebPi 2.1W 18.396 $2.08

It's actually cheaper to run my dual Pi set up than for me to keep our Keurig plugged in (and off). Even with a very conservative estimate and only comparing against idle consumption on the old KVM box I'm saving over $82 a year. I didn't quite hit my goal of paying the hardware off in one year, but I'm still quite happy with the results.

PlexPi. Velcroed to the wall in my closet

~MJ

Developing for Google App Engine from ChromeOS

The backstory

The holiday season brings with it a lot of great things including family, traveling, and a lot of time to relax. I travel pretty frequently and am accustomed to the whole process. I make it a personal challenge to see how slim I can pack (much to the exasperation of my wife). For this trip, in particular, my goal was to only bring one laptop. As I was packing to go on vacation I basically had one rule: no work laptop.

No problem. I'll just use one of my laptops (I am an IT guy, after all). Well, as it turns out I only have two laptops. One is an ASUS G75VW, a 17.3" gaming laptop (it's really a mildly portable desktop), and the other is a 10" ASUS Chromebook Flip.

I love my Flip. It's got great battery life that lasts 10-12 hours and is the perfect size for traveling. If Erin and I go to a coffee shop I frequently just have her toss it in her purse next to her iPad. As a convertible laptop I can play games on planes during take-off/landing, but it still has a physical keyboard.

Chromebook Flip and a coffee.. the essentials

Alright, alright, to the point of this post. One project I wanted to work on during my down time was my GAEmes database. Normally I'd just remotely access a virtual machine running from my apartment to write and submit code. For whatever reason I decided it would be a fun challenge to see if I could completely adapt my workflow to allow for App Engine development from the cloud. This means no remotely accessing machines I've got stuffed away in my closet.

Coding in the cloud

The first step was to figure out some way of writing/testing code from ChromeOS. There were two paths I could take. I could either write code locally on my Flip and find some way to deploy it into App Engine or find some sort of cloud IDE that would allow me to write and test code from the browser.

I ended up going the cloud IDE route because it seemed a bit more true to the nature of my challenge. There are a couple of options out there: Nitrous.iocodeanywhere.com, and c9.io (to name a few). Nitrous seems to directly support App Engine development, but doesn't have a free tier. I ended up going with Cloud9 because it was free, integrated into GitHub, and I could get the App Engine devappserver working (sort of).

Setting up a Cloud9 Workspace

Setting up a Cloud9 workspace is surprisingly easy. You can set up a free account at c9.io or log in with your GitHub or Bitbucket credentials. The latter options give you instant integration with your repositories.

Once signed in you can either clone one of your pre-existing repos into a workspace, try out the test workspace, or create a new workspace from scratch. For the purpose of this post I'll assume you're creating a new workspace from scratch. Be sure the keep the custom template selected.

Create a workspace with the custom template

This will drop you into the Cloud9 IDE interface for your newly created workspace. I've found the tiling options to be super useful for working on a small screen. Of particular note you'll see a bash terminal at the bottom of your screen. That's where we'll need to do a little work.

Cloud9 IDE

Installing Python App Engine SDK

We need to download, install, and configure the Python App Engine SDK to handle debugging and deploying our app. Let's get started.

$ VERSION=1.9.30
$ cd ~/
$ wget https://storage.googleapis.com/appengine-sdks/featured/google_appengine_$VERSION.zip
$ unzip google_appengine_$VERSION.zip

You should now have a folder in the home directory called google_appengine. This contains everything you need to deploy your app. Google has some great documentation on uploading and deploying apps to AppEngine.

Note: The first time you use appcfg.py you'll need to specify the --noauth_local_webserver flag.

Set up devappserver2.py

At this point you have everything you need to deploy an app. However, the debugging process will pretty painful if you need to deploy to AppEngine to test any change. The dev app server is great for debugging, but requires a bit of hacking to make it work in the Cloud9 environment. Full credit for this bit goes to Ole over at stack overflow.

First, open up the devappserver code:
$ open ~/google_appengine/google/appengine/tools/devappserver2/devappserver2.py
This should open up devappserver2.py in the text editor. First, comment out the following lines (lines 827-830 in SDK 1.9.30).
admin = admin_server.AdminServer(options.admin_host, options.admin_port,
                              self._dispatcher, configuration, xsrf_path)
admin.start()
self._running_modules.append(admin)

Next, we need to add the second line below (currently located at line ~1030). I've added the previous line for context:

options = PARSER.parse_args()
# Add this next line
options.host = os.environ['IP']
Lastly, modify the following lines (currently 927-928):
return api_server.APIServer(options.api_host, options.api_port,
                            configuration.app_id)
to look like this.
return api_server.APIServer(os.environ['IP'], options.api_port,
                            configuration.app_id)
You should now be able to launch the devappserver (without the use of the admin console, sadly). Once serving you can use the preview menu to view the served content.


That's it! You should now be able to write, test, and deploy apps for AppEngine from a ChromeOS device.

~MJ

GAEmes: A board game database built on Google App Engine

My first proper game
It's no surprise to many of you that I'm pretty big into board games. For me it all started when some friends invited me to a game night at their place back when I was in college. We played crazy games like 7 Wonders, Small World, and Settlers of Catan. These same friends were the ones who gave me my first proper game: Bohnanza.

Fast forward several years into the future and that one game turned into a collection of over 100 games. Keeping track of that collection starts to get a bit tedious when it's large and distributed throughout different closets and shelves in the apartment. As a result a few years ago I cobbled together a MySQL database with a shoddy html/php frontend.

This database allowed me to query my collection for games that could accommodate a certain player count and/or time limit. It was particularly useful when friends would come over and we'd sit down to figure out what to play.

Now that I've got this blog to look after I figured a fun project would be to open source my work in a more useful way. As a result, I've just publicly released the initial version of my most recent project: GAEmes

GAEmes is essentially a re-creation of that database I made so long ago. In true fashion the front end looks like rubbish, but it's functional.

GAEmes database landing page
A couple of things that set GAEmes apart from my first attempt are it lives in Google App Engine and actually has an authenticated admin page. App Engine is great for a number of reasons. It's scalable, low maintenance, free*, and isn't burning a hole in the electric bill at the apartment. The admin interface allows for the addition of games to the database by app owners (authenticated by Google account).

GAEmes database admin page
The best news is the only prerequisite is having a Google account (and a bit of time to fiddle with deploying to App Engine). If you're not interested in the code on GitHub perhaps you'll find the official Riley GAEmes Database interesting.

~MJ

*Free, assuming you stay beneath the daily quotas and don't have a billing account set up.

Pedaltrain PT-1 Pedalboard Makeover

This is, admittedly, a cheap post. I did this project a few months back but I still think it's pretty cool. Lately I've been playing electric guitar pretty frequently at church. Much of the modern christian worship music sounds pretty similar. This is actually really convenient if you want to be able to build a set up that allows you emulate those sounds. So, for the better part of the past year I've been building/assembling a pedal board for my guitar.

Pictured is what a fairly standard pedal board looks like (sans pedals). As you can tell it's pretty bland. In particular I came to the conclusion that I didn't like the gaudy Pedaltrain logo on the front side. Being the creative* person that I am I figured it would be cool to give it a bit of a paint job to freshen things up.

*At this point in time it's prudent to mention that the last time I attempted something which could be construed as art was in college. Our residence hall E-Board had assembled to make posters for some sort of event. The poster I created had what I thought was a fairly convincing likeness of a brown dog on it. Upon revealing my masterpiece everyone asked why I had drawn a brick of poop. My poster was promptly discarded.

Here's pretty much the same view post-makeover. I spray painted a base white coat to help cover up that nasty logo before covering it up with a lovely blue. I topped it off by stenciling my initials and some gears on the front. Considering my creative track record I think it turned out pretty good.

A couple things I learned throughout the process. Be sure to check the drying times of all the paints used. In my case the base white paint had a much longer drying time than that of the blue an gold I was applying over it. Lastly, don't use spray paint. At the time it seemed like it would be the easiest way. In order to get thick enough coverage I had to spray pretty closely which caused the paint to run. Something you can brush on will probably give you a much better result in the end.

There you have it. Project Pedalboard Makeover was a success (by some definition of the word). I'll leave you with this picture of the pedalboard fully assembled and ready to go.

~MJ