Linux システムのイメージの再作成

以前にインストール・メディアからインポートされたイメージをデプロイすることにより、Linux システムのイメージを再作成できます。

Linux ターゲット・システムのイメージを再作成する場合は、以前に ISO イメージから作成され、イメージ・ライブラリーに保管されたイメージ・ファイル (.LIM) をインストールします。デプロイできるイメージのタイプは「セットアップ」であり、「イメージ・ライブラリー」ダッシュボードの Origin フィールドによって識別されます。

イメージの再作成モード (アップグレードまたはインストール) に応じて、ターゲット・デプロイメントに必要なパラメーターを指定するよう求められます。指定したパラメーターをテンプレートに保存してから、「イメージの再作成」タスクを開始する必要があります。詳しくは、「テンプレートの管理」を参照してください。

注: ポート 8088 を listen するイメージ・プロバイダー・コンポーネントへの HTTP アクセスが必要です。詳しくは、「ベア・メタル OS Deployment サーバーが使用するポート」を参照してください。

Linux システムのイメージ再作成は、以下の 2 種類のモードで行うことができます。

アップグレード

このモードを選択した場合は、ターゲット上のオペレーティング・システムの RPM パッケージ・マネージャー・ファイル (.rpm) が、必要なレベルで更新されます。オプションで、ターゲットにインストールされている Endpoint Manager クライアントをアップグレードすることを選択できます。

インストール

このモードを選択した場合は、選択されたイメージがターゲット・システムにインストールされます。現行システムのデータは、新規インストールによって上書きされます。デフォルトでは、ターゲット上のディスクは再パーティション化されます。ターゲット上の以下の既存の設定は保持され、イメージが再作成されたシステムにコピーされます。

マシン ID (言語、キーボード、タイム・ゾーン、ネットワーク設定)
BigFix クライアント ID

注: 場合によっては、BigFix クライアント ID が保持されないことがあります。詳しくは、「Linux イメージ再作成後のサーバー・データベース内で重複するクライアント・コンピューター・エントリー」を参照してください。

重要:

プロキシー・サーバーによって管理されたターゲットに対するイメージ再作成はサポートされていません。
認証リレーに接続されているターゲットへのイメージの再作成はサポートされていません。
キャプチャーしたイメージの再作成はサポートされていません。
Ubuntu システムのイメージの再作成はサポートされていません。
アップグレードを行う前に、システムをバックアップすることをお勧めします。

「イメージ・ライブラリー」ダッシュボードから、デプロイする Linux ソース・イメージを選択して、「コンピューターに適用」をクリックします。

Linux 構成オプション

イメージの再作成プロセスでは、どちらのイメージ再作成モードでも、デプロイメント時に構成ファイルが使用されます。デフォルトの構成ファイルは、「イメージをコンピューターに適用」ダイアログの対応するフィールドに表示されます。このファイルには、最も一般的なパッケージのインストールに対する基本システム構成が含まれます。また、インストール・モードの場合のみ、標準パーティション・レイアウトのシステム構成も含まれます。

「イメージの再作成」タスクの実行中に、マシン ID を宛先イメージにコピーするために、構成ファイルがターゲット・システム上で更新されます。この目的で、言語、キーボード、タイム・ゾーン、およびネットワーク設定が実行時に追加されます。この動作をオーバーライドするには、構成ファイルを編集して、これらの設定の値を指定します。指定した値が、ターゲットでデフォルト値の代わりに使用されます。

サポートされている Linux オペレーティング・システムの構成ファイルのカスタマイズについて詳しくは、特定の Linux ベンダーの資料を参照してください。例えば、バージョン 6 の RedHat Enterprise Linux Kickstart 構成ファイルのオプションについての情報は、以下のリンクで確認できます。https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ch-kickstart2.htmlバージョン 11 SP3 用の SUSE Linux Enterprise Server コントロール・ファイルについては、以下のリンクを参照してください。http://doc.opensuse.org/projects/autoyast/index.html.

有効なイメージ再作成の組み合わせ

以下の表に、「インストール」モードで有効なイメージ再作成の組み合わせをリストします。

表 1. Linux イメージ再作成の組み合わせ - インストール・モードインストール・モードでのイメージの再作成の可能な組み合わせ
アーキテクチャー (再作成前/再作成後)	配分	OS の組み合わせ (再作成前/再作成後)
32 ビットから 32 ビットへ 32 ビットから 64 ビットへ 64 ビットから 64 ビットへ	RHEL から RHEL へ CentOS から CentOS へ SLES/SLED から SLES/SLED	RHEL 6.x から RHEL 6.x、7.x へ RHEL 7.x から RHEL 7.x、8.x へ RHEL 8.x から RHEL 8.x、9.x へ RHEL 9.x から RHEL 9.x へ CentOS 7.x から CentOS 7.x、8.x へ CentOS 8.x から CentOS 8.x へ SLES 11.x から SLES 11.x へ SLED 11.x から SLED 11.x へ SLES 12.x から SLES 12.x へ SLED 12.x から SLED 12.x へ SLES 11.x から SLE 15.x へ SLES/SLED 12.x から SLE 15.x へ SLE 15.x から SLE 15.x へ

以下の表に、「アップグレード」モードで有効なイメージ再作成の組み合わせをリストします。

表 2. Linux イメージ再作成の組み合わせ - アップグレード・モード
アーキテクチャー (再作成前/再作成後)	配分	OS/SP の組み合わせ (再作成前/再作成後)
32 ビットから 32 ビットへ 64 ビットから 64 ビットへ	RHEL から RHEL へ	バージョン 6.x から 6.x+n へ
		バージョン 6.10 から 7.9 へ
		バージョン 7.x から 7.x+n へ
		バージョン 8.x から 8.x+n へ
		バージョン 8.8 から 9.2 へ
		バージョン 8.9 から 9.3 へ
		バージョン 8.10 から 9.4 以降へ
		バージョン 9.x から 9.x+n へ
		Server 6.10 から Server 7.9 へ
		Server 7.9 から Server 8.10 および 8.10 へ
64 ビットから 64 ビットへ	CentOS から CentOS へ	バージョン 7.x から 7.x+n へ
64 ビットから 64 ビットへ	CentOS から CentOS へ	バージョン 8.x から 8.x+n へ
32 ビットから 32 ビットへ 64 ビットから 64 ビットへ	SLES から SLES へ SLED から SLED	バージョン 11.x から 11.x+1 へ
		バージョン 11.3 以降から 12.x へ
		バージョン 12.x から 12.x+n¹ へ
		バージョン 12.x から 15.x¹ へ
		バージョン 15.x から 15.x+n¹ へ

注:

選択した OS の組み合わせが製造メーカーによって推奨されていない場合は、「アップグレードの強制」を選択してアクションを実行します。

重要:

CentOS 7.x から CentOS 8.x へのアップグレードはサポートされていません。
64 ビット・アーキテクチャーの場合、BIOS ターゲットと UEFI ターゲットの両方がサポートされています。

SLE15 にアップグレードするには、必要なすべてのモジュールおよびリポジトリーを選択することで、イメージの再作成テンプレートの構成ファイルを正しく編集する必要があります。実行中の SLE15 ターゲットでは、モジュールのリストは /etc/zypp/repos.d にあります。ただし、リストには OS のインストール後にインストールされたパッケージは含まれません。

ガイドラインとして、構成ファイルは、使用可能なすべてのモジュールのコメント付きリストを報告します。BaseSystem モジュールは必須であるため、コメントは外されます。システムの要件に応じて、他のモジュールのコメントを外す必要があります。

アップグレード・モードでのイメージの再作成

「イメージをコンピューターに適用」ダイアログで、「アップグレード」を選択します。

このモードは、同一メジャー・リリースの新しいサービス・パックへのアップグレード、および RHEL が指定するバージョン 6 から 7、7 から 8、9 から 10 へのアップグレード・パス限定で利用できます。ただし、利用可能な場合、「アップグレードの強制」にチェック・マークを付けたときは、メジャー・リリースへのアップグレードが強制されるため、デプロイメントが正常に完了しない可能性があります。指定されていないアップグレード・パスの場合は、メジャー・リリースを変更するときは、インストール・モードを使用する必要があります。

アップグレード・モードの場合、必須パラメーターはありません。必要に応じて、BigFix clientのアップグレードを選択できます。これを行うには、該当するオプションにチェックマークを入れます。その後、クライアント・パッケージのバージョンを選択するよう求めるプロンプトが出されます。選択したすべての内容をテンプレートに保存する必要があります。選択内容をデフォルト・テンプレートに保存するか、または新規テンプレートに保存することを選択できます。あるいは、ダイアログに、以前に保存したテンプレートからの設定値を取り込むこともできます。インストーラー応答ファイルに保管されてアップグレードに使用される、デフォルト構成パラメーターが表示されます。イメージ再作成のニーズに合わせて、これらのパラメーターを変更できます。必要に応じて、Linux インストーラーがインストール時に使用する追加のカーネル・パラメーターや、ターゲットの任意のクライアント設定を指定できます。

RHEL インプレース・アップグレード

RHEL インプレース・アップグレードでサポートされているアップグレード・パスは、RHEL Server バージョン 6.10 から 7.9、RHEL Server バージョン 7.9 から 8.8 および 8.10、RHEL バージョン 8.8 から 9.2、RHEL バージョン 8.9 から 9.3、そして RHEL バージョン 8.10 から 9.4 以降です。インプレース・アップグレードを実行する前に、それぞれのアップグレードに対応する以下のリンクで条件と警告を確認する必要があります。

RHEL バージョン 6 から 7 のインプレース・アップグレード - https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html-single/upgrading_from_rhel_6_to_rhel_7/index。
RHEL バージョン 7 から 8 のインプレース・アップグレード - https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html-single/upgrading_from_rhel_7_to_rhel_8/index。
RHEL バージョン 8 から 9 のインプレース・アップグレード - https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/upgrading_from_rhel_8_to_rhel_9/planning-an-upgrade-to-rhel-9_upgrading-from-rhel-8-to-rhel-9。

タスクを続行する前に、特定の初期 OS 用のインプレース・アップグレード OS リソースを作成する必要があります。このリンクで利用可能な詳細 - https://help.hcl-software.com/bigfix/10.0/lifecycle/Lifecycle/OSD_Users_Guide/c_manage_linux_dep_media.html。インプレース・アップグレード・タスク (評価のみ、または実際のアップグレード) を実行するには、このドキュメントと Red Hat のドキュメントでインプレース・アップグレードの手順と警告を確認したことを示す免責事項に同意する必要があります。

免責事項に同意した後は、次のさまざまなオプションを選択できます。

RHEL バージョン 6 から 7 へのインプレース・アップグレードの場合: 評価のみを実行するか、実際のアップグレードを実行するかを選択できます。
- 「評価のみ」: このオプションは、コンピューターで評価のみを実行する場合に選択します。このオプションを使用しても、実際のアップグレードに備えてコンピューター上で変更を行うことができます。このオプションを実行した場合、コンピューターが実際のアップグレードを実行できる状態であればタスクは成功しますが、アップグレードは開始されません。ただし、このオプションを選択しなかった場合は、評価がコンピューター上で実行され、成功した場合は実際のアップグレードが開始されます。
- 「極度のリスクを許容」: 評価における極めて高いレベルのリスクを許容し、「評価のみ」オプションが選択されていない場合に実際のアップグレードを開始するには、このオプションを選択します。
注: 極度のリスクを許容しない場合でも、「評価のみ」オプションを選択しないと、高レベルのリスクが存在する状態でもアップグレードが実行されます。極めて高いリスクを許容する前にレポートを確認する場合、または存在するリスクとそのレベルを確認する場合は、極めて高いリスクを許容せずに評価を実行し、レポートを確認できます。テキスト・レポート・ファイルは、<bigfix client logs directory>/DeploymentLogs/preyumupgrad.log であり、タスクの実行後にアクセスできます。
RHEL バージョン 7 から 8 へ、および RHEL バージョン 8 から 9 へのインプレース・アップグレードの場合:
- 「評価のみ」: RHEL バージョン 6 から 7 へのインプレース・アップグレードと同じです。
- 「既知の阻害要因の修正」: インプレース・アップグレードを妨げる可能性のある既知の一部の阻害要因を修正するには、このオプションを選択します。他の阻害要因はインプレース・アップグレードをブロックする可能性があり、タスクを再起動する前に手動で修正する必要があります。Fixlet が修正する阻害要因は、次のとおりです。
  - RHEL バージョン 7 から 8 へのインプレース・アップグレードの場合:
    1. floppy モジュールおよび pata_acpi モジュールを削除します。
    2. アップグレード中に pam_pkcs11 モジュールの削除を受け入れることを確認します。
  - RHEL バージョン 8 から 9 へのインプレース・アップグレードの場合:
    1. Red Hat のデフォルト・ファイアウォール設定をこの設定で変更します AllowZoneDrifting=no
    2. ssh daemon configuration (設定 PermitRootLogin no) で、ルート・ユーザー・ログインを無効にします
    3. システムに VDO デバイスが存在しないか、すべての VDO デバイスが LVM 管理に正常に変換されていることを確認します。
    詳しくは、Red Hat の資料を参照してください。何をすべきかに同意しない場合は、「既知の阻害要因の修正」オプションを選択しないでください。既知の阻害要因を手動で修正済みの場合、このオプションを選択して阻害要因を修正すると、手動による修正が上書きされる可能性があります。そのため、手動修正後はこのオプションを選択しないでください。

インストール・モードでのイメージの再作成

「イメージをコンピューターに適用」ダイアログで、「インストール」を選択します。

前に保存したテンプレートを選択するか、新規テンプレートを作成して現行の設定を保存するか、あるいは選択内容をデフォルト・テンプレートに保存します。インストール・モードでイメージを再作成すると、BigFix clientがインストールされます。デフォルトのバージョンは、BigFix serverと同じバージョンです。「クライアント・バージョン」を展開して、別のバージョンを選択できます。ターゲットのルート・パスワードを指定するか、あるいは、以前に保存され、正しいルート・パスワードが含まれているテンプレートを選択する必要があります。

「クライアント・トラフィックを許可」オプションは、デフォルトで選択されています。ターゲットのオペレーティング・システム・ファイアウォールが有効にされている場合、このオプションを使用することで、サーバーからのインバウンド UDP トラフィックを正常に受信できます。このオプションをクリアする場合、Fixlet 678 または 682 (オペレーティング・システムのタイプに依存) を使用して、インバウンド・トラフィックを許可する必要があります。詳しくは、『ファイアウォール設定の変更』を参照してください。

SELinux ポリシー

このフィールドは、RHEL と CentOS でのみ使用可能です。SELinux Policy オプションを使用すると、適用する SELinux ポリシーを選択できます。値は以下のとおりです。

default: ポリシーを指定しない場合、オペレーティング・システムにはデフォルトのポリシーが適用されます。
disabled: SELinux ポリシーを disabled として構成します。
permissive: SELinux ポリシーを permissive として構成します。
enforcing: SELinux ポリシーを enforcing として構成します。この SELinux ポリシーを選択すると、構成されたタイプは自動的に「Targeted」として設定されます。
注: SELinux サポートでは、ポリシーが指定されていない場合は、デプロイされる OS レベルのデフォルトになります。継続して SELinux ポリシーを無効にしたい場合は、イメージの再作成テンプレートを編集して、その値を disabled として設定します。

インストーラー応答ファイルに保管されている、インストール用のデフォルトのデプロイメント構成パラメーターが表示されます。イメージ再作成のニーズに合わせて、これらのパラメーターを変更できます。必要に応じて、Linux インストーラーがインストール時に使用する追加のカーネル・パラメーターや、ターゲットの任意のクライアント設定を指定できます。

Linux システムのイメージ再作成タスクの使用

Linux システムのイメージ再作成タスクを使用して、Linux ターゲットのイメージを再作成できます。イメージとそれに関連付けられた構成テンプレート (前に作成してイメージ・ライブラリーに保存した、イメージ再作成プロセスに使用する設定が含まれる構成テンプレート) を選択します。インストール・モードでイメージを再作成する場合は、ターゲット・システムのルート・パスワードを指定します。平文のパスワードまたは暗号化されたパスワードのいずれかを指定できます。いずれの場合も、パスワードは、デプロイメント・プロセス中に必ず暗号化されます。

必要に応じて、インストーラーのブート時のカーネル・パラメーター、およびクライアント設定を指定できます。

選択したターゲットでイメージ再作成を正常に実行するには、これらのターゲットが接続されているリレーで、イメージ・プロバイダー・コンポーネントが実行されている必要があります。

タスクの実行中に、Linux インストーラーのブート・ファイルが /boot/OSD_XX (ターゲットが BIOS の場合) または /boot/efi/OSD_XX (ターゲットが UEFI の場合) に保存されます。ここで、XX はランダムに生成された数値です。

タスクの最終ステップで、ターゲットのリブート後に Linux インストーラーが開始されるように、元のブート・ローダー・シーケンスが変更されます。元のブート・ローダー構成ファイルは、/tmp/BOOTLOADER.rbobkp に保存されます。ここで、BOOTLOADER は、ターゲット上のブート・ローダーに応じて grub.conf または elilo.conf のいずれかになります。

パスワードの暗号化

イメージを再作成するために指定するルート・パスワードは、平文にすることも、対応する Linux インストーラーでサポートされている任意の暗号化方式を使用して暗号化することもできます。

「ソルト」ストリング値を使用して、以下の形式で暗号化パスワードを生成できます。

$id$mysalt$mypassword

ここで、mysalt は文字ストリングです。この文字ストリングに先行する "$id$" に含まれる id の値が、暗号化方式を識別します。文字ストリングの末尾にある "$" の後に、実際のパスワード・ストリングが続きます。salt ストリングの最大長は 16 文字です。

以下の方式 (id に許可される値) がサポートされます。

表 3. 一般にサポートされる暗号化方式および対応する ID
ID	方法
1	MD5
2a	Blowfish アルゴリズム
5	SHA-256
6	SHA-512

例 1:

MD5 を使用した暗号化:

# openssl passwd -1 -salt my_key
Password: mypassword

$1$my_key$jVY4Txf5wMoEsJX3ieQaR0

例 2:

SHA-512 を使用した暗号化:

# python -c 'import crypt; print crypt.crypt("mypassword", "$6$my_key")'

$6$my_key$2Wz7.0skHT/FQI3yy9TbjPtLjjRq9cmU.TjnPGHWu4WUjemTR/
.TdaK68y2E63cxdxVaD58i64dyQIpnabUjz/

ファイアウォール設定の変更

オペレーティング・システムでファイアウォールが有効になっているターゲットに対して、BigFix serverからイメージ再作成アクションが実行される場合は、インバウンド UDP トラフィックがブロックされるため、ターゲットはすぐにはアクションを受信しません。ターゲットは、新規アクション・サイトを収集するまで (通常は 1 日に 1 回発生)、通知パケットを受信しません。ターゲットでアクションが適時に受信されるようにするには、BES サポート・サイトにある以下の Fixlet を使用して、サーバーからのインバウンド UDP トラフィックを許可するようにファイアウォール設定を変更します。

RedHat ファイアウォールが BES トラフィックをブロック - BES クライアント (678)
SuSE ファイアウォールが BES トラフィックをブロック - BES クライアント (682)

Fixlet 678 または 682 を実行すると、ウィザードで「クライアント・トラフィックの許可」チェック・ボックスを選択する場合と同じ効果があります。これらの Fixlet は、サーバー自動化プランに含めることもできます。