On Sunday, April 22, 2018 at 2:26:11 AM UTC-5, Justin tim wrote:
>
> Hi,
>
> I've been trying to setup openstack keystone for my DEV environment using
> Puppet. Everything works fine, except the 'exec' resource.
>
> I have tried the below things, but not getting the desired results
>
> 1. '*/bin/bash -c 'source /root/openrc.sh*' in the command attribute, but
> nothing happens.
> 2. tried using the '*provider*' attribute in the exec resource.
> 3. tried using '*environment*' attribute.
>
> It's only when i manually run '*source /root/openrc.sh*', the variables
> are set.
>
> Below are the contents of the actual puppet manifest, and the openrc.sh
> file which is to be run on the node.
>
> # cat testexec.pp
>
> exec { 'admin':
> command => '/bin/sh /root/openrc.sh'
>
> }
>
> Contents of openrc.sh
>
> #!/bin/sh
> export OS_TOKEN="fbed3beb36960f2b3e1b"
> export OS_URL="http://openstack:35357/v3";
> export OS_IDENTITY_API_VERSION=3
>
>
>
> Is there a way we achieve this?
>
A way to achieve *what*, exactly? Your bash source is executable (if even
it is) only in a strict sense. *It has no effect that will persist beyond
the lifetime of the shell process in which it runs.* I have every reason to
think that Puppet is doing exactly what it should with this -- it's your
expectations that are wrong.
Note well that there is a fundamental difference between (a) running a file
of bash commands *as* a script and (b) using the '.' command or its alias '
source' to run the commands within. The former approach launches a new
shell process in which to run the commands, whereas the latter runs them in
the current shell process (and only works in a shell, because '.' and '
source' are internal shell commands, not OS-level commands).
What you have is a file of environment configuration commands. It is not
useful to run it as a script, so we are now back to my opening question:
what is it, exactly, that you are trying to achieve?
If you want to set up the target machine so that users receive those
settings in their environments automatically, then you must arrange for it
to be sourced by their shells. There are several ways to accomplish that,
but one would be to get /etc/profile to source it. On RedHat-family
systems, that can be achieved by dropping the script into /etc/profile.d/,
and making sure that it is readable by all users and that its name retains
the ".sh" suffix. Some other systems might require you to edit /etc/profile,
instead.
On the other hand, if you are trying to configure the environment for other
Exec resources that are applied in the same Puppet catalog run then you
need to do that inside the scope of those other Execs. Each Exec runs
commands in its own child process; these do not share environments. That
might look like this:
exec { 'example':
command => "/bin/bash -c '. /root/openrc.sh; /some/other/command'"
}
Alternatively, you could achieve the same thing with:
exec { 'example':
command => ". /root/openrc.sh; /some/other/command",
provider => 'shell'
}
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/be01fcbf-f1cc-4b0c-b965-8c9250519c83%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
