Custom Yum Rpm Repo Install

What the yum RPM deployer does

This Automox Worklet™ deploys a single RPM package to Linux endpoints by pulling it from the yum repositories already configured on each host. You set one variable in remediation.sh, schedule the policy, and the Worklet handles the install across every endpoint in scope.

The Worklet reads REQUIRED_PKG from the script (for example, REQUIRED_PKG="mod_ssl") and uses rpm -qa to check whether that package is already on the endpoint. When the package is absent, the script runs yum install "${REQUIRED_PKG}" -y -q to perform an unattended, quiet install. When the package is present, the script logs the existing version and exits 0 so the policy run reports compliant.

Because the package is pulled from the endpoint's existing /etc/yum.repos.d/ configuration, you never upload an RPM file to Automox. The Worklet works with vendor repositories, internal mirrors, EPEL, Extras, and any custom .repo file already trusted by the host. Yum handles dependency resolution and GPG signature verification using the rules each .repo file defines.

Why deploy RPM packages from yum repositories

Repository-driven installs are the cleanest path for shipping software to RHEL-family endpoints. Yum resolves dependencies against the full repository graph, applies the GPG keys already imported into the rpm database, and writes a transaction record that survives reboots and audits. Uploading a one-off RPM bypasses all of that and forces you to recreate dependency chains by hand. Internal tooling, vendor agents such as Falcon or Datadog, and third-party RPMs like mod_ssl or git-lfs all ship cleanly through this pattern once the repo is in place.

Repo-driven rollouts also align with CIS Benchmarks and STIG guidance for RHEL-family systems, which call out specific packages (chrony, audit, openscap-scanner) that must be installed and tracked through rpm. A scheduled policy run captures the exit code on every endpoint and surfaces drift on servers, VMs, and container hosts that lag a slow patch window, so the audit evidence sits in rpm transaction history rather than in admin notes.

How yum RPM deployment works

1. Evaluation phase: The evaluation.sh script exits 1 unconditionally. This design forces every targeted endpoint into remediation, where the actual presence check runs. The script is intentionally minimal because the remediation script does the rpm query and the install in a single transaction.

2. Remediation phase: The remediation.sh script runs PKG_OK=$(rpm -qa | grep "${REQUIRED_PKG}") to detect the package. If PKG_OK is empty, the script runs yum install "${REQUIRED_PKG}" -y -q and exits 0 on success or 1 on a yum failure. If the package is already installed, the script echoes the matching rpm record and exits 0 so Automox marks the endpoint compliant.

Yum RPM deployment requirements

• Linux endpoint running RHEL, CentOS, Rocky, Alma, Fedora, or another distribution that ships /usr/bin/yum

• Root or sudo privileges for the Automox agent (the default agent context already meets this)

• Network reachability from the endpoint to the repository host listed in /etc/yum.repos.d/

• The target package available in at least one enabled .repo file on the endpoint, with the matching GPG key imported into rpm

• Set REQUIRED_PKG in remediation.sh to the exact package name yum search returns (for example, REQUIRED_PKG="mod_ssl" or REQUIRED_PKG="falcon-sensor")

• For repositories not yet present on the fleet, run a repository-enforcement Worklet first so /etc/yum.repos.d/ contains the source before this policy executes

Expected state after RPM deployment

The named RPM is installed at the version selected by yum from the enabled repositories. Running rpm -q ${REQUIRED_PKG} on the endpoint returns the package name, version, release, and architecture (for example, mod_ssl-2.4.37-65.module+el8.10.0+22842+a4cd6027.x86_64). The yum history command shows a new transaction record with the install action, the user (root), and a timestamp matching the Automox policy run.

Service-providing packages such as mod_ssl drop their configuration files under /etc/ on first install but do not start a daemon. If your standard requires the service running, schedule a companion Worklet that runs systemctl enable --now <service> after this policy succeeds. For agent RPMs like falcon-sensor, the vendor post-install scriptlet typically handles registration; verify with systemctl status <service> and the vendor console once the install lands.

Subsequent runs of the policy report compliant without re-running yum install, because rpm -qa already shows the package. If an administrator removes the RPM with yum remove, the next evaluation flags the endpoint and the Worklet re-installs it. Capture rpm -qi ${REQUIRED_PKG} output alongside the Automox policy run identifier for audit evidence; the install date, source repository, and signing key fingerprint are all in that record.