stackkit host

Anbieterneutrale Operationen des Host-Vertrags.

stackkit host [flags]

Unterbefehle: stackkit host attach-conformance, stackkit host conformance, stackkit host delivery, stackkit host environment, stackkit host migrate-browser-ca, stackkit host preflight, stackkit host prepare, stackkit host reboot, stackkit host remediate, stackkit host security, stackkit host ssh, stackkit host updates

stackkit host attach-conformance

Exakte Host-Nachweise vor der Plan-Generierung an das Inventory anhängen.

stackkit host attach-conformance [flags]

Flag	Typ	Standard	Beschreibung
`--binding`	string	—	Erforderlich. Auf den Workspace beschränkte ExternalHostBinding-JSON
`--inventory`	string	—	Erforderlich. Auf den Workspace beschränkte inventory.json, die atomar aktualisiert wird
`--receipt`	string	—	Erforderlich. Auf den Workspace beschränkte HostConformanceReceipt-JSON

stackkit host conformance

Auf diesem Host einen anbieterneutralen Konformitätsbeleg erzeugen.

stackkit host conformance [flags]

Flag	Typ	Standard	Beschreibung
`--binding`	string	—	Erforderlich. Lokale ExternalHostBinding-JSON-Datei
`--output, -o`	string	`-`	Ziel des Belegs (’-’ für JSON auf stdout)

stackkit host delivery

Den versiegelten Host-Delivery-Empfänger dieses Nodes verwalten. Versiegelte Host-Delivery bringt Wallet-Einträge, Backup-Ziele und SSH-Zugriff auf diesen Node. Eine liefernde Instanz versiegelt jeden Wert mit dem Empfängerschlüssel dieses Nodes (HPKE, pkg/hostdelivery); nur dieser Node öffnet ihn in seine eigene Verwahrung. Techstack und Guard transportieren ausschließlich Chiffretext und Referenzen.

stackkit host delivery [flags]

Unterbefehle: stackkit host delivery detach, stackkit host delivery recipient, stackkit host delivery status

stackkit host delivery detach

Host-Delivery zu diesem Node beenden und die gelieferten Secrets zur Rotation auflisten. Diesen Node von Host-Delivery trennen: Jedes gelieferte Secret wird als rotationsbedürftig markiert, ausgemusterte Empfängerschlüssel werden vernichtet, und bis der Node mit ‘host delivery recipient --rotate’ neu registriert ist, wird keine Delivery mehr geöffnet. Das Ergebnis listet die Referenzen und Versionen auf, die dort rotiert werden müssen, wo sie herkommen; es enthält nie einen Wert. Werte, die bereits in der lokalen Verwahrung liegen, bleiben hier nutzbar.

stackkit host delivery detach [flags]

Flag	Typ	Standard	Beschreibung
`--owner-approve`	bool	—	Das Trennen dieses Nodes autorisieren

Beispiele

stackkit host delivery detach --owner-approve

stackkit host delivery recipient

Den Empfängerschlüssel dieses Nodes nachweisen, die liefernde Instanz festlegen oder den Schlüssel rotieren. Eine Erklärung ausgeben, die vom lokalen Owner-Schlüssel signiert ist, den Empfängerschlüssel dieses Nodes und seine Generation an dieses Site und den Node bindet und die Challenge des Aufrufers wiederholt. Der private Schlüssel verlässt nie die lokale Verwahrung. --authority-key legt den öffentlichen Ed25519-Schlüssel der liefernden Instanz für die aktuelle Generation fest; Wallet-Einträge und SSH-Zugriff öffnen sich nur, wenn sie von ihm signiert sind. Ein festgelegter Schlüssel wird nie in place ersetzt. --rotate registriert den Node unter der nächsten Generation neu (und mit --authority-key wird eine neue Instanz festgelegt): Der bisherige Schlüssel öffnet vor der Rotation ausgestellte Deliveries noch höchstens für deren 15-minütige Gültigkeit und wird danach vernichtet. Eine Rotation beendet außerdem ein Detach.

stackkit host delivery recipient [flags]

Flag	Typ	Standard	Beschreibung
`--authority-key`	string	—	Öffentlicher Ed25519-Schlüssel (base64) der liefernden Instanz, der für diese Generation festgelegt wird
`--authority-key-id`	string	—	Schlüssel-ID, mit der die liefernde Instanz die Envelopes signiert
`--challenge`	string	—	Frischer Wert der liefernden Instanz, den die Erklärung wiederholen muss
`--owner-approve`	bool	—	Diese Änderung des Empfängers für den Node autorisieren
`--rotate`	bool	—	Unter der nächsten Empfänger-Generation neu registrieren

Beispiele

stackkit host delivery recipient --challenge "$CHALLENGE" --authority-key "$WALLET_KEY" --authority-key-id wallet-1 --owner-approve
stackkit host delivery recipient --challenge "$CHALLENGE" --rotate --owner-approve

stackkit host delivery status

Die Empfänger-Generation, die festgelegte Instanz, den Detach-Status und die gelieferten Referenzen anzeigen. Die Empfänger-Generation und ihren Fingerprint dieses Nodes melden, außerdem noch öffenbare ausgemusterte Generationen, die festgelegte liefernde Instanz, ob der Node getrennt ist, und jedes gelieferte Secret mit Referenz und Version samt Rotationsmarkierung. Es wird kein Wert gelesen.

stackkit host delivery status [flags]

stackkit host environment

Beobachten, ob dieser Host wie ein Heimnetz oder wie ein öffentlicher Server aussieht. Die Netzwerkumgebung dieses Rechners erkennen. Das ist eine Beobachtung, keine Kit-Auswahl. Installer und init nutzen sie, um nachzufragen, bevor sie lokale Heimadressen auf einem VPS oder Cloud Kit auf einem LAN-Host anlegen. STACKKIT_NETWORK_ENV=home|vps|cloud|unknown überschreibt die Live-Erkennung.

stackkit host environment [flags]

Flag	Typ	Standard	Beschreibung
`--json`	bool	—	Die Beobachtung als JSON ausgeben

Beispiele

# Show whether this host looks like a home network or a public server
stackkit host environment

# The same observation as JSON
stackkit host environment --json

# Override a wrong detection for the next command, here Basement Kit init on a home host
STACKKIT_NETWORK_ENV=home stackkit init basement-kit --catalog-defaults --owner-source=local --owner-email you@example.com

stackkit host migrate-browser-ca

Die authentifizierte Legacy-CA dieses Nodes auf die browserfähige Richtlinie migrieren. Legacy-Basement-CA-Signaturschlüssel explizit migrieren und dabei den Owner-Signaturschlüssel, PocketID-Identitäten, Laufzeit-Secrets, Ingress-Leaf-Schlüssel, Adressen und Volumes erhalten. Eine bereits aktuelle Root bleibt bestehen. Vor --complete den aktuellen nativen Plan anwenden und verifizieren. Clients müssen eine geänderte öffentliche Root über die vorhandene Client-Trust-Übergabe genehmigen.

stackkit host migrate-browser-ca [flags]

Flag	Typ	Standard	Beschreibung
`--complete`	bool	—	Das Wiederherstellungsjournal nach aktuellem nativen Apply und regulärer TLS-Verifikation schließen
`--owner-approve`	bool	—	Den expliziten CA-Übergang dieses Nodes autorisieren

stackkit host preflight

Prüfen, ob dieser Host das gewählte StackKit ausführen kann. Diesen Host vermessen und mit der Untergrenze vergleichen, die das Kit deklariert. Preflight führt nur schreibgeschützte Probes aus: Es installiert, startet oder konfiguriert nie etwas. Apply führt dieselbe Zulassungsprüfung aus, bevor es den Host verändert.

stackkit host preflight [flags]

Flag	Typ	Standard	Beschreibung
`--json`	bool	—	Den versionierten Preflight-Report als maschinenlesbares JSON ausgeben
`--local-node`	string	—	Exakter lokaler Node im übergebenen ResolvedPlan
`--policy`	string	—	Zulassungsrichtlinie: strict, warn (Standard) oder skip
`--resolved-plan`	string	—	Verifizierter kanonischer ResolvedPlan, dessen Host-Listener geprüft werden

Beispiele

# Check this host against the kit selected in the current deployment directory
stackkit host preflight

# Also refuse on warnings and unknown facts, and print the report as JSON
stackkit host preflight --policy strict --json

stackkit host prepare

Diesen Host vor dem Cloud-Kit-Apply vorbereiten. Das Konto des Cloud-Ausführungskanals und die SSH-Schlüsselverwahrung bereitstellen, die nötig sind, bevor die Host-Security den Root-Login deaktiviert. Cloud-Kit-Installer und Apply rufen das automatisch auf. Der Befehl existiert für Diagnosen und um einen Workspace nach einer manuellen Unterbrechung zu konvergieren. Er erzeugt oder verwendet den vom Workspace verwahrten Schlüssel unter .stackkit/cloud-host-security/execution-channel/ wieder und installiert den passenden öffentlichen Schlüssel auf dem Linux-Konto des Ausführungskanals.

stackkit host prepare [flags]

Beispiele

# Converge the execution-channel account after an interrupted Cloud Kit install (run as root in the Cloud Kit deployment directory)
cd my-cloud
stackkit host prepare

stackkit host reboot

Einen Neustart dieses Nodes planen. Einen Neustart dieses Nodes nach kurzer Verzögerung planen und sofort zurückkehren. Die zurückgegebene boot_id_before identifiziert den aktuellen Boot, sodass ein Aufrufer am geänderten Boot-ID-Wert erkennt, dass der Node zurückgekehrt ist. Der Befehl verweigert sich bei einem Node, auf dem die Techstack-Control-Plane läuft, bei einem Node, auf dem apt oder dpkg seine Sperre hält oder ein Host-Update läuft, und bei einem Node, der nicht unbeaufsichtigt booten kann (Volumes in /etc/crypttab, die eine Passphrase brauchen, oder kein apt). Wenn die Verzögerung endet, prüft ein Guard erneut, wartet bis zu 15 Minuten, bis jede Paketoperation beendet ist, und fordert den Neustart an, während er die dpkg-Sperren hält. Ein Node, der beschäftigt bleibt, wird nicht neu gestartet; seine Boot-ID bleibt gleich.

stackkit host reboot [flags]

Flag	Typ	Standard	Beschreibung
`--delay`	duration	`30s`	Zeit bis zum Start des Neustarts (1s bis 5m)
`--json`	bool	—	Das stackkit.host-maintenance/v1-Ergebnis als maschinenlesbares JSON ausgeben
`--yes`	bool	—	Bestätigen, dass dieser Node neu starten darf

Beispiele

# Reboot this node in 30 seconds
sudo stackkit host reboot --yes

# Reboot in two minutes and report the boot ID to compare against
sudo stackkit host reboot --yes --delay 2m --json

stackkit host remediate

Korrekturen für die Preflight-Befunde des Hosts anzeigen oder ausführen. Die Korrekturen auflisten, die zu den Preflight-Befunden dieses Hosts passen, oder eine davon ausführen. Ohne --apply wird nichts geändert: Der Befehl vermisst den Host und gibt aus, was jede Korrektur tun würde, ob sie sich rückgängig machen lässt und ob sie Root braucht. Mit --apply <id> --yes läuft die benannte Korrektur, und die Prüfung, die sie begründet hat, wird danach erneut gemessen, sodass das Ergebnis aussagt, was sich tatsächlich geändert hat, und nicht nur, dass etwas versucht wurde.

stackkit host remediate [flags]

Flag	Typ	Standard	Beschreibung
`--apply`	string	—	Die benannte Auflösung ausführen (erfordert `--yes`)
`--auto-reversible`	bool	—	Jede rückgängig machbare Korrektur ausführen, die unbeaufsichtigt laufen darf (erfordert `--yes`)
`--json`	bool	—	Den Remediation-Plan oder -Eintrag als maschinenlesbares JSON ausgeben
`--policy`	string	—	Preflight-Richtlinie zum Finden der Befunde: strict oder warn (Standard)
`--yes`	bool	—	Bestätigen, dass die benannte Auflösung diesen Host verändern darf

Beispiele

# List the fixes for this host's preflight findings without changing anything
stackkit host remediate

# Carry out one fix by the ID the list printed
stackkit host remediate --apply <resolution-id> --yes

# Carry out every undoable fix that may run unattended
stackkit host remediate --auto-reversible --yes

stackkit host security

Die Host-Sicherheitsbaseline mit versionierten Nachweisen verifizieren und reparieren. Diesen Knoten anhand der StackKits-Host-Sicherheitsbaseline beobachten und Abweichungen beheben, ohne den Verwaltungspfad zu unterbrechen. verify ändert niemals den Host. Es erzeugt stackkit.host-security-evidence/v1 für Firewall, sshd, Brute-Force-Schutz, automatische und ausstehende Sicherheitsupdates, Neustartstatus, Kernelparameter, exponierte Listener und Zertifikatsablauf sowie für die SSH-CA-Vertrauensstellung und das Host-Zertifikat, die an diesen Node geliefert wurden (‘host ssh apply’), sobald sie aufgezeichnet sind. Jedes Kontrollelement ist konform, abweichend, unbekannt oder eine vom Besitzer genehmigte Ausnahme, und der Nachweis läuft ab: Eine veraltete Beobachtung ist unbekannt, und ein unbekanntes Kontrollelement gilt niemals als konform. Es funktioniert eigenständig (Standard Mode, ohne Konto) und über die festgelegte CLI, wenn Techstack die Bereitstellung verwaltet (--mode advanced).

stackkit host security [flags]

Unterbefehle: stackkit host security repair, stackkit host security status, stackkit host security verify

stackkit host security repair

Abweichende Baseline-Kontrollelemente wiederherstellen, ohne den Verwaltungspfad zu unterbrechen. Die Wiederherstellung abweichender Kontrollelemente planen oder mit --apply ausführen. Ohne --apply wird nichts geändert: Der Befehl misst den Host und gibt aus, was jede Reparatur tun würde. Mit --apply werden nur die benannten (--control) oder abweichenden Kontrollelemente verändert, und jede Änderung wird zuerst geprüft:

  - the firewall always keeps admitting the ssh sessions in use and every
    --management-source on every sshd port, and a policy that would not is
    refused before it is loaded;
  - password logins are disabled only when an account holds an authorized key;
    without one they stay on, the step is refused with reason no_authorized_key
    and the rest of the baseline is still repaired. The previous sshd and
    firewall configuration is restored if the new one does not validate or does
    not take effect;
  - fail2ban never bans the management path.

Ein Kontrollelement, das nicht beobachtet werden kann oder für das der Besitzer eine Ausnahme genehmigt hat, wird nicht verändert. Die Firewall und der Root-Login einer Cloud Site werden durch stackkit apply wiederhergestellt. Jeder Schritt zeichnet das Kontrollelement vorher und nachher auf; eine wiederholte Reparatur eines konformen Kontrollelements ändert nichts.

stackkit host security repair [flags]

Flag	Typ	Standard	Beschreibung
`--apply`	bool	—	Die Reparatur ausführen; ohne dieses Flag plant der Befehl nur
`--control`	stringArray	—	Die Reparatur auf diese Kontrollelement-ID beschränken (wiederholbar)
`--declared-port`	stringArray	—	Deklarierter Dienst-Port als tcp/443 oder udp/5353 (wiederholbar)
`--exceptions`	string	`/etc/stackkit/host-security/exceptions.json`	Vom Besitzer kontrollierte Ausnahmedatei (jede Ausnahme benötigt einen Besitzer und ein Ablaufdatum)
`--freshness`	duration	`15m0s`	Wie lange dem Nachweis bis zum Ablauf vertraut werden darf (1m bis 24h)
`--host-name`	stringArray	—	Name, den das gelieferte SSH-Host-Zertifikat tragen muss (wiederholbar; Standard: der Systemhostname)
`--json`	bool	—	Das Ergebnis als maschinenlesbares JSON ausgeben
`--kit`	string	—	Aufzuzeichnender Kit-Slug (Standard: das Kit der StackSpec im Workspace)
`--local-node`	string	—	Exakter lokaler Node im angegebenen ResolvedPlan
`--management-source`	stringArray	—	Netzwerk, das SSH immer erreichen können muss, als CIDR (wiederholbar)
`--mode`	string	`standard`	Aufzuzeichnender Lebenszyklusmodus: standard oder advanced, wenn Techstack diese Bereitstellung verwaltet
`--no-record`	bool	—	Den Nachweis nach der Reparatur nicht unter .stackkit/ schreiben
`--resolved-plan`	string	—	Verifizierter kanonischer ResolvedPlan, gegen dessen deklarierte Listener die Exposition bewertet wird
`--site-kind`	string	—	Art des Site dieses Hosts: home oder cloud (Standard: aus dem Kit abgeleitet; modern-homelab erfordert den Wert)

Beispiele

# See what would be repaired
sudo stackkit host security repair --site-kind home

# Restore only the firewall, keeping a jump host reachable
sudo stackkit host security repair --apply --control firewall.default_inbound --management-source 198.51.100.0/24

stackkit host security status

Den gespeicherten Nachweis in seinem jetzigen Zustand lesen, ohne den Host zu beobachten. Den zuletzt von verify in diesem Workspace aufgezeichneten Nachweis lesen und zur aktuellen Zeit bewerten. Ein Nachweis, dessen Aktualitätsbudget überschritten ist, ist unbekannt: Eine alte Beobachtung belegt nichts über den jetzigen Zustand des Hosts.

stackkit host security status [flags]

Flag	Typ	Standard	Beschreibung
`--drift-scope`	string	`all`	Kontrollelemente, die über `--fail-on-drift` entscheiden: all oder enforced (nur die von der Baseline selbst durchgesetzten Elemente; verzögerte Updates, ausstehende Neustarts, Exposition und Zertifikate werden weiterhin beobachtet und gemeldet)
`--fail-on-drift`	bool	—	Mit 5 beenden, wenn der Host abweicht, und mit 6, wenn sein Zustand unbekannt ist
`--json`	bool	—	Den Nachweis als maschinenlesbares JSON ausgeben

stackkit host security verify

Die Host-Sicherheitsbaseline beobachten und einen versionierten Nachweis schreiben. Jedes Baseline-Kontrollelement auf diesem Knoten beobachten und stackkit.host-security-evidence/v1 erzeugen. Auf dem Host wird nichts geändert. Die meisten Kontrollelemente benötigen root, um beobachtet zu werden; ein nicht beobachtbares Element wird mit Begründung als unbekannt gemeldet, nicht als Fehler. Der Nachweis wird unter .stackkit/host-security-evidence.json im Workspace geschrieben, sofern --no-record nicht angegeben ist, und läuft nach --freshness ab.

stackkit host security verify [flags]

Flag	Typ	Standard	Beschreibung
`--declared-port`	stringArray	—	Deklarierter Dienst-Port als tcp/443 oder udp/5353 (wiederholbar)
`--drift-scope`	string	`all`	Kontrollelemente, die über `--fail-on-drift` entscheiden: all oder enforced (nur die von der Baseline selbst durchgesetzten Elemente; verzögerte Updates, ausstehende Neustarts, Exposition und Zertifikate werden weiterhin beobachtet und gemeldet)
`--exceptions`	string	`/etc/stackkit/host-security/exceptions.json`	Vom Besitzer kontrollierte Ausnahmedatei (jede Ausnahme benötigt einen Besitzer und ein Ablaufdatum)
`--fail-on-drift`	bool	—	Mit 5 beenden, wenn der Host abweicht, und mit 6, wenn sein Zustand unbekannt ist
`--freshness`	duration	`15m0s`	Wie lange dem Nachweis bis zum Ablauf vertraut werden darf (1m bis 24h)
`--host-name`	stringArray	—	Name, den das gelieferte SSH-Host-Zertifikat tragen muss (wiederholbar; Standard: der Systemhostname)
`--json`	bool	—	Das Ergebnis als maschinenlesbares JSON ausgeben
`--kit`	string	—	Aufzuzeichnender Kit-Slug (Standard: das Kit der StackSpec im Workspace)
`--local-node`	string	—	Exakter lokaler Node im angegebenen ResolvedPlan
`--management-source`	stringArray	—	Netzwerk, das SSH immer erreichen können muss, als CIDR (wiederholbar)
`--mode`	string	`standard`	Aufzuzeichnender Lebenszyklusmodus: standard oder advanced, wenn Techstack diese Bereitstellung verwaltet
`--no-record`	bool	—	Den Nachweis nicht unter .stackkit/ schreiben
`--resolved-plan`	string	—	Verifizierter kanonischer ResolvedPlan, gegen dessen deklarierte Listener die Exposition bewertet wird
`--site-kind`	string	—	Art des Site dieses Hosts: home oder cloud (Standard: aus dem Kit abgeleitet; modern-homelab erfordert den Wert)

Beispiele

# Verify this host and record the evidence
sudo stackkit host security verify

# Machine-readable, advanced mode, exit non-zero on any drifted control
sudo stackkit host security verify --mode advanced --json --fail-on-drift

# What the Techstack host pre-step runs: only the controls the baseline enforces decide the exit code; patch lag, pending reboot, exposure and certificates are still observed and reported
sudo stackkit host security verify --mode advanced --json --fail-on-drift --drift-scope enforced

# Judge exposure against the ports the verified plan declares
sudo stackkit host security verify --resolved-plan plan.json --local-node node-1

stackkit host ssh

SSH-Zertifikatszugriff, der an diesen Node geliefert wird.

stackkit host ssh [flags]

Unterbefehle: stackkit host ssh apply

stackkit host ssh apply

Eine versiegelte SSH-CA-Vertrauensstellung, Sperrung oder Host-Zertifikat-Lieferung von stdin anwenden. Genau ein versiegeltes ssh-ca-trust-, ssh-ca-revoke- oder ssh-host-certificate-Envelope von stdin lesen, das von der festgelegten liefernden Instanz signiert ist, und es auf den sshd dieses Servers anwenden:

  - ssh-ca-trust installs the owner's user CA keys as TrustedUserCAKeys
    (/etc/ssh/stackkit/trusted_user_ca_keys) and one AuthorizedPrincipalsFile
    per local user (/etc/ssh/stackkit/principals/<user>). Root is never a
    target. An empty key list revokes like ssh-ca-revoke.
  - ssh-ca-revoke removes that trust. Revocations take effect at once and are
    never rolled back; one sshd cannot reload for is recorded as cleanup
    pending and finished by 'host security repair'.
  - ssh-host-certificate installs a host certificate beside the host key it
    certifies, only if it names every --host-name (default: the system
    hostname) and is currently valid.

sshd wird nur neu geladen, nachdem ‘sshd -t’ die neue Konfiguration akzeptiert hat; eine fehlgeschlagene Änderung wird zurückgerollt. Der angewendete Zustand wird in der Owner-Verwahrung aufgezeichnet, sodass ‘host security verify’ Abweichungen meldet und ‘host security repair’ ihn wieder installiert.

stackkit host ssh apply [flags]

Flag	Typ	Standard	Beschreibung
`--host-name`	stringArray	—	Name, den ein Host-Zertifikat als Principal tragen muss (wiederholbar; Standard: der Systemhostname)
`--owner-approve`	bool	—	Die Änderung des SSH-Zugriffs auf diesem Server autorisieren
`--tenant-ref`	string	—	Mandant, an den die versiegelte Delivery adressiert sein muss

Beispiele

sudo stackkit host ssh apply --tenant-ref "$TENANT" --owner-approve < envelope.json

stackkit host updates

Betriebssystem-Paketupdates auf diesem Node planen und anwenden. Betriebssystem-Paketupdates auf diesem Debian- oder Ubuntu-Node planen und anwenden. Die Container-Runtime (docker.io, docker-ce*, containerd*, runc) wird zurückgehalten: Sie steht im Plan, wird von apply aber nie installiert, weil ihr Upgrade jeden Workload neu startet. Apply entfernt nie Pakete, führt nie autoremove aus und startet nie neu; nutze dafür ‘stackkit host reboot’.

stackkit host updates [flags]

Unterbefehle: stackkit host updates apply, stackkit host updates plan

stackkit host updates apply

Genau den geprüften Update-Plan installieren. Genau die Paketmenge installieren, die ein geprüfter ‘stackkit host updates plan’ gemeldet hat. Die ausstehende Menge wird zuerst erneut simuliert; weicht ihr Digest von --plan-digest ab, wird nichts installiert (plan_stale). apt läuft nicht-interaktiv in einer transienten systemd-Unit (kombify-host-update-*) und behält bestehende Konfigurationsdateien, sodass ein Timeout von CLI oder Agent nur das Warten beendet und nie dpkg. Das Ergebnis hält die Version jedes Pakets vor und nach dem Update fest und ob der Node jetzt einen Neustart benötigt.

stackkit host updates apply [flags]

Flag	Typ	Standard	Beschreibung
`--json`	bool	—	Das stackkit.host-maintenance/v1-Ergebnis als maschinenlesbares JSON ausgeben
`--plan-digest`	string	—	Erforderlich. plan_digest des geprüften Plans (sha256:<hex>)
`--yes`	bool	—	Bestätigen, dass die geplanten Pakete installiert werden dürfen

Beispiele

# Apply the plan you reviewed
sudo stackkit host updates apply --plan-digest sha256:<digest> --yes

stackkit host updates plan

Den Paketindex aktualisieren und die ausstehenden Updates anzeigen. Den Paketindex aktualisieren und anzeigen, was ‘stackkit host updates apply’ installieren würde. Das Ergebnis listet jedes ausstehende Paket mit aktueller und neuer Version, die zurückgehaltenen Container-Runtime-Pakete, von apt zurückgehaltene Pakete, ob ein Neustart wahrscheinlich ist (Kernel, C-Bibliothek oder systemd) und dpkg-Probleme auf. plan_digest bindet die exakte Paketmenge; apply verweigert sich, wenn sie nicht mehr passt.

stackkit host updates plan [flags]

Flag	Typ	Standard	Beschreibung
`--json`	bool	—	Das stackkit.host-maintenance/v1-Ergebnis als maschinenlesbares JSON ausgeben

Beispiele

# Show the pending updates of this node
sudo stackkit host updates plan

# Machine-readable plan with its plan_digest
sudo stackkit host updates plan --json

Erste Schritte

Anleitungen

Referenz

stackkit host attach-conformance

stackkit host conformance

stackkit host delivery

stackkit host delivery detach

stackkit host delivery recipient

stackkit host delivery status

stackkit host environment

stackkit host migrate-browser-ca

stackkit host preflight

stackkit host prepare

stackkit host reboot

stackkit host remediate

stackkit host security

stackkit host security repair

stackkit host security status

stackkit host security verify

stackkit host ssh

stackkit host ssh apply

stackkit host updates

stackkit host updates apply

stackkit host updates plan

​stackkit host attach-conformance

​stackkit host conformance

​stackkit host delivery

​stackkit host delivery detach

​stackkit host delivery recipient

​stackkit host delivery status

​stackkit host environment

​stackkit host migrate-browser-ca

​stackkit host preflight

​stackkit host prepare

​stackkit host reboot

​stackkit host remediate

​stackkit host security

​stackkit host security repair

​stackkit host security status

​stackkit host security verify

​stackkit host ssh

​stackkit host ssh apply

​stackkit host updates

​stackkit host updates apply

​stackkit host updates plan

stackkit host attach-conformance

stackkit host conformance

stackkit host delivery

stackkit host delivery detach

stackkit host delivery recipient

stackkit host delivery status

stackkit host environment

stackkit host migrate-browser-ca

stackkit host preflight

stackkit host prepare

stackkit host reboot

stackkit host remediate

stackkit host security

stackkit host security repair

stackkit host security status

stackkit host security verify

stackkit host ssh

stackkit host ssh apply

stackkit host updates

stackkit host updates apply

stackkit host updates plan