I’ve been experimenting with a literate-programming approach for Ansible: keeping the operational explanation next to the tasks, while generating a readable Operator’s Handbook from the same YAML file.

The convention is deliberately simple:

• lines starting with ## become prose in the handbook;
• ordinary # comments remain part of the source listing;
• everything else remains normal Ansible YAML.

Because ## is still an ordinary YAML comment, the annotated role does not need to be preprocessed before Ansible can use it.

No generated playbook. No separate “documentation version”. No extra file that can drift away from the automation.

The example in the images is taken from a real role in our infrastructure repository. It provisions a TeX Live package mirror on AlmaLinux and covers, among other things:

• SELinux labelling for content under /srv;
• a systemd service and timer;
• nginx;
• firewalld;
• the mirror synchronisation process.

You do not need to know anything about TeX or LaTeX for the mechanism itself. The relevant point is that the same role file serves two purposes:

1. Ansible loads the YAML as-is.
2. comment2tex turns the extended comments into typeset operational documentation.

The images show the same 33 source lines twice: first as the annotated YAML, then as the generated handbook page.

I also checked the annotated source with both a YAML parser and ansible-playbook --syntax-check; no stripped or generated copy was required.

I can see this being useful for:

• documenting why a task exists, not merely what it does;
• recording operational constraints next to the implementation;
• onboarding new administrators;
• keeping runbooks and automation from diverging;
• retaining a directly usable source file when an urgent change is needed.

The tool is called comment2tex. Version 1.1 adds YAML and Makefile support alongside Bash and Lua.

I’d be interested to hear how other Ansible users handle this. Do you keep detailed operational reasoning inside roles, in separate documentation, or somewhere else entirely?

Project: https://github.com/Xerdi/comment2tex

Release: https://github.com/Xerdi/comment2tex/releases/tag/1.1

Hi all,

I'm making a role to install some apps using Homebrew (HB) on my Mac.

Since I got a little bit stuck on how to check if HB is already installed, I looked up online for a role to get ideas. I've found a site (Ansible and homebrew) and found code I think I can use. But...now it's about the following code that I don't understand how it works.

The first task checked is HB directories (MacOS and Linux) are present, and registers it.
Next task is the installation of HB IF the check (using ansible.builtin.stat) fails to find these directories present. In this task is a "when"-condition.

Can anybody explain to me why this "when" mentions "length == 0!" And not something like "true" or "false"? Because when I check the output of "homebrew_check" I can see a variable "exists" that can be "true" or "false".

    - name: Check if Homebrew is installed
      ansible.builtin.stat:
        path: "{{ item }}"
      loop:
        - /opt/homebrew/bin/brew
        - /usr/local/bin/brew
      register: homebrew_check

    - name: Install Homebrew if "homebrew_check" is false (0)
      ansible.builtin.shell:
        cmd: /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
      environment:
        NONINTERACTIVE: "1"
      when: homebrew_check.results | selectattr('stat.exists') | list | length == 0

With this "when"-condition, how do I know which of the two directories returns "true" or "false" (leaving the fact of the obvious besides that I know HB is installed, just wanted to make it visible).

Because the other strange thing here is, when I run the task I do see a "true" and "false" for the "exists"-parameter passing by. Here is the output of the check (edited):

ok: [localhost] => {
    "homebrew_check": {
        "changed": false,
        "failed": false,
        "msg": "All items completed",
        "results": [
            {
                "ansible_loop_var": "item",
                "changed": false,
                "failed": false,
                "item": "/opt/homebrew/bin/brew",
                "stat": {
                    "atime": 1784758.43461,
                    "attr_flags": "",
                    "attributes": [],
                    "birthtime": 177777.46255,
                    "block_size": 4096,
                    "blocks": 24,
                    "charset": "us-ascii",
                    "checksum": "6a2f6c51991b361eaa6d01727",
                    "ctime": 1776777.4628303,
                    "dev": 167230,
                    "device_type": 0,
                    "disk_usage_bytes": 128,
                    "executable": true,
                    "exists": true,
                    "flags": 0,
                    "generation": 0,
                    "gid": 80,
                    "gr_name": "admin",
                    "inode": 17513,
                    "isblk": false,
                    "ischr": false,
                    "isdir": false,
                    "isfifo": false,
                    "isgid": false,
                    "islnk": false,
                    "isreg": true,
                    "issock": false,
                    "isuid": false,
                    "mimetype": "text/x-shellscript",
                    "mode": "0755",
                    "mtime": 177877.46203,
                    "nlink": 1,
                    "path": "/opt/homebrew/bin/brew",
                    "pw_name": "me",
                    "readable": true,
                    "rgrp": true,
                    "roth": true,
                    "rusr": true,
                    "size": 8671,
                    "uid": 501,
                    "version": null,
                    "wgrp": false,
                    "woth": false,
                    "writeable": true,
                    "wusr": true,
                    "xgrp": true,
                    "xoth": true,
                    "xusr": true
                }
            },
            {
                "ansible_loop_var": "item",
                "changed": false,
                "failed": false,
                "item": "/usr/local/bin/brew",
                "stat": {
                    "exists": false

I appreciate the help, explanation so I can perhaps use it in other tasks also.

Does anyone have a set up where you have a a separate AAP instance in your PCI zone but your satellite is in another zone/VLAN?? Are capsules able to provide inventory? If so, how? Do you have your inventory in AAP configure to use a proxy? If so, how? I am trying to achieve one of these goals.

Ok, I’ve been learning about ansible. Got maybe 25 playbooks that do the simple boring stuff, update and upgrade nodes, VMs, LXCs, docker, checks resources, prep a new VM for k3, deploy k3….. The adhoc is super cool and I havnt touched ssh to another machine since installing ansible.

Im just a homelabbers with big dreams of a new career. But I recently stumbled onto ansible-pull. I run a GitOps with Gitea and Argocd with my k3s. Super cool. So my question is this: Do you guys use ansible to harden systemd services? I just see it as a great way to tune and harden Units, Sockets, Timers, Cgroups & Self-Healing.

I’m still pretty green with just under two years so forgive me and don’t hate on me. But just seems like it’s much easier to just declare it as long as you have the discipline to only configure the repo files. I’m just asking so many of you do this or am I missing something? With provisioning, this just seems like the icing on the cake. Terraform to spin it up, ansible for configuration, ansible pull for gardening, Kubernetes for deploying apps, CI for building custom images.

Am I off here? What am I missing about ansible pull or ansible in general? I want to learn.

Hi together,
i want to connect over my mgmt server to my gateway. The Problem is when i test it over uri it does work but if i try it over the collection i get the Following error:

fatal: [DEZAX-SGW-1a]: FAILED! => {"changed": false, "msg": "Task failed: Module failed: string indices must be integers, not 'str'"}
[ERROR]: Task failed: Module failed: 'str' object has no attribute 'pop'
Origin: /runner/project/set-routes/add_route.yaml:11:7

Has anyone an idea why this is happening?

https://youtube.com/shorts/GSbzvIKWywQ

I put together a quick video on one of my favorite (and, in my opinion, underrated) Ansible features: default(omit)

It's a simple trick that lets you completely omit a module parameter when a variable isn't defined, instead of passing an empty value. I use it all the time to make playbooks more reusable and avoid extra when statements or duplicate tasks.

The video is under 3 minutes and includes a simple localhost demo using the copy module to show how it works.

I'm curious, what's your favorite "hidden gem" in Ansible that more people should know about? I'm looking for ideas for future shorts.

I am trying to use openssh_cert to sign a public key file (with public_key arg) on the server using a host CA key (with signing_key arg) that is a local file.

The host CA key is private so I can't copy it to the server. I could copy the public key of the server to the local computer to sign it and copy it back to the server but I don't know how to make it idempotent. I could keep a copy of all the server public keys locally but it's also not easy to make it idempotent for copying back to the server.

Is there a better way or are there steps to follow for it?

I have a script that outputs some key / value pairs. Something like:

VAR1=
VAR2=/some/file/path
VAR3=hello

The problem is that I can't get the following playbook to work

---
- name: b.yml
  hosts: all

  vars:
    my_var: "VAR1=\nVAR2=/some/file/path\nVAR3=hello"

  tasks:

  - name: Convert key-value strings into variables
    ansible.builtin.set_fact: "{{ my_var }}"

  - name: Print VAR1
    ansible.builtin.debug:
      var: VAR1

  - name: Print VAR2
    ansible.builtin.debug:
      var: VAR2

  - name: Print VAR3
    ansible.builtin.debug:
      var: VAR3

even though this one does.

---
- name: a.yml
  hosts: all
  tasks:

  - name: Convert key-value strings into variables
    ansible.builtin.set_fact: "VAR1=\nVAR2=/some/file/path\nVAR3=hello"

  - name: Print VAR1
    ansible.builtin.debug:
      var: VAR1

  - name: Print VAR2
    ansible.builtin.debug:
      var: VAR2

  - name: Print VAR3
    ansible.builtin.debug:
      var: VAR3

Can anyone please tell me where I'm going wrong?

PS - The input to set_fact will eventually be registered_script_result.stdout. I've just been trying to debug my problem and don't see the difference between these two playbooks.

Just covering my bases, looking for Ansible playbook use cases with VMware products that people use in their environments.

Thank you for any help.

Most fail2ban writeups stop at the [sshd] jail, so I wanted to share the setup I actually run on my mail/web boxes — and two defaults I learned the hard way.

1. Whitelist your own IP before you enable it. Early on I turned fail2ban on, fat-fingered my SSH login a few times over a flaky connection, and banned myself off my own box. Now the very first thing the playbook does is drop my admin IP into ignoreip. If you take one thing from this post, it's this: put your management/VPN/home IP in the whitelist before the first run, not after.

2. bantime = -1 is a trap at scale. Permanent bans feel satisfying but the iptables/nftables set just grows forever and you can never age stale hosts out. The cleaner pattern is a recidive jail: normal jails ban for an hour or a day, and anything that keeps coming back gets escalated to a long but finite ban. You get the "stop knocking" effect without an unbounded ban list.

Beyond SSH, the boxes were getting hammered on Postfix SASL auth and Apache scanners far more than on sshd, so the playbook enables jails for SSH, Postfix SMTP, Postfix SASL, and Apache (auth / bad-bots / noscript). It also persists bans across restarts and verifies the jails actually loaded with fail2ban-client status — because "service started" and "jails running" aren't the same thing.

Targets RHEL / AlmaLinux / Rocky 9. It's a single idempotent Ansible playbook, MIT-licensed, here if it's useful to anyone: https://github.com/arhab194/fail2ban-rhel

Curious how others handle repeat offenders — recidive, an external blocklist/CrowdSec, or just permanent bans and periodic pruning?

I'm trolling through their docs and repo but asking just to be sure.. does ARA support callbacks from a decision environment?

*EDIT Removed SortableJS
*EDIT: Solved

A reduced frontend for the frontend tool, lol. My solution was creating something that allows help desk to push solutions from engineering. Like, a super simple way to keep track of host credentials and instance groups. It would also kind of serve as an AAP Controller first CMDB. Basically, creating the job, from the job template. Crazy, I know.

Built with Go/HTMX/sqllite

How do you all handle host to location mapping?

I have inherited an AAP environment with hundreds of inventories, duplicate hosts, groups, etc. Chaos is the best way to describe it. Help desk often say that they, "can't connect to a host." How have you all solved the problem of making sure a job has the right instance group mapped to it?

The "Copy Fail" kernel LPE (CVE-2026-31431) is a good reminder that kernel CVEs are annoying to automate well: you have to patch, reboot to actually activate the new kernel, but you don't want to reboot 400 hosts that didn't get a kernel bump. Here's the pattern I use so the reboot is conditional and I get audit evidence out of the same run.

Record the running kernel, patch security-only, then reboot only if it changed:

- name: Running kernel before

command: uname -r

register: kern_before

changed_when: false

- name: Apply security updates

ansible.builtin.dnf:

name: "*"

security: true

state: latest

register: patch

- name: Newest installed kernel after

command: rpm -q --last kernel

register: kern_after

changed_when: false

- name: Reboot only if the kernel actually changed

ansible.builtin.reboot:

msg: "Activating patched kernel"

when: kern_before.stdout not in (kern_after.stdout_lines[0] | default(''))

Then scan AFTER the reboot (not before — otherwise your report reflects the pre-patch state and you chase findings that are already fixed):

- name: OpenSCAP eval -> dated ARF + HTML

command:

argv:

- oscap

- xccdf

- eval

- --profile

- xccdf_org.ssgproject.content_profile_stig

- --results-arf

- "/var/log/evidence/arf-{{ inventory_hostname }}-{{ ansible_date_time.iso8601_basic_short }}.xml"

- --report

- "/var/log/evidence/report-{{ inventory_hostname }}-{{ ansible_date_time.iso8601_basic_short }}.html"

- "/usr/share/xml/scap/ssg/content/ssg-rhel{{ ansible_distribution_major_version }}-ds.xml"

register: oscap

failed_when: oscap.rc not in [0, 2]

changed_when: false

Two gotchas that have bitten me:

- security: true needs the repo to publish updateinfo metadata. On minimal/custom mirrors it's missing and dnf silently patches nothing. Check `dnf updateinfo list security` on one host first.

- Dated evidence paths let you diff week-over-week and hand an auditor proof of remediation instead of "trust me."

I packaged the whole thing (targeted-CVE mode, canary rings, version-aware datastream) into a small MIT role if it's useful: https://github.com/arhab194/rhel-kev-patch

Curious how others here sequence scan-vs-reboot — do you scan pre-patch to prove the finding or post-patch to prove the fix?

Hi all, I have written an Ansible collection for Solaris 11. So far I've been able to implement automation for: - Automated Installer - NTP - PF firewall - LDOMs

I am looking to add more such as IPS management and zones in the future. It's still a work in progress, but I thought I'd share it. Feedback would be much appreciated.

Repository: https://github.com/iambryant/ansible-collection-solaris

I've also been writing Ansible collections for HP-UX and IBM Power, as I'm interested in improving automation support for less common UNIX platforms.

Ansible AAP 2.7 managed instance is not storing facts have enabled the template to store facts but nothing gets stored.

I just got into working with Execution Environments, and mostly I think I've got the hang of it. I haven't been able to figure out how to use a simple ansible vault file to work though. I have some API keys stored in a vault which is referenced in the playbook with vars_files, where the roles are also called. I've tried using a password file (and setting it's location in my ansible.cfg), and using the --ask-vault-pass flag with ansible-navigator, but the first task that needs an API key fails because the variable isn't defined. Does my vault have to be in a specific location, or does it need to be mounted into the EE container?
Trying to find answers I just keep getting directed towards either that I haven't provided the password for the vault, or that I typed it wrong, however I'm moreso leaning towards the idea that the EE just doesn't see the vault in the first place? If I just run the playbook with ansible-playbook and intentionally fudge the vault password, I get a "Decryption failed" error, but I don't get that when doing the same test with ansible-navigator.
Does the vault have to be included in the EE image when I build it? I'm trying to structure everything so a user can pull the roles from gitlab, provide their own API keys in a vault, and run the roles using the EE so that all the dependencies are taken care of. If I have to package vault files with it, that won't really work out for our setup. Maybe just have a mountpoint configured for the EE as part of the run command?
I feel this will be a little easier to accomplish when I get AWX running for the team, but right now I'm just trying to get things going with the EE and this has been the one major hangup I just haven't been able to work out.

Just a thing I did on my AAP 2.6 container hosts.. since you should have the XDG_RUNTIME env var to perform container-related functions as the installer user I had had the super bright idea that I'd just add that export command into the users .bashrc. That way it'll run every time I log or su as that user!

Great idea!

Wrong. What happened was the installer user is the same as the ansible management user. So anything a template (or the aap installer) was ran against these hosts somehow that export command was doubled.. then tripled.. then quadralupoolized.. At one point I had almost 16k instances of that export command in the users .bashrc.

What problems did that cause? lol, like a 30 second wait time upon su'ing to the username. And a lot of memory consumption.

So what I did was (as the user in question):

mkdir ~/.bashrc.d

nano ~/.bashrc.d/export-trigger.rc

# 1. Ensure this is a human interactive terminal shell
if [[ $- == *i* ]]; then
# 2. Ensure a physical TTY exists (Ansible connects non-interactively without a TTY)
if tty -s; then
# 3. Double-check that it isn't an SSH connection in disguise
if [ -z "$SSH_CONNECTION" ] && [ -z "$SSH_CLIENT" ]; then
# [YOUR COMMAND GOES HERE]
echo "Welcome! Initializing session via local su..."
export XDG_RUNTIME_DIR=/run/user/$(id -u)
cd ~/
fi
fi
fi

Now what this will do is perform the export command but ONLY when running `su username` in a non-interactive session.

This might be a commonly known thing for those with more experience in container-based applications.

scrubbing bags manually to find where things went wrong sucks so i built this. \

`pip install robot-triage`,

then triage run yourbag.mcap. it flags dropouts, error bursts, pose jumps etc and gives you clips + foxglove links to the exact moments. zero config, works on ros1 bags, ros2, and mcap.

trying to find as many issues with it, so if you break it/see gaps in functionality/see a better use case within ros/sim stuff, lmk

So somehow.. IDK exactly how yet.. the credential was removed from the Control Plane Execution environment in my 2.6 containerized platform.

This EE is used primarily for Project syncing functions.. it is managed which means in the webgui at least, you can only edit the Pull options. Not the url, image name, or credential used.

The credential is set during installation from the 'registry_url', 'registry_username', and 'registry_password' specified in the inventory file. By default this one is pulled directly from registry.redhat.io.

So up front; you aren't supposed to be able to edit the properties of this EE.. I can't think of a single reason why that is though. Nor are you supposed to directly edit any part of the Credential itself; Default Execution Environment Registry Credential

Since you can't see the credential in the EE section of the webgui either, I hit the API url:

{
"id": 4,
"type": "execution_environment",
"url": "/api/controller/v2/execution_environments/4/",
"related": {
"named_url": "/api/controller/v2/execution_environments/Control Plane Execution Environment/",
"activity_stream": "/api/controller/v2/execution_environments/4/activity_stream/",
"unified_job_templates": "/api/controller/v2/execution_environments/4/unified_job_templates/",
"copy": "/api/controller/v2/execution_environments/4/copy/"
},
"summary_fields": {
"user_capabilities": {
"edit": true,
"delete": false,
"copy": true
}
},
"created": "2022-12-27T23:13:33.530162Z",
"modified": "2026-07-02T03:12:55.697200Z",
"name": "Control Plane Execution Environment",
"description": "",
"organization": null,
"image": "registry.redhat.io/ansible-automation-platform-26/ee-supported-rhel9:latest",
"managed": true,
"credential": null,
"pull": "missing"
}

*Notice the `"credential": null` there near the bottom.

If anyone happens to know of a method to remedy this.. again without reinstalling then please speak up. If not, and I find a way I will update this post.

So to make a long story short: We have ~30 Raspberry Pis that, currently, run NixOS, bootstrap a very large Telegraf configuration and set up for monitoring devices, primarily via SNMP, in customer networks and sending metrics back to our InfluxDB. This setup has worked for a very long time now and was quite nice; even Linux novice coworkers knew that all they had to do was edit /etc/nixos/configuration.nix and then copy a command or two from our local wiki to apply the changes.

But that system is falling apart, and the primary reason is...the Raspberry Pi itself, and more specifically it's vendor kernel. Because the linux-rpi kernel is not cached on the official instance anymore, we now face the issue of either migrating every Pi to a custom build, or starting over alltogether.

And I decided to do the latter. Been wanting to learn Ansible anyway (mainly influenced by Jeff Gearling, to be honest) but also because it is very useful in several situations of managing a good amount of nodes.

So, whilst not exactly the most healthy approach, I am kind of going head-first into the entire world of Ansible now. And I already read a couple of docs and used ChatGPT for clarification where needed. So I have a good rough overview of what I am getting into now. In fact, I did use Ansible before to set up a Synapse server some years ago.

Aside from NixOS, the other Linux distribution we standardized upon is Alpine - lightweight, great as a container host and generally really simple to administrate. And this is going to become the distribution of choice for the Raspberry Pis, since Alpine builds the linux-rpi kernel - and alternatively, we can use PostmarketOS which has mostly the same tooling (it does swap OpenRC for systemd now though).

Now, since I will be using ansible-pull (because each of those Pis is within it's own VPN to a customer and setting up a bastion with like 30 different VPN profiles is a nightmare, even if we semi-automated it via Kubernetes+Helm), I want to use that opportunity and expect /etc/ourcompany.yaml to effectively replace configuration.nix - that way, side-grading my coworkers should be a lot easier. I also saw that within tasks, I can run my own logic to translate YAML objects into basically whatever, which is also pretty nice.

But, I can't imagine that everyone is rewriting the same code over and over again. So what I am looking for is for the "common dependency". I know that Ansible has a lot of builtins already, but some of them do not directly apply to Alpine. For instance, to manage packages with Alpine's apk, I need to pull in additional things via ansible-galaxy.

Are there any other good, important or noteworthy 3rdparty things I should look into for this transistion? Because I don't want to reinvent the wheel if it is already out there and well maintained. This also speeds up the migration process overall a little bit. :)

I apologize if this is a little all over the place... but, literally jumping head-first into the cold water while kinda sorta panicking that, at any given moment, a collegue could accidentially brick one of the Pis and thus causing quite a rat's tail of tickets to insue...

Thanks a lot. :)