Custom Apt Dpkg Non Repo Install

What the external .deb deployer does

This Automox Worklet™ deploys a single .deb package to Debian and Ubuntu endpoints from an external URL. The Worklet pulls the file with wget, hands the local path to apt-get install, and removes the temporary download once the install succeeds. No permanent entry is written to /etc/apt/sources.list.d/, so the endpoint's apt source list stays exactly as it was before the policy ran.

The script targets the full apt/dpkg family: Ubuntu LTS releases, Debian stable and oldstable, Linux Mint, elementary OS, and any other derivative that ships the apt-get binary. Because apt-get install resolves dependencies against the existing repository cache, vendor packages that declare Depends: on libc6, libssl3, or other base libraries install cleanly without the broken-dependency errors that plain dpkg -i produces.

Set the INSTALLER_URL variable at the top of remediation.sh to the full HTTPS URL of the .deb file you want to deploy. The Worklet derives the filename from the URL using bash parameter expansion (FILENAME="${INSTALLER_URL##*/}"), so a URL ending in 1password-latest.deb becomes /tmp/1password-latest.deb on the endpoint.

Why deploy .deb packages without a permanent repository

Many vendor installers ship as standalone .deb files rather than apt repositories. 1Password, Slack, Zoom, Microsoft Teams, Postman, and the major browser builds all publish direct .deb downloads alongside their repository builds. Adding a repository for every one of these vendors bloats /etc/apt/sources.list.d/, creates new dependencies on third-party signing keys, and gives each vendor a standing channel to push updates the change-control board never reviewed.

A direct .deb deployment keeps the apt source list lean and leaves update timing under your control. URL-driven deployments also fit short-lived rollout windows: a new VPN client, EDR agent, or compliance shim can land on every Debian or Ubuntu endpoint in scope inside a single maintenance window, with the activity log capturing the exit code per host. When a vendor publishes a hotfix .deb out-of-cycle, the same Worklet redeploys against the updated URL without touching the apt source list or rebuilding the gold image.

How external .deb deployment works

1. Evaluation phase: The evaluation script exits 1 unconditionally. By design, this Worklet treats every policy run as a deployment opportunity rather than a state check, because the source of truth is the INSTALLER_URL variable rather than an installed-package version. Pair the Worklet with a scope filter (group membership, OS tag, or compliance label) so only the intended endpoints are targeted, and schedule the policy as one-time if you do not want re-runs.

2. Remediation phase: The remediation script runs wget "${INSTALLER_URL}" -O /tmp/"${FILENAME}" to fetch the package, then runs apt-get -y install /tmp/"${FILENAME}" --quiet, which performs the dpkg install and resolves any declared dependencies through the existing apt cache. On a successful install, the script logs "Successfully installed ${FILENAME}" and removes the temporary file with rm -f. If wget fails, the script logs "Failed." and apt-get is never invoked; if the install itself fails, it logs "Installation failed" so the activity log surfaces the cause.

External .deb deployment requirements

• Linux endpoint running an apt/dpkg-based distribution: Ubuntu (16.04 LTS and later recommended), Debian 10 or later, Linux Mint, elementary OS, or another derivative with apt-get available

• wget installed and resolvable on $PATH; most server and desktop images include it by default, but minimal containers may need apt-get install -y wget first

• apt-get version 1.1 or later, the first release that accepts a local .deb file path as the install target and resolves its dependencies (Debian 9, Ubuntu 16.04, and newer all qualify)

• Root or sudo execution context; the Automox agent runs as root by default, so no additional configuration is needed

• Outbound HTTPS reachability from the endpoint to the INSTALLER_URL host (vendor CDN, internal artifact server, or signed S3 bucket)

• At least 2x the .deb file size of free space on /tmp, since the package lives there for the duration of the apt-get install run

• Set INSTALLER_URL at the top of remediation.sh to the full HTTPS URL of the .deb file before scheduling the policy. The commented sample line in the script points at the 1Password Linux download as a reference

Expected state after .deb deployment

Once the Worklet exits 0, the package is registered in the dpkg database and behaves like any other apt-managed install. Run dpkg -l | grep <package> to confirm the package name and version, or run apt-cache policy <package> to see the Installed and Candidate fields. Files placed by the package are listed under dpkg -L <package>, and the systemd unit (if the package ships one) is enabled or started according to the maintainer scripts inside the .deb.

The /tmp directory is left in its original state after a successful run; the temporary .deb is removed by rm -f and no stray files remain. For audit evidence, capture the activity log line that contains "Successfully installed ${FILENAME}" alongside the policy run identifier, and store the output of dpkg-query -W -f='${Package} ${Version} ${Status}\n' <package> from a sample endpoint. Subsequent runs of the same policy will re-download and re-install the package, because the evaluation phase always returns non-zero. Restrict re-runs by scheduling the policy as one-time, or by removing the Worklet from the scope once the deployment is complete.