Recent Blog Posts

How can I get my PR merged into your open source project?

Recently I received an email from an IT student asking the following: I recently submitted a pull request to one of your open source projects on GitHub. What can I do to get this pull request merged? The answer below may sound somewhat like a cop-out, or harsh (especially considering it was to a starry-eyed student trying to dip his or her toes into the waters of open source software contribution)... but I've found that honesty is the best policy, and the best way I can maintain good OSS software is to guard my (limited) time for OSS work vigilantly, and try to not allow sentiment force the merge of any kind of code, no matter how simple/small the change. Here is my reply:

Thanks for the email! I maintain over 100 different open source projects on GitHub, all in my spare time (which can be hard to come by with 3 kids, a full time job at Acquia, and a few other hobbies!). I spend a few hours per quarter on any given project. Some of the more popular projects have dozens of issues, PRs, and new comments that need to be read through to figure out what I need to these few hours on.

Fixing a 2011 MacBook Pro booting to a Grey Screen - AMD Radeon Video Glitch

I've been a Mac user for years, and I've repaired hundreds of different Macs, from the early II series to the latest 2015 and 2016 model MacBook Pros, iMacs (and other Apple hardware to boot!), and there is almost never a hardware situation where I've thrown in the towel and told someone to ditch their Mac.

The 2011 MacBook Pro has, for almost a decade, been the exception to that rule. There was a major flaw in the AMD Radeon GPUs included with that model year's logic board which seemed to cause GPU failure either due to overheating, internal chip problems, BGA solder joints getting broken, or a combination of the above. The problem was so rampant, Apple was forced to set up a free repair program for affected MacBook Pros—though the 2011 model has since been dropped from that program. I've handled three 2011 MacBook Pros (none of them my own—I had an Air back then), and all three of them were scrapped because of the GPU issue.

Getting the best performance out of Amazon EFS

tl;dr: EFS is NFS. Networked file systems have inherent tradeoffs over local filesystem access—EFS doesn't change that. Don't expect the moon, benchmark and monitor it, and you'll do fine.

On a recent project, I needed to have a shared network file system that was available to all servers, and able to scale horizontally to anywhere between 1 and 100 servers. It needed low-latency file access, and also needed to be able to handle small file writes and file locks synchronously with as little latency as possible.

Amazon EFS, which uses NFS v4.1, checks all of those checkboxes (at least, to a certain extent), and if you're already building infrastructure inside AWS, EFS is a very cost-effective way to manage a scalable NFS filesystem. I'm not going to go too much into the technical details of EFS or NFS v4.1, but I would like to highlight some of the painful lessons my team has learned implementing EFS for a fairly hefty CMS-based project.

Properly deploying updates to or shutting down Jenkins

One of my most popular Ansible roles is the geerlingguy.jenkins role, and for good reason—Jenkins is pretty much the premiere open source CI tool, and has been used for many years by Ops and Dev teams all over the place.

As Jenkins (or other CI tools) are adopted more fully for automating all aspects of infrastructure work, you begin to realize how important the Jenkins server(s) become to your daily operations. And then you realize you need CI for your CI. And you need to have version control and deployment processes for things like Jenkins updates, job updates, etc. The geerlingguy.jenkins role helps a lot with the main component of automating Jenkins install and configuration, and then you can add on top of that a task that copies config.xml files with each job definition into your $JENKINS_HOME to ensure every job and every configuration is in code...

Getting Munin-node to monitor Nginx and Apache, the easy way

Since this is something I think I've bumped into at least eight times in the past decade, I thought I'd document, comprehensively, how I get Munin to monitor Apache and/or Nginx using the apache_* and nginx_* Munin plugins that come with Munin itself.

Besides the obvious action of symlinking the plugins into Munin's plugins folder, you should—to avoid any surprises—forcibly configure the env.url for all Apache and Nginx servers. As an example, in your munin-node configuration (on RedHat/CentOS, in /etc/munin/plugin-conf.d, add a file named something like apache or nginx):

# For Nginx:
[nginx*]
env.url http://localhost/nginx_status

# For Apache:
[apache*]
env.url http://localhost/server-status?auto

Now, something that often trips me up—especially since I maintain a variety of servers and containers, with some running ancient forms of CentOS, while others are running more recent builds of Debian, Fedora, or Ubuntu—is that localhost doesn't always mean what you'd think it means.

Ansible for DevOps - 50% off on LeanPub for Black Friday 2017

Though I've had a little less time to work on the book lately, I'm still very much invested in keeping Ansible for DevOps the best and most up-to-date guide to using Ansible for infrastructure automation. It's been over two years since the first '100% complete' edition was released, and in that time I have published over 200 updates on LeanPub—and even have full test coverage for all the book's examples, which are open-sourced and available in the Ansible for DevOps GitHub repo!

Ansible for DevOps - 50% off for Black Friday 2017

For this year's Black Friday, I'm discounting the book—50% off—but only on LeanPub. I like to push readers to LeanPub, because:

Pages

Subscribe to Jeff Geerling's Blog