Puppet users - Apr 2013 - MCollective and Puppet with periodic runs disabled

Hi,

I have looked all over the place and can''t seem to find a complete
answer
to my query

I am setting up MCollective to run alongside my puppet deployment and am 
having some problems getting it to play as I want it to

Basically, I need to make sure that puppet NEVER makes any changes without 
them being triggered by someone (I honestly can''t see how anyone would
ever
want that not to the the case but there you go).

I was going to just run puppet in cron in --noop mode for monitoring and 
manually run it for changes, but the ''mco rpc puppet'' command
requires that
it be running in daemon mode. Thats fine and working but I am unable to 
find a way to make this work and disable the puppet auto-runs. I found the 
--no-client option for the agent, which the docs seem to imply would do 
this for me, but when I use this option and trigger a puppet run it
doesn''t
not report success back to MCollective client:

With the daemon running normally I get:
  myserver                          : OK
    {:summary=>"Signalled the running Puppet Daemon"}

With no-client mode (which does prevent the auto-runs) I get:
  myserver                          : execution expired
      execution expired

It actually triggers a puppet run and all works, but I would like to know 
which hosts have sucessfully started a puppet run. Am I just misreading the 
error?

Am I just missing something here? Is there another way of making sure that 
puppet never makes automated changes in daemon mode?

I thought that maybe I could have the daemon in noop mode all the time and 
pass in the --no-noop flag but this gives:
  myserver                          : Cannot specify any custom puppet 
options when the daemon is running
    {:summary=>      "Cannot specify any custom puppet options when the 
daemon is running"}

I am using puppet 3.1 and the mcollective-puppet-common|agent|client plugin

Any ideas welcome, I just seem to be going round in circles now

Thanks
Josh

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

----- Original Message -----
> From: "Josh" <josh@chickenmonkey.co.uk>
> To: puppet-users@googlegroups.com
> Sent: Friday, April 12, 2013 10:01:13 AM
> Subject: [Puppet Users] MCollective and Puppet with periodic runs disabled
> 
> Hi,
> 
> I have looked all over the place and can''t seem to find a complete
answer
> to my query
> 
> I am setting up MCollective to run alongside my puppet deployment and am
> having some problems getting it to play as I want it to
> 
> Basically, I need to make sure that puppet NEVER makes any changes without
> them being triggered by someone (I honestly can''t see how anyone
would ever
> want that not to the the case but there you go).
> 
> I was going to just run puppet in cron in --noop mode for monitoring and
> manually run it for changes, but the ''mco rpc puppet''
command requires that
> it be running in daemon mode. Thats fine and working but I am unable to
you do not need to have puppet running for the agent to work, just stop it
entirely and then trigger runs through mcollective - in that setup it will
happily pass custom arguments like --noop or --no-noop etc

if you did want periodic noop runs then just cron 

   puppet agent --daemonize --onetime --noop
> find a way to make this work and disable the puppet auto-runs. I found the
> --no-client option for the agent, which the docs seem to imply would do
> this for me, but when I use this option and trigger a puppet run it
doesn''t
> not report success back to MCollective client:
> 
> With the daemon running normally I get:
>   myserver                          : OK
>     {:summary=>"Signalled the running Puppet Daemon"}
> 
> With no-client mode (which does prevent the auto-runs) I get:
>   myserver                          : execution expired
>       execution expired
> 
> It actually triggers a puppet run and all works, but I would like to know
> which hosts have sucessfully started a puppet run. Am I just misreading the
> error?
> 
> Am I just missing something here? Is there another way of making sure that
> puppet never makes automated changes in daemon mode?
> 
> I thought that maybe I could have the daemon in noop mode all the time and
> pass in the --no-noop flag but this gives:
>   myserver                          : Cannot specify any custom puppet
> options when the daemon is running
>     {:summary=>      "Cannot specify any custom puppet options when
the
> daemon is running"}
> 
> I am using puppet 3.1 and the mcollective-puppet-common|agent|client plugin
> 
> Any ideas welcome, I just seem to be going round in circles now
> 
> Thanks
> Josh
> 
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> 
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Friday, April 12, 2013 10:13:28 AM UTC+1, R.I. Pienaar wrote:
> you do not need to have puppet running for the agent to work, just stop it 
> entirely and then trigger runs through mcollective - in that setup it will 
> happily pass custom arguments like --noop or --no-noop etc 
>
Right, I was kind of hoping that would be how it works but I still get the 
message "execution expired" back from the node ... what is that even
meant
to mean? If you compare the output from my node and my puppetmaster (where 
I am running mco from):

2013-04-12 10:31:45: training-puppetmaster schedule status: Started a 
background Puppet run using the ''puppet agent --onetime --daemonize 
--color=false --no-noop'' command
2013-04-12 10:31:51: training-node1 schedule status: execution expired

 Is that just what I should be expecting?

Thanks
Josh

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

----- Original Message -----
> From: "Josh" <josh@chickenmonkey.co.uk>
> To: puppet-users@googlegroups.com
> Sent: Friday, April 12, 2013 10:33:17 AM
> Subject: Re: [Puppet Users] MCollective and Puppet with periodic runs
disabled
> 
> On Friday, April 12, 2013 10:13:28 AM UTC+1, R.I. Pienaar wrote:
> 
> > you do not need to have puppet running for the agent to work, just
stop it
> > entirely and then trigger runs through mcollective - in that setup it
will
> > happily pass custom arguments like --noop or --no-noop etc
> >
> 
> Right, I was kind of hoping that would be how it works but I still get the
> message "execution expired" back from the node ... what is that
even meant
> to mean? If you compare the output from my node and my puppetmaster (where
> I am running mco from):
> 
> 2013-04-12 10:31:45: training-puppetmaster schedule status: Started a
> background Puppet run using the ''puppet agent --onetime
--daemonize
> --color=false --no-noop'' command
> 2013-04-12 10:31:51: training-node1 schedule status: execution expired
> 
>  Is that just what I should be expecting?
> 
no idea - you''re not showing us what command you run, your configs,
what
logs these are from etc.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Sorry, slack of me:

*Running:*
*
*
 mco puppet -v runall 2

*Agent Config:*
*
*
[main]
  logdir=/var/log/puppet
  vardir=/var/lib/puppet
  ssldir=/var/lib/puppet/ssl
  rundir=/var/run/puppet
  factpath=$vardir/lib/facter
  templatedir=$confdir/templates

[agent]
  server      = puppetmaster
  ca_server   = puppetmaster
  report      = true

*And as I am using Debian, /etc/default/puppet:*
*
*
# Defaults for puppet - sourced by /etc/init.d/puppet

# Enable puppet agent service?
# Setting this to "yes" allows the puppet agent service to run.
# Setting this to "no" keeps the puppet agent service from running.
START=no

# Startup options
DAEMON_OPTS=""

*Server Config:*
*
*
[main]
  logdir    = /var/log/puppet
  vardir    = /var/lib/puppet
  ssldir    = /var/lib/puppet/ssl
  rundir    = /var/run/puppet
  factpath  = $vardir/lib/facter

[master]
  certname   = training-puppetmaster.plus.net
  ca         = true
  pluginsync = true
  manifest   = $confdir/manifests/unknown_environment.pp
  modulepath = $confdir/modules
  ssl_client_header = SSL_CLIENT_S_DN
  ssl_client_verify_header = SSL_CLIENT_VERIFY

[agent]
  server = puppetmaster
  ca_server = puppetmaster

[production]
  manifest    = /local/puppet/env/$environment/manifests/site.pp
  manifestdir = /local/puppet/env/$environment/manifests


*The error message is in the output of mco, puppet. Copied verbatim:*
*
*
root@training-puppetmaster:~# mco puppet -v runall 2
2013-04-12 11:37:05: Running all nodes with a concurrency of 2
2013-04-12 11:37:05: Discovering enabled Puppet nodes to manage
Discovering hosts using the mc method for 3 second(s) .... 2
2013-04-12 11:37:08: Found 2 enabled nodes
Discovering hosts using the mc method for 3 second(s) .... 0
2013-04-12 11:37:15: training-puppetmaster schedule status: Started a 
background Puppet run using the ''puppet agent --onetime --daemonize 
--color=false'' command
2013-04-12 11:37:21: training-node1 schedule status: execution expired

Thanks
Josh

On Friday, April 12, 2013 10:55:51 AM UTC+1, R.I. Pienaar
wrote:
>
>
>
> ----- Original Message ----- 
> > From: "Josh" <jo...@chickenmonkey.co.uk
<javascript:>>
> > To: puppet...@googlegroups.com <javascript:> 
> > Sent: Friday, April 12, 2013 10:33:17 AM 
> > Subject: Re: [Puppet Users] MCollective and Puppet with periodic runs 
> disabled 
> > 
> > On Friday, April 12, 2013 10:13:28 AM UTC+1, R.I. Pienaar wrote: 
> > 
> > > you do not need to have puppet running for the agent to work,
just
> stop it 
> > > entirely and then trigger runs through mcollective - in that
setup it
> will 
> > > happily pass custom arguments like --noop or --no-noop etc 
> > > 
> > 
> > Right, I was kind of hoping that would be how it works but I still get
> the 
> > message "execution expired" back from the node ... what is
that even
> meant 
> > to mean? If you compare the output from my node and my puppetmaster 
> (where 
> > I am running mco from): 
> > 
> > 2013-04-12 10:31:45: training-puppetmaster schedule status: Started a 
> > background Puppet run using the ''puppet agent --onetime
--daemonize
> > --color=false --no-noop'' command 
> > 2013-04-12 10:31:51: training-node1 schedule status: execution expired
> > 
> >  Is that just what I should be expecting? 
> > 
>
> no idea - you''re not showing us what command you run, your
configs, what
> logs these are from etc. 
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

----- Original Message -----
> From: "Josh" <josh@chickenmonkey.co.uk>
> To: puppet-users@googlegroups.com
> Sent: Friday, April 12, 2013 11:38:04 AM
> Subject: Re: [Puppet Users] MCollective and Puppet with periodic runs
disabled
> 
> Sorry, slack of me:
> 
> *Running:*
> *
> *
>  mco puppet -v runall 2
> 
> *Agent Config:*
> *
> *
> [main]
>   logdir=/var/log/puppet
>   vardir=/var/lib/puppet
>   ssldir=/var/lib/puppet/ssl
>   rundir=/var/run/puppet
>   factpath=$vardir/lib/facter
>   templatedir=$confdir/templates
> 
> [agent]
>   server      = puppetmaster
>   ca_server   = puppetmaster
>   report      = true
> 
> *And as I am using Debian, /etc/default/puppet:*
> *
> *
> # Defaults for puppet - sourced by /etc/init.d/puppet
> 
> # Enable puppet agent service?
> # Setting this to "yes" allows the puppet agent service to run.
> # Setting this to "no" keeps the puppet agent service from
running.
> START=no
> 
> # Startup options
> DAEMON_OPTS=""
> 
> *Server Config:*
> *
> *
> [main]
>   logdir    = /var/log/puppet
>   vardir    = /var/lib/puppet
>   ssldir    = /var/lib/puppet/ssl
>   rundir    = /var/run/puppet
>   factpath  = $vardir/lib/facter
> 
> [master]
>   certname   = training-puppetmaster.plus.net
>   ca         = true
>   pluginsync = true
>   manifest   = $confdir/manifests/unknown_environment.pp
>   modulepath = $confdir/modules
>   ssl_client_header = SSL_CLIENT_S_DN
>   ssl_client_verify_header = SSL_CLIENT_VERIFY
> 
> [agent]
>   server = puppetmaster
>   ca_server = puppetmaster
> 
> [production]
>   manifest    = /local/puppet/env/$environment/manifests/site.pp
>   manifestdir = /local/puppet/env/$environment/manifests
> 
> 
> *The error message is in the output of mco, puppet. Copied verbatim:*
> *
> *
> root@training-puppetmaster:~# mco puppet -v runall 2
> 2013-04-12 11:37:05: Running all nodes with a concurrency of 2
> 2013-04-12 11:37:05: Discovering enabled Puppet nodes to manage
> Discovering hosts using the mc method for 3 second(s) .... 2
> 2013-04-12 11:37:08: Found 2 enabled nodes
> Discovering hosts using the mc method for 3 second(s) .... 0
> 2013-04-12 11:37:15: training-puppetmaster schedule status: Started a
> background Puppet run using the ''puppet agent --onetime
--daemonize
> --color=false'' command
> 2013-04-12 11:37:21: training-node1 schedule status: execution expired
OK - and on training-node1 what is in mcollective server.cfg and if you
have in /etc/mcollective/plugin.d/puppet.cfg ?

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Friday, April 12, 2013 11:44:44 AM UTC+1, R.I. Pienaar wrote:
> OK - and on training-node1 what is in mcollective server.cfg and if you 
> have in /etc/mcollective/plugin.d/puppet.cfg ? 
>
The server.cfg (just password auth while I am testing):

topicprefix = /topic/
main_collective = mcollective
collectives = mcollective
libdir = /usr/share/mcollective/plugins
logfile = /var/log/mcollective.log
loglevel = info
keeplogs = 1
max_log_size = 10240
identity = training-node1
registerinterval = 300
daemonize = 1

# Plugins
securityprovider = psk
plugin.psk = unset

# ActiveMQ Configuration
connector = activemq
direct_addressing = 1
plugin.activemq.pool.size = 1

plugin.activemq.pool.1.host = 192.168.10.254
plugin.activemq.pool.1.port = 61613
plugin.activemq.pool.1.user = mcollective
plugin.activemq.pool.1.password = secret
plugin.activemq.pool.1.ssl = 0


# Facts
factsource = yaml
plugin.yaml = /etc/mcollective/facts.yaml 


I don''t have anything like /etc/mcollective/plugin.d/puppet.cfg on the 
server

Thanks
Josh

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

----- Original Message -----
> From: "Josh" <josh@chickenmonkey.co.uk>
> To: puppet-users@googlegroups.com
> Sent: Friday, April 12, 2013 12:11:36 PM
> Subject: Re: [Puppet Users] MCollective and Puppet with periodic runs
disabled
> 
> On Friday, April 12, 2013 11:44:44 AM UTC+1, R.I. Pienaar wrote:
> 
> > OK - and on training-node1 what is in mcollective server.cfg and if
you
> > have in /etc/mcollective/plugin.d/puppet.cfg ?
> >
> 
> The server.cfg (just password auth while I am testing):
ok - so if you did ''mco rpc puppet runonce -I training-node1''
do you get the
same timeout error?

anything in the logs on like mcollectived.log on training-node1?

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Friday, April 12, 2013 12:13:12 PM UTC+1, R.I. Pienaar wrote:
> ok - so if you did ''mco rpc puppet runonce -I
training-node1'' do you get
> the 
> same timeout error? 
>
Yes. Output:
root@training-puppetmaster:~# mco rpc puppet runonce -I training-node1

 * [ ============================================================> ] 1 / 1

training-node1                           Unknown Request Status
   execution expired

Finished processing 1 / 1 hosts in 5903.96 ms
 
> anything in the logs on like mcollectived.log on training-node1? 
>
Not beyond the stomp connections messages, even in debug mode.

Josh 

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

----- Original Message -----
> From: "Josh" <josh@chickenmonkey.co.uk>
> To: puppet-users@googlegroups.com
> Sent: Friday, April 12, 2013 2:04:45 PM
> Subject: Re: [Puppet Users] MCollective and Puppet with periodic runs
disabled
> 
> On Friday, April 12, 2013 12:13:12 PM UTC+1, R.I. Pienaar wrote:
> 
> > ok - so if you did ''mco rpc puppet runonce -I
training-node1'' do you get
> > the
> > same timeout error?
> >
> 
> Yes. Output:
can you show your client.cfg either /etc/mcollective/client.cfg or
~/.mcollective
where you ran this ''mco rpc....'' command?

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Friday, April 12, 2013 3:10:05 PM UTC+1, R.I. Pienaar wrote:
> can you show your client.cfg either /etc/mcollective/client.cfg or 
> ~/.mcollective 
> where you ran this ''mco rpc....'' command? 
>
Almost the same as the server.cfg tbh:

topicprefix = /topic/
main_collective = mcollective
collectives = mcollective
libdir = /usr/share/mcollective/plugins
logfile = /var/log/mcollective.log
loglevel = info
keeplogs = 1
max_log_size = 10240

# Plugins
securityprovider = psk
plugin.psk = unset

# ActiveMQ Configuration
connector = activemq
direct_addressing = 1
plugin.activemq.pool.size = 1

plugin.activemq.pool.1.host = 192.168.10.254
plugin.activemq.pool.1.port = 61613
plugin.activemq.pool.1.user = mcollective
plugin.activemq.pool.1.password = secret
plugin.activemq.pool.1.ssl = 0

# Facts
factsource = yaml
plugin.yaml = /etc/mcollective/facts.yaml

Josh 

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

----- Original Message -----
> From: "Josh" <josh@chickenmonkey.co.uk>
> To: puppet-users@googlegroups.com
> Sent: Friday, April 12, 2013 3:43:34 PM
> Subject: Re: [Puppet Users] MCollective and Puppet with periodic runs
disabled
> 
> On Friday, April 12, 2013 3:10:05 PM UTC+1, R.I. Pienaar wrote:
> 
> > can you show your client.cfg either /etc/mcollective/client.cfg or
> > ~/.mcollective
> > where you ran this ''mco rpc....'' command?
> >
> 
> Almost the same as the server.cfg tbh:
> 
> direct_addressing = 1
you need this everywhere if you set it...

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Friday, April 12, 2013 3:55:49 PM UTC+1, R.I. Pienaar wrote:
> you need this everywhere if you set it... 
>
It is in the client.cfg and the server.cfg across both hosts. I don''t
need
to add anything into my activemq configuration do I?

Josh

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

----- Original Message -----
> From: "Josh" <josh@chickenmonkey.co.uk>
> To: puppet-users@googlegroups.com
> Sent: Friday, April 12, 2013 4:21:38 PM
> Subject: Re: [Puppet Users] MCollective and Puppet with periodic runs
disabled
> 
> On Friday, April 12, 2013 3:55:49 PM UTC+1, R.I. Pienaar wrote:
> 
> > you need this everywhere if you set it...
> >
> 
> It is in the client.cfg and the server.cfg across both hosts. I
don''t need
> to add anything into my activemq configuration do I?
> 
everywhere, all client.cfg and server.cfg.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Friday, April 12, 2013 4:23:14 PM UTC+1, R.I. Pienaar wrote:
> everywhere, all client.cfg and server.cfg. 

Yup, it is everywhere then

Josh 

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

----- Original Message -----
> From: "Josh" <josh@chickenmonkey.co.uk>
> To: puppet-users@googlegroups.com
> Sent: Friday, April 12, 2013 4:31:45 PM
> Subject: Re: [Puppet Users] MCollective and Puppet with periodic runs
disabled
> 
> On Friday, April 12, 2013 4:23:14 PM UTC+1, R.I. Pienaar wrote:
> 
> > everywhere, all client.cfg and server.cfg.
> 
> 
> Yup, it is everywhere then
so it works now?

if not - first make sure ''mco rpc rpcutil ping -I your.node''
works
when that works the rest will also work.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Friday, April 12, 2013 4:41:24 PM UTC+1, R.I. Pienaar wrote:
> so it works now? 
>
> if not - first make sure ''mco rpc rpcutil ping -I
your.node'' works
> when that works the rest will also work. 
>
No, still not working, and the ping (and everything else for that matter 
just as inventory) works fine.

I am begging to suspect that there is some internal timeout in the mco 
plugin and the puppet agent is taking some time to fire up and hence 
triggering the timeout. This is all on virtual machines without a great 
deal of resources but it still seems to run puppet quickly enough when i 
run it manually 

I will have a think about it over the weekend, maybe I will have a flash of 
inspiration.

Many thanks for all your time today, I''ll post back if I get some
progress

Josh

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

----- Original Message -----
> From: "Josh" <josh@chickenmonkey.co.uk>
> To: puppet-users@googlegroups.com
> Sent: Friday, April 12, 2013 5:07:48 PM
> Subject: Re: [Puppet Users] MCollective and Puppet with periodic runs
disabled
> 
> On Friday, April 12, 2013 4:41:24 PM UTC+1, R.I. Pienaar wrote:
> 
> > so it works now?
> >
> > if not - first make sure ''mco rpc rpcutil ping -I
your.node'' works
> > when that works the rest will also work.
> >
> 
> No, still not working, and the ping (and everything else for that matter
> just as inventory) works fine.
> 
> I am begging to suspect that there is some internal timeout in the mco
> plugin and the puppet agent is taking some time to fire up and hence
> triggering the timeout. This is all on virtual machines without a great
> deal of resources but it still seems to run puppet quickly enough when i
> run it manually
> 
> I will have a think about it over the weekend, maybe I will have a flash of
> inspiration.
> 
> Many thanks for all your time today, I''ll post back if I get some
progress
ok - you could set direct_addressing=0 in your client.cfg, that I''d
guess
would make it work.

else turn on debug level logs and put those on pastebins cos that will enable
me to really figure out, thus far I''ve just been quessing at common
causes

This thread is probably best on the mcollective-users list also on google
groups.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.