There are two easy answers:
1) Our customers actually want to get rid of Tripwire (for multiple
reasons) and if we could just track file changes we've got the most
important replacement functionality.
2) The ability to track any parameter on any resource is a far cry
from just tracking file content. E.g., you could do things like track
password changes for root, which would be essentially impossible for a
tool like Tripwire because it lacks the semantic richness.
And here's a bonus reason, for free:
3) It's a great way for people to start managing - first monitor the
state so you know what the current operational mode is, and only once
you have that baseline do you start managing.
And this would only ever slow things down if you used it, just like
noop. And even then it shouldn't be slow - it should actually be
faster than actually managing a resource, because you're just
retrieving and comparing, rather than those two plus writing.
On Mar 22, 2010, at 3:19 AM, Trevor Vaughan wrote:
-----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
.
--
If you can't be a good example, then you'll just have to be a
horrible warning. -- Catherine Aird
---------------------------------------------------------------------
Luke Kanies -|- http://reductivelabs.com -|- +1(615)594-8199
--
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.
