rm-on-error-${name} always returns 1 on CentOS

[pegli]

I have been seeing failures on the rm-on-error-${name} task on my CentOS 6.4 VMs that I'm provisioning with vagrant and puppet. I believe this is happening because rm -f does not modify the command's exit code, so rm -f foo && exit 1 doesn't short-circuit as expected and always hits the exit 1 clause. Removing the && exit 1 from the exec appears to fix the problem.

[brianp]

I receive the same error on Ubuntu 12.04.

[joschi]

Actually that is the intended behaviour of the module. The rm-on-error-${name} Exec resource is only being realized if the downloaded file's checksum doesn't match the recorded checksum. In this case the downloaded file should be removed and the Puppet run should fail which is ensured by the exit 1 at the end of the rm-on-error-${name} command.

I think having an explicit error is preferable to a silent error in this case. Unfortunately the fail function cannot be used in relation to a resource, otherwise we'd probably use that to make the intention clear.

[jtslear]

joschi,

I keep running into this problem as well, and I never found out why it was happening until I ran a debug:

Debug: Exec[download digest of archive funfile.zip](provider=posix): Executing 'curl    -L -s -o /opt/funfile.zip.md5 http://someserver.com/whatfile.zip.md5'
Debug: Executing 'curl    -L -s -o /opt/funfile.zip.md5 http://someserver.com/whatfile.zip.md5'
Notice: /Stage[main]/Owf/Archive::Download[funfile.zip]/Exec[download digest of archive funfile.zip]/returns: executed successfully
Debug: /Stage[main]/Owf/Archive::Download[funfile.zip]/Exec[download digest of archive funfile.zip]: The container Archive::Download[funfile.zip] will propagate my refresh event
Info: /Stage[main]/Owf/Archive::Download[funfile.zip]/Exec[download digest of archive funfile.zip]: Scheduling refresh of Exec[download archive funfile.zip and check sum]
Debug: Exec[download archive funfile.zip and check sum](provider=posix): Executing 'curl  -L -s   -o /opt/funfile.zip http://someserver.com/whatfile.zip'
Debug: Executing 'curl  -L -s   -o /opt/funfile.zip http://someserver.com/whatfile.zip'
Notice: /Stage[main]/Owf/Archive::Download[funfile.zip]/Exec[download archive funfile.zip and check sum]: Triggered 'refresh' from 1 events
Debug: /Stage[main]/Owf/Archive::Download[funfile.zip]/Exec[download archive funfile.zip and check sum]: The container Archive::Download[funfile.zip] will propagate my refresh event
Info: /Stage[main]/Owf/Archive::Download[funfile.zip]/Exec[download archive funfile.zip and check sum]: Scheduling refresh of Exec[rm-on-error-funfile.zip]
Debug: file_metadata supports formats: pson b64_zlib_yaml yaml raw
Debug: Exec[rm-on-error-funfile.zip](provider=posix): Executing check 'md5sum -c funfile.zip.md5'
Debug: Executing 'md5sum -c funfile.zip.md5'
Debug: /Stage[main]/Owf/Archive::Download[funfile.zip]/Exec[rm-on-error-funfile.zip]/unless: md5sum: whatfile.zip: No such file or directory
Debug: /Stage[main]/Owf/Archive::Download[funfile.zip]/Exec[rm-on-error-funfile.zip]/unless: whatfile.zip: FAILED open or read
Debug: /Stage[main]/Owf/Archive::Download[funfile.zip]/Exec[rm-on-error-funfile.zip]/unless: md5sum: WARNING: 1 of 1 listed file could not be read
Debug: Exec[rm-on-error-funfile.zip](provider=posix): Executing 'rm -f /opt/funfile.zip /opt/funfile.zip.md5 && exit 1'
Debug: Executing 'rm -f /opt/funfile.zip /opt/funfile.zip.md5 && exit 1'
Error: /Stage[main]/Owf/Archive::Download[funfile.zip]/Exec[rm-on-error-funfile.zip]: Failed to call refresh: rm -f /opt/funfile.zip /opt/funfile.zip.md5 && exit 1 returned 1 instead ofone of [0]
Error: /Stage[main]/Owf/Archive::Download[funfile.zip]/Exec[rm-on-error-funfile.zip]: rm -f /opt/funfile.zip /opt/funfile.zip.md5 && exit 1 returned 1 instead of one of [0]

Looking carefully, it's downloading whatfile.zip, and due to my configured resource, it's naming the file funfile.zip on disk. But the function checking the checksum, does not recognize that and ends up failing. Of course this does two undesirable things,

1. it fails with an error that doesn't help us know what is going on
2. it removes a valid file

I bet this is the root cause of the reason why the fellas above put this issue in. I see that there is proper failing for when a checksum is indeed incorrect.

Here's what my resource declaration looks like:

archive::download { 'funfile.zip'
    ensure         => present,
    url            => 'http://someserver.com/whatfile.zip',
    checksum       => true,
    src_target     => '/opt',
  }

[joschi]

Basically it's md5sum failing because the file containing the file checksums contains the original filename ("whatfile.zip") and not the custom filename from the Puppet resource title ("funfile.zip").

IMHO there is no non-hacky way to prevent this and I don't want to start patching checksum files.