-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I certainly understand the need for this, but doesn't AIDE, tripwire,
samhain, etc... already give you this?
What's the benefit to making it part of Puppet except for having a
single tool to deal with? Is the investment of time worth the return?
Accepting the output of one, or more, of these tools into your tracking
dashboard might be a more flexible way to go without slowing down Puppet
for normal change runs.
Thanks,
Trevor
On 03/22/2010 01:37 AM, Luke Kanies wrote:
> Hi all,
>
> I kinda expect blank stares in response to this question, but I'll do
> what I can to both describe what I'm trying to do and to do it in an
> interesting way.
>
> One of the things I've always wanted Puppet to be able to do is to track
> changes of resources without having to actually manage a given
> resource. For instance, I want to be able to say:
>
> file { "/etc/passwd": check => content }
>
> And get an event if that file's content changes, even though I'm not
> specifying its content. This specific case actually worked until 0.25,
> but only for file content, and even then, only by specifying 'check =>
> checksum'. Something in 0.25 broke this, though, so I'm trying to fix
> it, and at the same time make it more general.
>
> I've just converted the checksum property to a parameter (in my
> refactor/master/checksum_as_parameter branch, imaginitively enough),
> which mostly just removed the now-non-functional code in the checksum
> parameter and made the rest of the content/checksum/source interaction
> considerably cleaner.
>
> So, life is better but we still don't have out-of-band change tracking.
>
> It's clear we now need something at the framework level - the system
> needs special support for this, rather than coding it into a parameter -
> and I'm thinking the right answer is to have something akin to noop, but
> comparing to previous state rather than desired state.
>
> This obviously is a structural change and thus, most likely, a sizeable
> change, so I want to make sure I'm on the right track. Unless it's a
> straightforward change, I'm not at all sure I'll be trying to get this
> done in the near future -- there's a lot of low-hanging fruit with a
> higher-priority -- but I'd like to have it in my head how it will work,
> anyway.
>
> In looking at how noop is implemented -- we just return a noop event
> instead of doing any work -- we should be able to return a similar event
> ("out_of_band_change" or something). The primary difference is that,
> with this, we have to track the state of every parameter for which we're
> doing this. This has always been the primary purpose of the 'state'
> file, and in general it shouldn't be a huge leap to start tracking this,
> but it's worth pointing out, anyway.
>
> One point worth making is that this definitely has to be done on top of
> my other event work, which means it'd never work in the 0.25 line.
>
> Comments? Fears?
>
- --
Trevor Vaughan
Vice President, Onyx Point, Inc.
email: [email protected]
phone: 410-541-ONYX (6699)
- -- This account not approved for unencrypted sensitive information --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkunREEACgkQyWMIJmxwHpQCeQCg3ZkuhzKk2wDypvdQfumI7Dyt
EWsAn2NHVGbTWZQgJfk71OHWXYycw/bK
=2hC4
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
