Fix mtree violation for Puppet and update to 2.6.8

[nigel@…]

This is both a defect and an update patch.

[nigel@…]

Update to 2.6.8, fix mtree violation

[nigel@…]

This should also close #27566

[nigel@…]

Also for posterity, thanks to David Magda for the mtree fix.

[ryandesign@…]

Using the patch from #15514, I get:

Warning: reinplace s|/etc/puppet|/opt/local/etc/puppet| didn't change anything in /opt/local/var/macports/build/_Users_rschmidt_macports_dports_sysutils_puppet/work/puppet-2.6.8/lib/puppet/defaults.rb
Warning: reinplace s|$confdir/ssl|/opt/local/var/puppet/ssl| didn't change anything in /opt/local/var/macports/build/_Users_rschmidt_macports_dports_sysutils_puppet/work/puppet-2.6.8/lib/puppet/defaults.rb

So I think some of those reinplaces aren't necessary, or need to be different.

There also doesn't seem to be a reason to use the -E flag for reinplace. In fact, if I remove it, only one warning is printed:

Warning: reinplace s|/etc/puppet|/opt/local/etc/puppet| didn't change anything in /opt/local/var/macports/build/_Users_rschmidt_macports_dports_sysutils_puppet/work/puppet-2.6.8/lib/puppet/defaults.rb

These reinplaces are a bit prone to breaking in the future and leaving it unclear to the next person to try to update the port how to do so. It might be clearer if you write patchfiles that first insert the correct paths into the files, with the @PREFIX@ placeholder, and then just use reinplace to replace @PREFIX@ with ${prefix}.

Finally, the post-destroot block doesn't do anything. It creates a directory, but since nothing is in that directory, MacPorts will delete it before the port install finishes. The solution, if you want the directory kept, is to add a destroot.keepdirs line.

[ian@…]

Cc Me!

[ian@…]

Any updates to this? I'd like to see Puppet 2.7.3 and Facter 1.6.0. Should I file that as a separate ticket, or would it make sense to revise this one? I tried the RubyGems route, but it leaves much to be desired.

[nigel@…]

Someone needs to spend some time hunting down what the problems are and resolving them :(

We've got PuppetConf on next week, and I just haven't had the time to spend on this sorry. After that I should have some time, but we could really do with a few people willing to submit patches/updates to MacPorts Puppet/Facter.

[deesto@…]

Cc Me!

[ian@…]

Subversion unified diff of trunk for Puppet and Facter Portfiles.

[ian@…]

To stoke the fire I've just added a patch that brings Facter to 1.6.2 and Puppet to 2.7.6.

It seems like the --destdir and --configdir options to install.rb do enough of the right thing in 2.7.6 to be passable. I've removed all the reinplace's accordingly. I've noticed that puppet master --genconfig outputs everything without ${prefix}, but I wouldn't consider that a show stopper. I'll submit a patch upstream for it. If anyone feels it needs to be addressed from the get go I can attack it with Ryan's suggested @PREFIX@ approach.

I also dropped the xinstall of ${prefix}/var/puppet/rrd as I was building up from what wasn't working for me. I can add it back with Ryan's suggested destroot.keepdirs fix as needed.

I added copying of the config examples to ${prefix}/share/examples/puppet/etc/puppet. I was going to add all the examples, but then I realized xinstall doesn't recurse directories (Ticket #14139). Is there a preferred way to handle a sizable tree otherwise?

There are so many ways to setup puppet that I'm curious to get people's input on whether default config and startup items would be desired, and if so what should they look like? For my initial use case I'm just using puppet apply on demand instead of puppet master and puppet agent. Perhaps startup items for the master and agent daemons, configured for localhost only, with a manifest that otherwise does nothing, would add some warmth and fuzziness to the port?

[deesto@…]

Thanks for this. Also nice to see an update to a "modern" version.

Replying to ian@…:

There are so many ways to setup puppet that I'm curious to get people's input on whether default config and startup items would be desired, and if so what should they look like? For my initial use case I'm just using puppet apply on demand instead of puppet master and puppet agent. Perhaps startup items for the master and agent daemons, configured for localhost only, with a manifest that otherwise does nothing, would add some warmth and fuzziness to the port?

In my case: on a global level, we're using "apply" mostly for local testing, and a master/agent model for most server configuration. It would be nice to have a working start-up master/agent model.

[raimue@…]

Committed in r90305 and r90306.

[mp@…]

I tried bootstrapping a brand-new machine with this, only thing is I copied pre-existing SSL keys from the "old" machine to /opt/local/etc/puppet. The rest of the necessary parameters (especially certname and server) is passed to "puppet agent" , which worked in the past.

Now this fails because the Agent looks for SSL keys in /etc/puppet, not /opt/local/etc/puppet. "puppet agent --genconfig" also does not show the config path below ${prefix}, but you mentioned that above.

Apart from that, we're using the master/agent model and start the agent via launchd as outlined in ​http://projects.puppetlabs.com/projects/puppet/wiki/Puppet_With_Launchd.

[raimue@…]

In the mean time, puppet was updated to 2.7.6. Do the problems reported in comment:12 still exist?

[egall@…]

Cc Me!