実行モデル

Sinter は観測と変更を分離し、結果の各次元を区別して扱います。

validate

sinter validate はレシピを読み込み、include と loop を展開し、スキーマと意味をチェックします。ターゲットには一切接続しません。

plan — 観測のみ

sinter plan はターゲットに接続して各リソースの現在の状態を観測し、 apply が何を行うかを報告します。以下は一切行いません:

ファイルの書き込みやステージングデータのアップロード
パーミッションや所有者の変更
パッケージのインストールや削除
サービスの変更
systemctl daemon-reload の実行
command リソースの実行

plan はプレビューであり、承認の根拠となる成果物ではありません。権威ある情報として再生されることはありません。

plan 内の先行リソースが systemd マネージャの入力（ユニットファイル、drop-in、 alias リンク、system.conf）を変更する場合、またはマネージャがすでに NeedDaemonReload=yes を報告している場合、後続の service リソースは「変更なし」でも失敗でもなく、unknown（?、apply 時のマネージャ同期まで保留）として報告されます。apply が行う reload は manager_reloads に別途一覧されます。

apply — 観測、変更、検証

sinter apply は変更の判断の直前に、すべてのステートフルなリソースを再観測します。変更後は結果を検証します。確認できない変更は indeterminate として報告され、自動でリトライされることはありません（ディスパッチ後のタイムアウト、応答の喪失、シグナルの不確実性）。

マネージャの同期。 変更されたリソースが systemd マネージャの入力に触れた場合、またはユニットが NeedDaemonReload=yes を報告した場合、apply は消費側の境界で systemctl daemon-reload を実行します。すなわち、service リソースが判断する前、通知された各ハンドラの前、そして成功した apply の最後です。 reload の後にユニットを再観測し、その新しい状態だけが次の動作を決めます。 reload は何も再起動しません。 serviceを参照してください。

ハンドラフェーズ。 通常のリソース処理が成功した後、ハンドラは宣言順に実行されます。各ハンドラの前には、保留中であればマネージャの reload、続いて新しい観測、restart/reload アクション、検証が行われます。途中で停止した実行は新たな reload を開始せず、その場合レポートにはマネージャが未同期であることが記載されます。

audit — 読み取り専用の検証

sinter audit は plan とは異なる問いに答えます。plan は「apply が何を変更するか？」を問い、audit は「ターゲットはすでにレシピと一致しているか？」を問います。同じ読み取り専用の観測経路を使い、変更は一切行わず、各リソースを PASS、DRIFT、NOT_AUDITABLE、 NOT_APPLICABLE、ERROR として決定的な依存関係／実行順で報告します。

command リソースは常に NOT_AUDITABLE です — audit が実行することはありません。
audit は daemon-reload を実行しません。マネージャが NeedDaemonReload=yes を報告する service には、望ましい状態どおり active かつ enabled であっても、独立した manager_reload ドリフトが表示されます。NeedDaemonReload=no は限定的な観測であり、読み込まれている定義がディスク上のファイルと等しいことの証明ではありません。
終了コードは判定を表します: drift も観測エラーもなければ 0、 drift があれば 7、観測エラーがあれば 6（エラーは drift より優先）。終了コード 0 の audit にも NOT_AUDITABLE や NOT_APPLICABLE のリソースが含まれ得るため、全リソースが検証されたと想定せず summary を確認してください。

結果の次元

Sinter は実行、変更、検証、処置を個別に報告するため、changed、 failed、indeterminate、possible、verified、blocked といった状態が boolean に押しつぶされることはありません。

変更に成功した後に後続で失敗した場合でも、変更は誠実に報告されます。
検証の失敗が成功として報告されることはありません。

Fail-fast

最初に失敗または indeterminate になったリソースで実行は停止します。残りのリソースは blocked として報告されます。

ターゲット側の実行

--host を省略するとローカルターゲット、指定すると SSH を使用。
v1.1.0 以降、--inventory でレシピを複数ホストに実行できます。対象はそのレシピ自身の targets が選んだホストだけで、インベントリにあることは実行の許可になりません。targets のないレシピはエラーです。複数ホスト参照。
リモートコマンドは正確な argv で実行されます。意図しないシェル評価はなく、NUL バイトは拒否されます。
--sudo はすべてのターゲット側操作を非対話の sudo -n で root として実行します。Sinter がパーミッション失敗を sudo でリトライすることはありません。
command リソースには固定のベースライン環境（PATH、LANG、 LC_ALL、HOME）が与えられます。コントローラや SSH セッションの環境変数は継承されません。
ファイルシステムの変更は親パスの信頼境界を強制し、予期しないシンボリックリンクを拒否し、rename によるアトミックな公開を行います。
コマンドごとに捕捉される stdout/stderr には上限があります（各 1 MiB）。

パッケージバックエンドの分離（dnf）

RHEL 系ターゲットでは、パッケージのインストールは DNF メタデータキャッシュのプライベートスナップショット経由で行われます: キャッシュのみのメタデータ検証と決定論的なトランザクション解決によって正確なパッケージ identity が凍結され、解決済みの RPM ペイロードはネイティブの dnf/librepo 転送経由でダウンロードされます — リポジトリ認証は dnf/librepo が担います — そして各ペイロードの RPM identity が凍結されたトランザクション集合に対して検証された後、最後にキャッシュのみの dnf によるインストール（-C --setopt=cachedir=...）が実行されます。ペイロードの完全性または identity を証明できない場合、変更の前にフェイルクローズします。プライベートスナップショットは 0700 パーミッションで作成され、失敗時を含めて処理後に削除されます。