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.
On Wednesday, September 14, 2016 at 1:31:37 PM UTC-4, Rob Nelson wrote:
>
> 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 <javascript:>
>
> On Wed, Sep 14, 2016 at 9:32 AM, HPUX_PUPPET <drid...@gmail.com
> <javascript:>> wrote:
>
>> 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.
>>
>>
>> On Tuesday, September 13, 2016 at 5:42:50 PM UTC-4, Rob Nelson wrote:
>>>
>>> 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
>>>
>>> On Tue, Sep 13, 2016 at 2:10 PM, HPUX_PUPPET <drid...@gmail.com> wrote:
>>>
>>>> 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!
>>>>
>>>>
>>>> --
>>>> 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...@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
>>>>
>>>> <https://groups.google.com/d/msgid/puppet-users/fd5cb2f3-8ab1-4c0e-8134-f8e5ec49c1ac%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>> 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...@googlegroups.com <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-users/7f6cc6b7-b55e-4e66-93f5-7fa1380c0edc%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/puppet-users/7f6cc6b7-b55e-4e66-93f5-7fa1380c0edc%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
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+unsubscr...@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.
For more options, visit https://groups.google.com/d/optout.
