Add Repository

What the Linux repository enforcer does

This Automox Worklet™ enforces the presence of a designated package repository on Linux endpoints. The Worklet inspects the endpoint to determine which package manager is installed, queries the currently enabled repository set, and adds the target repository when it is absent. Repositories already configured are left untouched, so the policy is safe to run on a mixed fleet.

On RHEL, CentOS, Rocky, Alma, and Fedora endpoints, the Worklet drives yum-config-manager (with the --enable flag applied after --add-repo) or dnf config-manager to register the repository URL. On Debian and Ubuntu endpoints, it uses add-apt-repository, which handles both PPA shortcuts such as ppa:ansible/ansible and full deb URI lines. The scripts read two variables defined inside the Worklet: aptOrYum (set to apt or yum) and repo (the repository identifier or URL).

Evaluation is idempotent, so the Worklet can run on a recurring policy to keep the repository pinned after a build script, image refresh, or manual edit removes it. The evaluation script exits 1 only when the repo identifier is missing from the active list, so endpoints already carrying the repository skip remediation entirely.

Why standardize repositories at fleet scale

Repository drift undermines patching. Engineering teams add vendor repositories to individual workstations, build pipelines bake repositories into golden images that diverge from production, and security teams add internal mirrors that never reach older endpoints on legacy provisioning pipelines. When a CVE patch requires every Linux host to carry the same vendor repository, admins discover the gaps only after updates start failing.

Configuration drifts every time someone drops a one-off .repo file, a container image refresh ships an older sources.list, or an in-place upgrade resets /etc/apt or /etc/yum.repos.d. Apply this Worklet through your Linux baseline policy and the same repository definition lands in the correct directory on RHEL, CentOS, Rocky, Alma, Ubuntu, and Debian endpoints from one variable set. Subsequent evaluations reassert the entry so dnf or apt pulls from a vetted mirror instead of the distribution default or a stale internal source.

How repository enforcement works

1. Evaluation phase: The Worklet tests for /usr/bin/yum first, then /usr/bin/apt-get, to identify the package manager. On RPM endpoints it captures the output of yum repolist enabled. On Debian endpoints it runs grep -rhE ^deb /etc/apt/sources.list* to collect every active deb entry from /etc/apt/sources.list and /etc/apt/sources.list.d/. The collected text is searched for the configured repo identifier; if it is not present, the script exits 1 and Automox schedules remediation.

2. Remediation phase: The remediation script branches on the aptOrYum variable. For yum, it prefers /bin/yum-config-manager and runs yum-config-manager --add-repo <repo> followed by yum-config-manager --enable <repo>; if that binary is absent, it falls back to /usr/bin/dnf with dnf config-manager --add-repo <repo>, which writes a .repo file into /etc/yum.repos.d/. For apt, it runs add-apt-repository --yes --update <repo>, which adds a .list file under /etc/apt/sources.list.d/ and refreshes the package index. The next scheduled evaluation reasserts compliance.

Repository enforcement requirements

• Linux endpoint running RHEL, CentOS, Rocky, Alma, Fedora, Debian, or Ubuntu with yum, dnf, or apt available

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

• Network reachability from the endpoint to the repository host (PPA launchpad, vendor URL, internal mirror)

• Set the repo variable in evaluation.sh (line 29) to the repository identifier the policy should check for

• Set aptOrYum (apt or yum) on line 35 of remediation.sh and repo on line 36; for apt, repo accepts either a ppa: shortcut or a full deb URI; for yum, repo accepts a repository URL

• On yum endpoints, /bin/yum-config-manager (from yum-utils) or /usr/bin/dnf must be installed; the script prefers yum-config-manager and falls back to dnf

• For signed third-party repositories, pre-stage the GPG key or run apt-key/rpm --import in a companion Worklet before scheduling this one

Expected state after repository enforcement

On RPM endpoints, a new .repo file appears in /etc/yum.repos.d/ with enabled=1, and yum repolist enabled shows the repository in the active set. On Debian endpoints, a .list file appears under /etc/apt/sources.list.d/ and apt-cache policy reflects the new origin. Subsequent policy runs report the endpoint as compliant without applying remediation again, because the evaluation grep or yum repolist already finds the repo identifier.

Validate by running yum search <package> or apt-cache search <package> against a package known to live only in the new repository, then attempting a dry-run install (yum install --downloadonly or apt-get install --simulate). For audit evidence, capture the contents of /etc/yum.repos.d/<repo>.repo or /etc/apt/sources.list.d/<repo>.list and store them alongside the policy run identifier. The repository persists across reboots and kernel upgrades; it is only removed if an administrator deletes the underlying .repo or .list file, at which point the next evaluation flags the missing identifier and the remediation script writes the definition back.