Snap-Pakete unter Ubuntu verwalten: Updates, Holds, Confinement und sicheres Entfernen

Worum es geht

Snap ist das eigene Paketformat von Ubuntu mit dem zugehörigen Daemon (snapd); unter Debian ist es standardmässig nicht vorhanden. snap list zeigt die installierten Snaps mit Tracking-Channel, Revision und allfälligen Hinweisen (etwa held); snap info <name> zeigt vor der Installation, welche Channels und welches Confinement ein Snap anbietet.

Warum es wichtig ist

Im Gegensatz zu apt-Paketen aktualisieren sich Snaps selbst nach einem Zeitplan im Hintergrund, den der Administrator nicht unbedingt ausgelöst hat – standardmässig "scheduled to refresh four times per day" (viermal täglich). Das ist für die Änderungskontrolle auf einem Server relevant, auf dem ein ungeplantes Anwendungsupdate unerwünscht ist. Das Confinement ist wichtig, weil ein Snap mit weitreichendem Systemzugriff einen Grossteil der Isolation aufhebt, die das Format bieten soll.

So wird es angewendet

• Den aktuellen Update-Zeitplan und bestehende Holds mit snap refresh --time und snap list prüfen (ein gehaltenes Snap zeigt in der Spalte Notes den Eintrag held).
• Um Updates für ein einzelnes Snap unbefristet oder für einen festen Zeitraum anzuhalten: snap refresh --hold=<name> oder snap refresh --hold=24h <name>; der Hold-Befehl "holds, or postpones, snap updates for individual snaps, or for all snaps on the system" (hält Snap-Updates für einzelne oder alle Snaps des Systems an bzw. verschiebt sie). Aufheben lässt sich ein Hold mit snap refresh --unhold <name>.
• Für eine flottenweite Richtlinie statt einzelner Holds die Systemoptionen refresh.timer (eigener Zeitplan) oder refresh.hold (alle Aktualisierungen bis zu einem angegebenen Datum bzw. einer Uhrzeit nach RFC 3339 verzögern) setzen, zum Beispiel mit snap set system refresh.hold="2026-10-01T00:00:00Z".
• Vor der Installation eines Snaps mit erweiterten Rechten dessen Confinement prüfen: snap info <name> meldet strict, classic oder devmode. Das "confinement level controls the degree of isolation it has from the user's system" (Das Confinement-Level bestimmt, wie stark ein Snap vom System des Benutzers isoliert ist); classic-Snaps laufen ganz ohne Sandbox und sind wie jede andere nicht eingeschränkte Paketinstallation zu behandeln.
• Zur Fehlersuche bei einem fehlerhaft arbeitenden Snap dessen eigenen Log-Strom lesen: journalctl, gefiltert auf die Unit des Snaps, oder das Hilfswerkzeug installieren (snap install snappy-debug) und sudo journalctl --output=short --follow --all | sudo snappy-debug ausführen. Damit werden AppArmor-Verweigerungen im Zusammenhang mit dem Snap-Confinement in eine lesbare Erklärung übersetzt.
• Um ein Snap zu entfernen: snap remove <name>. Standardmässig bleibt dabei ein Snapshot der Benutzer-, System- und Konfigurationsdaten des Snaps erhalten, "retained for 31 days" (31 Tage aufbewahrt). Eine versehentliche Entfernung lässt sich also mit snap saved bzw. snap restore rückgängig machen; mit --purge entfällt der Snapshot, und alles wird sofort gelöscht.

Stolpersteine

• Ein gehaltenes Snap erhält auch seine Sicherheitskorrekturen nicht; Holds sind regelmässig zu überprüfen, so wie ein apt-mark hold.
• Die Grenzen für Holds haben sich zwischen snapd-Versionen geändert: Ältere Versionen begrenzten refresh.hold auf 90 Tage, das aktuelle snapd akzeptiert auch unbefristete Holds (snap refresh --hold ohne Dauer oder refresh.hold=forever). snap version und die Dokumentation der installierten Version prüfen, bevor eines der beiden Verhalten vorausgesetzt wird.
• classic-Confinement muss pro Snap ausdrücklich gewählt werden und erfordert bei der Installation das Flag --classic; ein Skript, das gedankenlos --classic anhängt, um eine Fehlermeldung zu beseitigen, gewährt vollen Systemzugriff und umgeht nicht bloss eine Eigenheit der Sandbox.