Red Hat’s Insights-Client Rework Turns a Silent Self-Updater Into a Standard RPM Package

For years, a system health agent bundled with every Red Hat Enterprise Linux subscription updated itself in a way that broke every rule enterprises normally apply to production systems. Red Hat says it is finally closing that gap, starting with RHEL 9.8 and RHEL 10.2.

An agent that skipped the package manager

insights-client is the on-host agent for Red Hat Insights, the vulnerability, compliance, and performance analytics service bundled with every RHEL subscription. Its core logic lives in a companion component called insights-core. Until now, that core component was, in Red Hat’s own words, “distributed as a Python egg and updated itself automatically at runtime,” entirely separate from how every other piece of software on the system gets updated.

An egg is a legacy Python packaging format from the setuptools era, predating the now-standard wheel format. Software distributed that way can install, and run its own code, without ever touching dnf, rpm, or any of the verification and logging that come with them. For a monitoring agent that ships on essentially every production RHEL box, that is a meaningful blind spot: it updates on a schedule Red Hat controls, not one an administrator can inspect, test, or veto through the tools they use for everything else on the system.

Folding it into the package manager

Starting with RHEL 9.8 and RHEL 10.2, both insights-client and insights-core are delivered as ordinary RPM packages through the AppStream repository that comes with a standard RHEL subscription. Red Hat’s own Knowledgebase article on the change, titled “Security improvements and new distribution method for insights-client,” confirms the mechanics in its public summary: “insights-client will cease to automatically update insights-core during runtime,” and a new customized SELinux policy is being deployed alongside the change, governing what the agent is allowed to do on the host.

In practice, that means a RHEL admin now sees insights-core the same way they see any other package. Red Hat’s blog post frames the benefit directly: administrators “can apply it during your maintenance windows, test it in lower environments before promoting it, and track it in your change management system.” A routine update becomes a single, ordinary command:

sudo dnf upgrade -y insights-core

Teams that want the update to stay current without manual intervention can wire that into a daily cron job or a systemd timer, the same way they would for any other package, rather than trusting an agent to manage its own patch cadence in the background.

The fleet management case: Red Hat Satellite

The RPM-based model has a direct payoff for organizations running Red Hat Satellite to manage large RHEL fleets. Because insights-core is now just another package, it slots straight into Satellite’s existing content view workflow. Red Hat’s post puts it plainly: “insights-core is just another package in your content view. Sync it, promote it through your environments,” the same staged dev-to-production promotion path already used for every other package on a managed fleet, as long as the AppStream repository is included in that content view.

That matters because Satellite exists specifically to give large RHEL estates a single, auditable point of control over what software reaches which systems and when. A monitoring agent that quietly bypassed that control on every host was, in effect, an exception carved out of the fleet’s own governance model. Folding it into the same content view mechanism removes that exception rather than documenting around it.

What is not changing yet

The new model is not universal on day one. RHEL 8, RHEL 9.0 through 9.7, and RHEL 10.0 through 10.1 continue using the old Python egg self-update mechanism, according to Red Hat. Only RHEL 9.8, RHEL 10.2, and versions going forward pick up the RPM-based delivery model. Fleets running a mix of RHEL versions, which describes most large enterprise deployments, will run both update mechanisms side by side until older minor releases age out or systems are upgraded.

A name change that didn’t reach the plumbing

The product this agent reports to has itself changed names. Red Hat has rebranded Red Hat Insights as Red Hat Lightspeed, describing it now as “an end-to-end system management tool that predicts risks across Red Hat platforms, recommends actions, and tracks costs.” The component names on the host, insights-client and insights-core, have not changed to match, which is worth knowing if a search for “Lightspeed client” turns up nothing useful on a system.

Lightspeed’s product identity was already the subject of a separate architectural decision: which network path a RHEL system uses to reach it, a hosted-direct connection, a Satellite-proxied one, or a fully air-gapped setup with local analytics. sxz.io covered that connectivity question in detail in Red Hat Lightspeed Makes RHEL Connectivity a Control-Plane Decision. This update is a related but distinct layer: not how the client talks to Red Hat, but how the client itself gets patched on the host it runs on.

What RHEL admins should do now

Anyone managing RHEL fleets has a short, concrete checklist here. Check whether hosts are on RHEL 9.8, RHEL 10.2, or newer; those are the only versions that get the new model automatically. If a host qualifies, confirm the AppStream repository is enabled, either directly or through the relevant Satellite content view, since that is where the new packages live. Decide whether to run updates manually during a maintenance window or automate them with a cron job or systemd timer, now that both are real options instead of a workaround for a self-updating agent. Red Hat’s Knowledgebase article is the authoritative reference for the full technical detail, including the new SELinux policy, for teams that need to document the change for an internal change management or compliance process.