We want to install the chrony daemon on the server to keep the time in sync. Instead of running the command dnf install -y chrony on each of the servers, we’ll use ansible’s dnf module to do the same […].
$ ansible multi -b -m dnf -a “name=chrony state=present”
It seems clear from the example here that the dnfmodule is accessed via the Ansiblecommand line interface by using the moption for the ansible command, as it is this option that takes dnf as an argument. The a option then takes as argument, a string with the arguments for that module argued in the m option (for background, see 20250322141340-Getting_Server_Facts_in_Ansible).
As for the b option for the ansible command (Geerling 2023, 28):
From bib. source
The -b option (alias for --become) tells Ansible to run the command with become (basically, run commands with ‘sudo’). […] but if you’re running commands against a server where your user account requires a password for privilege escalation, you should also pass in -K (alias for --ask-become-pass), so you can enter your password when Ansible needs it.
In other words, b option allows you to run the remote commands as the superuser (or administrator / supervisor) on the target server.
Another example of using an Ansible server module through the command line would be the following, wherein the installed service from the previous example is then enabled (i.e., started and set to autorun on boot for the server) (Ibid):
For bib. source
We could use two separate commands, systemcl start chronyd and systemctl enable chronyd, but we’ll use Ansible’s server module instead.
$ ansible multi -b -m service -a “name=chronyd state=started enabled=yes”