Red Hat Enterprise Linux

RHEL 9 と RHEL 10 の x86_64 はサポートされ、受入検証済みの管理対象です。 どちらも dnf パッケージバックエンドを使います。

受入基準環境: RHEL 9.8 x86_64 および RHEL 10.2 x86_64 — 実際の SSH と sudo -n 越しに、パッケージのインストール/削除/冪等性、file、 service、command リソースについて検証済みです。ネイティブ認証の リポジトリ経由のパッケージペイロードダウンロードも含みます。 RHEL 9/10 は対応するversion lineであり、9.8 と 10.2 が検証済みの 基準環境です。他の各マイナーリリースを個別に検証した意味ではありません。

要件

要件	補足
RHEL 9 または 10	x86_64
OpenSSH サーバ	厳格な known_hosts 検証
systemd	service リソースに必要
/bin/sh	ターゲット側シェル
attr パッケージ	/usr/bin/getfattr。ターゲットで確認し、不在なら dnf で attr をインストール
sudo -n	--sudo 使用時はパスワードなし sudo
dnf	パッケージバックエンド。構成済みリポジトリが機能している必要あり

パッケージ管理

type: package のレシピはプラットフォーム中立です。同じレシピが RHEL 上では dnf で実行されます:

resources:
  - id: nano
    type: package
    with:
      name: nano
      state: present

標準的に構成された DNF リポジトリが機能している必要があります。 リポジトリの転送と認証はネイティブの dnf/librepo スタックに委任 されます — プロバイダのリポジトリインフラによってエンタイトルメントが 供給済みのクラウドイメージを含みます。Sinter 自体がリポジトリの クレデンシャルを扱うことはなく、Sinter 固有のリポジトリ設定も 不要です。

dnf インストールの仕組み

dnf のインストールでは、変更を行う dnf プロセスがメタデータのために ネットワークに触れることはありません:

1. DNF メタデータキャッシュのプライベートスナップショットが /var/tmp/sinter-dnf.* 配下にモード 0700 で作成される。
2. トランザクション解決とメタデータ検証がスナップショットに対して キャッシュのみで実行され、解決済みパッケージの正確な identity が凍結される。
3. 解決済みの RPM ペイロードがネイティブの dnf/librepo 転送経由で スナップショットへダウンロードされる — リポジトリ認証は dnf/librepo が担う — そして各ペイロードの RPM identity が 凍結されたトランザクション集合に対して検証される。
4. 最終的な変更が dnf -C --setopt=cachedir=<snapshot> で実行される — キャッシュのみ。
5. スナップショットは失敗時を含めて処理後に削除される。

ペイロードの完全性またはidentityを証明できない場合、変更の前に フェイルクローズします。

プラットフォーム検出

/etc/os-release の ID=rhel（RHEL ファミリ）が dnf バックエンドを 選択します。未知または非対応のプラットフォームは capability エラー です。Sinter がバックエンドを推測することはありません。

制限事項

• 検証済みは x86_64 のみ。aarch64 のサポートは想定しないでください。
• RHEL 9.8 と 10.2 が受入基準環境です。他のマイナーリリースは同じ インターフェースを共有しますが、個別には検証されていません。
• ハッシュ化された known_hosts エントリはサポートされません （すべてのターゲットで同じ）。