Linux - Data Collection & Auditing - Automox Agent Diagnostics

What the Linux agent diagnostic Worklet does

This Automox Worklet™ captures a structured connectivity and service health snapshot of the Automox agent on a Linux endpoint and writes the results to the Automox activity log and a timestamped CSV on the endpoint. The Worklet inspects amagent.service with systemctl, walks the routing table with ip route get, resolves every host in the Automox agent firewall allowlist with dig, and tests TCP port reachability with nc -zv. The combined output is enough for a support engineer to triage a connectivity issue without opening an SSH session to the host.

The Worklet records the amagent service install state, runtime status, boot-enabled state, supported OpenSSL TLS versions, default route next hop, route to the resolved api.automox.com address, DNS A records for automox.com, api.automox.com, the LaunchDarkly endpoints (app, clientstream, events), digicert.com, cdn.digicertcdn.com, and automox-policy-files.s3.us-west-2.amazonaws.com, and TCP reachability for those same hosts on ports 80 and 443. Each check is tagged Pass or Fail in the CSV at /var/lib/amagent/diagnostic_worklet_results/automox_diagnostics.<timestamp>.csv.

The Worklet runs from the Devices page, the Run Policy option, or FixNow. Automox recommends against scheduling this diagnostic because the CSV output is most useful when correlated to a specific support ticket. The script also installs dig (bind-utils) and nc (nmap or nmap-ncat) on demand using yum or apt-get if either tool is missing, so the diagnostic still returns a complete result on a minimal base image.

Why centralize Linux agent diagnostics

Linux endpoint connectivity tickets are slow because the data lives in several places: the systemd journal, /var/log/amagent/amagent.log, the local routing table, the resolver, and whatever the egress firewall is doing. A support engineer working through that surface on a single endpoint spends an hour or more; the same engineer doing it across a tier of ten Linux servers spends most of a shift. The cause is usually a firewall rule that drifted, a DNS forwarder that started returning stale answers, or a route that broke after a network change.

Triaging a stalled Automox agent on Linux normally means logging into the host, running systemctl status amagent, dig against the allowlist, and tail on the agent log. FixNow this Worklet against the RHEL, CentOS, Ubuntu, Debian, or Fedora host that is failing to check in to pull every one of those data points into the activity log and a CSV on the endpoint. The support engineer compares failure patterns across endpoints from a browser tab, and the CSV survives on the endpoint at /var/lib/amagent/diagnostic_worklet_results/ for offline analysis when the network team needs it.

How the Linux diagnostic sweep works

1. Evaluation phase: The evaluation script is a notice-only stub that prints a reminder that this policy is not intended to be scheduled and exits 0. All diagnostic work runs in the remediation phase, which is triggered by FixNow, the Devices page, or the Run Policy action.

2. Remediation phase: The Worklet installs dig and nc on demand, then runs systemctl list-unit-files, systemctl status, and systemctl is-enabled against amagent.service, captures default and api.automox.com routing with ip route get, checks supported TLS via openssl ciphers -v, resolves each allowlisted host with dig A, tests TCP 80 and 443 reachability with nc -zv, and tails the last LogLines (default 15) entries of /var/log/amagent/amagent.log. Results are echoed to the policy output and written to /var/lib/amagent/diagnostic_worklet_results/automox_diagnostics.<timestamp>.csv.

Linux diagnostic requirements

• Linux endpoint running a systemd-based distribution: RHEL 7+, CentOS 7+, Fedora, Ubuntu 16.04+, or Debian 9+, with bash, systemctl, openssl, and ip available

• Root privileges for the Automox agent (the default agent context already meets this) to read /var/log/amagent/amagent.log, install missing packages, and write the CSV under /var/lib/amagent/diagnostic_worklet_results/

• Working yum or apt-get package manager and outbound access to the distribution mirrors, so the Worklet can install bind-utils and nmap or nmap-ncat when dig or nc is missing

• LogLines parameter set to the number of amagent.log lines to capture; default is 15, raise the value when investigating a slow-burn issue that needs more history

• Trigger from the Devices page, the Run Policy option, or FixNow; this Worklet is not intended to be run on a recurring schedule

Expected diagnostic output

After the Worklet runs, the Automox activity log and the on-endpoint CSV contain a four-column table (Diagnostic Type, Evaluation Performed, Output, Result) with one row per check across Service Evaluation, Network Evaluation, and Data Collection. The final line prints either "All checks have passed." or "Some checks were marked as a failure." so a support engineer can triage from the policy output before opening the CSV.

Validate on a known-healthy Linux endpoint and confirm amagent.service shows Pass on installed, running, and enabled at boot; that the default route and the route to api.automox.com both resolve to a next hop; that DNS resolution returns answers for every allowlisted host; and that TCP 80 and 443 reachability is Pass for every host that should be reachable. For audit evidence, archive the CSV file at /var/lib/amagent/diagnostic_worklet_results/automox_diagnostics.<timestamp>.csv with the support ticket. A consistent Fail on reachability for a single host points at a firewall or proxy rule; a Fail on DNS across several hosts points at the resolver.