feat(gemini): An Ansible playbook to distribute and activate morale-boosting content (quotes, images, sounds) across community nodes, ensuring a steady supply of whimsy in dire times.

[polsala]

Implementation Summary

• Utility: nightly-ansible-morale-booster
• Provider: gemini
• Location: ansible-playbooks/nightly-nightly-ansible-morale-boost
• Files Created: 8
• Description: An Ansible playbook to distribute and activate morale-boosting content (quotes, images, sounds) across community nodes, ensuring a steady supply of whimsy in dire times.

Rationale

• Automated proposal from the Gemini generator delivering a fresh community utility.
• This utility was generated using the gemini AI provider.

Why safe to merge

• Utility is isolated to ansible-playbooks/nightly-nightly-ansible-morale-boost.
• README + tests ship together (see folder contents).
• No secrets or credentials touched.
• All changes are additive and self-contained.

Test Plan

• Follow the instructions in the generated README at ansible-playbooks/nightly-nightly-ansible-morale-boost/README.md
• Run tests located in ansible-playbooks/nightly-nightly-ansible-morale-boost/tests/

Links

• Generated docs and examples committed alongside this change.

Mock Justification

• Not applicable; generator did not introduce new mocks.

[polsala]

🤖 Review by GROQ Agent

✅ What's solid

• Clear purpose & isolation – The playbook lives in its own directory (ansible‑playbooks/nightly‑nightly‑ansible‑morale‑boost) and does not touch any existing infrastructure.
• Idempotent file handling – All file‑related tasks use ansible.builtin.file / ansible.builtin.copy with explicit ownership, mode and state: directory, which makes repeated runs safe.
• Template‑driven script – Using a Jinja2 template for the display script (display_script.sh.j2) keeps the Bash logic out of the YAML and makes future tweaks easy.
• Variable defaults – vars/main.yml provides sensible defaults (/opt/apocalypsai_morale, cron every 6 h, etc.) and they can be overridden via --extra-vars as documented.
• Test scaffolding – A dedicated tests/ folder with a playbook that spins up a temporary environment (tmp dirs, dummy MOTD) shows good intent to verify the workflow.

---

🧪 Tests

Observation	Recommendation
Missing cron task – The main playbook never creates a cron job, yet the test suite asserts that a cron entry exists (failed_when: "{{ test_morale_display_script_path }}" not in crontab_output.stdout).	Add a task that uses ansible.builtin.cron to install the display script with the configured cron_schedule. Example: yaml<br>- name: Install morale booster cron job<br> ansible.builtin.cron:<br> name: "ApocalypsAI Morale Booster"<br> user: root<br> job: "{{ morale_display_script_path }}"<br> schedule: "{{ cron_schedule }}"<br> state: present<br>
Include path mismatch – include_tasks: src/morale_booster.yml is relative to the test file (tests/). From that location the path resolves to tests/src/morale_booster.yml, which does not exist.	Use a relative path that climbs out of the tests directory, e.g.: yaml<br>ansible.builtin.include_tasks: ../src/morale_booster.yml<br> or, better, import the whole playbook with ansible.builtin.import_playbook: ../src/morale_booster.yml.
Cron verification method – The test runs crontab -l -u root and greps for the script path. This couples the test to the exact format of the crontab entry and may be flaky on systems where crontab is not installed.	Prefer the ansible.builtin.cron module in a check task to assert the job exists, e.g.: yaml<br>- name: Verify cron job is present<br> ansible.builtin.cron:<br> name: "ApocalypsAI Morale Booster"<br> user: root<br> state: present<br> register: cron_check<br> failed_when: not cron_check.changed and not cron_check.exists<br>
No test for template rendering – The template is never rendered in isolation, so syntax errors would only surface at runtime.	Add a small test that renders the template with ansible.builtin.template into a temporary file and asserts the file contains the expected placeholders (e.g., {{ morale_content_dir }}).
Cleanup order – The post‑run cleanup removes the cron job after the script has been executed. If the script runs via cron during the test window, it could interfere with the assertions.	Either disable the cron job before invoking the script manually, or set the test cron schedule to a far‑future time and only verify the job definition without letting it fire.

---

🔒 Security

• Privilege escalation – become: yes is required for writing to /etc/motd, /usr/local/bin, and installing a cron job. Ensure the playbook is only run by trusted operators; consider adding a --ask-become-pass prompt in the README to make the need explicit.
• Script injection surface – The display script reads a random line from a text file and writes it to MOTD or a log. While the source files are under version control, an attacker who can modify quotes.txt/affirmations.txt could inject malicious shell commands if the script later expands the line (e.g., via eval). Verify that the script treats the line as plain text (e.g., echo "$RANDOM_LINE" without eval).
• File permissions – The playbook sets 0644 on the content files and 0755 on the script, which is appropriate. Double‑check that the directory /opt/apocalypsai_morale is owned by root:root to prevent unprivileged users from swapping in malicious files.
• Cron job hygiene – When installing the cron entry, include the full path to the script and any required environment variables to avoid reliance on the user’s PATH. Example:
  
  /usr/bin/env bash {{ morale_display_script_path }}.
• Log file location – The fallback log (/var/log/apocalypsai_morale.log) is written without rotation. Consider adding a logrotate snippet or documenting that the log may grow over time.

---

🧩 Docs / Developer Experience

• README typo – The directory name in the header (nightly‑nightly‑ansible‑morale‑boost) contains a duplicated “nightly”. Align the folder name with the README title (nightly‑ansible‑morale‑boost) for consistency.
• Inventory instructions – The README shows ansible-playbook -i inventory.ini src/morale_booster.yml. Since the playbook lives under src/, users must run the command from the nightly‑nightly‑ansible‑morale‑boost root. Clarify the working directory or provide a wrapper script (e.g., run.sh).
• Variable documentation – The list of overridable variables is good, but the README still refers to morale_display_script_path while the vars file uses morale_display_script_path. Ensure the spelling matches everywhere (currently they match, but double‑check for hidden typos).
• Example cron command – Add a snippet showing the exact cron line that will be installed, e.g.:
  
  0 */6 * * * /usr/local/bin/display_morale.sh. This helps operators verify the job manually.
• Testing guide – The “Test Plan” section points to the README and the test playbook, but it would be helpful to include a one‑liner for CI, such as:
  
  ansible-playbook -i localhost, -c local tests/test_morale_booster.yml.
• License / attribution – Since the content (quotes/affirmations) is generated by Gemini, consider adding a short attribution note or a disclaimer that the text is AI‑generated.

---

🧱 Mocks / Fakes

• Mock rationale comment – The test includes ignore_errors: yes # Mock rationale: Ensure a clean slate…. While the comment explains the intent, the term “mock” is a bit misleading because no actual mock objects are used. Consider renaming the comment to “idempotent cleanup” to avoid confusion.
• Cron job mock – The test uses ignore_errors: yes when removing a pre‑existing cron job. This is fine, but you could replace it with a deterministic ansible.builtin.cron task that ensures the job is absent, which is more explicit than relying on error suppression.
• File system isolation – All test artifacts are placed under /tmp, which is good. Ensure the CI environment cleans /tmp between runs or uses a unique prefix (e.g., /tmp/apocalypsai_morale_{{ ansible_date_time.epoch }}) to avoid collisions when tests run in parallel.
• No external service mocks – The playbook does not call any external APIs, so no network mocks are needed. If future extensions add a remote content fetch, plan to use uri module with status_code checks and mock the endpoint in tests.

---

TL;DR Action Items

1. Add a cron task to the main playbook (use ansible.builtin.cron).
2. Fix the test include path (../src/morale_booster.yml or import_playbook).
3. Replace fragile cron verification with the cron module’s state: present check.
4. Add a unit test for the Jinja2 template to catch syntax errors early.
5. Review script for injection safety (avoid eval, quote variables).
6. Clarify README (folder name, inventory path, example cron line, CI one‑liner).
7. Rename “mock rationale” comments to reflect their true purpose.

Implementing these changes will make the utility more robust, secure, and easier for contributors to adopt and maintain. 🚀

[polsala]

🤖 Review by GROQ Agent

✅ What's solid

• Clear purpose & isolation – The playbook lives in its own directory (nightly‑nightly‑ansible‑morale‑boost) and does not touch existing infrastructure.
• Idempotent file handling – Uses ansible.builtin.file and ansible.builtin.copy with explicit ownership/permissions, which makes repeated runs safe.
• Configurable defaults – All paths and the cron schedule are defined in vars/main.yml and can be overridden via --extra-vars, keeping the playbook flexible.
• Self‑contained test suite – The tests/ folder ships a fairly comprehensive end‑to‑end scenario that exercises the main tasks (directory creation, file copy, script generation, cron entry, script execution).
• Good README layout – The README explains the high‑level idea, shows a minimal inventory, and provides example command‑lines with variable overrides.

🧪 Tests

Observation	Recommendation
The test includes the playbook with ansible.builtin.include_tasks: src/morale_booster.yml. The file, however, is a full playbook (it declares hosts, become, vars_files). Including it as a task can cause “duplicate hosts” errors or ignored variables.	Replace the include with an import_playbook call from the test runner, or split the reusable tasks into a role and include that role in the test. Example: yaml<br># in tests/test_morale_booster.yml<br>- import_playbook: ../src/morale_booster.yml<br>
The test checks the cron job by running crontab -l -u root and grepping for the script path. This depends on the host’s cron implementation and on the test runner having permission to read root’s crontab.	Use the cron module’s state: present with cron_file set to a temporary file (e.g., /tmp/apoc_cron) and then assert on the module’s result (cron.changed). This avoids needing root’s real crontab.
The test cleans up artifacts after the playbook run, but the cleanup runs inside the same play that created the cron job. If the cron entry fails to be removed, the subsequent test run could be polluted.	Separate the cleanup into a pre_tasks block that always runs (using always:) or create a dedicated teardown play that runs regardless of earlier failures.
No explicit assertions on the content of the generated script (e.g., that it references the correct variables).	Add a simple slurp or lineinfile check to verify that the rendered script contains the expected MOTD_FILE or LOG_FILE paths.
The test suite does not verify idempotency – running the playbook twice should not change anything.	Add a second run of the playbook and assert that changed is false for all tasks. This catches accidental “always‑changed” tasks.

🔒 Security

• Root privileges – The playbook uses become: yes to write to /etc/motd, /usr/local/bin, and to install a cron job. Make sure the target hosts have a restricted sudo policy (e.g., only allow the specific commands needed) to avoid granting broader root access than required.

• Content sanitisation – The display script reads a random line from the supplied text files and echoes it. While this is safe for plain text, a malicious contributor could inject a line containing shell‑special characters (e.g., $(rm -rf /)) that would be evaluated if the script ever switches to eval or source. Consider escaping the line before printing, e.g.:

  # In display_script.sh.j2
  SAFE_LINE=$(printf '%s\n' "$RANDOM_LINE" | sed 's/[][$*.^]/\\&/g')
  echo -e "\n--- ApocalypsAI Morale Booster ---\n$SAFE_LINE\n..."

• Cron job exposure – The cron entry runs the script as root. If the script path is writable by non‑privileged users, they could replace it with malicious code. The playbook already sets the script mode to 0755 owned by root, which is good, but ensure the directory containing the script (/usr/local/bin) is not world‑writable.

• File permissions – The copied content files are set to 0644 owned by root. If the content is meant to be user‑editable, consider a less‑privileged owner (e.g., ansible_user) or make the files read‑only for root only.

• Potential DoS – The script appends to /etc/motd on every run. Over time this could bloat the file. Adding a rotation or size‑check before appending would mitigate this.

🧩 Docs / Developer Experience

• Variable documentation – The README lists the overridable variables but does not reference the exact names used in vars/main.yml (e.g., morale_content_dir). Adding a table that maps variable → default → description would help newcomers.

• Prerequisites – Mention that the target hosts must have cron, shuf, and bash installed, and that the control machine needs Ansible ≥2.9 (or whichever version you target).

• Running the tests – Provide a one‑liner in the README, e.g.:

  # From the repository root
  ansible-playbook -i ansible-playbooks/nightly-nightly-ansible-morale-boost/src/inventory.ini \
    ansible-playbooks/nightly-nightly-ansible-morale-boost/tests/test_morale_booster.yml

  This removes ambiguity about the working directory.

• Example cron entry – Show the exact line that will be added to the crontab, so operators can verify it manually if needed.

• Extending content – The README could include a short “how to add new content types (e.g., jokes, memes)” and point to the Jinja2 template for the script.

🧱 Mocks / Fakes

• Cron handling – The current test interacts with the real system cron. In CI environments this can be flaky or require privileged containers. Consider mocking the cron module by using the cron_file parameter to write to a temporary file, then assert on that file’s contents.
• File system isolation – The test writes to /tmp which is fine, but the playbook itself writes to /opt/apocalypsai_morale and /usr/local/bin. In a CI run, those paths may not be writable. The test already overrides them with temporary paths, which is good. Ensure the include_tasks (or import_playbook) also receives those overrides, otherwise the original defaults could be used inadvertently.
• Command execution – The test runs the generated script with ansible.builtin.command. If the script depends on environment variables (e.g., PATH), the CI runner might not have shuf. Adding a pre‑task that verifies required binaries are present (which shuf) would make the test more deterministic.

---

Quick win checklist

• Replace include_tasks with import_playbook or refactor into a role.
• Add an explicit cron task to the main playbook (currently missing).
• Harden the display script against shell‑special characters.
• Document variables in a table and list prerequisites.
• Adjust the test to use a temporary cron file instead of the real root crontab.

These adjustments will make the utility more robust, safer to run on production nodes, and easier for contributors to understand and extend.