8i | 9i | 10g | 11g | 12c | 13c | 18c | 19c | 21c | Misc | PL/SQL | SQL | RAC | WebLogic | Linux

Home » Articles » Misc » Here

Ansible : Ad Hoc Commands

This article demonstrates how to run ad hoc commands using Ansible. It is based on the Introduction to ad hoc commands documentation, but amended for the infrastructure described in the Ansible : First Steps article.

Related articles.


We install the "nginx" package on all the hosts in the "appservers" group using the "dnf" module. On a previous release we would use the "yum" module. In the arguments we include the name of the package and the state we want. For an install the state is "present" or "latest". Notice we have used the --become flag, which tells Ansible it needs to run the command as the root user. On these VMs our user can sudo without a password, but if it required a password we could include the --ask-become-pass flag, and we would be prompted for the password for the privilege escalation.

$ ansible appservers -m dnf -a "name=nginx state=present" --become

We update an existing package using the state "latest". As mentioned before, this will install the package if it is not already installed.

$ ansible appservers -m dnf -a "name=nginx state=latest" --become

We remove a package using the state "absent".

$ ansible appservers -m dnf -a "name=nginx state=absent" --become

We update all the packages on the server using a wildcard name and the state of "latest".

$ ansible appservers -m dnf -a "name=* state=latest" --become


We create a file on the local server.

$ touch /tmp/my-file.txt

We copy the file to all the hosts in the "appservers" group. This is like using SCP to copy the file.

$ ansible appservers -m copy -a "src=/tmp/my-file.txt dest=/tmp/my-file.txt"

We change the permissions and ownership on the remote files. Notice we use --become, to elevate the privileges.

$ ansible appservers -m file -a "dest=/tmp/my-file.txt mode=777 owner=root group=root" --become

We remove the file from the remote servers. Since the file is now owned by root, we need to use elevated privileges.

$ ansible appservers -m file -a "dest=/tmp/my-file.txt state=absent" --become

Users and Groups

All the actions require elevated privileges, so the commands include the --become flag.

Create some groups on all database hosts using the "group" module.

$ ansible databases -m group -a "name=oinstall gid=54321" --become
$ ansible databases -m group -a "name=dba gid=54322" --become
$ ansible databases -m group -a "name=oper gid=54323" --become

Create a user, who is part of those groups on all database hosts, using the "user" module. Using the password of "*" means it's a disabled account.

$ ansible databases -m user -a "name=oracle password='*' uid=54321 groups='oinstall,dba,oper'" --become

Remove the user.

$ ansible databases -m user -a "name=oracle state=absent" --become

Remove the groups.

$ ansible databases -m group -a "name=oinstall state=absent" --become
$ ansible databases -m group -a "name=dba state=absent" --become
$ ansible databases -m group -a "name=oper state=absent" --become


We install NGINX on all hosts in the "appservers" group using the "dnf" module.

$ ansible appservers -m dnf -a "name=nginx state=present" --become

We start, restart and stop NGINX on all hosts in the "appservers" group using the "service" module.

$ ansible appservers -m service -a "name=nginx state=started" --become
$ ansible appservers -m service -a "name=nginx state=restarted" --become
$ ansible appservers -m service -a "name=nginx state=stopped" --become

We remove NGINX from hosts in the "appservers" group.

$ ansible appservers -m dnf -a "name=nginx state=absent" --become

Reboot Servers

Servers can be rebooted using using the "reboot" command with the default command module. This will typically return an error, as the host is no longer available for SSH, but the servers are rebooted as requested.

$ ansible databases -a "/sbin/reboot" --become
database1.localdomain | FAILED | rc=-1 >>
Failed to connect to the host via ssh: ssh: connect to host database1.localdomain port 22: Connection refused

When these commands are run as part of a playbook they can be made to tolerate the outage.

What Next

There are lots of modules, and we can use the default command module to run any Linux command, so we are really not limited by what operations we can perform. There is an index of modules here.

In many cases we should avoid ad hoc commands and write playbooks to hold the configuration of servers, which can be checked into version control.

For more information see:

Hope this helps. Regards Tim...

Back to the Top.