updated intro adhoc to use become
This commit is contained in:
parent
cb3493900c
commit
f26673904f
1 changed files with 14 additions and 16 deletions
|
@ -15,8 +15,7 @@ quick, but don't want to save for later.
|
||||||
|
|
||||||
This is a good place to start to understand the basics of what Ansible can do
|
This is a good place to start to understand the basics of what Ansible can do
|
||||||
prior to learning the playbooks language -- ad-hoc commands can also be used
|
prior to learning the playbooks language -- ad-hoc commands can also be used
|
||||||
to do quick things that you might not necessarily want to write a full playbook
|
to do quick things that you might not necessarily want to write a full playbook for.
|
||||||
for.
|
|
||||||
|
|
||||||
Generally speaking, the true power of Ansible lies in playbooks.
|
Generally speaking, the true power of Ansible lies in playbooks.
|
||||||
Why would you use ad-hoc tasks versus playbooks?
|
Why would you use ad-hoc tasks versus playbooks?
|
||||||
|
@ -60,23 +59,22 @@ behavior, pass in "-u username". If you want to run commands as a different use
|
||||||
|
|
||||||
$ ansible atlanta -a "/usr/bin/foo" -u username
|
$ ansible atlanta -a "/usr/bin/foo" -u username
|
||||||
|
|
||||||
Often you'll not want to just do things from your user account. If you want to run commands through sudo::
|
Often you'll not want to just do things from your user account. If you want to run commands through privilege escalation::
|
||||||
|
|
||||||
$ ansible atlanta -a "/usr/bin/foo" -u username --sudo [--ask-sudo-pass]
|
$ ansible atlanta -a "/usr/bin/foo" -u username --become [--ask-become-pass]
|
||||||
|
|
||||||
Use ``--ask-sudo-pass`` (``-K``) if you are not using passwordless
|
Use ``--ask-become-pass`` (``-K``) if you are not using a passwordless privilege escalation method (sudo/su/pfexec/doas/etc).
|
||||||
sudo. This will interactively prompt you for the password to use.
|
This will interactively prompt you for the password to use.
|
||||||
Use of passwordless sudo makes things easier to automate, but it's not
|
Use of a passwordless setup makes things easier to automate, but it's not required.
|
||||||
required.
|
|
||||||
|
|
||||||
It is also possible to sudo to a user other than root using
|
It is also possible to become a user other than root using
|
||||||
``--sudo-user`` (``-U``)::
|
``--become-user``::
|
||||||
|
|
||||||
$ ansible atlanta -a "/usr/bin/foo" -u username -U otheruser [--ask-sudo-pass]
|
$ ansible atlanta -a "/usr/bin/foo" -u username --become-user otheruser [--ask-become-pass]
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
Rarely, some users have security rules where they constrain their sudo environment to running specific command paths only.
|
Rarely, some users have security rules where they constrain their sudo/pbrun/doas environment to running specific command paths only.
|
||||||
This does not work with ansible's no-bootstrapping philosophy and hundreds of different modules.
|
This does not work with ansible's no-bootstrapping philosophy and hundreds of different modules.
|
||||||
If doing this, use Ansible from a special account that does not have this constraint.
|
If doing this, use Ansible from a special account that does not have this constraint.
|
||||||
One way of doing this without sharing access to unauthorized users would be gating Ansible with :doc:`tower`, which
|
One way of doing this without sharing access to unauthorized users would be gating Ansible with :doc:`tower`, which
|
||||||
|
|
Loading…
Reference in a new issue