Fetching instances from inside a custom Puppet provider

Back to Listing

Hanover, MD, 10 December 2017


The Problem

While creating a custom type for cleaning up stunnel::instance artifacts on the system, I needed to get a list of services that were running on the current host.

This is also something that the svckill native type requires, and was implemented manually in the past, so I thought that there had to be a more reusable method built into Puppet.

The Resolution

I started writing the stunnel_instance_purge type and thought that all services should be prefetched for optimization and that I would be able to get grab those prefetched instances without issue.

I was wrong on both counts!

Since I was targeting sysv and systemd systems, I started by taking a look at the lib/puppet/provider/service/init.rb file.

Here, I found that instances was defined but prefetch was not. This means that the puppet resource service command would be able to return information from this provider but that the information would not be prefetched into the catalog.

Honestly, this does make sense for sysv-style systems since there have been a number of scripts over time that behave badly when queried so fundamentally, this route was going to be unavailable to me for those.

But, I reasoned that, with chkconfig --list and systemctl list-unit-files *.service, I should be able to get some level of prefetch magic. Unfortunately, neither of those prefetched their services either!

Back to the Drawing Board

Having exhausted my hopes for prefetch, I started trying to figure out if there was an easy built-in method to get the instances on the running system.

It turns out that is pretty easy (if a bit confusing) to query the RAL from inside the custom type so that you can get a list of everything that the instances method will return on a given system.

Most instances methods don’t cache, so be careful with this since you’ll be executing whatever it calls to do its work each time.

The following will call the indirector and return all RESOURCE_TYPE resources that are returned by the instances method of the relevant providers. This behaves the same way as running the puppet resource RESOURCE_TYPE command from the command line.

Puppet::Resource::indirection.search('RESOURCE_TYPE', {})

As a more concrete example, the following would fetch all Service resources known by Puppet on your system:

Puppet::Resource::indirection.search('Service', {})

And would return something like the following:

[
  Service[NetworkManager-dispatcher.service]{:name=>"NetworkManager-dispatcher.service", :ensure=>:stopped, :enable=>:true, :provider=>:systemd, :hasstatus=>:true, :pattern=>"NetworkManager-dispatcher.service", :loglevel=>:notice},
  Service[arp-ethers.service]{:name=>"arp-ethers.service", :ensure=>:stopped, :enable=>:false, :provider=>:systemd, :hasstatus=>:true, :pattern=>"arp-ethers.service", :loglevel=>:notice},
  Service[auditd.service]{:name=>"auditd.service", :ensure=>:running, :enable=>:true, :provider=>:systemd, :hasstatus=>:true, :pattern=>"auditd.service", :loglevel=>:notice},
  Service[autovt@.service]{:name=>"autovt@.service", :ensure=>:stopped, :enable=>:true, :provider=>:systemd, :hasstatus=>:true, :pattern=>"autovt@.service", :loglevel=>:notice}
]

Reflection

I am very much hoping that the folks over at Puppet decide to provide a method where various resources can dig into cached version of items that have been prefetched but I have a feeling that this isn’t high on anyone’s priority list.

Trevor has worked in a variety of IT fields over the last decade, including systems engineering, operating system automation, security engineering, and various levels of development.

At OP his responsibilities include maintaining overall technical oversight for Onyx Point solutions, providing technical leadership and mentorship to the DevOps teams. He is also responsible for leading OP’s solutions and intellectual property development efforts, setting the technical focus of the company, and managing OP products and related services. In this regard, he oversees product development and delivery as well as developing the strategic roadmap for OP’s product line.

At Onyx Point, our engineers focus on Security, System Administration, Automation, Dataflow, and DevOps consulting for government and commercial clients. We offer professional services for Puppet, RedHat, SIMP, NiFi, GitLab, and the other solutions in place that keep your systems running securely and efficiently. We offer Open Source Software support and Engineering and Consulting services through GSA IT Schedule 70. As Open Source contributors and advocates, we encourage the use of FOSS products in Government as part of an overarching IT Efficiencies plan to reduce ongoing IT expenditures attributed to software licensing. Our support and contributions to Open Source, are just one of our many guiding principles

  • Customer First.
  • Security in All We Do.
  • Pursue Innovation with Integrity.
  • Communicate Openly and Respectfully.
  • Offer Your Talents, and Appreciate the Talents of Others

programming, puppet, ruby

Share this story

We work with these Technologies + Partners

puppet
gitlab
simp
beaker
redhat
AFCEA
GitHub
FOSSFeb