Puppet users - Oct 2012 - How to trace puppet execution to troubleshoot odd problems

What is the best way to get a full trace of what puppet is doing, with 
variable dumps and state, to troubleshoot problems like where a user''s 
password keeps getting reset every time puppet runs even though the 
password hashes match?  

I want to hack out a way to get HPUX working like we have our Linux 
environments but need to be able to track down right where a problem is 
coming in so I can adjust / override / submit changes to the code base.

  Thanks!

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/yspr-yxcnuEJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Oct 16, 2012 at 10:48 AM, HPUX_PUPPET <drider69@gmail.com> wrote:
> What is the best way to get a full trace of what puppet is doing, with
> variable dumps and state, to troubleshoot problems like where a
user''s
> password keeps getting reset every time puppet runs even though the
> password hashes match?
>
In these situations I try and run both the master and the agent with the
following options turned on:  --verbose --debug --trace --evaltrace

> I want to hack out a way to get HPUX working like we have our Linux
> environments but need to be able to track down right where a problem is
> coming in so I can adjust / override / submit changes to the code base.
>
With the --debug flag, providers will print out the exact command
they''re
executing to modify the system.

--noop is also useful to see what commands Puppet _would_ execute without
actually executing them.

-Jeff

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 10/16/2012 08:49 PM, Jeff McCune wrote:
> With the --debug flag, providers will print out the exact command
> they''re executing to modify the system.
What should a custom type/provider author put in provider code for 
--debug to print the command out, or is it automatic?


-- 
Jakov Sosic
www.srce.unizg.hr

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Sat, Oct 20, 2012 at 7:09 PM, Jakov Sosic <jsosic@srce.hr> wrote:
> On 10/16/2012 08:49 PM, Jeff McCune wrote:
>
>  With the --debug flag, providers will print out the exact command
>> they''re executing to modify the system.
>>
>
> What should a custom type/provider author put in provider code for --debug
> to print the command out, or is it automatic

It''s automatic (but customizable) when the RAL synchronizes the
"is" value
to the "should" value.

See:
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/property.rb#L101-118

-Jeff

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.