Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

access to original username via variable

170 views
Skip to first unread message

Christopher Snapp

unread,
Dec 16, 2012, 3:15:40 PM12/16/12
to ansible...@googlegroups.com
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.

Michael DeHaan

unread,
Dec 17, 2012, 12:37:57 PM12/17/12
to ansible...@googlegroups.com
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
> --
>
>

Christopher Snapp

unread,
Dec 19, 2012, 9:07:03 PM12/19/12
to ansible...@googlegroups.com
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?
> --
>
>



--
Chris

Michael DeHaan

unread,
Dec 20, 2012, 8:01:11 AM12/20/12
to ansible...@googlegroups.com
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
>
> --
>
>

Christopher Snapp

unread,
Dec 20, 2012, 8:29:40 AM12/20/12
to ansible...@googlegroups.com
ansible_user sounds good...I'd agree ansible_logname is pretty lame,
it was just an idea since someone thought it was a good name for a
command.
> --
>
>



--
Chris
Reply all
Reply to author
Forward
0 new messages