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 On Mon, Apr 23, 2018 at 7:08 PM, jcbollinger <john.bollin...@stjude.org> wrote: > > > 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 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+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 > <https://groups.google.com/d/msgid/puppet-users/be01fcbf-f1cc-4b0c-b965-8c9250519c83%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAGVZ_ipZLts4zVk%3DDNowxsgQwDva8iYvi7VjfZGH%2BnvCuNF%2BAA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
