but also I think Facter knows about the extension and won’t try to run in on linux… maybe?

dont deploy external facts to nodes that dint require them :)

This message was deleted.

This message was deleted.

The former uses the system’s DNS resolver. The latter uses /etc/hosts and implements its own weird caching, which has a lot of problems, especially around not honoring TTL’s and the like.

Hello Team! Any documentation help to migrate from Puppet Enterprise to Open source puppet..? Even new open source puppet server setup and add tools to daily operations and management.. Thanks!

This message was deleted.

https://github.com/voxpupuli/puppetboard, along with puppetdb can give you some level of dashboarding. but i am not sure how it compares to PE

This message was deleted.

@jhoblitt I think it was you asking for a way to get all classes installed in environments. You might take a look at https://github.com/puppetlabs/dropsonde/pull/26, I’m using that list to identify unused modules.

@binford2k ++

in that regards, https://github.com/puppetlabs/r10k/pull/1314

Bump for the pull request. TIA.

for detecting dead code, https://github.com/voxpupuli/puppet-ghostbuster is also nice

This message was deleted.

Are other branches checked out into their own environment/ directory on the Puppet server?

Trying to test a branch that you clone/check out directly onto an agent might be problematic, especially if you're pulling modules from Puppet forge.

message has been deleted

I messed up my puppet master’s

auth.conf

so it’s rejecting

/puppet/v3/catalog

requests. It happened to touch that file during a puppet run, so I’m trying to find if there’s a bucketed of the original. Where would I look for that?

Oh. I think it’s because I turned on

allow-header-cert-info

I’m getting this on a server it was working on. The class I’m using to manage puppetservers did bad touch and broke it somehow. The gem is still installed with

puppetserver gem

, but broken somehow

This message was deleted.

In my current puppet environment, we've made use of https://github.com/kumina/fact-pci_devices which creates raidcontroller<digit>_driver style facts based on lspci output. I need a way to load packages if any one of those facts matches megaraid. Currently, we have systems that would match where the digit is anywhere from 0 to 6. Is there a nice way to do a glob in the name of a fact in puppet code: bash like psuedo code:

for i in raidcontroller*_device; do
  if $i ~ 'megaraid.*"; then
    ensure_package('storcli')
  fi
done

we'd also have an

if defined($i)

or similar

I would rewrite it as a structured fact

Kinda looks like it builds a hash, which you should be able to iterate over.

they are all top level facts, so we'd likely need to rewrite so that we could iterate over sub items of a hash

considering storcli is so small it's easier to install it just based on some dmi information

I think you can get a key list from $::facts and then filter out for the keys you want to examine

do you have examples of that technique Joel?

Not presently.