On Wednesday, November 21, 2012 3:57:46 AM UTC-6, Alex Stanhope wrote:
>
> Hi Jakov,
>
> On 21 November 2012 02:03, Jakov Sosic wrote:
>>
>> exec{'first':
>> command => 'cd /tmp && wget mykey',
>> creates => '/tmp/mykey',
>> }
>>
>> exec{'second':
>> command => 'echo "" > /tmp/mykey | tee -a /tmp/mykey2',
>> creates => '/tmp/mykey2',
>> }
>>
>
> ...a really beautiful ugly hack. I appreciate the input because it sounds
> like I'm not missing anything really obvious. When coding in a new
> (declarative) language, I'm always mindful that I could be thinking about
> the problem incorrectly. I'm surprised in this case that more puppeteers
> haven't had the same problem. Perhaps I should be writing some kind of
> secure ssh-agent based key management plugin for Puppet?
>
If you're going to go with something like that then at least tidy it up:
1) Do not use run stages. It would be messy to set this up so that you
could do so. Instead, declare ordinary resource relationships that capture
the order you need.
2) For goodness sake, don't leave *two* state files per repo lying around
when you need only one.
3) Do put the state files somewhere other than /tmp, as putting them in
/tmp implies that it is safe to remove them.
The result might look something like this:
define mymodule::git_repo() {
exec { "get_repo_${name}_key":
command => "cd /var/local && wget
${mymodule::repo_key_base}/repo_${name}_key",
creates => "/var/local/repo_${name}_key",
provider => 'sh'
}
exec { "clone_repo_${name}":
command => "git clone ...",
refreshonly => true,
subscribe => Exec["get_repo_${name}_key"]
}
exec { "clean_repo_${name}_key":
command => "echo '' > /var/local/repo_${name}_key",
refreshonly => true,
require => Exec["clone_repo_${name}"],
subscribe => Exec["get_repo_${name}_key"],
provider => 'sh'
}
}
>
> Also John, thanks for the suggestion. Sending a plaintext password to the
> git clone call is an option, but I've got several git and several SVN
> repos, all connecting over SSH so the agent-play made more sense to me.
>
>
If you're saying that you envision all the repos' keys going to go into the
same file, then do be aware Jakov's approach does not serve that objective
very well. You really need one file per repo, since the approach relies on
an empty version being kept around as a marker that that repo has already
been cloned.
Indeed, it is the requirement for marker files that turns me off to the
idea. It is clever to clear the key files and leave them as markers, but
I'm not very keen on storing metadata on the managed node in the first
place. I much prefer techniques that are driven by the actual state of the
target node, instead of indirectly by what Puppet (or someone else) has
recorded about the state of the node.
With that said, you should go with what makes sense to you and works for
you. I just want you to make an informed decision.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/56cxhQa4DjMJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
