Puppet conveniently makes most variables from Puppet.settings available via Puppet[:variable]. Use this to generate minion.conf via a standard ERB template. ---
This change is the sort of thing that really begs for a second set of eyes, as it would cause too much trouble if it didn't work as intended.
A quick way to test that the template does the right thing is to grab http://fedorapeople.org/~tmz/tmp/func-minion-template-test.pp and run it through puppet, e.g. sudo puppet /tmp/func-minion-template-test.pp.
I noticed this while poking the func setup to see what settings were needed to make func use puppet's certificates with the new code from Seth in func's git tree. (I also noticed that the overlord.conf isn't puppet managed, and that's the one I was more curious to see, easily found on puppet01. ;)
modules/func/files/make-minion-conf.sh | 24 ------------------------ modules/func/manifests/init.pp | 24 ++++++++++++------------ modules/func/templates/minion.conf.erb | 13 +++++++++++++ 3 files changed, 25 insertions(+), 36 deletions(-) delete mode 100755 modules/func/files/make-minion-conf.sh create mode 100644 modules/func/templates/minion.conf.erb
diff --git a/modules/func/files/make-minion-conf.sh b/modules/func/files/make-minion-conf.sh deleted file mode 100755 index ea50c95..0000000 --- a/modules/func/files/make-minion-conf.sh +++ /dev/null @@ -1,24 +0,0 @@ -#!/bin/bash - - -certfile=`ruby -e "require 'puppet'; Puppet.parse_config; puts Puppet.settings['hostcert']"` -keyfile=`ruby -e "require 'puppet'; Puppet.parse_config; puts Puppet.settings['hostprivkey']"` -cacert=`ruby -e "require 'puppet'; Puppet.parse_config; puts Puppet.settings['localcacert']"` - - -cat <<EOM>/etc/func/minion.conf -# configuration for minions - -[main] -log_level = DEBUG -acl_dir = /etc/func/minion-acl.d - -listen_addr = -listen_port = 51234 -use_certmaster = 0 - -cert_file = $certfile -key_file = $keyfile -ca_file = $cacert - -EOM diff --git a/modules/func/manifests/init.pp b/modules/func/manifests/init.pp index 50d6ed8..b9d39fe 100644 --- a/modules/func/manifests/init.pp +++ b/modules/func/manifests/init.pp @@ -23,23 +23,23 @@ class func::funcd { } }
+ File { + require => Package['func'], + } + file { '/etc/logrotate.d/func_rotate': source => 'puppet:///func/func_rotate', - require => Package['func'] - } - file { '/usr/local/bin/make-minion-conf.sh': - source => 'puppet:///func/make-minion-conf.sh', - require => Package['func'], - mode => 0750, - notify => Exec['makeminionconf'] } - exec { 'makeminionconf': - require => File['/usr/local/bin/make-minion-conf.sh'], - command => '/bin/bash /usr/local/bin/make-minion-conf.sh', - refreshonly => true, - notify => Service['funcd'] + + file { '/etc/func/minion.conf': + content => template('func/minion.conf.erb'), + notify => Service['funcd'], }
+ # This can be removed once all systems are updated + file { '/usr/local/bin/make-minion-conf.sh': + ensure => absent, + } }
class func::certmaster { diff --git a/modules/func/templates/minion.conf.erb b/modules/func/templates/minion.conf.erb new file mode 100644 index 0000000..33395ca --- /dev/null +++ b/modules/func/templates/minion.conf.erb @@ -0,0 +1,13 @@ +# configuration for minions + +[main] +log_level = DEBUG +acl_dir = /etc/func/minion-acl.d + +listen_addr = +listen_port = 51234 +use_certmaster = 0 + +cert_file = <%= Puppet[:hostcert] %> +key_file = <%= Puppet[:hostprivkey] %> +ca_file = <%= Puppet[:localcacert] %>
On Sun, 2010-08-29 at 12:23 -0400, Todd Zullinger wrote:
Puppet conveniently makes most variables from Puppet.settings available via Puppet[:variable]. Use this to generate minion.conf via a standard ERB template.
This change is the sort of thing that really begs for a second set of eyes, as it would cause too much trouble if it didn't work as intended.
Which makes me ask - why change it?
We know it works now..
I don't see anything wrong with what you have but I'm not clear on why an ERB template is better.
-sv
seth vidal wrote:
Which makes me ask - why change it?
We know it works now..
I don't see anything wrong with what you have but I'm not clear on why an ERB template is better.
As a general code cleanup. Forking 3 shells to ruby to get data provided by puppet directly is less efficient and uglier than using a standard template. Also, while I don't imagine it will change anytime soon, but if the puppet code gets reorganized in the future, I can see the current ruby shell queries being broken more easily than accessing the variables via puppet.
But it's not a big deal if you think it's not worth the risk to clean it up.
Perhaps add a note there that the variables are available, so others perusing the puppet manifests don't think they need to resort to this sort of thing for other tasks? A lot of folks don't spend their days in puppet manifests and learn from reading the other code in the repository.
(I've been called a pedant before though. Shocking, I know. ;)
On Mon, 2010-08-30 at 11:22 -0400, Todd Zullinger wrote:
As a general code cleanup. Forking 3 shells to ruby to get data provided by puppet directly is less efficient and uglier than using a standard template. Also, while I don't imagine it will change anytime soon, but if the puppet code gets reorganized in the future, I can see the current ruby shell queries being broken more easily than accessing the variables via puppet.
That's a fair explanation.
Doing it b/c the puppet folks are more likely to break a relative edge-case is reasonable.
doing it b/c it is more puppet-y just irks me.
:)
But it's not a big deal if you think it's not worth the risk to clean it up.
test it. people1 is easy to get into if it breaks.
(I've been called a pedant before though. Shocking, I know. ;)
I've been called a fuddy-duddy, too. I'm not so keen on custom-languages for things like config-mgmt systems - but that's been my complaint about puppet from day one so...
-sv
On Mon, 2010-08-30 at 11:28 -0400, seth vidal wrote:
On Mon, 2010-08-30 at 11:22 -0400, Todd Zullinger wrote:
As a general code cleanup. Forking 3 shells to ruby to get data provided by puppet directly is less efficient and uglier than using a standard template. Also, while I don't imagine it will change anytime soon, but if the puppet code gets reorganized in the future, I can see the current ruby shell queries being broken more easily than accessing the variables via puppet.
That's a fair explanation.
Doing it b/c the puppet folks are more likely to break a relative edge-case is reasonable.
doing it b/c it is more puppet-y just irks me.
okay - I've found a usecase for this, now.
bxen04 was renamed from another name - the make-minion-conf never got reran so func was just not working.. If it was a thing in puppet it would have been working.
so... seems like your recommendation is a good one.
thanks, -sv
seth vidal wrote:
okay - I've found a usecase for this, now.
bxen04 was renamed from another name - the make-minion-conf never got reran so func was just not working.. If it was a thing in puppet it would have been working.
so... seems like your recommendation is a good one.
Apologies for not getting it tested on people1 like we talked about the other day. Work took precedence. But, I did find a nice hole in my current patch when I deployed it in another environment. The Puppet[:hostcert] and Puppet[:hostprivkey] get evaluate by the puppet master, and end up being invalid on the clients. I ended up using:
cert_file = <%= Puppet[:certdir] %>/<%= fqdn %>.pem key_file = <%= Puppet[:privatekeydir] %>/<%= fqdn %>.pem
in my environment, but that's not quite as nice as I'd envisioned. (And, of course, your test plan was well founded. I should know better. I'm glad you did. :)
I'll hopefully have time to update the patch in infrastructure and test this on people1 in the next few days. I'll ping you on irc before I do so, to make sure someone is around in case it doesn't work out. I have deployed this at work though, and it's working nicely there, so I'm more confident.
On Fri, 2010-09-03 at 11:48 -0400, Todd Zullinger wrote:
seth vidal wrote:
okay - I've found a usecase for this, now.
bxen04 was renamed from another name - the make-minion-conf never got reran so func was just not working.. If it was a thing in puppet it would have been working.
so... seems like your recommendation is a good one.
Apologies for not getting it tested on people1 like we talked about the other day. Work took precedence. But, I did find a nice hole in my current patch when I deployed it in another environment. The Puppet[:hostcert] and Puppet[:hostprivkey] get evaluate by the puppet master, and end up being invalid on the clients. I ended up using:
cert_file = <%= Puppet[:certdir] %>/<%= fqdn %>.pem key_file = <%= Puppet[:privatekeydir] %>/<%= fqdn %>.pem
in my environment, but that's not quite as nice as I'd envisioned. (And, of course, your test plan was well founded. I should know better. I'm glad you did. :)
I'll hopefully have time to update the patch in infrastructure and test this on people1 in the next few days. I'll ping you on irc before I do so, to make sure someone is around in case it doesn't work out. I have deployed this at work though, and it's working nicely there, so I'm more confident.
thanks. I'm around until next friday then I'll be AFK for a while.
-sv
infrastructure@lists.fedoraproject.org