Echo
3eb7fd9f95
ARCHITECTURE.md -> 0.0.3 REQUIREMENTS.md -> 0.0.2 SPEC.md -> 0.0.2 Closed OI-01 through OI-06 with concrete decisions: - OI-01: Encryption at rest delegated to hardware-host (no OS-level LUKS, no column-level). Compliance intent preserved at infrastructure layer. - OI-02: Argon2id starting parameters m=64MiB, t=3, p=1; 250-500 ms login-latency budget on Intel Xeon 4c/16GB; calibration recorded in system_config at deploy time. - OI-03: JWT signing = EdDSA/Ed25519; 90-day key rotation with 24-hour overlap; web holds signing key, worker holds verifying key only. - OI-04: CIDR scan concurrency = 128, per-host timeout = 1.5 s; /22 across sites completes under 10 s; progress UI + cancel required. - OI-05: PDF stack = printpdf + plotters (in-process, no sidecar); charts required; no branding; no digital signatures. - OI-06: /status/health = minimal unauthenticated liveness; /api/v1/status/fleet = authenticated fleet aggregates. Added architecture decisions: - AD-15: Web UI TLS certificate strategy (self-signed from internal CA by default; operator may supply external cert) - AD-16: Azure SSO + SMTP runtime configuration via Settings GUI with test-connection actions - AD-17: PDF generation via printpdf + plotters - AD-18: IP whitelist enforcement at every listener Added FR-07 (System Configuration) in REQUIREMENTS.md covering Azure SSO GUI, SMTP GUI, polling-interval tuning, Web UI TLS strategy, and IP whitelist management. SDD review pass also added (from v0.0.2): - IEEE 1016-aligned structure (Introduction, Stakeholders, Design Rationale, Risks, Open Issues, Glossary, References, Revision History) - Portable ASCII diagrams; split into Context/Logical/Deployment/Process views - Explicit WebSocket ticket authentication flow - Rollback data flow (6.5) - API error envelope + X-Request-Id correlation - Configuration, migration, and backup/DR sections - Worker heartbeat and dead-process detection - Sizing math for 2,500-host scalability claim - Split /status/health (Manager) from /api/v1/health (Agent) namespaces See ARCHITECTURE.md section 18 for the full change log.
Linux Patch Manager
Enterprise-class secure web-based management interface for controlling patching and updates on Linux servers and workstations.
Overview
Linux Patch Manager provides a centralized web interface to manage patching and software updates across a fleet of Linux servers and workstations. It communicates with managed devices through the Linux Patch API, leveraging mTLS-secured RESTful endpoints for all operations.
Key Features
- Centralized Dashboard — Monitor patch status across all managed hosts from a single interface
- Multi-Distribution Support — Manage Debian/Ubuntu, RHEL/CentOS/Fedora, Alpine, and Arch hosts
- Secure by Design — mTLS authentication, role-based access control, audit logging
- Batch Operations — Apply patches and updates across multiple hosts simultaneously
- Scheduling — Plan and schedule patch windows with approval workflows
- Reporting — Compliance reporting and patch status dashboards
Architecture
Linux Patch Manager is a web application that acts as a management plane, communicating with the Linux Patch API agent running on each managed host.
┌─────────────────────┐
│ Linux Patch Manager │ ← Web UI (this project)
│ (Management Plane) │
└──────────┬──────────┘
│ mTLS / REST API
┌──────┼──────┐
▼ ▼ ▼
┌──────┐┌──────┐┌──────┐
│ Host ││ Host ││ Host │ ← Linux Patch API agents
│ A ││ B ││ C │
└──────┘└──────┘└──────┘
Documentation
| Document | Description |
|---|---|
| SPEC.md | Full project specification |
| ARCHITECTURE.md | Architecture and design decisions |
| REQUIREMENTS.md | Functional and non-functional requirements |
Related Projects
- Linux Patch API — The API agent that runs on each managed host
License
Private — All rights reserved.