On Wed, Dec 19, 2012 at 9:07 PM, Christopher Snapp <
sna...@gmail.com> wrote:
> Certainly my original use case was thinking of ssh connection types.
> I'm wondering if it is invalid to expect to have the username of the
> underlying account running the ansible process always available
> though. Typically in fireball it may be run as root and you wouldn't
> be able to derive the original account that sudo'd up to establish the
> 0mq session, but isn't that still valid in a sense? The same goes for
> local runs, isn't it still worth surfacing the results of `logname`?
> If that is a semi-sane request would it make sense just to call it
> ansible_logname if only because it maps to the *nix command that
> provides the value?
ansible_user then ... but I don't care for ansible_logname so much.
>
>
> On Mon, Dec 17, 2012 at 12:37 PM, Michael DeHaan
> <
michael...@gmail.com> wrote:
>> We could populate this on the server side like some of the other
>> variables (inventory_hostname, etc, is similar magic).
>>
>> Guessing it should be set as "$ansible_ssh_user" and only set for the
>> SSH connection types.
>>
>> --Michael
>>
>>
>> On Sun, Dec 16, 2012 at 3:15 PM, Christopher Snapp <
sna...@gmail.com> wrote:
>>> I'd like to know if it would be possible to surface the username of the
>>> original account that has logged into the system to perform the given tasks
>>> via a fact.
>>>
>>> This would be useful in writing the username to a log entry on the machine
>>> during playbook execution; or something more useful would be that it would
>>> allow the use of 'when_string' conditionals based on the user executing the
>>> playbook.
>>>
>>> I would think a "fact" named "ansible_remoteuser" would be sufficient.
>>>
>>> --
>>>
>>>
>>
>> --
>>
>>
>
>
>
> --
> Chris
>
> --
>
>