Puppet keeps trying to change correct setting back to correct

[evan....@noaa.gov]

I have 3 settings that are already in the correct state yet puppet keeps seeing them as an incorrect state:

First one is here on the puppet master: (centos 6)
Notice: /Stage[main]/Puppet_enterprise::Profile::Mcollective::Peadmin/Puppet_enterprise::Mcollective::Client[peadmin]/Puppet_enterprise::Mcollective::Client::User[peadmin]/Pe_accounts::User[peadmin]/User[peadmin]/shell: current_value /bin/cdax/bash, should be /bin/bash

Yet the /etc/password file already has it correct: peadmin:x:500:500:peadmin:/var/lib/peadmin:/bin/bash  (if you are wondering the /bin/cdax/bash is from a different program). If it is not checking /etc/passwd were would it be finding this as the path for bash?

The next on a client: (centos 7)
/Stage[main]/Puppet_enterprise::Pxp_agent::Service/Service[pxp-agent]/enable and /Stage[main]/Puppet_enterprise::Mcollective::Service/Service[mcollective]/enable both service are state enabled whle both are enabled.

From the client:
mcollective        0:off    1:off    2:on    3:on    4:on    5:on    6:off
pxp-agent          0:off    1:off    2:on    3:on    4:on    5:on    6:off

Suggestions on where to start trouble shooting this?

Evan

[jcbollinger]

On Thursday, December 10, 2015 at 3:42:22 PM UTC-6, evan....@noaa.gov wrote:

 

Suggestions on where to start trouble shooting this?

Running the agent with --debug logging would likely provide more information for you to work with.


John

[evan....@noaa.gov]

Thats is how I got the notices. It is either in how the facts are being pulled, or how puppet is asking but I am can't determine which from what I am seeing in the --debug. 

[Chuck]

Here is what I see is going on.  On systemV script in /etc/init.d there is not a UnitFileState.


Debug: Executing: '/bin/systemctl is-active ossec-hids'
Debug: Executing: '/bin/systemctl show ossec-hids --property LoadState --property UnitFileState --no-pager'
Debug: Executing: '/bin/systemctl unmask ossec-hids'
Debug: Executing: '/bin/systemctl enable ossec-hids'
Notice: /Stage[main]/Ossec/Service[ossec-hids]/enable: enable changed 'false' to 'true'


# /bin/systemctl show ossec-hids --property SourcePath --property LoadState --property UnitFileState --no-pager
LoadState=loaded
SourcePath=/etc/rc.d/init.d/ossec-hids
UnitFileState=

# /bin/systemctl show sshd --property SourcePath --property LoadState --property UnitFileState --no-pager
LoadState=loaded
SourcePath=
UnitFileState=enabled

[Chuck]

I only see this issue with Puppet4 with RHEL/CENTOS 7

[jcbollinger]

On Friday, December 11, 2015 at 11:42:10 AM UTC-6, evan....@noaa.gov wrote:

Thats is how I got the notices. It is either in how the facts are being pulled, or how puppet is asking but I am can't determine which from what I am seeing in the --debug.

Along with the messages you presented, Puppet should also be logging debug messages giving the external commands it is running.  If it is not presenting any pertinent ones then that probably means it is using the Ruby library to obtain user information, as opposed to running an external command.  For instance, it might be using Etc.getpwent().  I'm not inclined at the moment to dig through the code to find this for you, but you could do it yourself.

In any event, if Puppet is retrieving the wrong information, then you should be concerned that other programs will do, too.  Or perhaps more accurately, you should be concerned that Puppet may be right about the initial state, and that its failure is in setting the desired target state.  You should look at your user name service configuration in /etc/nsswitch.conf to determine whether your system is relying any other user information sources than just /etc/passwd.

You should also look at the agent's debug output to determine what provider is selected for User resources -- that's probably near the top or each run's log.  Perhaps Puppet is choosing the wrong provider.


John

[jcbollinger]

On Friday, December 11, 2015 at 12:08:53 PM UTC-6, Chuck wrote:

Here is what I see is going on.  On systemV script in /etc/init.d there is not a UnitFileState. [...]

Um, Chuck?  I think you've posted this to the wrong thread.  I don't see how it relates to the topic of this one.


John 

[Chuck]

I was agreeing with his second issue and show I saw the same issue.

[Chuck]

So for your Centos 7 issue here is the TICKET.

https://tickets.puppetlabs.com/browse/PUP-5296