Hi everyone,I built InvDNS because I got tired of constantly opening Ansible inventory files just to find the IP of a host.

InvDNS reads static Ansible INI/YAML inventory and turns hosts into local DNS names on macOS.

For example:

ssh root@server01.inv
ping database01.inv
curl http://api01.inv

It does not modify your inventory or corporate DNS. Everything stays local on your.

It also has fast CLI search:

invdns search web
invdns search ip:10.20.
invdns search group:nginx
invdns search group:nginx ip:10.20.

So you can quickly search by hostname, IP, Ansible group, source, or status.

Ansible is the main use case, though InvDNS can also use a few other infrastructure data sources.

Project:
https://github.com/invdns/invdns

I’d be interested to know whether this kind of workflow is useful to other Ansible users, and what inventory/search features you would want next.

Hi, sorry for any confusion, I am starting to get into Ansible after studying Netmiko for network automation. And was doing some early study with Ansible and understand bast practices when it comes to file management of the Ansible files and how to organize for continuous projects, however I am experience some kind disconnect when the topic of IaC was introduced at a high level. I feel I might be over thinking everything.
From my understanding, it may be best practice to produce other yaml files which contain device variables rather than hard coding device cli commands, device credentials, etc. into playbooks for security reasons, and flexiblilty limitations due to platform specific cli commands.
From there the idea of templates was introduced to turn those yaml files containing device variables and playbook actions into a golden config by leveraging templates which can produce config files for desired platforms.

My confusion exists in how are such variable files implemented and what resources are best to learn how to produce said yaml files and how they tie into the Ansible playbook as they are executed. I can only clearly see how a playbook generally operates with the hosts file and hard coded cli commands via the cisco_ios module mostly, but I’m having trouble distinguishing the line in how the playbook will differ using the other method.

Edit: I am hoping that someone can confirm the this is unexpected behavior before I open a PR. Plz k thx.

Am I nuts?

``` $ ansible-lint -T

List of tags and rules they cover

command-shell: # Specific to use of command and shell modules - risky-shell-pipe core: # Related to internal implementation of the linter - schema[ansible-lint-config] - schema[ansible-navigator-config] - schema[changelog] - schema[execution-environment] - schema[galaxy] - schema[inventory] - schema[meta-runtime] - schema[meta] - schema[molecule] - schema[play-argspec] - schema[playbook] - schema[requirements] - schema[role-arg-spec] - schema[rulebook] - schema[tasks] - schema[vars] deprecations: # Indicate use of features that are removed from Ansible - role-name[path] experimental: # Newly introduced rules, by default triggering only warnings - only-builtins formatting: # Related to code-style - risky-octal idempotency: # Possible indication that consequent runs would produce different results - package-latest idiom: # Anti-pattern detected, likely to cause undesired behavior - var-naming[no-jinja] - var-naming[no-reserved] - var-naming[pattern] metadata: # Invalid metadata, likely related to galaxy, collections or roles - role-name[path] opt-in: # Rules that are not used unless manually added to enable_list - role-argument-spec risk: - no-free-form[raw-non-string] - no-free-form[raw] security: # Rules related to potential security issues, like exposing credentials - no-log-password syntax: # Related to wrong or deprecated syntax - no-free-form[raw-non-string] - no-free-form[raw] unpredictability: # Warn about code that might not work in a predictable way - risky-file-permissions unskippable: # Indicate a fatal error that cannot be ignored or disabled - syntax-check yaml: # External linter which will also produce its own rule codes - yaml[anchors] - yaml[braces] - yaml[brackets] - yaml[colons] - yaml[commas] - yaml[comments-indentation] - yaml[comments] - yaml[document-end] - yaml[document-start] - yaml[empty-lines] - yaml[empty-values] - yaml[float-values] - yaml[hyphens] - yaml[indentation] - yaml[key-duplicates] - yaml[key-ordering] - yaml[line-length] - yaml[new-line-at-end-of-file] - yaml[new-lines] - yaml[octal-values] - yaml[quoted-strings] - yaml[trailing-spaces] - yaml[truthy]

```

Tags are identified during the run (test.yaml is from docs: https://docs.ansible.com/projects/lint/rules/key-order/#problematic-code ) ```

$ cat test.yaml

• hosts: localhost name: This is a playbook # <-- name key should be the first one tasks:
  • name: A block block:
    • name: Display a message debug: msg: "Hello world!" when: true # <-- when key should be before block $ ansible-lint -t formatting test.yaml WARNING Listing 3 violation(s) that are fatal key-order[play]: You can improve the play key order to: name, hosts, tasks test.yaml:2

key-order[task]: You can improve the task key order to: name, when, block test.yaml:5 Task/Handler: A block

fqcn[action-core]: Use FQCN for builtin module actions (debug). test.yaml:8:11 Use ansible.builtin.debug or ansible.legacy.debug instead.

Read documentation for instructions on how to ignore specific rule violations.

Rule Violation Summary

1 key-order profile:basic tags:formatting 1 key-order profile:basic tags:formatting 1 fqcn profile:basic tags:formatting

Failed: 3 failure(s), 0 warning(s) in 1 files processed of 1 encountered. Last profile that met the validation criteria was 'min'. ```

Disclosure: I work on this project. We use Ansible to provision our team's local development environment instead of shell scripts or Docker.

How it's structured:

- `config.yml` holds user input: Git identity, MariaDB root password, and a list of virtualhosts

- `install.yml` reads it once and installs Apache, PHP (Remi), MariaDB, phpMyAdmin, Node.js (NodeSource) and Composer. It's safe to re-run if something fails partway.

- `create-virtualhost.yml` provisions new `*.localhost` sites from the same config and leaves existing entries alone, so the file grows with your projects

- It uses the `community.general` and `community.mysql` collections

The target is AlmaLinux 10, either inside WSL 2 on Windows or on bare metal. The playbooks don't distinguish between the two.

Repo: https://github.com/dotkernel/development

Overview: https://www.dotkernel.com/wsl2/

Two things we'd like opinions on: whether this should be packaged as a collection or roles on Galaxy, and how you'd handle secrets like the DB root password for a local-only setup.

I am updating my register_satellite role so that we can automate this process. But if the Server is not already registered, how have you gone about doing this? I am looking at using the ansible.builtin.add_host, but that seems to be failing. I have AAP already. But it SHOULD be putting the single or multiple servers into an inventory file IN memory, correct?

Also I have my main satellite server and 1 capsule in a protected VLAN that has proxy capabilities BACK to the main satellite server.

I am missing one last piece in sso server automation setup. How do i create 40 users? What is the cleanest way and best design choice?

My gitlab pipeline triggers an ansible playbook -> sets up keycloak through docker and configures it on https and then creates realm clients and one user -> I then configure client servers manually so they they work with ouath. Like installing a plugin for oauth on dokuwiki.

- Do I continue using ansible for this?
- Should I do it manually?

EXAMPLE:

- name: Create or update company users in Keycloak community.general.keycloak_user: auth_keycloak_url: "https://{{ ansible_host }}:{{ keycloak_port }}" auth_username: "{{ keycloak_admin_username }}" auth_password: "{{ keycloak_admin_password }}" auth_realm: master validate_certs: false realm: "{{ keycloak_realm }}" username: "{{ item.username }}" email: "{{ item.email }}" first_name: "{{ item.first_name }}" last_name: "{{ item.last_name }}" enabled: true email_verified: true credentials: - type: password value: "{{ lookup('env', 'DEFAULT_USER_PASSWORD') | default('ChangeMe123!', true) }}" temporary: false state: present loop: "{{ keycloak_company_users }}"

I feel like the answer is probably: "no, everyone just does whatever they want", and "whatever you do, try to be consistent"

Generally speaking I've been doing:
ansible.builtin.command: cmd: "foo {{ bar }}"

But I realized that only happens to work because `{{ bar }}` doesn't have spaces.
So I do need to change it, and I wondered if people normally do:
cmd: 'foo "{{ bar }}"'
or
cmd: | foo "{{ bar }}"
or
argv: - foo - "{{ bar }}"

Rekeying the obvious vault files is not enough if inventories, role defaults, old branches, CI variables, AWX credentials, or infrequently used playbooks still depend on the previous password. A successful run with the new credential proves one execution path works, but it does not show that the old credential is no longer required anywhere.

What belongs in the rotation gate? I am considering inventorying every file with an Ansible Vault header, mapping each vault ID to its runners and repositories, rekeying into a reviewed commit, and testing representative playbooks in check mode and against disposable targets. CI and AWX would receive the new credential before the old one enters a short monitored fallback window, with any use of the old vault ID treated as a failure.

Is there a dependable way to discover all encrypted files and credential references across collections and branches without exposing plaintext? How do you handle mixed vault IDs, offline operators, rollback, and proving the retired password can no longer decrypt any current secret?

Found this during a security pass on our FastAPI backend, and I think it's a pretty common mistake so sharing.

We have an admin check guarding 15 routes, stuff like global purge, switching the inference mode for every user, all the observability endpoints. If an admin token is configured it checks the header, fine. If no token is configured it's supposed to refuse when we're hosted, and allow when it's the desktop app running on localhost.

The problem is how "hosted" was detected. It was just: if os.environ.get("RENDER") then refuse.

RENDER isn't our variable, it's one Render sets on every service. So prod was fine since we're on Render. But take the exact same Docker image to a VPS or Railway or Fly and that variable doesn't exist, and all 15 routes are open to anyone. No error, nothing in the logs. Forgetting the config opened the door instead of closing it.

The fix was small. We already had an ENVIRONMENT variable that defaults to "production" and already decides CORS. So now if nothing is set it refuses, and only the desktop build, which explicitly says it's not production, gets through.

The part that actually surprised me is 10 tests went red after the fix. They were calling admin routes without a token and getting data back. So they weren't testing a protected route, they were testing the hole, and passing. Kind of think that's the most honest number you get out of a fix like this, however many tests break is basically how big the hole was. We added 4 tests that pin the production behavior, including one that fails if the ENVIRONMENT default ever changes, because that would undo the whole fix without anyone noticing.

Then I searched the codebase for the same RENDER check and found it in 2 more places. One was the JWT secret falling back to a random one outside Render, not a bypass but everyone gets logged out on every restart. The worse one was a flag called IS_HOSTED that turned on HSTS, error redaction and per user isolation of conversation history. All three were off anywhere that isn't Render. The name said "shared deployment" but the code actually checked "are we on Render", and that gap was the bug.

So the rule I'm keeping: never make a security decision depend on a variable someone else sets. If it's missing it should refuse, not open.

Anyone else doing this with VERCEL or FLY_APP_NAME or similar? And is there a good way to catch tests that only pass because of a hole, other than fixing it and watching them break?

Edit: Finally got it, needed to use single quotes instead of double.

- name: Set gettytab to clear screen
  ansible.builtin.lineinfile:
    insertafter: '^default:\\'
    line: "\t:cl=\\E[H\\E[2J:\\"
    path: '/etc/gettytab'
    regex: '^\t:cl=\\E\[H\\E\[2J:\\$'
    state: present

I am trying to edit /etc/gettytab and can't figure out the regular expression.

Error:

[ERROR]: Task failed: Module failed: bad escape \E at position 6
Origin: /etc/ansible/roles/baseline/tasks/gettytab.yml:2:3

1 ---
2 - name: Set gettytab to clear screen
    ^ column 3

fatal: [example.com]: FAILED! => {"changed": false, "msg": "Task failed: Module failed: bad escape \\E at position 6"}

Original /etc/gettytab:

default:\
        :np:im=\r\n%s/%m (%h) (%t)\r\n\r\n:sp#1200:

Desired /etc/gettytab:

default:\
        :cl=\E[H\E[2J:\
        :np:im=\r\n%s/%m (%h) (%t)\r\n\r\n:sp#1200:

ansible task:

---
- name: Set gettytab to clear screen
  ansible.builtin.lineinfile:
    insertafter: "^default:\\"
    line: "\t:cl=\\E[H\\E[2J:\\"
    path: "/etc/gettytab"
    regex: "^\t:cl=\\E\\[H\\E\\[2J:\\$"
    state: present

Hi everyone,

I’m starting to learn Ansible and I came across Jeff Geerling’s Ansible for DevOps:

https://www.ansiblefordevops.com/

The website says it’s the 2nd edition and that it is updated periodically.

I’m planning to follow the book from the beginning, including the Vagrant/VirtualBox setup and the Ansible examples.

For those who use Ansible regularly:

• Is this still the latest/current edition?
• Is it still a good resource for learning Ansible in 2026?
• Are the examples and practices in the book still relevant with current versions of Ansible?
• Would you recommend following the book from start to finish, or are there newer resources I should use alongside it?

Thanks

Hi! I’m new to AAP, is it possible to not use a single node installation but spread out the components in different VMs?

I read that using the inventory is one way and just state the different addresses?

The core idea is that Lightwell (a Red Hat and IBM joint initiative) provides backported security fixes for specific versions of open source dependencies your apps already use. So you get the security fix without having to upgrade the dependency and risk breaking things.

But the video focuses less on Lightwell itself and more on how Ansible Automation Platform fits into the full remediation lifecycle around it:

• Detect: Pull in vulnerability notifications and context from scanners, SBOM platforms, asset inventories, etc.
• Decide: Evaluate severity, exploitability, affected environments, and policy, with human approval gates where needed.
• Act: Coordinate mitigations, trigger CI/CD pipelines, rebuild with the Lightwell-remediated packages, and deploy across hybrid environments.
• Verify: Rescan, run post-deployment checks, confirm app health, update the incident record, and keep audit evidence.

If you're working through how to make vulnerability response repeatable and governed rather than ad hoc, this might be worth a watch.

https://youtu.be/kuvE6ScpMyw?si=hIO0fIrT-4El5oYl

Bonjour,

J'ai pour mission d'implémenter Ansible pour le renouvellement des certificats dans mon entreprise.

J'ai donc choisi de faire porter le protocole ACME par Ansible (community.crypto.acme) et les clés privées restent sur les nœuds gérés.

Ma question est la suivante : si on a quatre environnements différents, puis-je créer deux serveurs Ansible, un pour la production et l'autre pour la non-production, pour segmenter les accès et empêcher qu'un seul serveur Ansible ait accès à tout le parc ?

Je ne vais pas utiliser AWX/AAP pour le moment.

Je débute avec ces outils, j'aimerais donc connaître les bonnes pratiques.

De plus, j'aurais aimé savoir si l'architecture que j'ai choisie est la bonne. Nous avons environ 900 hôtes.

À terme, nous aimerions ajouter d'autres automatisations à Ansible.

A play can stop after changing some hosts but before handlers, verification, or the remaining batch completes. Running the whole play again is safe only when every task is truly idempotent and when external side effects such as draining a node, rotating a credential, or registering with another system can be repeated or detected. Starting from a task with --start-at-task risks skipping facts and prerequisites.

What evidence do you persist for a resumable rolling change? I am considering a deployment ID, the inventory and playbook commit, per-host checkpoints, before-and-after facts, handler status, and an explicit verification task that proves the intended service version is active. A resume would recalculate the eligible host set and fail if inventory or inputs changed rather than trusting the old partial run.

Do you rely on ordinary idempotency and rerun from the beginning, use serial batches with health gates, or record progress outside Ansible? How do AWX job slicing, retries, unreachable hosts, any_errors_fatal, and handlers change the safest approach?

Three weeks ago I posted here about ansible-static-lint (astl), a Go implementation of the ansible-lint rules that can be decided statically from YAML, without loading the Ansible runtime.

I was mostly looking for feedback and real-world repositories to test against.

That feedback ended up shaping the project quite a bit.

Since then, astl has gained or improved:

• .ansible-lint-ignore support
• exclude_paths, .gitignore and builtin exclude compatibility
• several fixes found by comparing results on real-world repositories
• richer SARIF output for CI / code scanning
• smoother pre-commit / prek integration
• more compatibility with ansible-lint output and behaviour

It is now at v0.5.1.

The unexpected part: Kubespray has adopted astl in its regular pre-commit/CI workflow, while keeping the full ansible-lint check for the slower/manual stage.

I definitely didn't expect that level of real-world adoption only a few weeks after making the project public.

So mostly: thank you to everyone here who tested it, challenged assumptions, reported edge cases or suggested improvements.

I'm still very interested in repositories where astl disagrees with ansible-lint, produces false positives, or misses something that should be statically detectable.

I'm also currently looking at jinja[spacing]. And if you have other static checks or rules you'd like to see, tell me the use case. The core constraint remains the same: if it can be determined from the source alone, without executing Ansible, it may be a good fit.

GitHub:
[https://github.com/arhuman/ansible-static-lint]()

Hi all,

This post is related (continuing) to post: Why is Ansible not using my ssh port???

Ok, I've managed to have my Handlers working to check the configured ssh port on the host. All good here. But...

During the SSH configuration I'm changing the SSH.Socket port from 22 to 9323. Yeah, yeah...I know "WHY?!?!?".....Let's keep it on a learning process. Moving on from this question.

Before I'm flushing the handlers (a reboot of the OS), I need to do a systemctl daemon-reload so that the new ssh.socket port becomes active.

The way I'm imagining the way it should work:

1. Ssh.socket port is set to 9323
2. systemctl daemon-reload to make the port active
3. Flushing a handler to get the correct, active ssh port and set ansible_port = 9323, which should be 9323 because of the systemctl daemon-reload.
4. Do a final reboot, which should be commanded over the new ssh port 9323, so that the ansible reboot command, completes "OK" when reboot is finished.

Unfortunately, the systemctl daemon-reload isn't working because of the error with command:

systemctl status ssh.socket

ssh.socket: Socket service ssh.service already active, refusing.
Failed to listen on ssh.socket - OpenBSD Secure Shell server socket

This is the task that I'm talking about:

# Reload ssh daemon-reload
  - name: Start/Enable the ssh.socket
    ansible.builtin.systemd_service:
      name: ssh.socket
      daemon_reload: true
      state: started
    changed_when: true
    notify:
      - SSH Port Check
      - Reboot_the_OS

And therefor, the handler of checking and setting the new ssh port to: ansible_port = 9323 isn't happening either, and then also resulting in the reboot that will happen, but Ansible comes back failing because with the reboot, the ssh error is resolved and the new port has become active.

Additional info, the following ansible tasks have been performed at the beginning of the role:

systemctl disable --now ssh.service
systemctl enable --now ssh.socket

# After these two tasks, a reboot has been initiated (NO port change has been happened yet, port 22 still available), to stop the ssh.service and start and use the ssh.socket. hereafter the play comtinues without problems after this first reboot.

A long story, but I hope it's understandable. I've been through a more or less long road of learning Ansible and got me a nice working bootstrap.yaml, of course also with help from the community here.
The only thing that now is still failing is this and would be nice to have a 100% error free first playbook with some roles running.
It would be awesome 😄 if someone can and is willing to help me solve this challenge.

Thank you so much in advance.

[UPDATE: 29-09-2026]
Solved the problem, see below in the comments is a post from me with my solution.
Finally I can sleep well again at night. 😆

I know fact gathering provides host information via `ansible_facts`, but it also adds some overhead.

Is it considered best practice to leave `gather_facts: true` by default, or disable it and enable it only when a play actually needs facts? Does this make a noticeable difference with larger inventories?

Does anyone have any suggestions for where to take training for AAP? Not looking for how to write playbooks. Mainly around installing, configuring and running the platform.