Replacing Aria Automation Config with VMware Salt (Single-Node) in My Homelab

A couple of years ago I ran SaltStack Config (later rebranded Aria Automation Config) in my homelab for automated Linux patching. For various reasons, I stopped maintaining it and reverted to rather infrequent, manual patching. Recently I decided it was time to get back into automated patching. My old Salt deployment had been neglected for some time so instead of just restarting it, I decided to setup VMware Salt (the productized version included in the Advanced Cyber Compliance addon), from scratch.

Picking a deployment model

VMware Salt supports a few deployment topologies. For a homelab, the choice was easy: the single-node (all-in-one) model, where the Salt Master, Salt RaaS server (including Postgres and Valkey/Redis), all run on one VM. It’s the simplest option to stand up since there’s only one VM, but it’s worth knowing the trade-offs before you commit to it even for a lab:

• Everything competes for the same CPU/RAM/disk I/O, so it can bog down under heavy load (lots of minions, frequent jobs)
• It’s a single point of failure and a single attack surface
• VMware explicitly does not consider this a production-grade topology; it’s meant for PoC, testing, and small labs

For a homelab with a modest minion count, that’s a completely reasonable set of trade-offs. If you’re planning something larger, look at the Basic Enterprise or Distributed Enterprise models instead. Details about each option can be found in the official documentation.

Building the VM

The documentation specifically calls out support for Red Hat Enterprise Linux (RHEL) 9. I built the target VM on Rocky Linux 9.8, using the template created in this post. Rocky Linux is an open-source enterprise operating system designed to be 100% bug-for-bug compatible with Red Hat Enterprise Linux. I then installed some prerequisites called out in the documentation, and enabled persistent firewall rules using the following commands:

sudo dnf install python3 python3.11-devel
sudo dnf config-manager --set-enabled crb
sudo dnf install epel-release
sudo dnf install libsodium

firewall-cmd --zone=public --add-service=https --permanent
firewall-cmd --zone=public --add-port=4505-4506/tcp --permanent
firewall-cmd --reload

Installing VMware Salt

With prerequisites in place, I extracted the installer and ran the single-node setup script:

tar -xzf VMware_Salt_RaaS-8.18.3-25253633.el9_Installer.tar.gz
cd sse-installer
./setup_single_node.sh

Licensing

After installing, I noticed a warning banner that the license would expire soon (2 weeks). I added a license key using the following command:

echo "<your-license-key>" > /etc/raas/vra_license && chown raas:raas /etc/raas/vra_license && systemctl restart raas

Replacing the default SSL cert

By default, the web UI ships with a self-signed certificate (localhost.crt/localhost.key). I don’t like clicking the ‘continue anyway’ link every time I access a ‘secure’ page in my lab, so I generated a proper CSR, got it signed, and swapped it in:

cd /etc/pki/raas/certs/
vi cm-vcfsalt-01.crt  # <press i & paste cert contents>
vi cm-vcfsalt-01.key  # <press i & paste key contents>
chown raas:raas cm-vcfsalt-01.crt cm-vcfsalt-01.key
chmod 400 cm-vcfsalt-01.crt cm-vcfsalt-01.key

Then point /etc/raas/raas at the new files by editing the tls_crt and tls_key properties and restart the raas service:

tls_crt: /etc/pki/raas/certs/cm-vcfsalt-01.crt
tls_key: /etc/pki/raas/certs/cm-vcfsalt-01.key
systemctl restart raas

Accepting the master key

Last step for a fresh install: log in to the web UI, go to Administration –> Master Keys (or use the “pending master keys” banner), and accept the default master key so minions can actually check in.

The next post will cover repointing existing salt minions from the old master to this new one.