Logstash is a really nifty log shipping, indexing, and searching suite. The typical centralized setup involves running a shipper agent on all your nodes, which are configured to ship certain log messages to a message broker. An indexing agent consumes the log messages from the broker, and writes them to elasticsearch. Logstash comes with a light web interface for searching this data.

Me, representing Puppet, versus Reza, good friend and lowly Chef user, at the moment of Puppet’s glorious victory:

Some time ago I worked with Reyk Floeter on the ininitial implementation of a new datacenter network during my time at one of the more well-known Information Security vendors. Reyk had this phenomenal idea for the network structure that seemed to simple it was one of those “why didn’t I think of that” ideas. So after we deployed, I looked over the net and couldn’t really find docs of people doing this, so I wrote a really short paper and some basic slides on it and presented at LOPSA PICC ‘11. I kind of suck at presenting, but this topic is actually super easy to understand, so I was able to get my ideas out fast and then answer a lot of questions. Anyways, this paper came up in an IRC chat tonight and I figured I should post a link to it, here ya go.

A couple gigs ago we were an Atlassian shop and I am actually a big fan of Atlassian software, though it takes a lot of work up front to get it deployed in the way you like, but I’m not going to cover all that here. What I did though was I enabled the SOAP api for a user named Puppet, opened up the IT or Systems area so I could write something here:

1

http://confluence.yourorg.com/Systems/${fqdn}

Recently I made a post about using Git submodules for Puppet and I pasted some code I use to interact with the repo and ensure I get the workflow right. One of these scripts, promote.sh, had a feature that listed commits not yet in the master branch of each submodule. This was done with git log master..develop. Unfortunately, this command will show commits that have been cherry-picked as not yet merged, since cherry-picks get a new SHA on the branch you bring them into. After doing some digging, I found a new command: git cherry.

One of the tasks when setting up a new master is to set up a new CA. This is not something most people think about because Puppet does it automatically for you. However, unless your puppet.conf is in place already, it may not create 4096 bit keys. Also, if you’re doing a completely automated setup of a new organization, you might want to just run a script to generate the CA in a version controlled directory.

As I’ve mentioned before I use a large set of cross-platform, relatively generic modules that I wrote for a system I call GRUMPS. The problem with this method is that you’re going to need to have some ERBs and files that are custom to your organization.

An often over-looked part of Puppet is the fact that you can programmatically test changes. The Puppet master has a –compile feature, which will work if you sync the fact YAMLs from your master to the machine you run the –compile from.

Often, in Puppet manifests you will find you need some arbitrary information about machines in your infrastructure. The stored configuration database, for all its blemishes, can be an easy way to achieve this.

Git submodules are somewhat of an ‘advanced’ git feature, akin to Subversion externals for those of us unlucky enough to have the pleasure of knowing svn. The most common usage is pulling in third party libraries to your project. You can think of git submodules as git checkouts within checkouts. The ‘parent’ checkout or ‘super-project’ as I call it, knows that there are submodules, and knows which SHA each submodule is at. Since most of my work as both a Systems Engineer at $dayjob and a general IT consultant part-time, I needed to use submodules slightly differently than the most common use-case.

During some time off during 2011 from having a dayjob, I developed a lot of Puppet code that used what was at the time new features like Parameterized classes, hashes, etc. I also pretty painstakingly made sure the code would work on OpenBSD, Debian, Ubuntu, Red Hat, and CentOS. The plan was to keep this code private and charge people for the service of supporting this set of modules and develop new ones etc. So, I needed a way to let people pull this code into their Puppet repo and use it. Submodules are the only easy way to do this. This code, along with some scripts to set up an environment utilizing this code was what I called the GRand Unified Modular Puppet System (GRUMPS).