Linux - Maintenance Tasks - Upgrade Automox Agent

What the Automox Agent upgrade Worklet does

This Automox Worklet™ upgrades the Automox Agent on Linux endpoints by uninstalling the running version and installing the latest release published to the Automox console. The Worklet handles RPM-based distributions (RHEL, CentOS, Rocky, Alma, Fedora) and DEB-based distributions (Ubuntu, Debian). Each path uses the native package manager so the upgrade leaves a clean package database and the same agent identity behind.

The evaluation script reads the latest agent_version from https://console.automox.com/api/info and compares it against the output of /opt/amagent/amagent version on the endpoint. When the versions match, the Worklet exits 0 and logs that the endpoint is already on the latest release. When they differ, or when the installed version cannot be parsed (older agents predating the version subcommand), the Worklet exits 1 and remediation runs.

Remediation does not replace the agent in-process. Stopping amagent mid-policy would orphan the run and leave the endpoint stuck mid-upgrade. The Worklet instead writes three short shell scripts into /var/tmp and schedules them as root crontab entries one, three, and five minutes in the future. Cron drives the uninstall, the reinstall against the `accesskey` secret you provide on the policy, and the cleanup of the temporary files and crontab lines. By the time the new agent checks in, every artifact from the upgrade is gone.

Why keep the Linux agent on the latest release

An out-of-date Automox Agent is a quiet failure mode. The endpoint still appears in the console, still answers a ping, and still claims to be managed, but a known policy bug, a deprecated API surface, or a missing TLS cipher in the older build can silently drop the host out of a patch window. Agent releases also carry security fixes for the agent itself, package manager interaction fixes for newer distro releases, and support for newer Automox features. Pinning a fleet to a stale agent makes every other Worklet less reliable than the version drift report suggests.

Stale Automox agents are how patch policies silently stop reporting on the Linux servers that need them most. This Worklet checks the installed amagent version on each endpoint, compares it against the current release advertised by the Automox console, and runs the distro-correct package manager command to bring the agent forward. Schedule it on a recurring Linux policy and version drift closes before it turns into a patch SLA miss or a console support ticket.

How the agent self-upgrade works

1. Evaluation phase: The script curls https://console.automox.com/api/info, parses the agent_version field, and stores it as the target version. It then runs /opt/amagent/amagent version with a five-second timeout to read the installed version. If the installed value parses and matches the target, the Worklet exits 0 with the message "This system is already using the latest version of the Automox Agent." If the values differ, or the installed binary returns nothing parseable (an older agent without the version subcommand), the Worklet exits 1 and remediation is queued.

2. Remediation phase: The remediation script re-confirms the installed and target versions, then detects the package manager. The RPM path runs when yum is on $PATH and the DEB path runs when apt-get is on $PATH. The Worklet writes three scripts into /var/tmp: uninstall_automox_agent.sh runs `service amagent stop`, `/opt/amagent/amagent --deregister`, and either `yum -y --setopt=tsflags=noscripts --noautoremove erase amagent` or `apt-get purge amagent -y`; install_automox_agent.sh pipes the installer from https://console.automox.com/downloadInstaller?accesskey=$accesskey into bash and runs `systemctl restart amagent`, registering the new agent under the same zone identity; automox_reinstall_worklet_cleanup.sh removes the temporary files and the crontab entries. The Worklet then snapshots the current root crontab, appends the three jobs at T+1, T+3, and T+5 minutes, and reinstalls the crontab. The Worklet exits, and cron carries out the upgrade on its own clock.

Linux agent upgrade requirements

• Linux endpoint running Automox Agent 1.40.0 or newer (older agents are still upgraded, but the evaluation cannot read a version string from them and treats the endpoint as non-compliant)

• One of the supported package managers in $PATH: yum (RHEL, CentOS, Rocky, Alma, Fedora) or apt-get (Ubuntu, Debian). The script branches on `command -v yum` first, then `command -v apt-get`; dnf-only and zypper-only hosts are not on a supported upgrade path.

• Outbound HTTPS to https://console.automox.com/api/info (version lookup) and https://console.automox.com/downloadInstaller (installer download), through any forward proxy the endpoint normally uses

• Root execution context (the default Automox Agent context) so the Worklet can stop amagent, run the package manager, and edit the root crontab via crontab -l / crontab -

• Automox access key configured as a policy secret input named `accesskey` (exact lowercase), used by install_automox_agent.sh to re-register the upgraded agent into the same zone

• A running cron daemon (cron, cronie, or vixie-cron) accepting root crontab entries; under systemd this is typically `systemctl status crond` or `systemctl status cron`

• Writable /var/tmp with under 1 MB of free space for the three transient scripts

Expected agent state after the upgrade

Within roughly five minutes of the Worklet exiting, the endpoint runs the latest agent and reports back to the console under the same identity it had before. Run /opt/amagent/amagent version on the endpoint to confirm the new build, and check the endpoint detail view in the Automox console for the updated agent_version field. The Automox Activity Log records a two-line entry showing the previous version and the version that replaced it, which is the artifact to capture for change-control evidence.

The three scheduled cron jobs are designed to fail loudly. If the uninstall job cannot stop amagent or cannot deregister, that job logs to the Activity Log and the install job still runs; if the install job cannot reach downloadInstaller or the access key is wrong, the cleanup job still fires and removes the temporary files so the endpoint is not left holding stale scripts. If the policy reports the endpoint as non-compliant on the next evaluation, the most common causes in order are: an outdated or misnamed `accesskey` secret, an outbound proxy that blocks the installer URL, or a missing yum or apt-get binary on a minimally provisioned host. The Worklet is safe to re-run on the next policy schedule once those are corrected.