Linux - Software - Apply Updates With Exceptions File

What the exclusion-aware Linux patcher does

This Automox Worklet™ applies available software updates to Linux endpoints while honoring an exclusion list supplied as a policy payload file. The Worklet sources /etc/os-release to identify the distro, picks yum for the RHEL family (RedHat, CentOS, AlmaLinux, Rocky, Fedora, Amazon, CloudLinux, Oracle Linux Server) or apt for Debian and Ubuntu, then runs the native update command with the exclusions applied. Packages whose names appear in the payload file are skipped; every other available update lands.

On Debian and Ubuntu endpoints, the Worklet places an apt-mark hold on each excluded package, runs apt -y upgrade (or apt upgrade --dry-run in test mode), then runs apt-mark unhold on the same list to restore the previous state. On the RHEL family, it builds a yum command of the form yum -y update --skip-broken --exclude=pkg1 --exclude=pkg2 (one --exclude flag per excluded package). The script reads the exclusions one per line from the payload file referenced by the FILE variable (default ./exclusions.txt) and supports shell-style globs in the list, such as kernel*, httpd*, or openssl.

The remediation script ships with MODE='test' as the default so the first policy run prints the planned changes without applying them. Switch the MODE variable to 'prod' once the dry-run output matches the intended outcome. The Worklet echoes the exclusions list at the start of every run, so the activity log captures exactly which packages were held back on each endpoint.

Why patch with exclusions instead of patching everything

Blanket Linux updates are risky on fleets that depend on a specific kernel build, a custom-compiled library, a vendor-pinned database client, or a driver tuned for a particular hardware revision. A single yum -y update can quietly upgrade those packages along with everything else and break the next workload that touches them. Operations teams respond by deferring all updates until a validation cycle completes, which is what produces the unpatched-Linux backlog that surfaces on every security audit.

Pinning kernel, MySQL, or a vendor agent package while still patching everything else is a familiar Linux operational pattern, and the per-package exclude flag on yum and apt-mark hold on apt have to live somewhere. Apply this Worklet through the Linux patch policy so it reads the payload exclusions file and feeds the list into yum or apt on RHEL, CentOS, Ubuntu, and Debian endpoints from a single configuration. Security updates reach the endpoint quickly while the small set of pinned packages stays where the change-advisory board left them. Pair the patch run with a separate validation policy that handles the pinned packages on a slower cadence.

How exclusion-aware patching works

1. Evaluation phase: The evaluation script exits non-zero on every run, which flags the endpoint for remediation on each policy pass. Compliance posture is therefore set by the remediation script itself, which is idempotent: when no non-excluded updates are pending, yum and apt simply report nothing to do and the activity log records that result.

2. Remediation phase: The script sources /etc/os-release and sets PACKAGE_MGR to apt for Debian or Ubuntu, or yum for the RHEL family. It reads the exclusions payload file line by line. For apt-based systems it runs apt-mark hold on each excluded package, then apt -y upgrade (or apt upgrade --dry-run when MODE='test'), then apt-mark unhold to clear the holds. For yum-based systems it composes yum -y update --skip-broken with one --exclude flag per package read from the file, and runs eval against the composed command. Test mode prints the planned command without applying it.

Linux patch exclusion requirements

• Linux endpoint running Debian, Ubuntu, RedHat, CentOS Linux, AlmaLinux, Rocky, Fedora Linux, Amazon Linux, CloudLinux, or Oracle Linux Server with /etc/os-release populated

• Root or sudo privileges for the Automox agent (the default agent context already meets this) to run apt, apt-mark, or yum

• An exclusions text file attached to the policy as a payload, with one package name per line (shell-style globs such as kernel*, httpd*, openssl are supported). The remediation script reads it from the path set in the FILE variable, which defaults to ./exclusions.txt

• MODE variable in the remediation script set to 'prod' for production rollouts; the script ships with MODE='test' so the first run is a dry-run that prints the planned command

• Network access from the endpoint to its configured package repositories; pre-stage an internal mirror for air-gapped or bandwidth-constrained sites

• Awareness that holding a package can block dependency upgrades for non-excluded packages on apt-based endpoints; if an excluded package is a dependency of a security update, the security update will be skipped along with the held package

Expected Linux state after patching

After a successful production-mode run, every non-excluded package on the endpoint is at its latest available version from the configured repositories. Excluded packages retain their previous version. On apt-based endpoints the hold state is cleared at the end of the run, so the next policy can change its scope by editing the payload file alone. The activity log captures the exclusions list, the package manager's full output, and the script's exit status.

Validate on a single endpoint by running rpm -qa or dpkg -l before and after the policy and confirming the version changes match the package manager output. For audit evidence, capture both package lists with the policy run identifier and store them with the change-management ticket. If an excluded package upgraded anyway on an apt-based endpoint, the most common cause is that apt-mark hold did not survive a dist-upgrade or a transitive dependency update bumped the version; review /var/log/apt/history.log and /var/log/dpkg.log to confirm the upgrade path.