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
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/51beda0d-6d3b-4253-8f3a-0976c478e3b6%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
On Monday, December 9, 2013 5:12:42 PM UTC-6, Stuart Cracraft wrote:> > > 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? > >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 -- 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+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/a7a0fd0d-8d5e-4620-9852-50ff541de460%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
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... On Tuesday, December 10, 2013 7:11:10 AM UTC-8, jcbollinger wrote:> > > On Monday, December 9, 2013 5:12:42 PM UTC-6, Stuart Cracraft wrote: >> >> >> 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? >> >> > > 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 > >-- 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+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/96950e41-e4a9-49ad-9f75-2a1107c4976c%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.