Custom Yum Rpm Non Repo Install

What the custom RPM URL installer does

This Automox Worklet™ downloads an RPM package from a URL you configure and installs it on the target Linux endpoint with rpm -i. The remediation script reads a single INSTALLER_URL variable, derives the filename from the path, fetches the package into /tmp/, and hands it to the rpm binary with the --quiet flag. There is no repository registration, no yum metadata refresh, and no dependency on dnf or zypper being on PATH.

The Worklet is built for the cases standard package managers cannot cover. A vendor that ships a single signed .rpm from their download page (Google Chrome, Zoom, Microsoft Teams, AnyDesk, Splunk Universal Forwarder), an internal artifact server that hosts proprietary builds, or a one-off hotfix RPM dropped on an S3 bucket. In each case, registering a full yum repository is overkill and the operator just needs the package on the endpoint.

Because the install runs with rpm -i (not rpm -U), the Worklet performs a fresh install rather than an upgrade. If the package is already present at the same version, rpm exits with a conflict and the script logs "Installation failed" to the Automox activity log. Plan upgrades as a separate Worklet that pairs rpm -U with a version check, or wrap this script with an rpm -q guard before re-running it on the same fleet.

Why deploy RPM packages from a URL

Not every Linux package lives in a repository the fleet trusts. Vendor download pages, internal artifact stores, and CI-built hotfix RPMs all bypass yum and dnf metadata, so the operator is left with three options: SSH to each endpoint and run wget plus rpm by hand, build a repository wrapper around a single file, or stage the package through Automox. The first does not scale past a handful of hosts. The second adds overhead the vendor never asked for. The third is what this Worklet does.

Point INSTALLER_URL at the target .rpm and schedule this Worklet against a Linux server or workstation group; the package lands on every endpoint in the next evaluation window with a logged exit code per host. The same approach handles off-repository deployments at scale: vendor hotfix RPMs, internally signed agents, and CI-built artifacts all flow through one policy without standing up a repository wrapper or running wget against each host by hand.

How the URL-based RPM install works

1. Evaluation phase: The evaluation script exits non-zero on every run, which flags the endpoint as non-compliant and queues the remediation phase against any policy schedule. This design is intentional for a single-use install: the Worklet treats every target endpoint as needing the package, and the remediation script’s own rpm -i call handles the no-op case by failing the install when the package is already present. If you need idempotent behavior, replace evaluation.sh with an rpm -q <package-name> check that exits 0 when the package is found.

2. Remediation phase: The remediation script reads INSTALLER_URL, computes FILENAME="${INSTALLER_URL##*/}", and downloads the file with wget "${INSTALLER_URL}" -O /tmp/"${FILENAME}". On a successful download, it runs rpm -i /tmp/"${FILENAME}" --quiet. If the install succeeds, the script echoes "Successfully installed ${FILENAME}" and removes the temporary file with rm -f. If wget fails, it logs "Failed."; if rpm -i fails, it logs "Installation failed". All output lands in the Automox activity log for the run.

URL-based RPM install requirements

• RPM-based Linux endpoint: RHEL, CentOS, Rocky, Alma, Fedora, Oracle Linux, Amazon Linux, or openSUSE with the rpm binary on PATH

• wget installed on the endpoint (most enterprise distributions ship it by default; on minimal images install with yum install -y wget or dnf install -y wget)

• Network reachability from the endpoint to the URL host; HTTPS endpoints with valid TLS certificates avoid the wget --no-check-certificate footgun

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

• Set INSTALLER_URL in remediation.sh to the full URL of the .rpm file (for example https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm)

• If the RPM is signed by a third-party vendor and the endpoint has gpgcheck enabled, pre-import the vendor GPG key with rpm --import <key-url> in a companion Worklet before scheduling this one; otherwise rpm -i will refuse the package with NOKEY

• Free space in /tmp/ at least equal to the size of the downloaded RPM; on hardened endpoints with noexec on /tmp, redirect FILENAME to /var/tmp/ instead

Expected state after the URL-based RPM install

On a successful run, the package is registered in the local rpm database and visible to standard tools: rpm -qa | grep <package-name> returns the installed version, rpm -qi <package-name> shows the full package metadata, and rpm -ql <package-name> lists the files the package wrote to disk. The temporary download in /tmp/ is removed by the script. Automox activity log captures the wget output, the rpm exit code, and the success or failure message for that endpoint.

Validate by querying the rpm database with rpm -q <package-name> on a sample of endpoints and confirming the version matches the binary you hosted at INSTALLER_URL. For audit evidence, capture the rpm -qi <package-name> output alongside the Automox policy run identifier. If the package contains an executable, run it once to confirm the install is complete; some vendor RPMs ship %post scripts that require a second login or a service restart before the binary is available on the user’s PATH.

If a later run needs to upgrade or replace the package, pair this Worklet with an rpm -e <package-name> uninstall step or switch the remediation to rpm -U for an upgrade-or-install pattern. Removing the binary alone does not deregister the package from rpm; always go through the rpm tooling so the database stays consistent with what is on disk.