Everyday policy management

Update, verify and roll back Sentinel Linux policy safely.

This manual turns Policy as Packages into a practical routine for ordinary users. It explains how to check an update before installing it, preserve evidence, update the coordinated Sentinel package cohort, verify the result and recover when a policy change causes a problem.

Preview first See available versions and simulate changes
Keep the cohort together Do not mix arbitrary Sentinel policy versions
Verify after change Audit packages, drift and release state
Restore deliberately Use package restore, downgrade or backup as appropriate
Current release boundary: Sentinel Linux v1.0 uses package-owned policy and a non-destructive drift audit. The weekly audit reports problems but does not automatically remove third-party applications, user files or application data.
Before changing policy

Create a small recovery record.

Policy packages can be repaired or downgraded, but package management is not a replacement for a backup. Save your important files first, then record the installed Sentinel package versions and any APT holds. Keep the record somewhere outside the machine when possible.

mkdir -p "$HOME/sentinel-policy-recovery"
dpkg-query -W 'sentinel*' 'sentinelos*' \
  > "$HOME/sentinel-policy-recovery/installed-packages.txt"
apt-mark showhold \
  > "$HOME/sentinel-policy-recovery/apt-holds.txt"
sudo cat /var/log/apt/history.log > \
  "$HOME/sentinel-policy-recovery/apt-history.log"
Lay-user update path

Safe policy update, step by step

The normal update path uses Debian's own APT tools. Sentinel packages should move as a coordinated release cohort rather than as unrelated one-off versions.

1. Refresh package information

Download the latest signed repository metadata without installing anything.

sudo apt update

2. Review what is available

Look at the proposed updates and inspect important policy package candidates.

apt list --upgradable
apt-cache policy sentinelos-release-baseline
apt-cache policy sentinelos-drift-control

3. Simulate the upgrade

APT can show the planned package actions before the real transaction.

sudo apt-get -s full-upgrade

4. Read the change record

Check the Sentinel Linux release page, advisories and package notes. Stop if the update requires a special migration or reboot that you are not ready to perform.

5. Install the coordinated update

Apply the complete dependency solution rather than forcing one policy package in isolation.

sudo apt full-upgrade

6. Verify the package database

Confirm that dpkg does not report interrupted or incomplete package state.

sudo dpkg --audit

7. Run Sentinel audits

Use the installed package-owned commands where available.

sudo sentinelos-drift-control --audit --json
sudo sentinelos-release-gate --verify --json

8. Reboot only when required

Kernel, login, boot, graphics or session changes may require a restart. Ordinary application updates often do not.

Verification after update

What a successful update should show

  • sudo dpkg --audit produces no package-database warning.
  • The drift audit reports the expected Sentinel package versions and trusted repository configuration.
  • The release gate reports the current release identity and complete phase markers.
  • Your desktop, login and applications start normally.
  • No unexpected APT holds or removed dependencies appear.
Package problem Use reinstall or a documented package downgrade.
Managed setting problem Prefer the package-owned restore command where one exists.
Personal data problem Use your backup. Package rollback does not recreate deleted user data.
Driver or hardware problem Collect logs and use Debian recovery methods; policy rollback may not address the cause.
Recovery decision

Choose the correct rollback method

There is no single universal rollback command. The safe method depends on what changed and what the package owns.

Package-owned restore

Use this when a policy package provides an explicit restore operation. It is usually safer than downgrading because the package knows which managed settings and saved baseline it owns.

sudo sentinelos-hardening \
  --restore-safe-baseline \
  --confirm RESTORE_SENTINELOS_HARDENING_BASE

Reinstall current version

Use this when package-owned files were damaged or manually changed but the current version is still desired.

sudo apt install --reinstall PACKAGE_NAME

Downgrade a compatible cohort

Use this only when the earlier versions remain available and the release notes identify a compatible set. Do not downgrade a single policy package while leaving tightly coupled packages at newer versions.

apt-cache policy PACKAGE_NAME
sudo apt install PACKAGE_NAME=VERSION
Guided package downgrade

Use exact versions and keep related packages together.

Replace the example names and versions with the documented cohort from the relevant release record. APT may require all interdependent Sentinel packages on the same command line.

apt-cache policy sentinelos-release-baseline
apt-cache policy sentinelos-drift-control

sudo apt install \
  sentinelos-release-baseline=OLDER_VERSION \
  sentinelos-drift-control=OLDER_VERSION

sudo dpkg --audit
sudo sentinelos-drift-control --audit --json

Temporary holds

A temporary hold can stop APT immediately reinstalling a known-bad version while an advisory is investigated.

sudo apt-mark hold PACKAGE_NAME
apt-mark showhold

Remove the hold when the corrected release is available.

sudo apt-mark unhold PACKAGE_NAME

Repository no longer has the old version

Do not download an unknown package from an unofficial mirror. Use a verified local package archive, an official Sentinel rollback bundle or restore the machine from a trusted snapshot or backup.

Rollback limits

A downgrade may restore package-owned files but may not reverse database migrations, user-data changes, deleted files, external service changes or manual administrator edits.

Do not force the transaction: avoid dpkg --force , dependency removal, broad package purges or an arbitrary mixture of old and new Sentinel policy packages. Stop and collect evidence when APT proposes removing major desktop or policy components.

Where can I see what changed?

Use the website release ledger and advisories, then inspect /var/log/apt/history.log and /var/log/dpkg.log on the machine.

Will Sentinel automatically undo my custom settings?

No. Current drift control is report-first and does not automatically remediate. A package repair or explicit restore can replace settings owned by that package, so review the operation before approving it.

Will an update delete third-party applications?

Not as normal policy behaviour. The current cleanup contract disables automatic APT autoremove and does not remove user files or application data. A third-party package may still conflict with a managed Sentinel package, and APT will show that proposed conflict before installation.

Related guidance

Understand policy theory and third-party boundaries.