Yep, it's per task. -- Michael
On Nov 23, 2013, at 3:30 PM, Steven Haddox <ste...@haddox.us> wrote: Completely understandable. I'm pretty sure I was expecting environment to set variables that would also be usable in the template / action lines but they only set variables for use within the shell of the command I think is what I've gathered between the documents & testing. Thanks! On Saturday, November 23, 2013 11:41:14 AM UTC-5, Michael DeHaan wrote: > > Sorry, I don't have time to debug playbooks. > > Happy to answer specific questions. > > > > > On Wed, Nov 20, 2013 at 10:23 AM, Steven Haddox <ste...@haddox.us<javascript:> > > wrote: > >> Michael, >> >> Thanks. I have no doubt that environment works properly, I think I'm just >> have something setup slightly wrong as newb (sorry). >> >> Here's my current debug output (-v and -vvv): >> https://gist.github.com/stevenhaddox/26c8e0bd093887fab2b0<https://www.google.com/url?q=https%3A%2F%2Fgist.github.com%2Fstevenhaddox%2F26c8e0bd093887fab2b0&sa=D&sntz=1&usg=AFQjCNHlGBRIRpSZRYPcif06ks7aWZEPDQ> >> >> Here's my current code setup: >> https://github.com/stevenhaddox/ansible_rails_enterprise/tree/gnu_stow<https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fstevenhaddox%2Fansible_rails_enterprise%2Ftree%2Fgnu_stow&sa=D&sntz=1&usg=AFQjCNGrdtj65sTOSQIA0MwMektuKSbiUg> >> >> Specifically I'm trying to set my environment variable(s) in the >> `provisioning/group_vars/all.yml` file: >> >> https://github.com/stevenhaddox/ansible_rails_enterprise/blob/gnu_stow/provisioning/group_vars/all.yml<https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fstevenhaddox%2Fansible_rails_enterprise%2Fblob%2Fgnu_stow%2Fprovisioning%2Fgroup_vars%2Fall.yml&sa=D&sntz=1&usg=AFQjCNHBOrNTqiMjYII3HDgLpXrtYsH-iw> >> >> And I'm trying to load the environment in the task `Copy Stow src file to >> remote node` in my common role tasks: >> >> https://github.com/stevenhaddox/ansible_rails_enterprise/blob/gnu_stow/provisioning/roles/common/tasks/main.yml<https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fstevenhaddox%2Fansible_rails_enterprise%2Fblob%2Fgnu_stow%2Fprovisioning%2Froles%2Fcommon%2Ftasks%2Fmain.yml&sa=D&sntz=1&usg=AFQjCNG1pP4utcpF1gvYXA0YFWp6nYyZ3Q> >> >> Oh, Ansible on the Mac I'm running this on is currently at 1.3.4. >> >> Hope this helps, >> >> Steven >> >> >> >> On Tuesday, November 19, 2013 11:56:23 PM UTC-5, Michael DeHaan wrote: >> >>> Environment works for sure, show us what you have now and what ansible >>> version you are using? >>> >>> -- Michael >>> >>> On Nov 19, 2013, at 11:14 PM, Steven Haddox <ste...@haddox.us> wrote: >>> >>> Rodger that. Now if I could just get the environment module to work as >>> expected... I'm adding an environment variable to the global_vars/all.yml >>> file where I have other variables set but it's not picking it up when I add >>> `environment: <environment_var_name>` for some reason. I'll keep debugging >>> this and once it's done I should be pretty much good to go through most of >>> my playbook tasks (hopefully). >>> >>> Thanks again, >>> >>> Steven >>> >>> On Tuesday, November 19, 2013 11:00:20 PM UTC-5, Michael DeHaan wrote: >>>> >>>> nope, environment keyword is your friend. >>>> >>>> This is a configuration management and deployment system, it's designed >>>> to not trust the user's configuration on purpose. >>>> >>>> >>>> >>>> >>>> On Tue, Nov 19, 2013 at 9:36 AM, Steven Haddox <ste...@haddox.us>wrote: >>>> >>>>> PS - Is it possible that I could somehow get Ansible to load / source >>>>> the {{HOME.stdout}}/.bashrc as part of an environment in Ansible and then >>>>> just pass that environment in? I'm not familiar at all with the >>>>> environment >>>>> module. It looks like it's mostly for setting variables so I'm wondering >>>>> if >>>>> maybe I'd at least be best off using an environment variable to store the >>>>> command to source .bashrc as a way to at least ensure it could be easily >>>>> modified without changing every subsequent task later, but ideally it'd be >>>>> awesome to get the shell to load the ~/.bashrc as the first step for >>>>> anytime a task uses that environment, but I'm not sure if that's >>>>> possible... >>>>> >>>>> >>>>> On Tuesday, November 19, 2013 9:28:18 AM UTC-5, Steven Haddox wrote: >>>>>> >>>>>> Nick, >>>>>> >>>>>> Thanks very much for your reply and thoughts. This has helped >>>>>> tremendously (and will help as I write the rest of these playbooks). >>>>>> Alright... here goes: >>>>>> >>>>>> > Source is normally a shell-builtin, not an actual executable. As >>>>>> > you're calling the command module rather than the shell module, it >>>>>> > doesn't run an actual shell and so it can't find an executable >>>>>> called >>>>>> > 'source'. That likely explains the error you are seeing, and using >>>>>> > 'shell' rather than 'command' will likely solve that. >>>>>> >>>>>> Thanks for this. The thought hadn't even occurred to me that command >>>>>> vs shell would've been a way to fix it or that command wouldn't recognize >>>>>> source. As Gru says, "liiiight buuulb!" I changed the module to shell >>>>>> quickly and it looks like that definitely got it working instantly for >>>>>> that >>>>>> particular command. >>>>>> >>>>>> > That said, 1) I don't believe Ansible runs two consecutive shell >>>>>> tasks >>>>>> > in the same shell anyway, and 2) it uses /bin/sh rather than the >>>>>> > user's default shell, making the point moot. >>>>>> >>>>>> As to point 1 I actually had this exact thought as I was laying my >>>>>> head down on the pillow last night and realized I may be trying to solve >>>>>> a >>>>>> task that doesn't even need to exist as all subsequent commands would >>>>>> probably already have sourced the newly updated ~/.bashrc when ansible >>>>>> connects to issue the next command. Do we know for a fact that this is >>>>>> how >>>>>> it occurs? What about in "fireball" mode? Does that still reconnect for >>>>>> each subsequent task? Trying to figure out if my playbook will be >>>>>> properly >>>>>> usable in all modes that Ansible could be run in. >>>>>> >>>>>> As to point 2 this could give extra emphasis as to your point you >>>>>> made later. I was quasi-expecting Ansible to use the non-login shell >>>>>> (e.g. >>>>>> the user that's sudoed into would have their ~/.bashrc loaded before >>>>>> executing commands) and that's why I thought to put these variables here >>>>>> for Ansible (primarily just due to Linux/Unix defaults). I'll get into >>>>>> why >>>>>> they go here in my particular situation next. >>>>>> >>>>>> > The above issues of making it work aside, relying on the user's >>>>>> bashrc >>>>>> > sounds very brittle. What if he/she decides to start using another >>>>>> > shell in the future (such as zsh for example)? >>>>>> >>>>>> Okay, so to put this all in perspective... I'm using Ansible to >>>>>> automatically provision / setup servers that have very restrictive access >>>>>> controls. Once I login as a non-privileged user with my SSH key I'm then >>>>>> able to sudo into only two other users. One is meant to install >>>>>> libraries / >>>>>> tools from source, the other to deploy the application. This is a pretty >>>>>> common Enterprise / restrictive setup in my experience. As a result I >>>>>> have >>>>>> learned to very strongly love GNU Stow which allows me to basically have >>>>>> my >>>>>> own /opt dir in my home folder and handles symlinking active tools / >>>>>> packages / libraries and all their differing subfolders, etc. into a >>>>>> target >>>>>> directory (one folder above the path where you stow things by default). >>>>>> Rather than having to ensure that everyone remembers the stow path >>>>>> properly >>>>>> (there's a few of us and we're all human after all) I've taken to >>>>>> setting a >>>>>> $STOW environment variable that's loaded in the .bashrc so that we can >>>>>> ensure that we always use the same directory. We also want to use all the >>>>>> programs we've stowed away like pack rats so I've gotten used to >>>>>> prepending >>>>>> PATH with $STOW/../bin so that we have access to git, tmux, vim, python, >>>>>> ruby, node, bzip2, etc., etc. all compiled from source. This way we don't >>>>>> have to prepend / remember the stow directory and we don't have to invoke >>>>>> git with: $ stow_path/../bin/git, we can just simply call $ git and get >>>>>> the >>>>>> proper version. >>>>>> >>>>>> Now... as to why .bashrc. I touched on this lightly above, but >>>>>> basically I need to have somewhere for these global environment variables >>>>>> to be set, and to my knowledge the best place for that in Linux / Unix >>>>>> has >>>>>> always been the .bashrc file. Granted, if a user somehow installs (from >>>>>> source in my situation) zshell or another alternative then they don't get >>>>>> these variables, but keep in mind I'm 9/10 times using this to provision >>>>>> staging and production boxes where users shouldn't be customizing things >>>>>> to >>>>>> their desired intent. My goal is to use Ansible to get rid of those >>>>>> customizations on those boxes and have a reliably consistent >>>>>> environment. I >>>>>> don't think I've ever used a production box with something besides the >>>>>> default bash shell running and so .bashrc has always been the best >>>>>> solution. I would love to level up and be taught how to do this properly >>>>>> / >>>>>> differently if that isn't correct (just so I don't come off defensive, >>>>>> trying to explain my thought process, not seem stubborn as I'm 100% open >>>>>> to >>>>>> change if I'm doing it wrong). >>>>>> >>>>>> > Is there a specific reason you can't just set any necessary >>>>>> environment >>>>>> > variables in your playbook, and/or call programs by their full path >>>>>> instead >>>>>> > of relying on $PATH? >>>>>> >>>>>> So... the problem with putting these variables into my playbook >>>>>> instead of directly into $PATH is that we do our deployments using >>>>>> Capistrano (I've used it for 5 years and couldn't be happier and have no >>>>>> desire to use a provisioning tool for something as simple as >>>>>> deployments). >>>>>> In turn this means that any environment variables set in Ansible >>>>>> playbooks >>>>>> won't be accessible to my deployment environments. It also means that I'd >>>>>> either have to rewrite everything to deploy with Ansible (which isn't the >>>>>> community best practice in Ruby world, even to use Chef or Puppet >>>>>> wouldn't >>>>>> be ideal for the vast majority of teams) or it means I'll have to >>>>>> duplicate >>>>>> variables in my playbook environment variables and then again somewhere >>>>>> in >>>>>> my tasks to setup those variables for the user when they login. I was >>>>>> expecting Ansible to load a user's .bashrc for commands given that I'm >>>>>> logging in specifically to that user's account with the sudo_user & sudo >>>>>> variables in my playbook; however, I can see why Ansible wouldn't do that >>>>>> (especially if a user has a different shell potentially rather than bash >>>>>> which Ansible seems to have an expectation for as well). >>>>>> >>>>>> So that leads to yet another question... Is there a best practice to >>>>>> be able to get Ansible tasks to load my .bashrc if I'm sure it'll be >>>>>> there >>>>>> before running the shell module or am I likely to have to always do the >>>>>> following? >>>>>> >>>>>> shell: source {{HOME.stdout}}/.bashrc; <cmd> >>>>>> >>>>>> The next question is, is there an alternative approach to storing >>>>>> environment variables / modified $PATH without having to use the .bashrc >>>>>> but that would still be accessible for a user actually logged into the >>>>>> box >>>>>> from a remote terminal? I've been playing with server setup / maintenance >>>>>> as a side-duty of all my jobs for about a decade and haven't come across >>>>>> any, but it's also not my full-time $dayjob and I'm not an expert by any >>>>>> means. I'd love to hear suggestions or tips from others as to a better >>>>>> approach than putting $STOW and $PATH modifications / exports in the >>>>>> .bashrc of the sysadmin user. >>>>>> >>>>>> Thanks so much for all of your help and time, >>>>>> >>>>>> Steven >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tuesday, November 19, 2013 4:33:15 AM UTC-5, Nick Groenen wrote: >>>>>>> >>>>>>> Source is normally a shell-builtin, not an actual executable. As >>>>>>> you're calling the command module rather than the shell module, it >>>>>>> doesn't run an actual shell and so it can't find an executable >>>>>>> called >>>>>>> 'source'. That likely explains the error you are seeing, and using >>>>>>> 'shell' rather than 'command' will likely solve that. >>>>>>> >>>>>>> That said, 1) I don't believe Ansible runs two consecutive shell >>>>>>> tasks >>>>>>> in the same shell anyway, and 2) it uses /bin/sh rather than the >>>>>>> user's default shell, making the point moot. >>>>>>> >>>>>>> > The goal of this is to export variables in ~/.bashrc for the user >>>>>>> who will be using those variables a lot later in the playbook(s) for >>>>>>> this >>>>>>> setup. >>>>>>> >>>>>>> The above issues of making it work aside, relying on the user's >>>>>>> bashrc >>>>>>> sounds very brittle. What if he/she decides to start using another >>>>>>> shell in the future (such as zsh for example)? Is there a specific >>>>>>> reason you can't just set any necessary environment variables in >>>>>>> your >>>>>>> playbook, and/or call programs by their full path instead of relying >>>>>>> on $PATH? >>>>>>> >>>>>>> -- >>>>>>> Nick Groenen | zoni | @NickGroenen >>>>>>> https://zoni.nl<https://www.google.com/url?q=https%3A%2F%2Fzoni.nl&sa=D&sntz=1&usg=AFQjCNEO4ATVjBui01JJlQWvH4AoKrh7yA>| >>>>>>> GnuPG/GPG key ID: 0xAB5382F6 >>>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Ansible Project" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to ansible-proje...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>> >>>> >>>> >>>> >>>> -- >>>> Michael DeHaan <mic...@ansibleworks.com> >>>> CTO, AnsibleWorks, Inc. >>>> http://www.ansibleworks.com/<http://www.google.com/url?q=http%3A%2F%2Fwww.ansibleworks.com%2F&sa=D&sntz=1&usg=AFQjCNEn7XMcb-1wMxliSyOhlnyBBlDaQg> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Ansible Project" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to ansible-proje...@googlegroups.com. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Ansible Project" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to ansible-proje...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > Michael DeHaan <mic...@ansibleworks.com <javascript:>> > CTO, AnsibleWorks, Inc. > http://www.ansibleworks.com/<http://www.google.com/url?q=http%3A%2F%2Fwww.ansibleworks.com%2F&sa=D&sntz=1&usg=AFQjCNEn7XMcb-1wMxliSyOhlnyBBlDaQg> > > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
