Hello Cleavr Team,
I am working on tightening the security posture of several Cleavr-managed VMs. To satisfy external vulnerability scanning compliance, I need to routinely patch system dependencies. However, I want to avoid breaking the automated DevOps pipeline or causing configuration drifts that would disrupt Cleavr’s management scripts.
I am aware that Cleavr provisions servers with unattended security upgrades enabled by default. My primary concern lies with the remaining non-security service updates and minor dependency packages.
To help me map out a safe patching strategy, could you clarify the following points regarding Cleavr’s underlying architecture:
-
What specific core packages should be strictly held (via
apt-mark hold) or blacklisted from automated/manual updates to protect Cleavr’s integrations? (e.g., nginx, php*-fpm, mysql-server, redis-server, nodejs, etc.) -
What exactly breaks if a core service like Nginx or PHP-FPM receives a standard package update? Does Cleavr rely on highly specific custom binaries, or is the threat primarily about default package maintainer configurations overwriting Cleavr’s custom templates in /etc/nginx/ or /etc/php/?
-
Is there an officially recommended way to safely run general repository updates (like system libraries, utilities, or kernel patches) without blinding the Cleavr dashboard or bricking site connectivity?
-
If an external compliance audit explicitly demands we upgrade a non-security system package that Cleavr manages, how should we evaluate if it’s safe? Is there a recommended way to test if a package update will break Cleavr’s integration hooks prior to running it on production?
I want to avoid a scenario where an upgrade feels too risky to attempt, but leaving it unpatched triggers compliance alerts. Any insight into what is safe to touch and what is a dangerous would be incredibly helpful!
Thank you!