"server_daemonize = true" should be the default

[luksi1]

Puppet agent: 3.4.3
OS: Ubuntu 12.04 och 14.04

This clause is causing me problems and I'm not sure why it's even there:

manifests/defaults.pp
if ($::operatingsystem == 'Ubuntu' and versioncmp($::operatingsystemrelease, '14.10') <= 0){ $server_daemonize = false # See https://tickets.puppetlabs.com/browse/MCO-167 } else { $server_daemonize = true }
A server.cfg with a daemonize = 0 will cause the mcollective init script to hang in 12.04 and 14.04 (and I presume any versions less than that).

[antaflos]

Which version of MCollective are you using? Because it works fine on our 12.04 and 14.04 machines running MCollective 2.9.0 (2.8.x also worked fine), installed from the Puppetlabs-provided packages.

If you look at the init.d script /etc/init.d/mcollective you should see that the --daemonize flag is explicitly added to the commandline arguments for starting MCollective. This overrides the default setting of daemonize = 0 in server.cfg.

The rationale is discussed in https://tickets.puppetlabs.com/browse/MCO-167 and https://tickets.puppetlabs.com/browse/MCO-181 but the TL;DR is that this way you can start MCollective via init.d or Upstart without having to also touch the server.cfg configuration file, since Upstart works best if the server runs in foreground while init.d (or start-stop-daemon) work best if the server is daemonized.

[luksi1]

14.04 uses mcollective v2.0
12.04 uses mcollective v1.2.1

These are directly from the Ubuntu repos. Does the module require the use of puppetlabs repos? Or a higher mcollective version? If so, I suppose I can submit a pull request for some version verification.

I can verify that 14.04 works with v2.0, but only with $server_daemonize = true, otherwise the init.d script will hang.

This is the start-stop-daemon from v2.0 from Ubuntu's package repo.

start-stop-daemon --start --quiet --pidfile /var/run/mcollective.pid --startas /usr/sbin/mcollectived -- --config=/etc/mcollective/server.cfg --pid=/var/run/mcollective.pid

[antaflos]

So the Ubuntu-provided packages use init.d scripts and not Upstart? Then this is indeed problematic, as you have reported.

I think this module is written with the Puppetlabs-provided packages in mind (it was originally developed by Puppetlabs, after all) so you should really think about using these packages instead. At least with Puppet 3.8 and Ubuntu 12.04 and 14.04 you should be fine; the packages work very well, as do the packaged plugins (like shell, puppet, filemgr, and so on). Plus 1.2.1 and 2.0 are really old by now.

Once you go into Puppet 4 AIO and Ubuntu 16.04 territory things will get more complicated: MCollective is provided by the AIO puppet-agent package and none of the plugins are packaged for 16.04/PC1 and the AIO layout. See https://tickets.puppetlabs.com/browse/MCO-722 for some discussion.

[luksi1]

The more that I dig and attempt to set up an MCollective SSL based infrastructure with Puppet as the primary agent, the more I understand "I think this module is written with the Puppetlabs-provided packages in mind". There is no mcollective-puppet-agent installed in Ubuntu's default repos. These are only provided by PuppetLabs and to top things off the docs point to the PC1 repo, not the full repo, which is where the MCollective agent resides.

Can we get some validation to ease up this bumpy ride?

Can we assume that this module is configuring an mcollective server or client and an mcollective puppet agent if installing a server? It's a Puppet module for god sake, how many want the server without the agent? At the least, can we add a parameter to install it? Something like

$mcollective_puppet_agent = false

If so..

mcollective-puppet-agent should be installed or puppet.rb should be placed in the appropriate agent directory.

mcollective >= 2.2 needs to be installed.

[luksi1]

I apologize. Just saw the option.

mcollective::plugin { 'puppet':
package => true,
}

Forget my comment regarding mcollective-puppet-agent.