Skip to content
Sencai.docs

Linux fleet inventory and hardening

You have a set of Linux servers - some provisioned through Sencai, most not - and no single place that answers “what is installed on all of them”. The questions that keep coming back are always the same four: is every host actually reporting, where is a given package installed, which hosts are behind on updates, and how badly configured are they.

Sencai answers those four questions from one agent installed per host. What it does is collect and report: the fleet agent scans each host on a schedule and publishes the results into screens you can search and filter across the whole organization. What it does not do is fix anything for you. There is no button that patches a host, and no button that remediates a hardening finding - both remain your team’s job on the host itself. Treat this as a measurement layer, not an automation layer.

The order below matters, because each step is a prerequisite for the next one being non-empty. In particular, a host that is connected but missing a capability grant looks exactly like a host with nothing to report - no error, no warning, just an absent row.

What this looks like in Sencai

Section titled “What this looks like in Sencai”

1. Enroll every host. Start at Enrolling a fleet agent. You generate a token in Fleet → Agents (/gravity/agents) and run the install script as root on the target host; the agent connects outbound only, so no inbound port is opened. Generating a token needs an Owner or Admin role. Once a host is enrolled it sends a heartbeat every 30 seconds, which is what “every host reporting” actually means in practice - the connected/disconnected state on Fleet → Agents.

2. Grant the capabilities, per host. A freshly enrolled agent has monitoring only. Inventory scanning, patch scanning, and CIS scanning each have to be granted individually from Fleet → Agents → Grant Capability, on every agent, as described in Fleet agent. This is the step people skip, and it is the reason a fleet can be fully enrolled and still produce three empty screens.

3. Search installed packages. Software inventory covers Compliance & Audit → Software (/gravity/inventory/software). Enter a package name and you get one row per host that has it, with version, package source, when that host was last scanned, and an end-of-life status where the package has known end-of-life data. This is the screen for “which of my hosts still run this” after a disclosure lands.

4. Read patch state. Patch management covers Infrastructure → Patches (/gravity/patches): the detected package manager (apt, dnf, or zypper), how many updates are available per host, and when the scan ran. Read that page carefully before you plan work around it - see the next section.

5. Score each host’s configuration. CIS hardening covers Compliance & Audit → CIS Hardening (/gravity/inventory/cis): a 0-100 Lynis-based score per host, the fleet-wide average, and the top warnings per host with Lynis’s own warning IDs. Lynis has to already be installed on the host - Sencai runs the scan, it does not install the scanner.

6. Add your own recurring checks. When a package name search is not the question you have - a specific service’s running state, a container image tag - Custom probes run one of a fixed set of allow-listed binaries across your fleet on a schedule and collect the exit code and output per agent.

What will surprise you

Section titled “What will surprise you”

The patch screen reports; it does not patch. There is no apply button, no scheduled apply, and no self-service way to trigger one from the app. The Applying and Applied statuses exist in the data model but no customer-reachable path produces them today, so do not build a process that waits for a host to reach Applied. The maintenance windows shown in a scan’s details are informational: there is no screen to configure them and nothing currently reads them. Granting the patch-apply capability is a prerequisite for a future apply, but on its own it causes nothing to happen. You patch on the host; the next scan reflects the lower count.

Capabilities are per agent, and a missing one fails silently. Deny-by-default is the correct security posture, but it means “no rows for this host” and “this host was never granted the capability” are visually identical. When a host is missing from Software, Patches, or CIS Hardening, check the grant on that specific agent first - before you conclude the host is clean.

A newly enrolled fleet is not populated for about a day. The first patch scan runs roughly five minutes after the agent starts, and the first inventory scan roughly ten minutes after the agent starts; both then settle into a roughly 24-hour cycle, as do CIS scans. Do not judge coverage on the first afternoon.

The software screen is a search, not a catalog. It is built to answer “where is this package installed” across the fleet. It will not hand you a full package list for one named host, so plan your queries around package names rather than around hosts.

Custom probes have no per-agent targeting. A probe runs as root on every enrolled agent in the organization, on your schedule. Only the binary is allow-listed - its arguments are not - so a probe defined with a mutating command really will run that command fleet-wide. Review the exact command the screen shows you before saving.

Fleet software inventory and cloud inventory are different pictures. Compliance & Audit → Software is what is installed on hosts running the agent. Compliance → Inventory is what exists in your connected cloud accounts. A host can appear in one and not the other, and that is not a bug.

What’s next

Section titled “What’s next”