Unable to run source using 'exec' resource

[Justin tim]

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?

Thanks in Advance.
J

[Christopher Wood]

I'm not really sure what's going on (bit rusty in bash), but the following things to check on come to mind.

/bin/sh may not be linked to bash, and "export THING=whatever" is a bashism. It could be that "THING=whatever; export THING" will work better for you. However you're likely using something Linux so this doesn't count.

Execs are going to run in a subshell and be separated at the process level from other execs. If you check the source builtin in the bash manual it says "in the current shell environment". You running source at the command line and then running puppet means that puppet will pick up environment settings from your current environment, whereas "bash -c" and the exec make the settings exist in a subshell. They will be contained to a single child PID and vanish when the exec is over.

The documentation suggests that openrc.sh is sourced, so if you need to set up environment variables for the rest of the keystone setup a single exec definitely won't work.

https://docs.openstack.org/liberty/install-guide-ubuntu/keystone-openrc.html#using-the-scripts

In your place (with 100% less openstack experience than you) I would be provisioning openrc.sh as a file resource on the system, with 0600 permissions, and then ensuring that the keystone clients (handled elsewhere in puppet?) source that file, with their resources depending on the openrc.sh file resource so things were in the right order.

> --
> 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 [1]puppet-users...@googlegroups.com.
> To view this discussion on the web visit
> [2]https://groups.google.com/d/msgid/puppet-users/05c9d71f-c02d-4d5a-8607-70ecbf68dafe%40googlegroups.com.
> For more options, visit [3]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:puppet-users...@googlegroups.com
> 2. https://groups.google.com/d/msgid/puppet-users/05c9d71f-c02d-4d5a-8607-70ecbf68dafe%40googlegroups.com?utm_medium=email&utm_source=footer
> 3. https://groups.google.com/d/optout

[jcbollinger]

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

[Justin Timberlake]

Hello John / Chris,

First of all, I’d like to thank both of you for taking out time and providing your valuable inputs on this topic. I am extremely sorry if my query was not clear enough.

I am trying to set up a keystone (Identity server) for openstack.

content of openrc.sh file:
-------------------------------------
# cat /root/openrc.sh

#!/bin/sh
export OS_TOKEN="fbed3beb36960f2b3e1b"
export OS_URL="http://openstack:35357/v3"
export OS_IDENTITY_API_VERSION=3

My manifest with exec resource :
------------------------------------------------

exec { 'admin':
    command => '/bin/sh /root/openrc.sh'
   
  }

One of the steps required to set up the Keystone server is to source a file that has the admin token, Manually this is done using

# source /root/openrc.sh <-  And this seems to work perfectly fine.

However, when i try to source /root/openrc.sh file on the client i.e. the keystone server, using Puppet's exec resource (highlighted above), it doesnt work. I am not getting an error, but its not giving the desired result either.

I have tried the below, but still doesn't seem to work

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.

The whole of my Keystone server can get built in few seconds using Puppet, if i can just get through this issue. What i am currently doing is execute all the Puppet classes required to run before the source command, then manually run the source command, (shown below), then run puppet again to execute the rest of the classes to complete the whole of the Keystone setup. It feels so bad, when i have to intervene for just a small step while the rest of the complex tasks have been taken care of.

root@openstack:~# source /root/openrc.sh
root@openstack:~#
root@openstack:~#
root@openstack:~# openstack service list
+----------------------------------+----------+----------+
| ID                               | Name     | Type     |
+----------------------------------+----------+----------+
| d94e266986fd46b582b832ca48ae1974 | keystone | identity |
+----------------------------------+----------+----------+

So my question is how can i run -> source /root/openrc.sh, using Puppet?

Thanks in Advance,

J

--
You received this message because you are subscribed to a topic in the Google Groups "Puppet Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/VdQaKRtHgtM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to puppet-users+unsubscribe@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.

[John Gelnaw]

jcbollinger has it right.  You're setting environment variables, and then exiting the environment.

Here's what is effectively happening:

# bash

# source ./opensh.rc

echo $OS_TOKEN

fbed3beb36960f2b3e1b

# exit

# echo $OS_TOKEN

#

When you tell Puppet to do an exec, it spawns a new instance of the shell (Probably bash), sets the path based on the path attribute, sets any variables in "environment", and executes your command.

Then the shell exits.

Your environment variables set via your script only exist within the scope of that (ephemeral) shell, so as soon as it exits, the variables go bye-bye as well.

Instead, consider this off-the-cuff example (Disclaimer:  I know nutzing about openstack!):

exec { 'openstack server create':
  cwd => '/root',
  path => '/bin;/sbin;/usr/bin;/usr/sbin',
  environment => [ 'OS_TOKEN="fbed3beb36960f2b3e1b"',
                   'OS_URL="http://openstack:35357/v3"',
                   'OS_IDENTITY_API_VERSION=3'
  ]
}

Which should pass the environment variables you want to the process you want to actually exec.

[jcbollinger]

Dear Justin,

On Monday, April 23, 2018 at 9:49:34 AM UTC-5, Justin tim wrote:

Hello John / Chris,

First of all, I’d like to thank both of you for taking out time and providing your valuable inputs on this topic. I am extremely sorry if my query was not clear enough.

To whatever extent that any apology was needed, yours is accepted.  Much more than an apology, however, I would have appreciated you taking the time to read and understand the answers that we wrote, which both manage to speak to your (clarified) issue despite any uncertainty about the original question.  Mine in particular even provides demonstration Puppet code appropriate for you to directly adapt to your use.  I see that you now have an additional answer saying the same thing and presenting a viable variation on the same approach.

Your clarification is welcome, and if you are having trouble understanding the answers then by all means do feel welcome to ask followup questions. If you want to continue receiving responses, however, then I recommend demonstrating that you are actually paying attention to what we say.

John

[Justin Timberlake]

Hi John,

I get it now. I haven’t got a chance to work on my DEV openstack of late, but i am sure, i will be able to achieve what i want using the examples given above.

Besides the information that one can find on the net, it is always helpful to have someone who has had experience with similar issues :)

Thanks to all,

Best Regards,

J

--
You received this message because you are subscribed to a topic in the Google Groups "Puppet Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/VdQaKRtHgtM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to puppet-users+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/ffb4bb8e-243b-45fc-9c17-a9685798441f%40googlegroups.com.