FAQ
Hi,

We do not want to have puppet changing things out from under us, then
looking at a log file after-the-fact. We are okay with running puppet agent
manually for the particular application we have chosen it for under our
control. With that framework in mind, please ponder the following question.

My question is: what is the method to disable puppet agent on a host
yet still permit a manual application of a pp file.

I.e. something like "modify your agent node's puppet.conf to have
xyz-whizbang" and keep your puppet agent running in the normal way
with /etc/init.d/puppet start and system boot using normal rc processes,
then when you run manually either use mcollective or manually do
a puppet apply xyz.pp on the box in question.

Thanks for your wizardry.

Stuart

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/942b8fae-472a-4b45-9eab-3673c8713d44%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Stuart Cracraft at Nov 22, 2013 at 8:43 pm
    This appears to document it:

    http://grokbase.com/t/gg/puppet-users/132ddnva3r/daemonize-puppet-agent-but-disable-periodic-runs

    A yea or a nay from the userbase or p-labbers would be helpful.

    My goal is to have it running, not automatically, and responsive to manual
    puppet apply.
    On Friday, November 22, 2013 11:43:01 AM UTC-8, Stuart Cracraft wrote:

    Hi,

    We do not want to have puppet changing things out from under us, then
    looking at a log file after-the-fact. We are okay with running puppet agent
    manually for the particular application we have chosen it for under our
    control. With that framework in mind, please ponder the following question.

    My question is: what is the method to disable puppet agent on a host
    yet still permit a manual application of a pp file.

    I.e. something like "modify your agent node's puppet.conf to have
    xyz-whizbang" and keep your puppet agent running in the normal way
    with /etc/init.d/puppet start and system boot using normal rc processes,
    then when you run manually either use mcollective or manually do
    a puppet apply xyz.pp on the box in question.

    Thanks for your wizardry.

    Stuart
    --
    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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/fae02243-68ea-497a-a16d-09a9cf66590b%40googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at Nov 25, 2013 at 2:34 pm

    On Friday, November 22, 2013 1:43:01 PM UTC-6, Stuart Cracraft wrote:
    Hi,

    We do not want to have puppet changing things out from under us, then
    looking at a log file after-the-fact. We are okay with running puppet agent
    manually for the particular application we have chosen it for under our
    control. With that framework in mind, please ponder the following question.

    My question is: what is the method to disable puppet agent on a host
    yet still permit a manual application of a pp file.

    I.e. something like "modify your agent node's puppet.conf to have
    xyz-whizbang" and keep your puppet agent running in the normal way
    with /etc/init.d/puppet start and system boot using normal rc processes,
    then when you run manually either use mcollective or manually do
    a puppet apply xyz.pp on the box in question.

    Thanks for your wizardry.
    To run the *agent* manually, once, use the --onetime --no-daemonize
    options. You can certainly specify them on the command line, and I think
    you can also specify them in puppet.conf (in the [agent] section). Because
    this method uses the Puppet agent, it relies on a master being accessible.

    To apply manifests that are resident locally on the system, use "puppet
    apply" that mechanism is always a one-time, non-daemon activity.

    It is important for you to decide whether you want to use the "agent"
    interface or the "apply" interface, as these have very different
    requirements for the location of your manifests and config data, and very
    different implications for you you can or should deliver changes to those.
    Either one could satisfy the requirements you described.

    Note also,

        1. Command-line options override the config file, so your config cannot
        *prevent* an authorized user from starting the agent in daemon mode if
        they intend to do so.
        2. Naturally, you will also want to configure the system to not start
        the daemon automatically. This is done via the same mechanism that
        controls other system services (which varies with OS flavor).

    As far as I am aware, the --no-client option you asked about in your
    followup will not achieve what you want. That is, although it will prevent
    the agent daemon from performing periodic runs, it will not do anything
    useful to enable manual runs (and you don't need any special enablement for
    that, anyway).


    John

    --
    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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/cca2abee-aaab-4737-84a3-dd2a9fbcf7ad%40googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Calvin Walton at Nov 25, 2013 at 10:40 pm

    On Fri, 2013-11-22 at 11:43 -0800, Stuart Cracraft wrote:
    Hi,

    We do not want to have puppet changing things out from under us, then
    looking at a log file after-the-fact. We are okay with running puppet agent
    manually for the particular application we have chosen it for under our
    control. With that framework in mind, please ponder the following question.

    My question is: what is the method to disable puppet agent on a host
    yet still permit a manual application of a pp file.

    I.e. something like "modify your agent node's puppet.conf to have
    xyz-whizbang" and keep your puppet agent running in the normal way
    with /etc/init.d/puppet start and system boot using normal rc processes,
    then when you run manually either use mcollective or manually do
    a puppet apply xyz.pp on the box in question.
    If you're only ever going to be using e.g. 'puppet agent --test' or
    'puppet apply foo.pp' on the command line, then you don't need puppet
    running as a daemon at all. Just stop the service, disable the init
    script, and you're good to go.

    --
    Calvin Walton <calvin.walton@kepstin.ca>

    --
    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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1385419194.4379.18.camel%40hp-a6734f.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Stuart Cracraft at Nov 25, 2013 at 10:55 pm
    Hi Calvin,

    We want continuous 7x24x365 test with no changes unless physically applied
    by one or more authorized people only.

    As far as I can tell, the way to do this is:

        puppet agent --test --verbose --noop

    on the node and

       puppet apply whatever.pp

    on the node itself, with full logging back to the puppet master...

    I don't believe the above fulfill all that. We want the minimum footprint
    on the remote boxes (i.e. no mcollective, etc.) and want to avoid ssh'ing
    all around the universe, instead depending on the command-and-control
    (and reporting) which Puppet implements.

    On Monday, November 25, 2013 2:39:54 PM UTC-8, Calvin Walton wrote:
    On Fri, 2013-11-22 at 11:43 -0800, Stuart Cracraft wrote:
    Hi,

    We do not want to have puppet changing things out from under us, then
    looking at a log file after-the-fact. We are okay with running puppet agent
    manually for the particular application we have chosen it for under our
    control. With that framework in mind, please ponder the following question.
    My question is: what is the method to disable puppet agent on a host
    yet still permit a manual application of a pp file.

    I.e. something like "modify your agent node's puppet.conf to have
    xyz-whizbang" and keep your puppet agent running in the normal way
    with /etc/init.d/puppet start and system boot using normal rc processes,
    then when you run manually either use mcollective or manually do
    a puppet apply xyz.pp on the box in question.
    If you're only ever going to be using e.g. 'puppet agent --test' or
    'puppet apply foo.pp' on the command line, then you don't need puppet
    running as a daemon at all. Just stop the service, disable the init
    script, and you're good to go.

    --
    Calvin Walton <calvin...@kepstin.ca <javascript:>>
    --
    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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/0a21a7e8-f164-4da3-9aef-8af81f7f095f%40googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedNov 22, '13 at 7:43p
activeNov 25, '13 at 10:55p
posts5
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase