Inventory and connectivity

Choose the machine before the operation

An inventory gives Ansible a set of host aliases, groups, and connection settings. The alias is the name you target in automation; the connection address is where the transport connects. A group such as study lets a play select a related set of hosts. A correct task aimed at the wrong group is still the wrong change.

Keep using the Ansible installation from the first lesson. This exercise connects from your Mac to the sk-foundations OrbStack Linux machine created in System engineer foundations. If it is not available, create that prerequisite machine first or use your own disposable Linux VM with known SSH details; do not substitute an unfamiliar server.

Establish SSH before Ansible

From the Mac, run:

ssh sk-foundations@orb id

Expected: the identity of the regular user in that learning machine. OrbStack supplies this SSH integration; the transport is distinct from an OpenSSH daemon you might configure inside a guest. A full VM instead needs its actual reachable address, login account, key, and SSH port. Host-key verification helps detect a different host answering at an expected address; disabling it globally is not a normal connectivity fix.

Save inventory.ini in ansible-practice:

[study]
study-vm ansible_host=orb ansible_user=sk-foundations

study-vm is the alias, orb the SSH destination, and sk-foundations the OrbStack machine selector used as the SSH user. These values rely on that specific integration; a normal VM uses its real login account instead.

Inspect the selection, then test module execution

ansible-inventory -i inventory.ini --graph
ansible study -i inventory.ini --list-hosts
ansible study -i inventory.ini -m ansible.builtin.ping

The graph should show study-vm in study, and the host listing should contain only the intended target. The last command is an ad hoc command: a single module invocation without a playbook. Expected successful module output includes "ping": "pong". Ansible's ping is not ICMP; it checks that Ansible can connect and run its Python module.

Read errors by stage. A hostname problem occurs before SSH authentication. A key or account problem prevents login. A Python compatibility problem may occur after SSH succeeds. Permission errors can appear only when a module touches a protected path. Solve the failing stage instead of retrying with root access.

Add scope and variables carefully

A play's hosts pattern selects from inventory. --limit study-vm narrows that selection; it does not add a host absent from inventory. Use --list-hosts before applying a new play or a changed inventory. Group variables can hold common non-secret settings, while host variables describe exceptions. Avoid defining the same setting in several places before you understand precedence.

Dynamic inventory queries a system such as a cloud account to discover hosts. Its filters and credentials are part of target selection, not a guarantee of safety. The static two-line inventory here makes that selection easy to inspect.

Practice and reasoning

Try ansible missing-group -i inventory.ini --list-hosts. An empty match means no intended host was selected; it is not evidence that a task succeeded. Restore the study target and explain the difference between alias, destination, and execution account.

Would a successful ssh ... id prove a package-install task will succeed? No: module interpreter support and permission to manage packages are separate requirements. The upcoming marker play uses the regular user's home and needs no become privilege escalation. Keep this inventory for all subsequent Ansible lessons.

References: inventory↗, ad hoc commands↗, ping module↗, and OrbStack SSH↗.

Additional primary references: Ansible installation requirements↗.