Custom Apt Dpkg Repo Install

What the apt package deployer does

This Automox Worklet™ installs a single named package on Linux endpoints that use the apt and dpkg toolchain. You set the package name once in the REQUIRED_PKG variable at the top of remediation.sh. On each run, the Worklet asks dpkg whether that package is already installed and calls apt-get when it is not.

Debian, Ubuntu, Raspbian, Linux Mint, and other Debian-derived distributions are all in scope. The Worklet uses whichever repositories are listed in /etc/apt/sources.list and the files under /etc/apt/sources.list.d/. That covers upstream distribution mirrors, vendor repositories from Microsoft, Google, or HashiCorp, internal apt mirrors, and PPAs added earlier in the build pipeline.

The remediation script handles both the check and the install in a single transaction, then exits 0 on success or 1 with "Install failed." written to stderr. Failures surface in the Automox activity log instead of going silent, so you can spot the unreachable repository, missing GPG key, or typo without logging into the endpoint.

Why distribute apt packages through Automox

Most Linux fleets carry at least one package that has to land on every endpoint: an EDR agent, a monitoring collector, a VPN client, a security scanner, an SSH hardening package, or a developer toolchain. Hand-rolling that rollout with SSH loops, Ansible ad-hoc commands, or shell scripts breaks down the moment the fleet crosses a few dozen hosts. Off-network laptops miss the run, build images drift from production, and the audit team has no clean evidence that the package is installed everywhere.

This Worklet replaces the SSH loop with a policy that targets every Debian-based endpoint Automox manages. The dpkg check is idempotent, so the policy is safe to schedule on a recurring cadence. Endpoints that already have the package report success in seconds. Off-network laptops, dormant servers, and freshly imaged hosts pick up the install the next time they check in.

Standardized package installs also support compliance evidence. CIS Benchmarks for Debian and Ubuntu call for specific security packages such as auditd, aide, and rsyslog to be present on every host. A scheduled run of this Worklet against the relevant package list produces a fleet-wide artifact showing which endpoints reported installed and which reported a failure, with no manual spreadsheet reconciliation.

How apt package deployment works

1. Evaluation phase: evaluation.sh exits 1, so every targeted endpoint is queued for remediation. The actual install check runs inside the remediation script, which means you do not need to mirror the package name into a second file.

2. Remediation phase: The remediation script runs dpkg-query -W --showformat='${Package} Version ${Version} ${Status}\n' "$REQUIRED_PKG" and greps for the literal string "install ok installed". When that string appears, the script echoes the dpkg line and exits 0. When it does not, the script calls apt-get -y install "${REQUIRED_PKG}", which resolves dependencies against /etc/apt/sources.list and /etc/apt/sources.list.d/ and pulls every transitive package in one transaction. A clean install exits 0; a non-zero return from apt-get writes "Install failed." to stderr and exits 1.

Apt package deployment requirements

• Linux endpoint running Debian, Ubuntu, Raspbian, Linux Mint, or another Debian-derived distribution with apt-get and dpkg available on the default PATH

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

• The target package must exist in at least one repository listed under /etc/apt/sources.list or /etc/apt/sources.list.d/, and the GPG signing key for that repository must already be trusted

• Network reachability from the endpoint to the repository host, whether that is an internal apt mirror, a vendor URL, or a PPA on launchpad.net

• Set REQUIRED_PKG at the top of remediation.sh to the exact package name apt would accept (for example, openvpn, nginx, or mdatp)

• Sufficient free disk space on /var and /usr for the package, its dependencies, and the apt cache footprint

• If the target package lives in a third-party repository that the endpoint does not yet trust, pre-stage the source list and signing key with a companion Worklet before scheduling this one

Expected endpoint state after deployment

On every endpoint that completed remediation, dpkg-query -W "$REQUIRED_PKG" returns a row whose Status field reads "install ok installed". The binaries shipped by the package appear under their normal locations such as /usr/bin, /usr/sbin, or /opt. Service units packaged with systemd integration are registered but are not started by this Worklet. If the package owner expects the service to be running, schedule a follow-up Worklet that calls systemctl enable --now <service>.

Validate a sample of endpoints by running dpkg -l | grep "$REQUIRED_PKG" and apt-cache policy "$REQUIRED_PKG" from a shell. The first confirms installed state and version. The second confirms which repository served the package, which is useful audit evidence when the policy is meant to standardize on an internal mirror rather than the public Debian or Ubuntu archive. Capture both outputs alongside the Automox activity log entry for the policy run when you need a clean compliance artifact.

Endpoints that already had the package installed at remediation time skip the apt-get call and report exit 0 with the dpkg-query line written to the activity log. Endpoints that fail report exit 1 with "Install failed." on stderr. The usual causes are an unreachable repository host, a missing or expired GPG key, a typo in REQUIRED_PKG, or a dependency conflict from a partially upgraded distribution. Fix the underlying cause and re-run the policy; the Worklet converges on the desired state without further input.