# Assignment

The Nautilus DevOps team is testing Ansible playbooks on various servers within their stack. They've placed some playbooks under /home/thor/playbook/ directory on the jump host and now intend to test them on app server 3 in Stratos DC. However, an inventory file needs creation for Ansible to connect to the respective app. Here are the requirements:


a. Create an ini type Ansible inventory file /home/thor/playbook/inventory on jump host.


b. Include App Server 3 in this inventory along with necessary variables for proper functionality.


c. Ensure the inventory hostname corresponds to the server name as per the wiki, for example stapp01 for app server 1 in Stratos DC.


Note: Validation will execute the playbook using the command ansible-playbook -i inventory playbook.yml. Ensure the playbook functions properly without any extra arguments.

# Solution

# Ansible Inventory — App Server 3 (`stapp03`)

Create an INI-format inventory at `/home/thor/playbook/inventory` so
`ansible-playbook -i inventory playbook.yml` connects to App Server 3 with **no extra arguments**.

> Note: this is an Ansible task, not Kubernetes — there's no manifest to pipe into `kubectl`. The
> heredoc below writes the inventory file instead.

## Create the inventory (heredoc → file)

```bash
cat > /home/thor/playbook/inventory <<'EOF'
[app_servers]
stapp03 ansible_user=banner ansible_ssh_pass=BigGr33n ansible_connection=ssh
EOF
```

## How it works

### Why the hostname must be `stapp03`

Requirement (c) pins the inventory hostname to the **server name from the wiki** — `stapp01`,
`stapp02`, `stapp03` for App Servers 1–3 in Stratos DC. This matters twice over:

1. The playbook's `hosts:` directive refers to hosts (or groups) by these names. Naming the entry
   `appserver3` or a raw IP would mean `hosts: stapp03` never matches, and Ansible skips with
   "no hosts matched."
2. **`stapp03` is itself resolvable** from the jump host (via `/etc/hosts` / DNS in the lab
   network), so the inventory name doubles as the connection target. That's why **no `ansible_host`
   is needed** — Ansible resolves `stapp03` directly. Hardcoding an IP would add an assumption that
   could be wrong and break a setup that otherwise works.

Confirm resolution before running anything:

```bash
getent hosts stapp03        # or: grep stapp /etc/hosts
```

If that returns an address, you're set. `ansible_host` is only warranted in the rare case where the
name **doesn't** resolve — and then you'd take the IP from that lookup or the wiki.

### The connection variables

Each `key=value` after the hostname is a **host variable** telling Ansible how to authenticate:

| Variable | Purpose |
|----------|---------|
| `ansible_user` | SSH username on App Server 3. |
| `ansible_ssh_pass` | SSH password. Needed because these servers use password auth, not key-based. |
| `ansible_connection` | Transport plugin; `ssh` is the default for remote hosts, stated explicitly for clarity. |

> **Verify the credentials against your lab's wiki.** The values shown (`banner` / `BigGr33n`)
> follow the common Stratos DC pattern, but treat them as placeholders to confirm rather than
> facts — substitute whatever the wiki lists for App Server 3.

### Why the variables live *in* the inventory

The validation runs exactly `ansible-playbook -i inventory playbook.yml` — no `-u`, no `-k`, no
`--private-key`. So every piece of connection information must come from the inventory file itself.
Putting user and password in as host vars is what makes the bare command work; omitting them would
force Ansible to fall back to the current user and key-based auth, and the connection would fail.

### Password auth needs `sshpass`

`ansible_ssh_pass` requires the `sshpass` utility on the control node (the jump host). It's normally
pre-installed in these labs; if Ansible errors with "to use the 'ssh' connection type with
passwords, you must install the sshpass program," install it (`sudo yum install -y sshpass`).

### Host key checking

A first-time SSH connection can fail on host-key verification. The safest fix for the validation is
an `ansible.cfg` beside the playbook, since it applies with no extra command-line arguments:

```bash
cat > /home/thor/playbook/ansible.cfg <<'EOF'
[defaults]
host_key_checking = False
EOF
```

(The equivalent `export ANSIBLE_HOST_KEY_CHECKING=False` works too, but relies on the environment
being set when validation runs.)

## Verify

```bash
cd /home/thor/playbook

# Inventory parses and lists stapp03
ansible-inventory -i inventory --list

# Connectivity check — this settles hostname resolution AND credentials at once
ansible -i inventory stapp03 -m ping

# The actual validation command
ansible-playbook -i inventory playbook.yml
```

Expected — `ansible-inventory` showing `stapp03` with its vars, the ping returning
`"ping": "pong"` with `SUCCESS`, and the playbook running to completion with no failed tasks.

> `UNREACHABLE` on the ping means either the hostname didn't resolve (check `getent hosts stapp03`)
> or the user/password don't match the wiki. "No hosts matched" from the playbook means its `hosts:`
> value doesn't align with `stapp03` or the group name — open `playbook.yml` and match the inventory
> group to it.