If you're on the development branch, we identified a bug yesterday where
registered variables were not accessible via hostvars, which was a result
of the new "Fact Caching" additions.
This is now resolved as of yesterday.
Can you let me know what Ansible version you were using and whether this
resolves the problem?
On Tue, Sep 9, 2014 at 12:09 PM, Abubakr-Sadik Nii Nai Davis <
dwa2...@gmail.com> wrote:
> Wonderful! Thank you.
>
> ". The above obviously failed because register can not be
> associated with the host on which the module run."
>
> For the above, say I run a command in a task on every host in a play. I
> was thinking it wil be nice to register the output of the command such that
> the
> output of the command can be accessed as it run on the host in a later
> task.
>
> In other words when the output of the command is registered, it can be
> saved along with the host variables for the remote host on which the command
> run. This way at a later time we can always access the registered output
> using a syntax like '{{hostvars[hostA][result]}}'. For example
>
> - name: a task
> command: some cmd
> register: result
>
> - name: another task
> some_module:
> parm1: "{{hostvars[item][result]"
> parm2: "another param"
> with_items: groups['somehosts']
>
>
> On Tuesday, September 9, 2014 3:43:05 PM UTC, Michael DeHaan wrote:
>>
>> ". The above obviously failed because register can not be
>> associated with the host on which the module run."
>>
>> I'm not understanding this part entirely, but I'd recommend authorizing
>> keys for specific users and setting up sudo in general in that case.
>>
>> For our own ansible infrastructure, this involves a list of users and
>> their keyfiles, and then something like what's below.
>>
>> Checking your authorized keys into source control can be a good idea.
>>
>> You may also wish to template the authorized_key file using a list of
>> keys, rather than using the authorized_key module.
>>
>>
>> - name: create/managed authorized users user: name={{ item.username }}
>> groups=wheel append=yes with_items: authorized_users
>> - name: remove unauthorized user accounts user: name={{ item.username }}
>> state=absent with_items: unauthorized_users - name: add user keys
>> authorized_key: user={{ item.username }} key="{{ lookup('file',
>> item.key) }}" with_items: authorized_users
>>
>> On Tue, Sep 9, 2014 at 11:18 AM, Abubakr-Sadik Nii Nai Davis <
>> dwa...@gmail.com> wrote:
>>
>>> Hello gentle people,
>>>
>>> I think being able to register the output of commands/modules as host
>>> variables will be very useful.
>>> I got this idea writing a playbook to do;
>>>
>>> 1. create a root user key pair for a couple hosts
>>> 2. authorizing the root user public key of all hosts to connect to all
>>> other hosts.
>>>
>>> My approach is to use the 'user' module to create generate the key pair,
>>> then use the output
>>> of the user module for each host as the key parameter to the
>>> 'authorized_key' module.
>>>
>>> - name: generate SSH key pair for root user
>>> user:
>>> name: root
>>> generate_ssh_key: yes
>>> ssh_key_comment: "{{inventory_hostname}}"
>>> register: root_key
>>>
>>> - name: add authorized keys for root
>>> authorized_key:
>>> user: root
>>> key: "{{hostvars[item]['root_key']['ssh_public_key']}}"
>>> with_items: groups['allservers']
>>>
>>> Unless I am not using 'register' right. The above obviously failed
>>> because register can not be
>>> associated with the host on which the module run. This will definitely
>>> be a good thing to have.
>>>
>>> Any thoughts on my approach to generating and authorizing key pairs for
>>> all hosts?
>>> Is the ability to register module output like a host variable useful or
>>> can such be accomplished by
>>> other means?
>>>
>>> --
>>> 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.
>>> To post to this group, send email to ansible...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/ansible-project/b7889e8c-289a-42e5-b59b-
>>> bdb57616d752%40googlegroups.com
>>> <https://groups.google.com/d/msgid/ansible-project/b7889e8c-289a-42e5-b59b-bdb57616d752%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
> "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ansible-project+unsubscr...@googlegroups.com.
> To post to this group, send email to ansible-project@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/711cf219-5505-48a1-8e40-11fce09f0970%40googlegroups.com
> <https://groups.google.com/d/msgid/ansible-project/711cf219-5505-48a1-8e40-11fce09f0970%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
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgzF2GwWtihCLwq3EgghF4nhc7d11SLr2jwzs%3DvHNNWB%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
