Puppet 4 directory layout

[gotyaoi]

since puppet 4 relocated things beneath /etc/puppetlabs, there's a few things that this module might be able to do automatically. Off the top of my head:

• confdir should be /etc/puppetlabs/mcollective instead of /etc/mcollective
• libdir in server.cfg and the client cfg files can take multiple entries. The default that ships with the package is now

libdir = /opt/puppetlabs/mcollective/plugins

# consult the "classic" libdirs too
libdir = /usr/share/mcollective/plugins
libdir = /usr/libexec/mcollective

• logfile default has also moved

logfile = /var/log/puppetlabs/mcollective.log

Not sure if there might be more, but those are the ones that jumped out at me.

[igalic]

@gotyaoi would you mind providing a patch for this?

[gotyaoi]

Ah, yes, I could probably get a PR together. It should probably switch behavior on the puppet version, or do you think there's a better criteria?

[nibalizer]

Well so.
http://pkgs.fedoraproject.org/cgit/puppet.git/tree/0001-Fix-puppet-paths.patch

So at least on fedora/epel native packages we'll have puppet4 using /etc/puppet.

[gotyaoi]

Hmm. That is... quite awkward. But perhaps it's a thing to say that this module's defaults should follow upstream to a certain extent?

[nibalizer]

Two sets of packagers sit between the software and the consumer... this is the kind of problem puppet is meant to solve, not to create.

[rendhalver]

This is how I did it in my puppet management module.
https://github.com/abstractitptyltd/abstractit-puppet/blob/production/manifests/defaults.pp
I basically set confdir and codedir and use those throughout my code.
I was going to use the settings:: variables but setting::codedir only exists in puppet 4.

As a sideline I had to cheat and set those in my spec tests as well.
https://github.com/abstractitptyltd/abstractit-puppet/blob/production/spec/classes/puppet_master_server_spec.rb

[gotyaoi]

@nibalizer Puppetlabs packages the software one way, epel another. Debian could be different again, as could ubuntu, as could gentoo. The fact that these packaging differences are occurring with puppet itself is certainly ironic. Still, we need some defaults, and defaulting to how puppetlabs packages things is the most agreeable path in my mind.

[Herr-Herner]

Can someone confirm that we have a problem with plugin installation in this module and the new Puppet 4 directory structure? The plugins get copied into /opt/puppetlabs/mcollective/mcollective, but in Puppet 4 I think it must be /opt/puppetlabs/mcollective/plugins, right?

[jyaworski]

Hello:

Is this still needed?

[pythianali]

I had an issue with Puppet 4.10 and CentOS7 while trying to get the puppetrun button to work in foreman. The mco puppet command that is executed for the puppetrun failed when running manually.
I hadn't played with mcollective in a while and realized that the puppet and other plugins are not installed by default like I was used to. Installing those using the module placed them in /usr/libexec/mcollective/mcollective (libdir = /opt/puppetlabs/mcollective
). However, mco did not show them listed afterwards.

I ended up symlinking that dir to the /opt/puppetlabs/mcollective/mcollective one and restarted the mcollective service. The mco command now shows those plugins installed now and I can execute 'mco puppet'. I am not sure what the correct default location and correct behavior should be and am only reporting my experience.

UPDATE:
The symlinks get overwritten when puppet runs. Ended up using the core_libdir parameter and now my servercfg looks like this (and works):

libdir = /opt/puppetlabs/mcollective:/usr/libexec/mcollective

[igalic]

do we have a patch yet?