docs: add 100 Days of DevOps challenge notes

100 - days of devops/devops-82.md

@@ -0,0 +1,123 @@
+# 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.