"I had to implement this approach after finding that ansible_env.HOME did what it should, but not what I needed."
Yep! The HOME environment variable is not always predictable in sudo scenarios. On Fri, Mar 21, 2014 at 7:52 PM, Grant BlahaErath <[email protected]>wrote: > Okay, my example kind of sucks and I'm not surprised that you noticed. > I had to implement this approach after finding that ansible_env.HOME did > what it should, but not what I needed. > > The playbooks run with "sudo: yes" because it was maddening to declare > sudo state for each task. That makes ansible_env.HOME evaluate to > "/root". This is how I solved that problem, but it became difficult to > reuse code that had {{ansible_home_result.stdout}} everywhere. > > The pattern is generally applicable for converting any dictionary pair > into a single value variable. > > I'm not sure how durable this solution will be since it depends on the > pre_task executing and updating the global dictionary before the role is > evaluated. I feel like its depending on an implied behavior instead of a > contract. A "setvar" solution like you proposed would be superior because > the behavior is explicit. > > > On 3/21/14, 4:20 PM, Michael DeHaan wrote: > > If you do "ansible hostname -m setup" in recent versions, you should see > that environment variables are provided, in which case you can pull $HOME > from there. > > This of course would only work for the active user. > > > http://docs.ansible.com/faq.html#how-do-i-access-shell-environment-variables > > > > > On Fri, Mar 21, 2014 at 6:46 PM, Grant BlahaErath <[email protected]>wrote: > >> Old thread, but it popped up in my goog when I was looking for answers. >> Since I worked out two different solutions, I wanted to share them. >> >> 1) >> >> I needed to get a user account home directory and share it with a role. >> Just using register meant I would have to use "variable.stdout" >> everywhere. Instead I used the pre_tasks section of the playbook to >> retrieve the value and then pulled the key/value out on the role's variable >> declaration. Here's the code I used. I hope this helps out others. >> >> pre_tasks: >> - name: Get ansible_user home directory >> shell: 'getent passwd "{{ansible_ssh_user}}" | cut -d: -f6' >> register: ansible_home_result >> roles: >> - { role: boxprep_debian, ansible_home: >> '{{ansible_home_result.stdout}}', when: ansible_os_family == 'Debian' } >> - { role: boxprep_redhat, ansible_home: >> '{{ansible_home_result.stdout}}', when: ansible_os_family == 'RedHat' } >> >> 2) >> >> Another approach that is far more elaborate but can solve anything is >> to create a python application that uses jinja2, and then process all your >> .yml files as if they were jinja2 templates. The python application can >> solve any kind of variable instantiation challenge while leaving the .yml >> reusable for other scenarios. Because jinja2 will only process the >> template variables it is told to, it will leave other {{variables}} for >> ansible to define. I use this approach to query an elaborate AWS cluster, >> and then preprocess the ansible scripts. >> >> >> >> On Thursday, March 14, 2013 6:19:43 PM UTC-7, Will Thames wrote: >>> >>> Let's say that I want to use a variable if it's passed to >>> ansible-playbook (via -e) and derive it otherwise >>> >>> I can use register to get the results of the derivation, but the actual >>> information I need is then typically in the stdout property. >>> >>> Is there a better way to do the following ? >>> >>> --- >>> ... >>> tasks: >>> - name: derive latest 2.5 release >>> local_action: shell ls /var/releases/v2.5-* | tail -1 >>> register: release >>> when_unset: $version >>> >>> - name: register version into release >>> local_action: command echo $version >>> register: release >>> when_set: $version >>> >>> >>> I would prefer the second task to be something like this (rather than >>> having to store the result of echoing the property!) >>> >>> - name: store release.stdout into version >>> local_action: variable name=version value=${release.stdout} >>> when_unset: $version >>> >>> And then just use $version after that. >>> >>> Hope that makes sense - basically I just want to be able to set >>> arbitrary variables during a playbook run rather than just before. >>> An alternative would be if register could be given an attribute that >>> says 'only store stdout' (or stderr or any other property) >>> >>> e.g. >>> register: property=stdout release >>> or >>> register: property=rc returncode >>> >>> Will >>> >> -- >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/ac43d9a7-b385-4312-a2ea-790e654a39bd%40googlegroups.com<https://groups.google.com/d/msgid/ansible-project/ac43d9a7-b385-4312-a2ea-790e654a39bd%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 a topic in the > Google Groups "Ansible Project" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/ansible-project/wqiclLkqmGU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/CAEVJ8QODgHkQJPNPMVCii73ChsF8RGaHaHajkiZDwdEC4vPN6w%40mail.gmail.com<https://groups.google.com/d/msgid/ansible-project/CAEVJ8QODgHkQJPNPMVCii73ChsF8RGaHaHajkiZDwdEC4vPN6w%40mail.gmail.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 > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/532CD0B2.3070203%40spryhive.com<https://groups.google.com/d/msgid/ansible-project/532CD0B2.3070203%40spryhive.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 "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAEVJ8QP7HLd7a0DeSaBtTfTMYAVP365keXuQb%2B8ign2-YLCFsA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
