Posted: 2026-01-11
Ansible and Rex are both configuration management tools, which are nice for automating consistency in infrastructure deployments.
If you have to deploy ten servers, and each need the same, or a slightly different configuration, it's often worth codifying this with one tool or another.
I've used Puppet a fair bit, took a short class on Chef, used Salt fairly extensively, have used Ansible for a while now, and finally I'm trying out Rex.
To be honest, I can barely remember Chef or Puppet. I used Puppet over 10 years ago. The Chef class was before that. I remember Puppet worked fine for what we needed it for, and had some nice configuration merging functionality between environments.
For the past 10 years, I've worked with deployments too small to warrant agents, using just SSH configuration. I've been writing configuration managent for Debian, Ubuntu, FreeBSD, and OpenBSD.
This post is about Ansible vs Rex, but I want to quickly cover Salt as I know it well enough to speak on. It works great and is very fast, especially with an agent. The biggest issue I had with it was a lack of support in recent years. It wouldn't run on the newer Python versions. I think this may have been partly over less developers using Salt. In some ways, configuration management is a little bit of a "dated" technique compared to containers and Terraform-type options.
I've ended up with a dedicated server to run Salt on (just with SSH agents) more than once, because of one breakage or another. And aside from just Python code compatibility, there's been one or two serious bugs that prevented it from running. Still, most of the time it worked well, and I still have some legacy Salt.
Ansible is generally considered leaner than Salt. I don't know if that's true, but it's meant to be agentless, which makes sense for me. It's well documented, has never broken on me. I think it's better supported than Salt, and is often the "go to" option in the space.
I'm very new to Rex and Perl as well. In some ways, this could be a Perl vs Python comparison.
As a seasoned Python developer, I'm quite comfortable with it already. I assumed Perl was dated and pointless for a long time, as well as hard to read. While some Perl is hard to read, I am starting to come around to it.
I've also noticed the OpenBSD space really embraces Perl, and some have mentioned Rex. I've generally found that the OpenBSD way makes sense once you start to use it, even if it feels about 10-20 years "behind." As such, I felt it was worth giving Perl a try and Rex.
I wanted to do a fair, but small comparison between Rex and Ansible.
I've currently had logic in Ansible for setting up the SlowServers DNS slaves: freya.ssvr.net, ceto.ssvr.net, ate.ssvr.net, and eos.ssvr.net.
All this does is install a NSD configuration file, which is lightly templated, and if it changes, reloads NSD. It also makes sure NSD is enabled, and enables it if not.
So on cold runs, where a reload is required, I saw execution taking about 20 seconds for Rex on one host, or 40 seconds on Ansible whether one host or all four. Rex with four hosts worked out to be about 100 seconds, with about 40 seconds spend on just eos.ssvr.net, which has a lot higher latency.
I'm still not sure why eos.ssvr.net is so much slower. It's at least twice as slow as others. I am not familiar with Rex internals enough to know why this is, or if there's another component to it.
I'm also new enough to Rex that I may be missing some simple tuning. Rex has a -b batch mode option that I can't figure out. There's no documentation on it, that I can find anyway. Maybe it runs hosts in parallel, and then Rex could be as fast or faster than Ansible?
One thing I've noticed is that Rex is slower host-by-host, but Ansible is slower task-by-task. So if you have more than 3 tasks, Rex might start looking much faster than Ansible.
So far, Rex has been pretty easy for me to learn. And Perl, for that matter. I don't think it's as clean as Python, in a lot of ways. It has a bit more of a Unix/systems feel to it, versus the genericness of Python. For me, the lower level aspect isn't confusing, so I may be picking it up faster than I would otherwise.
As my first real Perl script, I wrote 'debbiedowner.pl'. It's a basic monitoring agent. I know my Perl is not good, and there's lots of room for improvement. But what I found is that there was a library for all sorts of stuff ready to go. It may have not been updated in 10 years, but they worked fine. Perl really reminds me of one of OpenBSD's reigning themes: Don't fix it if it isn't broken.
This script came together pretty quickly. It does ICMPv4 + ICMPv6 monitoring. Tor+Gemini, Tor+HTTP, HTTPS, Gemini, and DNS SOA. This lets me make sure the DNS slaves are in sync with the master. It also validates Gemini fingerprints.
It runs every minute, and runs on three different servers. One of them writes this data out for display on status.slowservers.net.
For not knowing Perl at all, this came together rather fast and works quite well. I haven't tuned it much, but it's fast enough for what I need it to do.
I am certainly impressed with Perl. I think the language may be inferior in some ways, and it's certainly less actively developed, but it reminds me of a 30 year old Honda Civic in the shed. It still runs and drives even if people aren't ooing and awwing over it.
Python is by no means "too heavy" for much of the modern era of computing, or even anything in the past 15 years. So maybe Perl's lightness doesn't matter for most. But lightness, all things being equal, is prreferable in my opinion.
I'm disappointed that I've tried to avoid Perl so extensively in the past couple of decades, where I could have been benefitting from it. It really is a good tool for certain jobs, at a minimum.
Thank you for reading!