SLES 15 KVM セットアップ: 選択した仮想マシンを起動時に自動的に起動するように設定
SLES 15 KVMおよびlibvirtツールをインストールし、適切なホストサービスを有効にし、選択した仮想マシンが再起動後に起動するように設定します。
SUSE Linux Enterprise Server 15 上のサードパーティ製ドライバは、コンパイルは正しく完了するものの、「必要なキーが利用できません」または「サービスによってキーが拒否されました」というエラーでロードに失敗する場合があります。UEFI セキュアブートがモジュール署名を強制する場合、カスタムカーネルモジュールを信頼できる証明書で署名し、マシンオーナーキー (MOK) 管理を通じてその証明書を登録してから、セキュアブートを無効にせずにモジュールを通常どおりロードすることで解決できます。
kernel-defaultこの手順は、SUSE shim、カーネル、管理者権限、および信頼できるドライバソースを使用する標準的なSLES 15 UEFIシステムを前提としています。カスタム.koモジュールを対象としており、代替カーネルへの署名やファームウェアプラットフォームキーの変更は対象としていません。以下の例はSLES 15 SP6/SP7の管理モデルに基づいています。インストールされているサービスパックのパッケージとカーネルフレーバーの違いを確認してください。
管理者権限でログインし、実際に起動したカーネルを特定してください。パッケージ名が一致するだけでは、モジュールがそのカーネルにロードできるとは限りません。
uname -r
mokutil --sb-state
ls -ld "/lib/modules/$(uname -r)/build"

セキュアブートが有効になっていると報告されている場合mokutil、信頼できない署名がキー関連のロード失敗の原因である可能性が高いです。無効になっている場合は、キーを生成する前に他の原因を調査してください。明示的なカーネル署名の強制も関係する場合があります。ロード失敗後にカーネルログを確認し、実際の拒否メッセージを確認してください。
sudo journalctl -k -b --no-pager | tail -n 50
インストールする前に、候補モジュールを検査してください。例のファイル名は実際のファイル名に置き換えてください。ファイル名は、vermagic実行中のカーネルリリースおよび互換性のあるビルドプロパティと一致している必要があります。
modinfo -F name /path/to/mydriver.ko
modinfo -F vermagic /path/to/mydriver.ko

まず、ハードウェアまたはソフトウェアのベンダーに、SLES互換で署名済みのカーネルモジュールパッケージ(KMP)を問い合わせてください。バイナリを手動でインストールするよりも、この方法の方が望ましいです。ベンダーによっては、カーネルのアップデート処理や証明書登録の手順を文書化して提供している場合があります。ベンダーの署名は、すべてのセキュアブートマシンで自動的に信頼されるわけではありません。
ドライバをビルドする必要がある場合は、実行中のカーネルに対応する開発ファイルをインストールしてください。kernel-default通常、SLES パッケージには、デフォルトのカーネル開発パッケージ、カーネル開発ファイル、およびビルドツールが含まれています。リポジトリの可用性とバージョンは、登録状況と有効化されている SLES モジュールによって異なります。
sudo zypper install gcc make openssl mokutil kernel-devel kernel-default-devel
rpm -q kernel-default-devel kernel-devel
readlink -f "/lib/modules/$(uname -r)/build"

ビルドディレクトリが存在しない場合、または開発パッケージが別のカーネルリリースを対象としている場合は、まずパッケージとカーネルの不一致を修正してください。新しくインストールしたカーネルの場合、ビルドを行う前に制御された再起動が必要になる場合があります。
信頼できるドライバソースディレクトリから、ベンダーのビルド手順に従ってください。従来のkbuildベースのモジュールの場合、以下のコマンドは実行中のカーネルに対してビルドを実行します。このコマンド自体がドライバをダウンロードしたり作成したりするわけではありません。
cd /path/to/driver-source
make -C "/lib/modules/$(uname -r)/build" M="$PWD" modules

信頼できるベンダーから互換性のあるバイナリを既に入手している場合は、コンパイルをスキップしてください.ko。誤ったバイナリでモジュールを強制的にロードしないでくださいvermagic。署名によって互換性のないバイナリを修復することはできません。
ルート権限のみのディレクトリに、専用のRSA鍵とX.509証明書を生成します。公開証明書は登録されますが、秘密鍵は保護しておく必要があります。秘密鍵を管理する者は、このマシンが信頼する可能性のある追加モジュールに署名できるからです。
sudo -i
umask 077
mkdir -p /root/module-signing
cd /root/module-signing
openssl req -new -x509 -newkey rsa:3072 -sha256 -days 3650 -nodes \
-subj "/CN=SLES Custom Module Signing/" \
-keyout MOK.priv -out MOK.pem
openssl x509 -in MOK.pem -outform DER -out MOK.der
chmod 600 MOK.priv

-nodes簡単な例として、暗号化されていない秘密鍵を作成します。本番環境の署名パイプラインでは、セキュリティポリシーに従って、適切に保護された暗号化鍵または外部署名サービスを使用してください。ここに示されている10年間の有効期間はあくまで例示であり、組織における証明書の有効期間の推奨事項ではありません。
完成したモジュールを実行中のカーネルのモジュールディレクトリにコピーします。パッケージ化、ストリップ、その他のファイル変更を行った後、インストールされたファイルそのものに署名します。mydriverと のパスを、モジュールの実際のベース名と場所に置き換えます。
install -D -m 0644 /path/to/mydriver.ko \
"/lib/modules/$(uname -r)/extra/mydriver.ko"
SIGN_FILE="$(readlink -f /lib/modules/$(uname -r)/build)/scripts/sign-file"
test -x "$SIGN_FILE" || echo "Locate the sign-file binary for this kernel"
"$SIGN_FILE" sha256 /root/module-signing/MOK.priv \
/root/module-signing/MOK.der \
"/lib/modules/$(uname -r)/extra/mydriver.ko"
modinfo -F signer "/lib/modules/$(uname -r)/extra/mydriver.ko"

そのパスにツールが存在しない場合はsign-file、無関係なバージョンをコピーするのではなく、対応するカーネルビルドファイルに同梱されているツールを探してください。署名者が表示されている場合は、ファイルに署名メタデータが含まれていることを意味しますが、署名者が登録されていることを証明するものではありません。署名後にモジュールを削除したり変更したりしないでください。
DER形式の公開証明書(ではなく)をインポートしMOK.priv、によって要求されるワンタイム登録パスワードを設定しますmokutil。再起動する前にコンソールアクセスを設定してください。認証はSSHシェルではなく、起動時のMokManagerインターフェースで行われます。
mokutil --import /root/module-signing/MOK.der
mokutil --list-new
reboot

次回の起動時に「MOK登録」を選択し、確認プロンプトに従ってワンタイムパスワードを入力し、起動を続行してください。メニューの表示はファームウェアとシムのバージョンによって異なります。登録を確認せずにLinuxに戻ると、新しい証明書は信頼されない状態になります。
起動後、特定の証明書が登録されていることを確認してください。
sudo mokutil --test-key /root/module-signing/MOK.der
sudo mokutil --list-enrolled
モジュールの依存関係メタデータを更新し、モジュールをファイルパス全体ではなく名前でロードします。modprobe依存関係を解決し、標準のモジュール構成を尊重します。
sudo depmod -a
sudo modprobe mydriver
lsmod | grep -w mydriver
modinfo -F signer mydriver

それでも読み込みが失敗する場合は、証拠に合致する是正措置を選択してください。
mokutil --test-key。インストールしたファイルが署名済みのファイルであることを確認し、ドライバのアップデートによって置き換えられていないか確認してください。modinfo -F vermagicと比較しuname -r、アクティブなカーネル用に再ビルドし、CPUアーキテクチャを確認してください。journalctl -k -bベンダーの必須モジュールとカーネル ABIを調べてください。別の署名を使用しても不足しているシンボルは修正されません。起動時に重要なストレージドライバやネットワークドライバについては、まず非本番システムでテストを行い、リカバリコンソールが利用可能であることを確認してください。ドライバが確実に動作することを確認してから、自動ロードを設定してください。/etc/modules-load.d/デバイス検出時にロードされないモジュールについては、SUSEのドキュメントを参照してください。
永続的な読み込みが重要な場合は、メンテナンスウィンドウ内で再度再起動してください。セキュアブートが有効になっていること、公開鍵が登録されていること、モジュールが存在すること、カーネルが新たな検証エラーや互換性エラーを報告していないことを確認してください。.koカーネルまたはベンダードライバのアップグレード後、更新版を再構築または再インストールして署名してください。
mokutil --sb-state
sudo mokutil --test-key /root/module-signing/MOK.der
modinfo -F signer mydriver
lsmod | grep -w mydriver
sudo journalctl -k -b --no-pager | tail -n 30
主要なドキュメント: SUSE SLES 15 SP6: UEFI およびマシン所有者キー、SUSE: カーネルモジュールの管理、Linux カーネル: モジュール署名機能、Linux カーネル: 外部モジュールの構築。SLES 15 SP6 管理ガイドは 2026 年 9 月 17 日に更新されました。サードパーティ製ドライバインストーラおよびデフォルト以外のカーネルフレーバーのコマンド動作については、それぞれのメンテナに確認してください。
SLES 15 KVMおよびlibvirtツールをインストールし、適切なホストサービスを有効にし、選択した仮想マシンが再起動後に起動するように設定します。
systemdジョブと前回の起動ジャーナルを使用して、遅いサービス、マウント、またはストレージの依存関係を特定し、原因を隠蔽することなく修正します。
firewall-cmd を使用してアクティブゾーンを検査し、HTTP を安全に許可し、SSH アクセスを維持し、SLES 15 でルールが再読み込み後も有効であることを確認します。
PAMの障害が発生した原因を、サービス、アカウントポリシー、またはIDプロバイダーに特定し、正常に動作する管理者セッションを維持しながら、適切なSLES構成を修復します。
セキュアブートを無効にせずに、カスタムSLES 15カーネルモジュールをロードします。実行中のカーネルと一致させ、.koファイルに署名し、MOKキーを登録し、ロードが成功したことを確認します。
NextcloudのファイルとMariaDBをまとめてバックアップし、cronを使って暗号化されたResticスナップショットをスケジュール設定し、稼働中のサーバーにリスクを負わせることなく復旧を検証します。
Zimbra Community Editionの個々のメールボックスをエクスポートし、そのTGZバックアップを検証し、既存のメールを上書きすることなく、不足しているアイテムを復元します。
システムツリーの準備、ブート統合、デプロイメントチェック、ロールバックなど、仮想マシン上でDebianベースのOSTreeデスクトップを作成およびテストする方法を学びます。
Keycloakとトークン認証を使用してJitsi Meetルームを開始できるのは承認済みのアカウントのみとし、必要に応じてゲスト参加も可能にする。
ONLYOFFICE DocSpaceをActive DirectoryまたはOpenLDAPに接続し、ユーザーとグループを安全にインポートし、アカウントフィールドをマッピングし、信頼性の高い同期をスケジュールします。