noop = true and what for test?

[Stuart Cracraft]

Hi,

When I put

  noop = true

in /etc/puppet/puppet.conf

on the node in question, I observe no changes. Great. Good

But also, I see because of

  report = true

absolutely zero information in the yaml regarding what would have

been changed.

Is there an equivalent to the above for "test = true" or must I alter

the rc file to include --test ?

Thanks ahead Puppet wizards!!!

[Stuart Cracraft]

What I had to do (confirm or deny at-will please) is:

  uncomment the node in /etc/puppet/manifests/nodes.pp

on the puppet master

and

on the daemon have

  noop = true

in the main section of the puppet.conf

and run the agent simply as /usr/bin/ruby /usr/bin/puppet agent --verbose

Now the yaml's get generated, have the message indicating what would be changed

but don't change it at all.

And we get "Would have triggered 'refresh' from N events in the /var/log/messages on

the node.

The only betterment to the above would be that /var/log/message over on the puppet master.

Desirable and controllable!!!!

Stuart

[Stuart Cracraft]

And, also, update the runinterval = NN

in the [agent] section of the puppet.conf.

It would be great if Puppet had even more centralized

control...

The agent/node still has too much need-to-visit...

On Tuesday, November 26, 2013 4:30:14 PM UTC-8, Stuart Cracraft wrote:

[Rich Burroughs]

Hi Stuart,

I'm not sure what your use case is for running the agent as a daemon in noop mode? I can't think of a situation at least in my workplace when I'd want to do that.

You know that you can run the agent once in noop mode from the command line? You can do that without changing any configs really easily:

puppet agent -t --noop

We do that a lot where I work when we're testing code. The agent just runs once and will report on what it would have done, but won't make any changes. A lot of times when we test that we're doing it on a different git branch, and we use "--environment=" to run against that other branch.

I'm not sure if this is helpful, maybe you already know about it :)

Rich

--
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/3b0f53bf-7d5d-4094-8a26-fe975a1e6f17%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Stuart Cracraft]

The rationale expressed to me has to do with non-specific auditing/security requirements...

My requirement is to research and contradict with prima face evidence or report and confirm 

or some mixture thereof, which is not the simplest of assignments.

If anyone at Puppet Labs and the community can think of a way to contradict the first paragraph, send it over.

Stuart

P.S. Thanks for your input that puppet agent need not be a daemon and can be run with:

  puppet agent -t --noop

I will put that in place tomorrow.

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/0vhLrU0Rl_0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAPGcbtCN5ovzMjx2ii0CVaFdzsr2_y%2BVD4JQ%3D3jPiMQF0pnH1Q%40mail.gmail.com.

[jcbollinger]

On Tuesday, December 3, 2013 2:18:25 AM UTC-6, Stuart Cracraft wrote:

The rationale expressed to me has to do with non-specific auditing/security requirements...

My requirement is to research and contradict with prima face evidence or report and confirm 

or some mixture thereof, which is not the simplest of assignments.

So, you intend to use Puppet to detect variances from nodes' expected configuration without bringing the target nodes into compliance?  This is possible.  However, you do need to be aware of the limitations of noop mode.

Chief among these is that when running in noop mode, Puppet has to proceed as if it were successful in syncing each out-of-sync resource, without knowing whether it actually would be successful and without having any actual effect on the target node.  This may produce anomalies when one resource depends on another, either because the analysis of whether a dependent resource is in sync might depend on its dependency being synced, or in some cases because success of one resource can serve as a condition for whether another is even considered for syncing.

You should also be aware that even when running in noop mode, Puppet will still execute commands on the target node to determine the current state of each resource in the catalog.  Generally speaking, these do not alter the target node's state, but in principle they might trigger a security alert or otherwise be logged, which would be a form of state change.  Moreover, Puppet cannot guarantee that the state-inspection commands executed by third-party custom resource types or by Exec resources do not alter the target node in other ways.

 

If anyone at Puppet Labs and the community can think of a way to contradict the first paragraph, send it over.

Stuart

P.S. Thanks for your input that puppet agent need not be a daemon and can be run with:

  puppet agent -t --noop

I will put that in place tomorrow.

In fact, just about any configuration option can be specified on the command line as well, overriding the config file.


John

[Stuart Cracraft]

Understood JC. The use case is a little different and certainly non-Puppeterian in theoretic value

but there is rationale for it. I.e. keeps Puppet agent installed but not running on the various nodes

except for occasional manual run.

When needed to be run (for example for an audit or a forced "drift-back", etc.), run puppet agent -t --noop.

Gather logs (yaml's on PM, /var/log/messages on managed node or logged back, etc.) and analyze

for changes which would be required to bring the system back into conformity. Then trace down

the issues, find root cause, report, etc.

We can filter out expected or excused log messages so that is not too much of a concern.

The rationale for the above methodology is: hosting firm doing database hosting in a (very)

highly secured environment seeking to ensure extreme care of the "crown jewels."

We realize it is not an exciting use case.

--Stuart

[John Warburton]

On 4 December 2013 04:54, Stuart Cracraft <smcra...@gmail.com> wrote:

The rationale for the above methodology is: hosting firm doing database hosting in a (very)

highly secured environment seeking to ensure extreme care of the "crown jewels."

We realize it is not an exciting use case.

We run a similarly unexciting puppet environment with strict change control, so no "standard" updating every 30 minutes. We run a puppet noop twice a day from cron (not daemon mode), which reports back to the puppet dashboard.

We can then extract the dashboard information as a CSV and report on non conformity, especial some modules like "security". See some examples in a previous post

John

[Stuart Cracraft]

Thanks for sharing this. 

--

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/0vhLrU0Rl_0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAAJLFxWoQBGrc83%3Dd_jxDkhcTReenKSN_ovWg63gREQmiVaBew%40mail.gmail.com.