Sending automated notifications to HipChat rooms

At work we have been piloting HipChat’s new self-hosted on-premises option for the last few months.  It has been great having a bunch of people who work in different buildings and on different schedules using shared chat rooms for communication.

I have also been experimenting with hooking HipChat into our toolchain. We now have a chat room where every Capistrano deployment is announced, and another where all of our high-priority Zabbix alerts are collected. HipChat makes this easy with their version 2 API’s room notifications feature. A room owner can simply generate a room-specific API token and plug it into a script to send notifications.

Here is an example:HipChat Zabbix Alerts

And to make it easy for the next person who wants to do this, I’ve released the code on GitHub in my zabbix-scripts repository.

There are three pieces of the puzzle:

  1. A Zabbix alertscript that expects a specific input, but needs no customization. This script then calls…
  2. A generic HipChat notifications script that is completely Zabbix-independent. This script has one external dependency (the “micro-optparse” RubyGem) and requires a configuration file with your HipChat API token. You can use this script with Zabbix or in any other way you’d like, including directly from the command line.
  3. Zabbix configuration to support the alerting, which takes the form of a new “Media Type” that points to the alert script and a new “Action” that outputs data in the prescribed format (documented in the README).

And 15 minutes later, you’re in business with pretty and useful Zabbix notifications in HipChat.  I used a similar process for the Capistrano integration, although I’m probably not going to bother to post that since we are happy on Capistrano 2 and the completely re-written Capistrano 3 is utterly backwards-incompatible.

Bridge to Mt Moosilauke trailhead

Moosilauke revisited

On Saturday Mat and I hiked Mount Moosilauke, one of New Hampshires “4000-footers.”  The weather was warm (40s), although the day was overcast and the summit was fogged in.  We got a late start after a wrong turn (kids, bring maps!), so we were a bit concerned about daylight.

A trail report from a few days earlier indicated that it would be smooth going, but apparently we mis-read it, because everyone else on the mountain that day had either skis, snowshoes, or both.  We had neither, and for the first 3+ miles almost ever step resulted in snow up to our knees.

We held out hope that as we gained elevation (and colder weather) the base would be harder-packed.  That was the case eventually, but the slow going coupled with our late start made us decide to turn back prior to the summit.  It was an adventure regardless, and on the way down we got in a lot of “sledding” on our behinds, which was a blast.

The eighth iteration

The last time I substantially changed this blog was in 2009, and in the last few years it has languished. I’m very happy with this modern update, which is very clean, simple, and content-focused. I’ve removed almost everything else, which should help me focus on the writing.  I plan to back-fill some posts from things I’ve written on Facebook and elsewhere, and go from there.  Welcome to AgBlog version 8, now with a new name and location!

Dan and Jess at Newport Beach

A brief California whirlwind

On Friday I headed out to the West coast for a brief visit in order to surprise Aunt Linda on the occasion of her 60th birthday party. Well, she was surprised, thanks to some excellent planning, scheming, and misdirection. It was a really nice party.

On Saturday the out-of-town partygoers gathered at Strand Terrace for brunch.  I always love it when we host meals while I am in town because it is fun to cook together as a family.  Shaina made quiche, I chopped things and cooked up bacon, Mom made an apple cake, and Dad and Jess cooked as well as taking care of all the grocery shopping. The parents have redone their patio to give it more of an “outdoor living room” feel, and I think it really works — definitely a good fit for the California climate.

On Monday Jessica, Mom and I went paddle boarding in Newport Beach, which is fun once you recognize how absurd and inefficient it is.  The high winds kept pushing us back and threatening to topple us over, but we made it to our arbitrary goal (a bridge) and back without major incident.  In the morning Mom and I had also hiked at Santiago Oaks, so it was an active sort of day.

Throw in some family time, pool time, meal time, and beach time, and cap it with lunch at In-N-Out — a pretty good few days in the sun!  I’m sad that the trip is already over, but I’m spending a few days in Portland with Jessica before heading back home.

Docking the hype of Docker (sort of)

Update 4/22/14: James Turnball has covered similar territory and reached similar conclusions. In fact the more I look, the more I see this debate playing out and the first generation of solutions beginning to take form. In just two months I’m now much more optimistic about the immediate applicability and viability of Docker to real-world problems.

I originally posted this entry on the HUIT DevOps community blog

DockerWhen I first heard about Docker I knew it was something to watch.  In a nutshell Docker is a mechanism on top of Linux Containers (LXC) that makes it easy to build, manage, and share containers.  A container is a very lightweight form of virtualization, and Docker allows for quickly creating and destroying containers with very little concern for the base OS environment they are running on top of.

Because Docker is based around the idea of running “just enough” OS to accomplish your goals, and because it is focused on applications rather than systems, there is a lot of power in this model.  Imagine a base server that runs absolutely nothing but a process manager and the Docker daemon, and then everything else is isolated and managed within its own lightweight Docker container.  Well imagine no longer, because it is being built!

But with power always come responsibility, and Docker has a caveat you can drive a truck through — the ephemeral, process-oriented nature of Docker strongly favors moving back to the old “Golden Master Image” approach to software deployment.  That is to say, its great that you can easily distribute a completely isolated application environment that will run everywhere with no effort.  But in doing so, it is very easy to ignore all of the myriad problems that modern configuration management (CM) systems such as Puppet were built to address.

Continue reading

New to Mac or Linux? Try this basic shell configuration

I originally posted this entry on the HUIT DevOps community blog

I’ve recently worked with several folks who live in a Windows world and are either moving to a Mac laptop or have to do work on a Linux server.  In the DevOps world, developers are often pushed outside of their comfort zone.  Having to work in a UNIX shell can be quite disconcerting.

While I can’t give you a 5-minute primer that takes all the pain away, I can point you in the right direction.  I have created a Bash shell configuration that provides some sane and useful command line defaults, much better than what you get out of the box.

Continue reading

Moonrise Kingdom (2012)

This movie is absolutely wonderful. A boy and girl who are outsiders and without friends find solace in one another and run away together on an island in New England. All the typical Wes Anderson charm and whimsy is on display, and the plot takes an unexpected turn half-way through. Excellent performances by all involved, and some amazing faux-1960s kitsch.

Some people love Wes Anderson, some hate him, for me it really varies by movie — I couldn’t stand Royal Tenenbaums, but I couldn’t get enough of this. Just perfect.

Salty W Dog

A new member of the family

And now we are four.  Salty is a yellow lab/collie/something mix that we adopted from Northeast Animal Rescue. He comes to us 3 months old and weighing 13 lbs, and will probably quadruple in size in the not-too-distant future.

Our Feel-Good War on Breast Cancer
This week’s New York Times Magazine cover story is an in-depth and pretty devastating critique of three decades of breast cancer awareness campaigns, especially focused on the Susan Komen foundation. The one sentence summary: Komen’s campaigns aren’t helping to cure or prevent cancer, they aren’t dispensing good medical advice, but they are causing women to live in unnecessary fear.
How Boston exposes America’s dark post-9/11 bargain
I’m proud of how the people and politicians of Boston reacted to the bombing of the 2013 Marathon and resulting manhunt. But I share a lot of this columnist’s anger at the choices we as a country have made about how we confront terror, and what those choices have cost us.

Capistrano multistage deploy configuration stored in a YAML file with MultiYAML

I spend a lot of time working on deploying a variety of software applications smoothly to different environments. A tool central to my workflow is Capistrano, an SSH-based deployment framework written in Ruby. In its Ruby-ish way, Capistrano’s multistage functionality requires stubbing out different Ruby files for each stage — staging, production, etc. In our environment, I decided it was better to instead store all of the per-stage configuration in one single configuration file, and I chose to do it in the simple YAML format. There are several advantages to this approach:
  • The file format is straightforward and can be modified both by humans and scripts, including automatic updates from a central source of truth.
  • There are fewer configuration files, and within the single configuration file there is much less repetition of configuration, because we can use YAML’s built-in anchor/alias functionality.
  • It strongly encourages storing deployment logic in the deploy.rb file and hooking tasks using Capistrano’s before/after callback functionality, rather than building stage-specific tasks.
The module I built is inspired by Jamis Buck’s original Capistrano multistage module, as well as Lee Hambly’s prototype YAML multistage extension, which was never packaged and is no longer maintained. My capistrano-multiyaml module is available on GitHub along with documentation, and can be installed via RubyGems.
Unfit for Work
NPR’s Planet Money investigates the 14 million Americans on a “hidden” form of welfare — disability. Eye opening.
As it gets easier for one member of a group to destroy the entire group, and the group size gets larger, the odds of someone in the group doing it approaches certainty. Our global interconnectedness means that our group size encompasses everyone on the planet, and since government hasn’t kept up, we have to worry about the weakest-controlled member of the weakest-controlled country. Is this a fundamental limitation of technological advancement, one that could end civilization? First our fears grip us so strongly that, thinking about the short term, we willingly embrace a police state in a desperate attempt to keep us safe; then, someone goes off and destroys us anyway?

Bruce Schneier's chilling new op-ed