Linux Fleet Readiness: Risk Audit & Decommission Planning

Two questions come up constantly in infrastructure work: which Linux hosts need attention before they become an outage or a security finding, and can this host be retired without breaking something?

The CLI reads a JSON inventory and policy file and flags:

FLT001 Patches older than policy allows (High)

FLT002 Production host without a verified backup (High)

FLT003 Monitoring disabled (Medium)

FLT004 Storage encryption disabled (High)

FLT005 OS family outside the supported policy (Medium)

Findings are sorted by severity, and a threshold such as --fail-on high lets it fail a CI pipeline.

A host is blocked if owner approval is missing, service dependencies remain, the final backup is unverified, or it is classified as production. For hosts that pass, it generates a step-by-step plan: evidence capture, traffic removal, monitoring, credential revocation, shutdown observation, resource deletion and inventory closure. It produces a plan only and never acts on it.

Read-only: never connects to or changes a server

Strict schema validation, so bad input fails visibly

Audit findings kept separate from decommission plans

Production decommissioning intentionally blocked

Text or JSON output, clear exit codes, no runtime dependencies, Python 3.10+, tested in GitHub Actions.

All examples use synthetic data. This is a personal portfolio project, not client work.