Opened 13 years ago

Closed 9 years ago

#29676 closed update (fixed)

Fix mtree violation for Puppet and update to 2.6.8

Reported by: nigel@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: haspatch maintainer Cc: ian@…, deesto (John S. De Stefano Jr.), cooljeanius (Eric Gallager)
Port: puppet

Description

This is both a defect and an update patch.

Attachments (2)

Portfile-puppet.diff (2.1 KB) - added by nigel@… 13 years ago.
Update to 2.6.8, fix mtree violation
Portfile-facter-puppet.svn.diff (2.9 KB) - added by ian@… 12 years ago.
Subversion unified diff of trunk for Puppet and Facter Portfiles.

Download all attachments as: .zip

Change History (18)

Changed 13 years ago by nigel@…

Attachment: Portfile-puppet.diff added

Update to 2.6.8, fix mtree violation

comment:1 Changed 13 years ago by nigel@…

This should also close #27566

comment:2 Changed 13 years ago by nigel@…

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

comment:3 Changed 13 years ago by mf2k (Frank Schima)

Keywords: haspatch maintainer added
Version: 1.9.2

comment:4 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

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.

comment:5 Changed 13 years ago by ian@…

Cc: ian@… added

Cc Me!

comment:6 Changed 13 years ago by 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.

comment:7 Changed 13 years ago by 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.

comment:8 Changed 12 years ago by deesto (John S. De Stefano Jr.)

Cc: deesto@… added

Cc Me!

Changed 12 years ago by ian@…

Subversion unified diff of trunk for Puppet and Facter Portfiles.

comment:9 Changed 12 years ago by 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?

comment:10 in reply to:  9 Changed 12 years ago by deesto (John S. De Stefano Jr.)

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.

comment:11 Changed 12 years ago by raimue (Rainer Müller)

Resolution: fixed
Status: newclosed

Committed in r90305 and r90306.

comment:12 Changed 12 years ago by mp@…

Resolution: fixed
Status: closedreopened

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.

comment:13 in reply to:  12 Changed 11 years ago by raimue (Rainer Müller)

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

comment:14 Changed 11 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:15 Changed 9 years ago by petrrr

What is the status here, can this be closed now?

comment:16 Changed 9 years ago by mf2k (Frank Schima)

Resolution: fixed
Status: reopenedclosed

The original issue appears to be fixed. Please open a new ticket for this problem if it still exists.

Note: See TracTickets for help on using tickets.