audit

[Stuart Cracraft]

Assume the following question is in regards to Puppet 3.3.2.

So my question is in relation to audit.

file { '/some/random/path/through/the/tree/to/a/file':

  owner => 'luke',

  group => 'rebelalliance',

  mode => '0444',

  audit => all

}

And more specifically: will the named file be force-owned to luke with the

group and mode and then any alterations to that initial setting be reported (i.e.

audited)?

How does audit differ from leaving out audit?

Does audit centralize its checksum activity on the server rather than the client?

Stuart

[jcbollinger]

Here are the docs: http://docs.puppetlabs.com/references/3.stable/metaparameter.html#audit

Basically, auditing some or all properties of a resource causes puppet to log changes to those properties from run to run, and causes them to be included in the output of "puppet inspect".  Nothing more or less.  In particular, marking a resource property for audit has no effect on Puppet's evaluation of whether its host resource must be synced, nor on whether Puppet synchronizes that particular property.

Thus in your example, Puppet will enforce that /some/random/path/through/the/tree/to/a/file is owned by user 'luke', with group 'rebelalliance' and mode 0444 when it applies that resource (unless running in noop mode).  I'm slightly unclear on this, but I think it will audit not just those properties, but ALL File properties it knows about:

• ensure
• content
• ctime
  
• group
• mode
• mtime
  
• owner
• selrange
• selrole
• seltype
• seluser
• target
  

Other attributes of File do not represent "properties" of the target resource, rather they are "parameters" affecting the process of syncing the resource.  Even 'source' is a parameter -- it affects how the 'content' property is synced.

Leaving out 'audit' will omit logging changes to those properties, and will omit enrolling them for inclusion in Puppet inspection reports (though it's conceivable that some will be enrolled by other means).

I'm not sure I understand the question about checksum activity.  Puppet must compute checksums of both the actual and expected file content.  Checksums of the actual content are computed on the target machine, where that content actually is.  Checksums of the expected content are computed on the master, the source of that content.  When the 'source' parameter is used, computing the checksum on the master allows the content transfer to be avoided when it is unneeded.  When static content is specified directly via the 'content' property, the master has an opportunity to cache the checksum, though I'm uncertain how aggressive or effective it is at performing such caching.

If this is of interest to you then I would suggest experimenting with 'audit' to get a feel for it.


John

[Stuart Cracraft]

Very cool.

We have extremely heavy audit requirements so this will help.

I like the idea that it is noted and extractable and recordable and countable for analytics.

Now, if I could only get Puppet to tell me exactly what CLI it would propose running...

As I don't want to have to massage YAML files into reasonability...