Hello all,
I''m thinking about a configuration class that, amongst other things
execs out to a ''dangerous'' configuration script. I''d
like to make this
a noop by default, so the operator has to try a bit harder to invoke it.
So I thought about doing something like:
class blah {
exec { danger:
noop => true,
tag => hitme,
command => "might_break_it",
path => "/bin:/usr/bin:/usr/local/bin",
logoutput => true
}
}
And fire up puppetd with
puppetd -o --tags hitme
Unfortunately it doesn''t fire the script... Whilst I see from an
earlier
post there you can supply --no-noop to puppetd, it makes no difference.
I presume this getoptism only works if the noop you''re using has been
put in puppet.conf, not in the type.
I also looked briefly at virtual resources. Unfortunately I can''t see
any way to make puppet realise the resource from the command line.
Anyone got any ideas?
Cheers,
Derek
------------------------------------------------------------------------
For important statutory and regulatory disclosures and more information about
Barclays Capital, please visit our web site at http://www.barcap.com.
Internet communications are not secure and therefore the Barclays Group does not
accept legal responsibility for the contents of this message. Although the
Barclays Group operates anti-virus programmes, it does not accept responsibility
for any damage whatsoever that is caused by viruses being passed. Any views or
opinions presented are solely those of the author and do not necessarily
represent those of the Barclays Group. Replies to this email may be monitored
by the Barclays Group for operational or business reasons.
Barclays Capital is the investment banking division of Barclays Bank PLC, a
company registered in England (number 1026167) with its registered office at 1
Churchill Place, London, E14 5HP. This email may relate to or be sent from other
members of the Barclays Group.
------------------------------------------------------------------------
On Jun 21, 2007, at 4:37 AM, <Derek.Whayman@barclayscapital.com> wrote: [...]> Unfortunately it doesn''t fire the script... Whilst I see from an > earlier > post there you can supply --no-noop to puppetd, it makes no > difference. > I presume this getoptism only works if the noop you''re using has been > put in puppet.conf, not in the type. > > I also looked briefly at virtual resources. Unfortunately I can''t see > any way to make puppet realise the resource from the command line. > > Anyone got any ideas?This seems like a bug, since there should be a way to selectively trigger a resource. I''d appreciate it if you''d file an enhancement request for this. In the meantime... I see two basic ways to do this: You could create a schedule that effectively never matches (the first minute of the first hour of the first day of the first month or something; I think there are other options for this), then use -- ignoreschedules and --tags to run that specific command. The downside to this is that any call with --ignoreschedules will run this script (as long as tags match). Another option is to use a custom fact. It''s a little-known fact that Facter will pull facts from the shell environment, so you could key the presence of the script in your configuration off of such a variable, then set it when you want to run: Puppet code: case $bedangerous { default: { # nothing } true: { exec { "rm -rf /": } } } export facter_bedangerous=true sudo puppetd -t Of course, sudo clobbers env variables by default, so this wouldn''t work if you actually use sudo. -- What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? --Larry Wall in <1992Aug26.184221.29627@netlabs.com> --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
<Derek.Whayman@barclayscapital.com>
2007-Jun-21 16:32 UTC
Re: Noop and "dangerous" classes
Ticket #682 created. Actually, AFAIK sudo only clobbers things like LD_PRELOAD that could be used to try to compromise the system. So, your facter method below does in fact work (once you quote "true"). Nice. Many thanks, Derek -----Original Message----- From: puppet-users-bounces@madstop.com [mailto:puppet-users-bounces@madstop.com] On Behalf Of Luke Kanies Sent: 21 June 2007 16:52 To: Puppet User Discussion Subject: Re: [Puppet-users] Noop and "dangerous" classes On Jun 21, 2007, at 4:37 AM, <Derek.Whayman@barclayscapital.com> wrote: [...]> Unfortunately it doesn''t fire the script... Whilst I see from an > earlier post there you can supply --no-noop to puppetd, it makes no > difference. > I presume this getoptism only works if the noop you''re using has been > put in puppet.conf, not in the type. > > I also looked briefly at virtual resources. Unfortunately I can''t see> any way to make puppet realise the resource from the command line. > > Anyone got any ideas?This seems like a bug, since there should be a way to selectively trigger a resource. I''d appreciate it if you''d file an enhancement request for this. In the meantime... I see two basic ways to do this: You could create a schedule that effectively never matches (the first minute of the first hour of the first day of the first month or something; I think there are other options for this), then use -- ignoreschedules and --tags to run that specific command. The downside to this is that any call with --ignoreschedules will run this script (as long as tags match). Another option is to use a custom fact. It''s a little-known fact that Facter will pull facts from the shell environment, so you could key the presence of the script in your configuration off of such a variable, then set it when you want to run: Puppet code: case $bedangerous { default: { # nothing } true: { exec { "rm -rf /": } } } export facter_bedangerous=true sudo puppetd -t Of course, sudo clobbers env variables by default, so this wouldn''t work if you actually use sudo. -- What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? --Larry Wall in <1992Aug26.184221.29627@netlabs.com> --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users ------------------------------------------------------------------------ For important statutory and regulatory disclosures and more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ------------------------------------------------------------------------
Derek.Whayman@barclayscapital.com wrote:> Ticket #682 created. > > Actually, AFAIK sudo only clobbers things like LD_PRELOAD that could be > used to try to compromise the system. So, your facter method below does > in fact work (once you quote "true"). Nice.Debian''s sudo does clobber environment variables: $ head -n 6 /usr/share/doc/sudo/README.Debian The version of sudo that ships with Debian by default resets the environment, as described by the "env_reset" flag in the sudoers file. This implies that all environment variables are removed, except for HOME, LOGNAME, PATH, SHELL, TERM, DISPLAY, XAUTHORITY, XAUTHORIZATION, LANG, LANGUAGE, LC_*, and USER. Jordan