犬でも分かるPXEブート(6):kickstartによるOS自動インストール

前回は、OSのインストールメディアを配信するリポジトリーを構築しました。今回は、OSを自動インストールするためのkickstart(キックスタート)の仕組みについて解説します。kickstartもPXEブートの構成要素ではありませんが、PXEブートの後にOSのインストールを自動処理するのにとても便利な機能なので解説します。
PXEブートを含むOSインストールの自動処理のフローの図でいうと、以下の赤線の範囲が対象です。。

kickstartとは何か

kickstart(キックスタート)は、OSのインストールプロセスの一部または全部を自動化するための仕組みです。通常のOSインストールでは、インストーラが提供するGUIから管理者が必要な情報を選択･入力してインストールの処理を進めます。kickstartは、管理者が選択･入力する内容が予め kickstartファイルに定義されていて、インストーラがそれを読み込み、インストールプロセスを自動実行します。

grub.cfgファイルにおいて、カーネルの引数に「inst.ks=<kickstartファイルのURL>」というオプションを指定すると、起動されたインストーラがそのkickstartファイルを読み込みます。

kickstartファイルの作り方

kickstartファイルは、kickstartの構文によって記述することができます。しかし、一から作成するのはとても難易度が高いです。
一番簡単な方法は、一度、インストール対象のマシンにOSを手動インストールして、そのときに自動生成された /root/anaconda-ks.cfg ファイルをコピーして利用することです。何故ならば、そのようにして作成したanaconda-ks.cfg には、対象マシンの
･NICのデバイス名が記述されている
･ストレージのデバイス名とブロックサイズが記述されている
からです。
デバイス名やストレージのブロックサイズは、機器によって異なる場合がありますので、一度手動インストールして調べるのが一番確実です。OSの自動インストールは、2台以上のサーバにOSをインストールする際に効果的なので、1台目は手動インストールするついでに anaconda-ks.cfgを取得し、2台目以降はkickstartで自動化を図る、という考えで進めるのが良いでしょう

自動インストールのために修正する箇所

インストールメディアの指定

1台目(1回目)のOSインストールをDVDからインストールしたのであれば、以下のように記述された箇所があります。今回はHTTPのリポジトリーからのインストールとなるので削除しましょう。

その代わりに、以下の例のようにAppStreamに対するレポジトリを指定して下さい。BaseOSのほうは指定が不要で、AppStreamは明示的に指定する必要があるらしいです。私の環境では、リポジトリーのHTTPサーバのIPアドレスが 192.168.2.203 で、リポジトリーのディレクトリを /var/www/repositories/rhel-8.8-x86_64/ としているので、以下の記述となります。

パーティションの作成

何回か失敗を繰り返しながらkickstartファイルの修正とOSインストールの自動化を進めることを考慮すると、パーティションを毎回初期化して再作成するように書き換えるのが良いでしょう。

と記載されている箇所を、以下の通りに修正します。

SELinuxの無効化

SELinuxを最初から無効化するために、以下の行を追加します。

EULAへの同意

EULAへの同意を自動化するために、以下の行を追加します。

再起動の指示

OSインストール後に自動的に再起動するように、以下の行を追加します。

インストールモードの指定

初期の設定では、インストールモードは以下の通り、グラフィカルモードになっています。

kickstartファイルのデバッグが完了するまでは、グラフィカルモードでkickstartのテストをしていたほうが分かりやすいです。何故なら、コンソールを確認してインストールプロセスを監視していると、エラー箇所で処理が止まり、インストーラのGUI上にエラーメッセージが表示されるからです。
例えば、パーティションの定義にエラーがあれば、
kickstartファイルのデバッグが完了したら、以下の通り、テキストモードに変更しても良いでしょう(テストモードのほうが処理が早いらしい..)。

自動インストールでやらせたいことを追加するには..

インストールするパッケージを追加する

例えば、手動インストールのときに「最小限のインストール」を選択した場合は、anaconda-ks.cfgファイルの packagesセクション は以下の通りになっているはずです。

%packagesから%endまでがpackagesセクションです。@で始まる名前はパッケージグループを差しています。例えば、追加インストールするパッケージグループに 「Development Tools」、追加インストールするパッケージに rear, grub2-efi-x64-modules.noarch, nfs-utils を追加したければ、packagesセクションの記述は以下の通りとなります。

nfs-utilsをインストールしたのは、インストールプロセスの中でNFSのファイルシステムをマウントしたかったからです。理由は後で解説します。

インストール時に追加で処理したいことをpostscriptとして記述する

postセクションには、インストール後に処理したい内容をシェルスクリプトで記述することができます。これをpostscriptと呼びます。postscriptは %post から %end までの範囲に記載します。

「–log=/tmp/postscript.log」では、ここに記述したpostscriptの実行のログの出力先を指定しています。その後、NFSのマウントポイント /home/shareを作成し、NFSサーバ 192.168.2.200 がexportしている /home/shareをNFSでマウントしています。NFSを利用すると、インストールで使用したいファイルやらスクリプトやらを送り込めるので便利です。この例では、インストール直後からパスワードなしでsshログインできるように、作成済の公開鍵を /root/.ssh/authorized_keys にコピーしています。また、予め静的なIPアドレスを定義したネットワークスクリプトを /etc/sysconfig/network-scripts/ifcfg-enp3s にコピーして、再起動後はIPアドレスを静的に割り当てるようにしています。

postscriptとして記述しておくと便利なことの例として、上記の他には以下のようなものがあります。
･ ホスト名の設定
･ EPELパッケージのインストール
･ RHELのサブスクリプション登録(Rocky Lunixの場合は、もちろん不要)
･ PKGのupdate
･ ユーザの登録
･ /etc/fstabにNFSマウントの定義を追加

逆に、postscriptの中には記述できないこともあります。postscriptはインストールプロセスの最後の処理として実行されますが、インストール直後なので、例えば、NetworkManagerが起動していません。従って、nmcli コマンドでネットワーク設定を行おうとしてもエラーになります(だから、上記の例のようにネットワークスクリプトをコピーしておいて、次の起動からその設定が有効になるようにしました)。
また、postscriptの中でPKGのupdateを行った場合に、カーネルもupdateされることもあります。追加したいパッケージがカーネルをupdateした後でないとインストールできないような場合は、一度、再起動して新しいカーネルでシステムを起動してからでないとインストールできません。
このような必要がある場合は、postscriptの中でcron(@reboot で定義する)を仕掛けて、次の再起動の後にcronで呼び出しすると良いかと思います。

広告主へのリンク

このブログにおける関連リンク

･犬でも分かるPXEブート(1):PXEブートとは
･犬でも分かるPXEブート(2):起点は電源ON
･犬でも分かるPXEブート(3):DHCPサーバの構築
･犬でも分かるPXEブート(4):TFTPサーバの構築
･犬でも分かるPXEブート(5):HTTPサーバとリポジトリーの構築
･犬でも分かるPXEブート(7):実際にやってみた