[Puppet Users] Re: Resolving/ Expanding module puppet:/// URI in exec line

What happens if you run '/bin/tar zxf /usr/local/java/apache-maven-
3.0.3-bin.tar.gz' from the command line?

Additionally, you could change your manifest so that it executes 'pwd &&
/bin/tar zxf /usr/local/java/apache-maven-3.0.3-bin.tar.gz' so that you can
see what directory the contents of the file are being extracted to. My
suspicion is that you're either extracting to the wrong directory, or the
directory you're extracting to has incorrect permissions set on it or the
tar file has incorrect permissions set on it.

Regards,

Matt.

From the command line all works fine, only not from Puppet. BTW, I am
not the only one with this complaint online on your forums and
elsewhere, people complain that Tar works, but not UnTar. -S

I see no reason to think that this arises from a bug in Puppet. Almost
certainly it involves issues with how Puppet is being used. Here are some
of the aspects of the execution environment provided by Puppet Exec
resources that could be related to such issues:

    - Puppet provides a very sparse environment to commands it executes.
    Any other desired environment variables need to be specified in the
    'environment' property of the Exec resource or set within the command
    itself. Environment variables are not inherited from the environment
    provided to the agent, nor are the shell startup files read.
    - The working directory in which the command starts is not defined
    unless you provide the 'cwd' parameter to the Exec.
    - The 'command', 'unless', and 'onlyif' commands of every exec all have
    independent environments. You cannot use any of them to modify the
    environment variables or working directory provided to others.
    - If you want an executable search path, you must provide it via the
    'path' parameter or among the specified environment variables. Otherwise,
    you must give the fully-qualified pathname of the command(s) you want to
    run.
    - By default, the command is run with the credentials and security
    context of the Puppet process. Even though the agent normally runs as a
    privileged user, mandatory access controls (e.g. SELinux) may still deny it
    permission to perform some actions.
    - Privileged users on the local system may have less -- or even no --
    privilege on remote systems. This can be an issue, for example, with
    remote NFS filesystems mounted on the local machine.
    - By default the command is passed directly to the system to execute,
    bypassing the shell. On POSIX clients, setting provider => 'shell' will
    cause the command to be executed via '/bin/sh', instead, or you can always
    Exec the shell directly.
    - By default, success of an Exec is judged by whether the command exits
    with code 0. Additional or different successful exit codes can be
    specified via the 'returns' parameter.

All of those are intentional and logical, but some may nevertheless take
users by surprise, especially users more used to a script-centric model of
system administration. The Puppet model does not work the same way.


John