RHCE: Managed Node Preparation and Ad Hoc Commands

What a managed node needs

A reachable SSH service, a user account with the control node's public key in ~/.ssh/authorized_keys, sudo rights if tasks need root (NOPASSWD for fully non-interactive runs, otherwise supply -K), and a Python interpreter for the modules being used. Nothing else is installed on the target.

Inventory

INI groups are declared with [web]; nested groups use [prod:children]; ranges expand as web[01:05].example.com. Host variables may be inline (web1 ansible_host=10.0.0.5 ansible_user=deploy) or placed in group_vars/ and host_vars/ directories next to the inventory. Verify what Ansible parsed with ansible-inventory --graph or --list.

Ad hoc syntax

ansible <pattern> -m <module> -a "<args>". Useful flags: -i inventory, -l limit, -u remote user, -b become, -K ask become password, -k ask SSH password, -C check mode, -f forks.

Examples:

• ansible all -m ping - connectivity plus Python check
• ansible web -m dnf -a "name=httpd state=present" -b
• ansible all -m setup -a "filter=ansible_distribution*"
• ansible db -m command -a "systemctl is-active postgresql"

Traps

ping is not ICMP; it is a module that proves SSH and Python work, so a failure usually means missing Python, a bad key, or a sudo problem (look at module_stderr). Ad hoc runs do not gather facts automatically - that requires the setup module. Arguments passed with -a are a single string, so shell quoting errors change meaning.

Rule of thumb

Prove access with ansible all -m ping before every ad hoc session or playbook run; it distinguishes connection failures from task failures.