It can make an inventory from csv. Written in rust - probably fast. I know - there are similar projects. But I'm going to add support for different sources - like Redis. And maybe a python bindings to make it a proper inventory module. 😀

We pull in our hosts using a VCenter inventory, and are now trying to create Constructed Groups to break them into CGs for Windows, Linux etc.

All of the Windows hosts have several variables, including config.guestId, which contains the string 'windows'

So I added the following to the Constructed Inventory:

plugin: constructed
strict: true (for troubleshooting)
groups:
windows_vms: config.guestId is defined and 'windows' in (config.guestId | string | lower)

It will run and pulls in all the hosts, but the windows_vms group never gets created, so I cannot limit the inventory using it.

What am I missing?

Hello All,

I am new to ansible and wondering if anyone use ansible to fully automate LPAR provisioning?

Distro repositories often ship open-vm-tools builds that lag significantly behind upstream releases, delaying kernel/driver fixes, memory balloon enhancements, and CVE patches.

I open-sourced vmware-tools-builder to automate building and distributing the latest upstream binaries without polluting the host environment:

- Containerized builds: Uses Docker to compile upstream source into standalone .deb and .rpm packages.

- Target OS matrix: Ubuntu, Debian, RHEL/Rocky/Alma (8 & 9), Fedora, and openSUSE.

- Fleet orchestration: Includes an Ansible role that automates deployment, handles migration from distro-managed packages, and validates the vmtoolsd service state.

- Distribution: Packaged and installable directly from Ansible Galaxy (giuliosavini.vmware_tools_builder).

Repository: https://github.com/GiulioSavini/vmware-tools-builder

Feedback, testing across different hypervisor versions, and GitHub stars are welcome.Distro repositories often ship open-vm-tools builds that lag significantly behind upstream releases, delaying kernel/driver fixes, memory balloon enhancements, and CVE patches.I open-sourced vmware-tools-builder to automate building and distributing the latest upstream binaries without polluting the host environment:- Containerized builds: Uses Docker to compile upstream source into standalone .deb and .rpm packages.- Target OS matrix: Ubuntu, Debian, RHEL/Rocky/Alma (8 & 9), Fedora, and openSUSE.- Fleet orchestration: Includes an Ansible role that automates deployment, handles migration from distro-managed packages, and validates the vmtoolsd service state.- Distribution: Packaged and installable directly from Ansible Galaxy (giuliosavini.vmware_tools_builder).Repository: https://github.com/GiulioSavini/vmware-tools-builderFeedback, testing across different hypervisor versions, and GitHub stars are welcome.

Hi all, I've recently been attempting to migrate my Juniper devices from being hand-managed to automated. I've been able to create and document the following resources. I hope they can help others, and I'm looking to add more in the future. Feedback would be much appreciated:

Junos-dev-playbook repository:

This repository contains a handful of Ansible playbooks and templates I use to automate my infrastructure. I currently have EX, NFX, QFX, and SRX devices in my homelab. I'm also working on adding more advanced playbooks/tasks to fully showcase how to automate properly with the juniper.device Ansible collection.

Containerizing vSRX for CI/CD + Containerlab

I've made a blog post on how to get started with containerlab and tools they offer such as vrnetlab. It serves as a guide for containerizing VM-based applications like the vSRX so that you can use them in CI/CD jobs.

I recently stood up AWX for my team, and while I had worked with it before many years ago, I think how my old team was using it was a little different from how I envisioned my new team using it.

Previously when my old team used it, we each had credentials set up for our individual AD based user account. In order to use these credentials we had enabled prompt on run forcing someone to enter their password in order to use credential SSH keys and Become elevation. I think I can do that with my current team, but it would be really handy to simply restrict runs to use a private credential for each user.

Additionally some of the roles that I have built for provisioning and decommissioning servers requires the use of API tokens for multiple systems. When running these rolls with ansible CLI, the instructions involve using ansible vault and saving specific keys in your own vault. I'm trying to learn how to use an external vault like OpenBao/Hashicorp Vault, but it seems like AWX will require a single credential to access a single vault.

Does anyone know if it is possible for individual users to keep and maintain their own vault and select that vault and their own credentials when running a shared job?

It seems like the most common approach is to create service accounts that awx will use when running these jobs, and while I think that should be easy to configure, I generally prefer seeing user actions taken on separate systems instead of a general service account which could be misconfigured to allow users to perform actions they may not otherwise have the rights to do.

Hey all, a colleague of mine, Roger Lopez, put together a demo video walking through automation orchestrator. If you've been curious about how it actually works in practice rather than just reading docs, this is a pretty good visual breakdown.

I put together an overview video covering automation orchestrator, a new workflow canvas add-on for Red Hat Ansible Automation Platform. Worth watching if you're already running AAP or evaluating where orchestration fits into your ITOps strategy.

It doesn't replace anything you've already built. Your existing job templates, roles, and collections immediately become reusable workflow nodes with zero rewrites required. You can also export an entire workflow as a single YAML/JSON file, which makes it Git-friendly and easy to share across teams.

A few highlights from what the video covers:

- One canvas that unifies manual, scheduled, webhook, and Event-Driven Ansible triggers (around the 00:53 mark)

- New logic nodes like branch, loop, converge, and a switch node that routes workflows based on real infrastructure data instead of just binary success/fail outcomes (02:51)

- AI task agents that can analyze unstructured signals like alerts or tickets and recommend a next step, but with human approval or a predefined policy required before Ansible actually executes anything (04:26)

That last point matters. A lot of "AI in automation" talk skips over governance entirely. The approval gates and audit trails being built in from the start is the right approach for anything touching production infrastructure.

Curious if anyone else has been testing this out or has thoughts on where the switch node fits into workflows you're already running.

I'm fairly new to infrastructure and trying to understand the actual reason for using both.

From what I understand, Ansible can also provision cloud infrastructure through its cloud modules/collections, so technically it can be used for IaC, while also handling VM/server configuration.

Terraform seems to be more declarative and infrastructure-focused, with things like state, dependency graphs, and planning changes before applying them.

So what's the practical reason for choosing Terraform over Ansible for cloud infrastructure?

Is it mainly the state/plan/declarative model and the fact that Terraform is better suited to managing things like VPCs/VNets, subnets, IAM, load balancers, databases, etc.? Or are there other important technical reasons?

I'm not asking about job requirements or popularity. I'm mainly trying to understand the technical reason to use Terraform when Ansible can provision cloud resources through its cloud modules and also handle the configuration afterwards.

ansible-lint slowness turned out to be a fascinating exploration opportunity.

It started with a simple question:

What if I remove Ansible from the linting process and only do static analysis?

A few days later, first surprise: a relatively small subset of purely static rules could already detect around 80% of the findings in ansible-lint's own test corpus.

Today, ansible-static-lint implements the 38 out of 51 default ansible-lint rules that can be decided from YAML alone. On that same corpus, it finds 89.5% of the findings, near instantly, with byte-for-byte compatible pep8 output.

Tests on public repositories are encouraging so far.

ansible-static-lint is not meant to replace ansible-lint. The idea is to exploit sub-second feedback, often under 100ms, for editor-on-save, pre-commit and fast CI checks, while keeping ansible-lint for the deeper runtime-dependent checks.

I'd love feedback from ansible-lint users: does this look useful to you? Where would it fit, or fail to fit, in your workflow?

https://github.com/arhuman/ansible-static-lint

We recently started configuring AAP 2.6 (deployed using OpenShift Operators) and I'm very confused about the Roles.

Our company has three subsidiaries. Sub_1 is the biggest with 100+ teams, and Sub_2, Sub_3 have about a dozen each. I have created 3 separate Organizations and teams under each one of those Organizations. Then I configured AD based authentication and authentication mapping to add a logged in user to specific team based on their group membership. When a user logs on they get "Team member" role on their specific team.

But what I noticed is that a "Team member" cannot almost do anything by themselves. Resources like Projects/Inventory/Credentials can only be created by an Org admin and assigned to specific team(s). Only then the "team member" can use those resources.

Is this the expected behavior or am I missing something? If users have to go to Org admin for creating any resource, doesn't this cause huge bottleneck at Org admin? How are you guys solving this problem?

Any tips for a beginner getting started with Ansible?

Hi everybody,

I'm have created two playbooks for my Proxmox nodes:
- Bootstrap = NAG removal, Add repos, create 2 users, setup SSH
- Proxmox_play = Setting up the whole system to my desires

The Bootstrap has to be done with elevated privileges (root: become=true). I'm passing through the root password as a vault encrypted file.

Now, for the Proxmox_play, I read that one should use a different user to perform all remaining tasks. I'm just talking about a home-lab, nothing exposed to the WWW.

1. Do I really need to use a different user to execute all the remaining tasks, what are the implications if I don't do that?
2. How can I tell Ansible that it should use user X with passwd Y to execute all tasks on hosts: 1, 2, 3, 4, 5, 6, etc...?

Additionally, I'm currently storing the encrypted files in a separate directory where all my ansible related stuff resides....NOT directly within the roles, though!
What is the recommendation of the community where to store these files best? (I'm not using GitHub at the moment...is something pending to learn/setup).

Thank you in advance for the recommendations.

I've been working on a project called PatchOps : a small, reproducible environment for managing Linux patching through Ansible and AWX.

What Ansible/AWX does

• Ansible roles for Aptly, clients, governance DB and notifications
• Ansible playbooks for scanning, patching, promotion and rollback
• AWX handles scheduling, job history, credentials and orchestration
• Docker-based Execution Environment for consistent Ansible execution

There are also Grafana dashboards backed by PostgreSQL for fleet status, package upgrades, snapshots and patch history.

Everything runs on a single machine with Docker Compose, so it's reasonably easy to spin up a lab and experiment with the whole pipeline.

Blog: https://2ssk.medium.com/controlled-linux-patch-management

GitHub: https://github.com/2SSK/patchops

I'd particularly like feedback from people who use Ansible/AWX in production:

• Does this architecture make sense to you?
• What would you change about the AWX/Ansible side?
• Are there better patterns for handling patch promotion and rollback?
• What would you consider essential before calling something like this production-ready?

Hi all,

I'm in a doubt here what would be best practice to use. Both solutions work for me, though. Nevertheless, I'm learning and would like to satisfy my curiosity on this one.

I'm modifying the root crontab to run an rclone script every 4 minutes on my Mac.
With Ansible, I've created a play that used the ansible.builtin.cron and the results are exactly as any example is showing:

0 11 * * 1-5   <the jobs>

Boring and for some, not very obvious.

I also did the same this, but using ansible.builtin.blockinfile to make it look like this:

# Mins  Hours   Days    Months  WkDay
#=====================================
## rclone-sync - This job will run every Monday to Friday at 11 am
  0     11      *       *       1-5   <the jobs>

I know, if both ways work, choose to your liking. What would be the choice of the community and are there any pro's or con's on both methods?

Thank you for your comments in advance.

Has anyone install the self service portal alongside their AAP 2.6 instance? I understand that I will need a separate server for this, but the deployment seems...odd? I'm following the instructions here - https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.7/install-proc_self_service_install_kvm

I recently set up my first Ubuntu 26.04 VM, and the same become setup that worked in 24.04 doesn't seem to work anymore. It times out waiting for the sudo password prompt:

<testhost1.int> SSH: EXEC ssh -vvv -C -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=no -o 'IdentityFile="/Users/user/Repos/ansible/.config/ansible.key"' -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o 'User="ansible"' -o ConnectTimeout=10 -o 'ControlPath="/Users/user/.ansible/cp/60a45616b8"' testhost1.int '/bin/sh -c '"'"'sudo -H -S -p "[sudo via ansible, key=hvrkoxpcyrigyzsedwfokswksezxecco] password:" -u root /bin/sh -c '"'"'"'"'"'"'"'"'echo BECOME-SUCCESS-hvrkoxpcyrigyzsedwfokswksezxecco ; /usr/bin/python3'"'"'"'"'"'"'"'"' && sleep 0'"'"''
fatal: [testhost1.int]: FAILED! => {
    "msg": "Timeout (12s) waiting for privilege escalation prompt: "
}

From what I've read this is probably issue with the sudo-rs password prompt being a bit different which causes Ansible to miss it. If I change the Ansible user's sudo config to not require a password then everything works fine, which certainly makes that plausible.

I found this Github issue that makes it look like the prompt problem is solved long ago. The changelogs are difficult to navigate though. I found a changelog fragment for it, but I don't see that file or its text on any release branch, and even with ansible-core at version 2.19.12 Ansible misses the prompt.

So, should this work or not? And which Ansible version do I need?

EDIT (correction): As u/Practical_Board_1810 points out in the comments, on a stock EL9 install rsyslog is enabled and populates /var/log/secure, so the file-based setup works fine there — my original framing was too broad. The zero-parses gotcha applies to journald-only setups: minimal/cloud images, containers, or boxes where rsyslog is absent or disabled. journald acquisition works in both cases, which is why the role still defaults to it.

A few people in my fail2ban thread suggested CrowdSec for handling repeat offenders, so I moved my mail/web boxes over. Install went fine, services green — and a day later, cscli decisions list was empty while the box was visibly getting hammered.

The gotcha: RHEL 9 ships sshd logging to journald, not /var/log/secure. Most CrowdSec writeups are Debian-flavored and point file acquisition at paths that don't exist on EL9, so cscli metrics shows zero lines parsed and no scenario ever fires. The fix is a journald source:

# /etc/crowdsec/acquis.d/sshd-journald.yaml
source: journalctl
journalctl_filter:
  - "_SYSTEMD_UNIT=sshd.service"
labels:
  type: syslog

If cscli metrics shows 0 lines for sshd, you have this problem. "Service started" and "logs being parsed" are different claims — verify with metrics, not systemctl.

Second lesson, carried over from my fail2ban days: whitelist your own IP before the engine's first start, not after. CrowdSec replays logs on startup — my own flaky-VPN SSH retries from earlier in the week counted against me. A whitelist in /etc/crowdsec/parsers/s02-enrich/ does it:

name: my/admin-whitelist
whitelist:
  reason: "admin IPs"
  ip:
    - "YOUR.ADMIN.IP"

Two more EL9-specific notes: firewalld is nftables-backed, so use crowdsec-firewall-bouncer-nftables (the iptables one fights the native backend). And I keep a coarse GeoIP pre-filter (firewalld ipset + ipdeny zone files) in front so CrowdSec spends its cycles on the interesting attackers — just create the ipset with a bumped maxelem, because cn + ru together clear the 65536 default.

I packaged the whole thing — engine, nftables bouncer, journald acquisition, whitelist-first (the role hard-fails if you leave the placeholder IP), optional country blocking — into a small MIT role: https://github.com/arhab194/crowdsec-rhel

For those running CrowdSec: do you use the console/community blocklist or keep it purely local? Anyone been burned by the community list false-positiving a legit customer IP?

Hi all!

I've used Ansible many years ago to manage VMs and other cloud infra, stopped using it but recently rediscoverd Ansible to manage my local system.

Turned my past knowledge in a set of reusable Ansible roles with a simple CLI wrapper.

Do you mange your system in the same way? :)
Curious to hear your experiences and insights!

When a task depends on another how do you decide if you should use a handler or checking if the register was changed? Handlers run at the end unless you force them. Are there are other things you think about?