2

I am using the following Puppet version on CentOS Linux release 7.2:

# puppetserver -v
puppetserver version: 2016.5.0.11

I have a Win agent node and i might have few more later. Agent version on Win node:

C:\Windows\system32>puppet --version
4.8.1

I would like to disable the agent runinterval permanently so i can only push from my Puppet server when required. I saw few links and tried putting the following line in Puppet server's /etc/puppetlabs/puppet/puppet.conf file. I also restarted the server but still the agent is fetching the catalog.

[agent]
daemonize=false

I would also like to know whether it's possible to disable runinterval only on specific nodes. If yes, how?

Technext
  • 7,887
  • 9
  • 48
  • 76
  • 1
    You have a good answer explaining how to prevent the agent from issuing catalog requests, but it's unclear to me how you expect to implement any kind of pushing from the master to other nodes. Not via Puppet, certainly, unless this is a PE feature I don't know about. Puppet has *never* had a push feature, though until Puppet 4 it had a remotely-trigger-a-catalog-request feature (which required the agent to be running, but not necessarily configured to issue catalog requests). – John Bollinger Feb 07 '17 at 22:12
  • Though i didn't go into the implementation, i thought `mco` will be of help in pushing changes. Is that not possible while keeping the agent service disabled? – Technext Feb 08 '17 at 05:46
  • 1
    You can use MCollective to cause agents to perform catalog runs on demand. If that serves your needs then well and good. However, it is not technically a push, and it is not facilitated by core Puppet. These fine distinctions may not matter to you. – John Bollinger Feb 08 '17 at 14:08
  • So does it mean i will have to keep the agent service enabled? If that's the case, then may be i will have to set the `runinterval` to a very large number making it effectively disabled. – Technext Feb 09 '17 at 07:49
  • 1
    No, if you're planning to use MCollective to trigger catalog runs, then you do not need the Puppet service to be enabled. I am primarily pointing out that doing so is not technically a push. That may not matter for you, but it does differ in some details that *could* matter. For example, with a push, the agents would not need to be able to initiate connections with the master, but with your approach they will need to be able to do, even though they will do it only at times you choose. – John Bollinger Feb 09 '17 at 13:00
  • Thank you John for mentioning these details. :) As long as i am able to control the runs, it should suffice however, the details do matter to me for the sake of my understanding. Right now, i haven't went into those but will _surely_ do once i get into the implementation phase. Thanks again! – Technext Feb 09 '17 at 14:12

2 Answers2

3

What you are basically looking at doing is stopping the Puppet service. This is accomplished most easily with a puppet service resource:

service { 'puppet':
  ensure => stopped,
  enable => false,
}

To do this only on certain nodes, merely supply it for the corresponding node definitions in your classifier or main site manifest:

node /ones_to_disable/ {
  service { 'puppet':
    ensure => stopped,
    enable => false,
  }
}

This is the easy and common method for accomplishing push-style Puppet and disabling pull-style.

Matthew Schuchard
  • 25,172
  • 3
  • 47
  • 67
  • I also saw `--no-client` option somewhere however, i am not sure how can i use this in config file and which file is this applicable for. Is this a better approach than disabling the service the way you've specified? – Technext Feb 06 '17 at 12:53
  • @Technext This is super easy, works very well, and satisfies your needs. There may be an even better solution than this, but I have not seen it or implemented it at any company where I have been involved in a Puppet implementation. If you try to do this in a config file then it becomes client-side and becomes part of the bootstrap process. This method just works automatically for all future node subscriptions, which is one reason why we go this route. – Matthew Schuchard Feb 06 '17 at 13:10
  • I understand what you're trying to explain. Even i am looking only for a server-side config change as it's anytime easier to maintain. It seems `--no-client` is a client-side option. I was assuming otherwise. :) Although your solution is straightforward, i'll try it out first and then update you. – Technext Feb 06 '17 at 17:57
1

If you want to disable Puppet agent on given node you have to use this command: puppet agent --disable. You can specify a reason, why you are disabling agent on given node. The message that you could supply will be printed next time someone will type puppet agent on node.

Cosaquee
  • 724
  • 1
  • 6
  • 22
  • For both the cases, i am looking for change that needs to be done in the _config_ file, not on the command line. – Technext Feb 06 '17 at 08:37