words with kitchen

thoughts and ramblings of a pedal powered geek

Off to PuppetConf 2012

Tonight I’m heading up to San Francisco for PuppetConf 2012!

I’m really looking forward to this conference, the talks they have lined up look really amazing. My only regret is that I can’t be in more than one place at a time. Hopefully they’ll record all of the talks and make them available online, as I imagine a lot of them would serve as excellent documentation.

Here’s the schedule of talks I’ll be attending:



And here’s a list of the talks I’ll hopefully be able to download videos of afterward:

thursday talks

friday talks

If you’re going to be going to PuppetConf 2012 and want to meet up, just toss me a mention on twitter and we’ll get together for a beer or 10. I will definitely be heading to 21st Amendment probably Thursday night after the VMWare social bar, so you might just look for me there!

Hope to see some folks there!

Introducing Peabody

I’m proud to announce the arrival of peabody, cron’s best friend!

Peabody grew out of a need for various features I found myself continually writing into cron jobs.

Here are some of its key features:


Everyone has always told you to avoid running your cron jobs “on the hour” or “right at midnight”, and you know it’s bad, but you still do it, and often times, if you’re using one of the @hourly-style features, you don’t have much choice. But you also have thousands of jobs, and you don’t want to have to modify all of them to put in random sleeps to spread the spike out around the interval. What happens if you want to change the duration of the sleep, now you have to change a line of code.

Not anymore! Peabody’s “splay” feature allows you to delay starting your job by a random interval up to the duration you specify. Since this lives outside of your code, and on your systems, you are the one who has control over the duration, and you can change it any time you want should you require. Additionally, it doesn’t require modifying any existing code. You simply add peabody -s <interval> in front of the command in your cron entry, and you’re done!

concurrency protection

You have a cronjob which you want to run every minute. But sometimes that job can take more than a minute to run. And the job isn’t very smart, so a second job will start working on the same things, maybe even stepping on the work the other one is doing. How can you fix this?

Well, you could have your job be smarter about the work it’s doing and make it so it doesn’t step on its friends. This has problems of its own if you have a high rate of queue injection and the individual tasks consume a lot of resources. Not to mention this is a whole lot more than one line of code!

Or, you could have your job check to see if there’s already a copy of itself running. But then you’d have to do this in all of your jobs, and that’s a headache. Did I mention the line of code?

Or! You could just let Peabody do it for you! Simply add peabody -l /tmp/jobname.lock before the command in your cron entry, and now only one can run at a time and you can make everything run at 1 minute intervals. Logs bedamned!


Maybe your job takes a while to run, but you know that if it takes over an hour, it’s gone on too long. You could write some sort of timeout into your code. And honestly, you should. Seriously. Your code should time itself out. I’m not even kidding.

But, maybe you can’t! Maybe it’s a third-party program which you don’t have any easy control over. It doesn’t have to be a closed source program to have issues like this.

Peabody to the rescue! Simply put peabody -t <softtimeout> -T <hardtimeout> in front of your job and off you go! Once the job has run for the softtimeout interval, Peabody will send a happy little SIGTERM to your job, asking it to stop what it’s doing and get lost. If that doesn’t work (or you just want to be a little more harsh out of the gate), once it reaches the hardtimeout interval, Peabody will send your job a SIGKILL. Not even Linus can ignore a SIGKILL (unless he’s busy flirting with your NFS server).

ok, I’m sold

Great! Head on over to the Peabody page on GitHub and check it out!

where do we go from here?

Peabody was initially conceived to take the output of a cron job and shove it into logstash. It’s actually rather ironic that it doesn’t yet do this. However, it is on the roadmap, and it is definitely still something I want to add. I just got a bit distracted by all the other things I would want a wrapper like this to do.

My Mutt Setup

For many years off and on, I’ve tinkered around with mutt, with varying degrees of success. At the very least, it’s always been in the back of my mind every time I get fed up with my mail client du jour. Recently, after a 3 month stint of using Outlook at work, I decided to give mutt another shot. Fortunately, this time I was sucessful, and I’m now using mutt as my primary email client both at work and at home. Let me tell you, it’s a breath of fresh air!

(Pretty, ain’t it?)

Because I’d had so many difficulties with mutt in the past, and now have things set up fairly decently, I thought I should write something which might prove helpful for other potential mutt users, or maybe even seasoned veterans.

Jekyll, Bootstrap, and Octopress

So, here we are, again.

After many years of trying to start up writing a blog, I was never really overly pleased with the available offerings. Every now and then a new blogging system would come along and I would check it out, but ultimately, I kept falling back to WordPress. And, as great as WordPress is, I felt like operating the blog was more work than writing content for it, and seeing as how I used to work for a web hosting company which specialized in WordPress, and having to deal with all of the issues of hacked installs, broken upgrades, etc… It just didn’t feel like “home” to me.

Back in December of 2011, while attending LISA ‘11 in Boston, I heard about a project called Jekyll and I was immediately curious. I’ve been using git for some time, and I really do try to find any excuse I can to use revision control. There’s just something about revision control that gets me stoked. Anywho. So I heard about Jekyll and decided I wanted to play around with it. The concept of a completely static site generator where you template everything and then write your pages/posts with markdown in one-file-per-post sort of way really piqued my interest. Then I found out that GitHub pages was powered by Jekyll, and being a big fan of git, GitHub, and the entire ecosystem, I was sold.

Unfortunately, after playing around with it for a while, I realized that I just wasn’t that interested in building all of my templates and such from scratch. I’m not an HTML guy. Don’t get me wrong, I like HTML just fine, it’s just that I don’t have the mindset of “semantic markup”… Or maybe, I have too much the mindset and just get caught up in the details and never go anywhere. It certainly doesn’t help that I’m terrible with CSS, so anything I create [ed: scriptkitchen.com now just points to my blog] looks awful, and I am not patient enough to spend hours tweaking my site so it looks and works great in every browser. (Don’t get me started on IE).

Then, a few days ago, along came Jekyll Bootstrap. I thought to myself, “this is amazing, this is exactly what I’ve been looking for.” Sadly, after playing around with it some more, I realized that it wasn’t quite what I was looking for. I had to do a lot of work just to uncruft the default clone, I had to write my own index page which would show me my latest posts, and it just didn’t feel all that much like “home” to me either.

However, the bug had bitten me. I wanted to do a blog again. Dammit.

At first, I was hoping to find something which could run fully on GitHub’s servers when I commit. I’m a firm believer in “only things which are required to build the project should go into source control”. Since GitHub would be building the static site for me, I needed to make it so I worked within GitHub’s constraints. I realize, now, that this was one of my biggest mistakes. Having it so I fully generate the site locally, and then upload the generated site, gives me so much more flexibility. I mean, the site is going to eventually be fully static anyways, right? Why not build it here and push it up already-built?

A bunch of googling later, and I stumbled across Octopress. This is exactly what I’ve been looking for. It has a default front page with layouts and partials so I can change the templates and they update the view on the front page as well as on the post page, and it does pagination on that! It has a premade archive page to list out the various posts over time. It has a bunch of plugins which make things like gist inclusion and really cool stuff like pull quotes ridiculously easy. It … It’s just … It’s just amazingly awesome, and the default theme, while pretty generic, is pretty and functional and clean and … Yes.

So. Here we are. Again. This time, I’m in full geek-out mode. And when I go full geek-out mode, shit gets done.

I look forward to this relationship, Octopress. May we have many great times along the way.