Puppet users - Nov 2010 - Exported resources, stale checksums in state.yaml, and eternally growing filebuckets

I have found what I believe to be incorrect checksums in state.yaml, and
somewhat wasteful thrashing in the contents of exported
ssh_authorized_key resources (and possibly others).

My ultimate goal is to create a "stop the line" sort of system: if
someone has manually edited a puppet-managed file, the next catalog
collection will grind to a halt and alerting systems will send out
notifications.  To this end, I have done the following:

	* I have a custom fact that parses state.yaml into a format
	  suitable for being fed into md5sum -c, and returns true if any
	  of the checksums fail.
	* I have a module that calls fail() if the custom fact is true.

This system actually works rather well, I find!  My problem is that I
have an exported resource to allow ssh triggering of commands on a
central machine from a set of other machines:

	@@ssh_authorized_key { "user@$hostname":
		key => $user_rsa_key,
		type => ''ssh-rsa'',
		user => ''foo'',
		options =>
"command=\"...\",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,from=\"$ipaddress\"",
	}

And then:

	node ''central.example.com'' {
		# Create the authkeys file automatically
		Ssh_authorized_key <<| user == "foo" |>>
	}

The entry for /home/foo/.ssh/authorized_keys in state.yaml causes my
md5sum system to fail every time.  Upon inspection, I note that the
entry in state.yaml is exactly one revision out of date!

	# md5sum /home/foo/.ssh/authorized_keys; puppetd --environment=staging -t  |
grep ''checksum changed''; md5sum /home/foo/.ssh/authorized_keys
	fc9e4d3f84f99cff14a16dbe20f0db70  /home/foo/.ssh/authorized_keys
	notice:
/Stage[main]//Node[central.example.com]/File[/home/foo/.ssh/authorized_keys]/checksum:
checksum changed ''{md5}7c2a499471221f2511afde8e2ca3c329'' to
''{md5}fc9e4d3f84f99cff14a16dbe20f0db70''
	8492d19fb29b15d52c916a8d60c4b55c  /home/foo/.ssh/authorized_keys

And then in state.yaml:

	File[/home/foo/.ssh/authorized_keys]: 
	  :checked: 2010-11-15 12:52:54.896678 +00:00
	  :checksums: 
	    :md5: "{md5}fc9e4d3f84f99cff14a16dbe20f0db70"
	  :synced: 2010-11-15 12:52:54.899011 +00:00
		
Shouldn''t the system have noticed a change from
"{md5}fc9e4d3f84f99cff14a16dbe20f0db70" to
"{md5}8492d19fb29b15d52c916a8d60c4b55c" there?

Further, grepping for a chunk of the options in this resource in the
clientbucket finds hundreds of entries, and it would appear that all
possible orderings are coming from the puppetmaster.  I realize that
technically there is a finite limit to the number of permutations, but
this strikes me as wasteful.

So partly I''m trying to understand how this works, but I would like to
know two things:
	
	1. Is there someplace with a "blessed" copy of the *current*
	   checksum for this file?
	2. Is there any way I can lock this exported resource to a
	   specific ordering, or otherwise prevent it from updating when
	   there has been no change in the component records?

My puppetmaster is running 2.6.1-0ubuntu2 and central.example.com is
running 0.25.4-2ubuntu6 (as are most of the other puppet clients, the
remainder running the same as the master).

-- 
"These people program the way Victorians dress.
It takes two hours and three assistants to put on
your clothes, and you have to change before dinner.
But everything is modular."    -- Miles Nordin, on PAM

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Nick Moffitt:
> Further, grepping for a chunk of the options in this resource in the
> clientbucket finds hundreds of entries, and it would appear that all
> possible orderings are coming from the puppetmaster.  I realize that
> technically there is a finite limit to the number of permutations, but
> this strikes me as wasteful.
In fact, the waste came from the fact that the header for any provider
descended from the parsedfile provider includes a timestamp.  This will
grow forever, unfortunately, even as the practical elements of the file
do not change one bit.

-- 
How do you get mailings?... from the lists
1. suspects
2. elbows
                -- Don Saklad

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Nick Moffitt:
> 	# md5sum /home/foo/.ssh/authorized_keys; puppetd --environment=staging -t 
| grep ''checksum changed''; md5sum
/home/foo/.ssh/authorized_keys
> 	fc9e4d3f84f99cff14a16dbe20f0db70  /home/foo/.ssh/authorized_keys
> 	notice:
/Stage[main]//Node[central.example.com]/File[/home/foo/.ssh/authorized_keys]/checksum:
checksum changed ''{md5}7c2a499471221f2511afde8e2ca3c329'' to
''{md5}fc9e4d3f84f99cff14a16dbe20f0db70''
> 	8492d19fb29b15d52c916a8d60c4b55c  /home/foo/.ssh/authorized_keys
Well it would appear that this may be a bug:

	http://projects.puppetlabs.com/issues/5301

-- 
"As I soared high into the tag cloud Xeni Jardin
carefully put up for me, I couldn''t help but wonder how
high we were above the blogosphere." -- Carlos Laviola

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.