#mcollective

Hi, I have mcollective 2.4.1 and puppet 3.3.2 installed. The boot/startup order is S24 for mcollective and S98 for puppet agent

This allows executing the puppet agent with an "mco puppet runonce" before puppet agent is started as a daemon on the system

and causes the init script for puppet to fail to start

the problem seems to be that the mco call doesn't use --no-daemonize and so a puppet-agent.pid file is created that blocks the puppet init script to start the agent in daemon mode

Is there a reason for mcollective to start at S24? If it is possible to create a race condition, shouldn't always start after the puppet daemon? Or...

shouldn't the mco puppet use --no-daemonize?

I'm reluctant on changing the boot order myself, because this is how the packages are delivered

Within my environment I have dev, qa, staging and prod machines. How do I limit access (through an mco client) to a certain environment

for instance I have dev users that need to manage the dev machines and only the dev machines

I know I cna filter on that fact but that puts the responsility on the user to not accidently forget to filter their requests

cyrus_mc: https://github.com/puppetlabs/mcollective-actio...

trying to set a default policy for the actinpolicy plugin. https://gist.github.com/cyrus-mc/1aaa1b2cac89c9... I then create a file in /etc/mcollective/policies/default (also tried default.policy) that just denies everything

but enabling debug shows that mcollective is looking for policies/service.policy (since I was using the service agent)

if I copy the default file to service.policy it blocks as expected

ah..got it. can't use true