Best way to set variables based on packages installed on client?

[HPUX_PUPPET]

I am moving from Puppet 0.25 to Puppet 4.  In doing so I am re-writing a lot of the modules to work better than what I inherited. 

So my current issue I am trying to figure out is how to update PAM variables based on what external 3rd party authentication package we have installed on that server. The old method that had been employed was to use an exec to push a file with the correct settings.  I am trying to do it via a template. 

The problem I am having is that I need to check if the PAM module is installed before making the changes and revert them if it is removed. I know I can write a custom fact, but on the 0.25 version a custom fact required both puppet.conf edits and a bounce of the agent. I haven't tried on the later versions, but I remain gun shy, 

Ideally I would run an execute to check the module and only do the changes if the PAM module is in place. I haven't figured out how to do that yet with templates. 

Has anyone else figured out the least invasive way to do this. Aka no custom facts?

Do I need to just knuckle down and learn enough Ruby to have it determine if the package is set and use one variable, if not the other? 

I am still new to Puppet coding in Puppet 4, well in general too, when getting into the weeds like this. I would assume there is a simple think like below. (Notes this is probably not correct puppet code, just a pseudocode example) 

     

    if ( ! exec { check_package: 

          path => "/usr/bin:/bin:/sbin:/usr/sbin",   

          command => "rpm -q <package>",

          } ) { 

         $extra_lines = [ 

         'blah blak', 

         'blah',

         ]

       }

Think is I just don't have enough skill yet to make it work on my own yet, so I am reaching out to see if someone already figured this out as I keep hammering on it. 

Thanks! 

             

[Rob Nelson]

I wouldn't be that shy of custom facts in Puppet 3/4 (don't know if you are stair stepping or starting fresh), they mostly "just work". Throw them in a module and poof, agents get them on the next run, and they're processed before the catalog compilation of that run so they take effect immediately. Learning Just Enough Ruby(TM) also should not make you too shy. A long time ago, I wrote a sample custom fact that parses a hostname with a regex and grabs a portion of the string (https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/lib/facter/puppet_role.rb) - if you are comfortable with regex, you can probably pick up the minimal ruby required to understand the rest of it. It wouldn't be too difficult to add a system() call to rpm and check the return code.

All that said, perhaps instead of using a fact, you could use ordering within your puppet manifest, to implement the PAM module first, THEN update the config via template afterward. This could be as simple as this:

  package{'pam-additional-module':

    ensure => present,
  } ->

  file{'pam-additional-module-config':

    ensure => present,

    path => /etc/pam.d/additional.conf,

    contents => template('profile/pam/additional.conf.erb'),
  }

This would install the package 'pam-additional-module', then install a configuration file for it based on an ERB template. Just an example you can adapt. I hope that helps!

Rob Nelson
rnel...@gmail.com

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/fd5cb2f3-8ab1-4c0e-8134-f8e5ec49c1ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[HPUX_PUPPET]

Thanks Rob!

I am sort of "starting fresh" so I have a lot of latitude here. The way it was done before was shoddy and required a lot of files, so I am trying to reduce them. 

I will go back to investigating a custom fact.  I have used them in the past, but the problem was more related to needing to manually go to each host to restart puppet so it would recognize that a fact had been added. 

Unfortunately installing PAM is less the issue as having customized lines that need to be added to the top of the files for servers using the 3rd party AD authentication for boxes where it is installed. As they had mandatory require lines, if the files are not there, we are locked out. Currently we a file param to create the needed files in temp on all boxes and then if the software was installed, we would switch files. Trying to keep it less kludgy so I was seeing if Puppet could use an RPM list from the host to check. A custom fact seems the best way to go here. 

Rob Nelson
rnel...@gmail.com

To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

[Rob Nelson]

Are there cases where a node might not have the package, ever? Or do you just want to make sure it's done in the right order? If you did this:

  package{'some-pam-package':

    ensure => present,
  }

...and the package was already installed, nothing would happen. However you could then leverage that, as in the previous example, in ordering to make sure the file shows up afterward.

You could put this in a profile that is only applied to certain roles/nodes, or some other conditional (i.e. a param `$manage_pam` to a profile where, when true, the example code is hit), to restrict which nodes receive that in their catalog. This lets the 'package' type do its job rather than writing more complicated code and conditional, and protects you if somehow that package is uninstalled - puppet will enforce the desired state and re-install the package and configuration.

Does that make sense?

Rob Nelson
rnel...@gmail.com

To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/7f6cc6b7-b55e-4e66-93f5-7fa1380c0edc%40googlegroups.com.

[HPUX_PUPPET]

I only wish it was that simple and thus the problem i had been facing.

The 3rd party package requires hands-on steps to get installed, but the package itself isn't the issue. It is that it puts 2-5 lines at the head of the PAM module conf files (system-auth, password-auth, common-auth, ...).  If the lines are pushed by a default configuration and the software it not installed or connected to AD, then you can't get in, even with root. You have to boot to single-user mode to correct it. When pushing out PAM setups to servers, we cannot assume the 3rd party software has been installed at that point. 

But thanks to your great encouragement, I wrote some down and dirty custom facts that check if it is installed and if so, the version as well. I put the fact in the module directory and it deployed immediately.  Not the experience I had with the 0.25 puppet client at all.  

Now I have the easy part of checking to ensure the package is installed to add the lines to variables I am using in the PAM template files. 

This post was mainly about seeing if Puppet / Factor had been tweaked over the years to pull lists of installed RPMs given Red Hat Satellite 6 using Puppet as part of their software management and server build solution. 

Rob Nelson
rnel...@gmail.com

[Rob Nelson]

I don't think you'll see that added as a core fact because it would still have a relatively narrow appeal. Due to the partnership between RH/Puppet, there may be a Satellite mod that includes such a custom fact. If you do something like that yourself, I would keep an eye on https://tickets.puppetlabs.com/browse/FACT-348 and the RFC for a facter.conf file that includes TTL/caching, since that would be a pretty heavyweight fact to generate.

Glad you found a solution. That sounds like a hairy problem in general!

Rob Nelson
rnel...@gmail.com

To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/cf6d8847-3bdc-4e26-8c4f-4630ddcade31%40googlegroups.com.

[Thomas Müller]

Am Donnerstag, 15. September 2016 14:53:57 UTC+2 schrieb HPUX_PUPPET:

...

This post was mainly about seeing if Puppet / Factor had been tweaked over the years to pull lists of installed RPMs given Red Hat Satellite 6 using Puppet as part of their software management and server build solution. 

 unfortunatly besides integration of Puppet in foreman GUI it's not very sophisticated in sense of additonal features to manage RHEL systems. I first hoped they will release supported puppet modules to make configuration of basic stuff easy but this did not happen.

now they bought ansible I don't think they will make investments in better support. IMHO Puppet 4 is still not supported on the satellite 6 server.

- Thomas

[Jim Perry]

Thanks.

While I see that Ansible is a nice tool, the clientless access requiring a login has a fatal flaw when compared to puppet.

More than once we have had a PAM, SSHD or similar setup get corrupted over dozens, if not all, systems. We were able to fix in Puppet and get the corrections pushed out. With Ansible we would have needed to hard shut then down and come up in single user mode.

In fact this very post is related to ensuring we can fix issues with PAM related to our third party AD with tool.  We had a typo in the setup that locked all access, even console, out because we broke PAM.

--
You received this message because you are subscribed to a topic in the Google Groups "Puppet Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/xJh1au94dqE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to puppet-users+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/d48d5590-cda0-4052-a727-295ec3e891dc%40googlegroups.com.