Puppet users - Feb 2011 - logoutput=>on_failure doesn't work as expected

I''m using puppet 0.25.1.  I''ve got a simple resource:

exec { "/bin/ls $oracle_base/dba/bin/database_backup.ksh":
    logoutput => on_failure,
}

and I don''t want it to log every time it''s successfully run:

$ sudo tail -F /var/log/messages | grep puppetd
Feb 17 16:36:11 test puppetd[26614]: (//my_module/Exec[/bin/ls /u01/
app/oracle/dba/bin/database_backup.ksh]/returns) executed successfully

but logoutput => on_failure doesn''t suppress the above message.

Is that parameter not available in my version of puppet, or am I
perhaps misunderstanding its purpose?  I''m guessing the latter since
it looks like it was introduced 3 years ago.

In the meantime, I''m using this ugly, redundant hack to do what I
want:

exec { "/bin/ls $oracle_base/dba/bin/database_backup.ksh":
    unless => "/bin/ls $oracle_base/dba/bin/database_backup.ksh",
}

Thanks!

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

On Feb 17, 5:33 pm, Bryan <bmaupinc...@gmail.com>
wrote:
> I''m using puppet 0.25.1.  I''ve got a simple resource:
>
> exec { "/bin/ls $oracle_base/dba/bin/database_backup.ksh":
>     logoutput => on_failure,
>
> }
>
> and I don''t want it to log every time it''s successfully
run:
>
> $ sudo tail -F /var/log/messages | grep puppetd
> Feb 17 16:36:11 test puppetd[26614]: (//my_module/Exec[/bin/ls /u01/
> app/oracle/dba/bin/database_backup.ksh]/returns) executed successfully
>
> but logoutput => on_failure doesn''t suppress the above message.
>
> Is that parameter not available in my version of puppet, or am I
> perhaps misunderstanding its purpose?  I''m guessing the latter
since
> it looks like it was introduced 3 years ago.
logoutput is about whether the command''s standard output is copied
into Puppet''s log.  If that''s still not clicking for you, try
changing
to logoutput => true to see the difference, especially when the target
file is present.  (When its argument is absent, ls writes to standard
error, which I think Puppet always copies to its log.)
> In the meantime, I''m using this ugly, redundant hack to do what I
> want:
>
> exec { "/bin/ls $oracle_base/dba/bin/database_backup.ksh":
>     unless => "/bin/ls
$oracle_base/dba/bin/database_backup.ksh",
>
> }
This would be less redundant, but still hackish:

exec { "check_database_backup.ksh":
    command => "/bin/false",
    unless => "/bin/ls $oracle_base/dba/bin/database_backup.ksh 2> /
dev/null",
}


I''m not sure exactly what you''re after, but a File resource is
usually
better than an Exec for managing and monitoring files.  For instance,
it is possible that this would serve your purposes:

file { "$oracle_base/dba/bin/database_backup.ksh":
    ensure => present,
    audit => all
}

It should produce output to the Puppet log only if the file is not
initially present.  However, it might create an empty file (and
subsequently not log anything while that file remains); if that
matters to you then test.  Also, the resource will not fail if the
file is absent, which an Exec could do.

If all you want to do is test for the presence of a file, however,
then really you should create a custom fact (which is easy) instead of
attempting to use a resource.  That will fit much more naturally into
the Puppet Way, and it will be a lot more flexible for you.


John

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

Hi,

On 02/18/2011 12:33 AM, Bryan wrote:
> I''m using puppet 0.25.1.  I''ve got a simple resource:
> 
> exec { "/bin/ls $oracle_base/dba/bin/database_backup.ksh":
>     logoutput => on_failure,
> }
> 
> and I don''t want it to log every time it''s successfully
run:
> 
> $ sudo tail -F /var/log/messages | grep puppetd
> Feb 17 16:36:11 test puppetd[26614]: (//my_module/Exec[/bin/ls /u01/
> app/oracle/dba/bin/database_backup.ksh]/returns) executed successfully
> 
> but logoutput => on_failure doesn''t suppress the above message.
First of: What the hell? What do you need that for? You don''t seem to
be
subscribing to it.
> Is that parameter not available in my version of puppet, or am I
> perhaps misunderstanding its purpose?  I''m guessing the latter
since
> it looks like it was introduced 3 years ago.
> 
> In the meantime, I''m using this ugly, redundant hack to do what I
> want:
> 
> exec { "/bin/ls $oracle_base/dba/bin/database_backup.ksh":
>     unless => "/bin/ls
$oracle_base/dba/bin/database_backup.ksh",
> }
There''s indeed a misunderstanding. Puppet will always drop a notice
about a resource that changes (i.e., an exec that is run).
log_output allows puppet to include the stdout of the exec''d process in
its logs.

What you''re looking for is e.g.
loglevel => debug

HTH,
Felix

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

On Feb 18, 8:40 am, jcbollinger <John.Bollin...@stJude.org>
wrote:
> On Feb 17, 5:33 pm, Bryan <bmaupinc...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > I''m using puppet 0.25.1.  I''ve got a simple
resource:
>
> > exec { "/bin/ls $oracle_base/dba/bin/database_backup.ksh":
> >     logoutput => on_failure,
>
> > }
>
> > and I don''t want it to log every time it''s
successfully run:
>
> > $ sudo tail -F /var/log/messages | grep puppetd
> > Feb 17 16:36:11 test puppetd[26614]: (//my_module/Exec[/bin/ls /u01/
> > app/oracle/dba/bin/database_backup.ksh]/returns) executed successfully
>
> > but logoutput => on_failure doesn''t suppress the above
message.
>
> > Is that parameter not available in my version of puppet, or am I
> > perhaps misunderstanding its purpose?  I''m guessing the
latter since
> > it looks like it was introduced 3 years ago.
>
> logoutput is about whether the command''s standard output is copied
> into Puppet''s log.  If that''s still not clicking for you,
try changing
> to logoutput => true to see the difference, especially when the target
> file is present.  (When its argument is absent, ls writes to standard
> error, which I think Puppet always copies to its log.)
>
> > In the meantime, I''m using this ugly, redundant hack to do
what I
> > want:
>
> > exec { "/bin/ls $oracle_base/dba/bin/database_backup.ksh":
> >     unless => "/bin/ls
$oracle_base/dba/bin/database_backup.ksh",
>
> > }
>
> This would be less redundant, but still hackish:
>
> exec { "check_database_backup.ksh":
>     command => "/bin/false",
>     unless => "/bin/ls $oracle_base/dba/bin/database_backup.ksh
2> /
> dev/null",
>
> }
>
> I''m not sure exactly what you''re after, but a File
resource is usually
> better than an Exec for managing and monitoring files.  For instance,
> it is possible that this would serve your purposes:
>
> file { "$oracle_base/dba/bin/database_backup.ksh":
>     ensure => present,
>     audit => all
>
> }
>
> It should produce output to the Puppet log only if the file is not
> initially present.  However, it might create an empty file (and
> subsequently not log anything while that file remains); if that
> matters to you then test.  Also, the resource will not fail if the
> file is absent, which an Exec could do.
>
> If all you want to do is test for the presence of a file, however,
> then really you should create a custom fact (which is easy) instead of
> attempting to use a resource.  That will fit much more naturally into
> the Puppet Way, and it will be a lot more flexible for you.
>
> John
Okay, that makes more sense.

Essentially this file is created by someone else during the server
setup process.  I''d put it in Puppet myself but I''m unable to
for
reasons I won''t go into.  We have automated backup scripts that depend
on this file, and I don''t want them to be put into place until this
file is there, so it didn''t seem like a File resource would work
because 1. I don''t want to put a file there and 2. I want the resource
to fail until the file is put there so its dependencies aren''t put
into place.

I want puppet to bug me until the file''s put into place, but once
it''s
there I don''t want to see extra output in the Puppet logs every time
it checks.

I probably need to rethink how I''m doing this, but in the meantime
I''ll look into a custom fact.

Thanks for your help.

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

On 2011-02-18 16:33, Bryan wrote:
> On Feb 18, 8:40 am, jcbollinger <John.Bollin...@stJude.org> wrote:
>> (When its argument is absent, ls writes to standard
>> error, which I think Puppet always copies to its log.)
Crazily enough, Puppet doesn''t capture standard error at all.  It
is always thrown away, making debugging exec:s unnecessarily hard.
(Unless this has changed in 2.6; I still haven''t had time to try
that out.)
> Essentially this file is created by someone else during the server
> setup process.  I''d put it in Puppet myself but I''m
unable to for
> reasons I won''t go into.  We have automated backup scripts that
depend
> on this file, and I don''t want them to be put into place until
this
> file is there, so it didn''t seem like a File resource would work
> because 1. I don''t want to put a file there and 2. I want the
resource
> to fail until the file is put there so its dependencies aren''t put
> into place.
> 
> I want puppet to bug me until the file''s put into place, but once
it''s
> there I don''t want to see extra output in the Puppet logs every
time
> it checks.
Here is one way:

    file {
	"$oracle_base/dba/bin/database_backup.ksh":
	    ensure => file, noop => true, loglevel => err;
    }

The ''noop => true'' parameter tells Puppet to not actualy
create that
file, and ''loglevel => err'' makes it log that fact as an
error instead
of as a notice.  If the file doesn''t exist, you will get a message like
this on every Puppet run:

    err: //Node[kumiko]/File[/opt/oracle/dba/bin/database_backup.ksh]/ensure:
         is absent, should be file (noop)

And here is another way:

    exec {
        database-backup-script-missing:
            command => ''/bin/echo "database_backup.ksh
missing"; /bin/false'',
            creates => "$oracle_base/dba/bin/database_backup.ksh",
            logoutput => true, loglevel => err;
    }

This gives me the messages

    err: //Node[kumiko]/Exec[database-backup-script-missing]/returns:
         database_backup.ksh missing
    err: //Node[kumiko]/Exec[database-backup-script-missing]/returns:
        change from notrun to 0 failed: /bin/echo "database_backup.ksh
missing"; /bin/false
        returned 1 instead of one of [0] at /tmp/blaha.pp:17

when the file doesn''t exist.


	/Bellman

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

On Fri, Feb 18, 2011 at 7:59 AM, Thomas Bellman <bellman@nsc.liu.se>
wrote:
>
> >> (When its argument is absent, ls writes to standard
> >> error, which I think Puppet always copies to its log.)
>
> Crazily enough, Puppet doesn''t capture standard error at all.  It
> is always thrown away, making debugging exec:s unnecessarily hard.
> (Unless this has changed in 2.6; I still haven''t had time to try
> that out.)
>

2.6.4 definitely has this included.

http://projects.puppetlabs.com/issues/2359

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

T

On Thursday, February 17, 2011 3:33:43 PM UTC-8, Bryan
wrote:
> I''m using puppet 0.25.1. I''ve got a simple resource: exec
{ "/bin/ls $oracle_base/dba/bin/database_backup.ksh": logoutput =>
on_failure, } and I don''t want it to log every time it''s
successfully run: $ sudo tail -F /var/log/messages | grep puppetd Feb 17
16:36:11 test puppetd[26614]: (//my_module/Exec[/bin/ls /u01/
app/oracle/dba/bin/database_backup.ksh]/returns) executed successfully but
logoutput => on_failure doesn''t suppress the above message. Is that
parameter not available in my version of puppet, or am I perhaps
misunderstanding its purpose? I''m guessing the latter since it looks
like it was introduced 3 years ago. In the meantime, I''m using this
ugly, redundant hack to do what I want: exec { "/bin/ls
$oracle_base/dba/bin/database_backup.ksh": unless => "/bin/ls
$oracle_base/dba/bin/database_backup.ksh", } Thanks!
This is an old one, but I found it ALMOST useful.  I''d like to take
this one step further:

I have a subscribe statement on a service that requires a file. And, now I have
the error on the non-existent file, it is still trying to run the service. I
have tried every possible way to bypass this, even with an exec (file not
found). Since the exec statement itself is "successful" (in not
finding the file), it sill launches the service dependent on that file.
Finally, I really don''t want errors to go to the client syslog... that
is the whole reason why I want to do the checking first.  To avoid errors in
syslog when the service fails (for reason of a lacking patch... another issue:
how to work with patching "if grep for patch; exists/not exists; optional
run"). I''ll keep looking but this lack of conditional services is
painful.

file {''clientxml'':
path => "/var/svc/manifest/network/sendmail-client.xml",
ensure => true,
backup => false,
noop => true,
loglevel => err,
}
service { "clientmail":
name => "sendmail-client:default",
manifest => "/var/svc/manifest/network/sendmail-client.xml",
provider => smf,
enable => true,
hasrestart => true,
require => File[''clientxml'']
}

Example:

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/KuU0kquGRWkJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

I think you are using the syntax wrong.  Try to phrase your request in
statements like "ensure this is true" instead of if/then case logic.

    ensure foo
        requires bar

Also remember that the server doesn''t know anything about the client,
and the client''s information is only collected once, and sent to the
server from which a compiled catalog (with all if/thens resolved) is produced. 
So you can''t have an if/then which is resolved at runtime.

If you require a file, you will get a failure that the file exists or not. And
an info message that service can''t be dealt with since requirement
failed. I think what you want to do is create a fact about whether the file
exists or not, and then only define the service if the fact is true.  Look up
custom facts and you''ll get there. Then your fact will be submitted,
and the catalog will be revised based on the value of the fact -- which should
meet your needs.

On Aug 25, 2012, at 8:49 PM, mthebie99 wrote:
> On Thursday, February 17, 2011 3:33:43 PM UTC-8, Bryan wrote:
>> I''m using puppet 0.25.1. I''ve got a simple resource:
exec { "/bin/ls $oracle_base/dba/bin/database_backup.ksh": logoutput
=> on_failure, } and I don''t want it to log every time it''s
successfully run: $ sudo tail -F /var/log/messages | grep puppetd Feb 17
16:36:11 test puppetd[26614]: (//my_module/Exec[/bin/ls /u01/
app/oracle/dba/bin/database_backup.ksh]/returns) executed successfully but
logoutput => on_failure doesn''t suppress the above message. Is that
parameter not available in my version of puppet, or am I perhaps
misunderstanding its purpose? I''m guessing the latter since it looks
like it was introduced 3 years ago. In the meantime, I''m using this
ugly, redundant hack to do what I want: exec { "/bin/ls
$oracle_base/dba/bin/database_backup.ksh": unless => "/bin/ls
$oracle_base/dba/bin/database_backup.ksh", } Thanks!
> 
> This is an old one, but I found it ALMOST useful.  I''d like to
take this one step further:
> 
> I have a subscribe statement on a service that requires a file. And, now I
have the error on the non-existent file, it is still trying to run the service.
I have tried every possible way to bypass this, even with an exec (file not
found). Since the exec statement itself is "successful" (in not
finding the file), it sill launches the service dependent on that file.
> Finally, I really don''t want errors to go to the client syslog...
that is the whole reason why I want to do the checking first.  To avoid errors
in syslog when the service fails (for reason of a lacking patch... another
issue: how to work with patching "if grep for patch; exists/not exists;
optional run"). I''ll keep looking but this lack of conditional
services is painful.
> 
> file {''clientxml'':
> path => "/var/svc/manifest/network/sendmail-client.xml",
> ensure => true,
> backup => false,
> noop => true,
> loglevel => err,
> }
> service { "clientmail":
> name => "sendmail-client:default",
> manifest => "/var/svc/manifest/network/sendmail-client.xml",
> provider => smf,
> enable => true,
> hasrestart => true,
> require => File[''clientxml'']
> }
> 
> Example:
> 
> -- 
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/KuU0kquGRWkJ.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
> 
-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.



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

Thank you for replying, Jo ! And yes, the resultant errors (once I got the
service dependency to actually fail when the file wasn''t found) are
also
not desireable as its misleading and creates to much verbosity(and alarm
for any admin seeing) in the client syslog.  I will give it a try...albiet
I probably won''t have response to you for another week.  This is
something
I had not tried.  (The addition of a  "require" statement
didn''t operate
correctly either probably for reason you so noted).
- alison -
On Mon, Aug 27, 2012 at 1:44 PM, Jo Rhett <jrhett@netconsonance.com>
wrote:
> I think you are using the syntax wrong.  Try to phrase your request in
> statements like "ensure this is true" instead of if/then case
logic.
>
>     ensure foo
>         requires bar
>
> Also remember that the server doesn''t know anything about the
client, and
> the client''s information is only collected once, and sent to the
server
> from which a compiled catalog (with all if/thens resolved) is produced.  So
> you can''t have an if/then which is resolved at runtime.
>
> If you require a file, you will get a failure that the file exists or not.
> And an info message that service can''t be dealt with since
requirement
> failed. I think what you want to do is create a fact about whether the file
> exists or not, and then only define the service if the fact is true.  Look
> up custom facts and you''ll get there. Then your fact will be
submitted, and
> the catalog will be revised based on the value of the fact -- which should
> meet your needs.
>
>  On Aug 25, 2012, at 8:49 PM, mthebie99 wrote:
>
> On Thursday, February 17, 2011 3:33:43 PM UTC-8, Bryan wrote:
>
> I''m using puppet 0.25.1. I''ve got a simple resource: exec
{ "/bin/ls
> $oracle_base/dba/bin/database_backup.ksh": logoutput => on_failure,
} and I
> don''t want it to log every time it''s successfully run: $
sudo tail -F
> /var/log/messages | grep puppetd Feb 17 16:36:11 test puppetd[26614]:
> (//my_module/Exec[/bin/ls /u01/
> app/oracle/dba/bin/database_backup.ksh]/returns) executed successfully but
> logoutput => on_failure doesn''t suppress the above message. Is
that
> parameter not available in my version of puppet, or am I perhaps
> misunderstanding its purpose? I''m guessing the latter since it
looks like
> it was introduced 3 years ago. In the meantime, I''m using this
ugly,
> redundant hack to do what I want: exec { "/bin/ls
> $oracle_base/dba/bin/database_backup.ksh": unless => "/bin/ls
> $oracle_base/dba/bin/database_backup.ksh", } Thanks!
>
>
> This is an old one, but I found it ALMOST useful.  I''d like to
take this
> one step further:
>
> I have a subscribe statement on a service that requires a file. And, now I
> have the error on the non-existent file, it is still trying to run the
> service. I have tried every possible way to bypass this, even with an exec
> (file not found). Since the exec statement itself is "successful"
(in not
> finding the file), it sill launches the service dependent on that file.
> Finally, I really don''t want errors to go to the client syslog...
that is
> the whole reason why I want to do the checking first.  To avoid errors in
> syslog when the service fails (for reason of a lacking patch... another
> issue: how to work with patching "if grep for patch; exists/not
exists;
> optional run"). I''ll keep looking but this lack of
conditional services is
> painful.
>
> file {''clientxml'':
> path => "/var/svc/manifest/network/sendmail-client.xml",
> ensure => true,
> backup => false,
> noop => true,
> loglevel => err,
> }
> service { "clientmail":
> name => "sendmail-client:default",
> manifest => "/var/svc/manifest/network/sendmail-client.xml",
> provider => smf,
> enable => true,
> hasrestart => true,
> require => File[''clientxml'']
> }
>
> Example:
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/KuU0kquGRWkJ.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
>  --
> Jo Rhett
> Net Consonance : net philanthropy to improve open source and internet
> projects.
>
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
>  To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.