KickstartによるLinuxインストール自動化 (手動トリガー・HTTP連携)

Kickstartシリーズ

Kickstartとは、Linuxのインストールを自動化する機能です。
本シリーズではRHEL, Fedora, CentOS Streamをモデルに紹介します。

一連の記事でKickstartの構成を3パターン紹介します。
今回の記事では、1つ目の構成を紹介します。

本記事は初回のため、Kickstartの概要、及びKickstartファイルの書き方にも言及します。

1. KickstartによるLinuxインストール自動化 (手動トリガー・HTTP連携) ← 今ココ
2. KickstartによるLinuxインストール自動化 (自動トリガー・ローカルディスク接続)
3. KickstartによるLinuxインストール自動化 (自動トリガー・PXEブート連携)

Kickstartの概要

Kickstartとは

Kickstartとは、上述のようなLinuxのインストール作業を自動化する仕組みです。

事前準備として、インストール用の設定値をテキストファイル (Kickstartファイル) に予め記述しておきます。
そしてインストール対象のマシンからそのファイルを読み込むことで、人間の操作を介することなくインストール作業を完了できます。

主なユースケース

Kickstartは、設定の書き方次第ではディスクサイズの違いを吸収して単一の定義ファイルで表現できます。
例えば、/bootに1GiB、/に残り全てといったパーティションサイズの指定が可能です。

絶対ではありませんが、書き方を工夫することで異なるバージョンのディストリビューションを同じKickstartファイルで管理できるケースもあります。
とはいえ、少なくともメジャーバージョンが異なる場合はKickstartファイルを分けたほうが無難です。

VMクローンだとこのようにはいきません。
ディスクサイズやディストリビューションのバージョンなど、ほんの少しでも差分があれば新たなテンプレートVMを用意する必要が出てきます。

テンプレートVMはファイルサイズが大きい上に、UIによっては既存のVMと表示が入り混じって目障りになることもあります。
少ないファイルで多くの構成パターンをカバーできるKickstartは、VMクローンよりも管理しやすさの点で優秀です。

構成概要

今回の構成では、Kickstartファイルのみをネットワーク上に配置します。
インストール対象のVMのローカルには、インストーラのイメージファイルと空のディスクをセットしておきます。

Kickstartのトリガーは手動で行い、KickstartファイルはHTTP(S)、FTP、NFSのいずれかによってダウンロードする構成です。

環境構築は以下の手順で行います。
詳細は#環境構築にて説明します。

1. Kickstartファイルを作成する
2. 作成したKickstartファイルをサーバにアップロードする (今回はHTTPサーバの例を示します)

Kickstartは以下の手順で開始します。
詳細は#Kickstartの実行にて説明します。

1. LinuxをインストールしたいマシンにISOファイルとディスクファイルをセットする
2. ISOファイルから起動する
3. インストーラの画面においてinst.ks=http://...という形式でKickstartファイルのURLを入力してKickstartを開始する

この構成のメリットは以下の2点です。

• Kickstartの構成を組むのがトップクラスに簡単であること
• どのような構成でも容易に実現できる

一方でデメリットは、以下の2点です。

• Kickstart実行時、HTTP/FTP/NFSサーバが起動している必要がある
• inst.ks=...というURLの指定に多少の手間がかかる

環境構築

#構成概要の環境を構築する手順を紹介します。

ここで紹介する手順はRHEL8のマニュアルに準じています。
関係するURLは、#参考URLにてまとめて紹介します。

ISOファイルの入手

CentOS Stream限定のお話となりますが(※)、本記事の手順ではDVD ISOファイルを使用します。
Boot ISOファイルは使用しません。
(※) そして恐らくRHELも同様

ダウンロードするファイル名のイメージは以下のとおりです。

• CentOS-Stream-9-latest-x86_64-dvd1.iso
• CentOS-Stream-9-20220328.0-x86_64-dvd1.iso

以下のBoot ISOファイルではないのでご注意ください。

• CentOS-Stream-9-latest-x86_64-boot.iso
• CentOS-Stream-9-20220328.0-x86_64-boot.iso

DVD ISOファイルが必要な理由については#(参考) DVD ISOファイルが必要な理由にて補足しますので、興味のある方はご確認ください。

Kickstartファイルの雛形の入手

Kickstartファイルは、Linuxを手動でインストールしたときに/root/anaconda-ks.cfgに自動生成します。
このファイルをベースに書き換えて、自分の望む形のKickstartファイルを作成することにします。

今回使うKickstartファイルのベースを以下に示します。
以下のファイルはCentOS Stream9のインストール時に生成したので、centos_stream9というファイル名で保存しておきます。

(※) 末尾のパスワードハッシュ文字列は、平文ではmypasswordです

# Generated by Anaconda 34.25.0.25
# Generated by pykickstart v3.32
#version=RHEL9
# Use graphical install
graphical
repo --name="AppStream" --baseurl=file:///run/install/sources/mount-0000-cdrom/AppStream

%addon com_redhat_kdump --enable --reserve-mb='auto'

%end

# Keyboard layouts
keyboard --vckeymap=jp --xlayouts='jp'
# System language
lang en_US.UTF-8

# Network information
network  --bootproto=dhcp --device=enp1s0 --ipv6=auto --activate
network  --hostname=cs

# Use CDROM installation media
cdrom

%packages
@^minimal-environment

%end

# Run the Setup Agent on first boot
firstboot --enable

# Generated using Blivet version 3.4.0
ignoredisk --only-use=vda
# Partition clearing information
clearpart --none --initlabel
# Disk partitioning information
part pv.111 --fstype="lvmpv" --ondisk=vda --size=39935
part /boot --fstype="ext4" --ondisk=vda --size=1024
volgroup cs --pesize=4096 pv.111
logvol / --fstype="ext4" --size=38908 --name=root --vgname=cs
logvol swap --fstype="swap" --size=1024 --name=swap --vgname=cs

# System timezone
timezone Asia/Tokyo --utc

# Root password
rootpw --iscrypted $6$GMEsgHeNZwjJWb.d$BuP/sn9FX6xKEFGYo8KzNmLB5jPl7RhFQyHnklgrK2CkQntcsT2aOCz4Ozzcefc5J7gXO7IXVvj7KdQOddpv81
user --groups=wheel --name=endy --password=$6$qtY89ARpZJNqk8ap$1u6e3CplnSGpqBppAyd/.f9fheOt74TA.fqMdPsROa3kmSSlHuOyXurBWSr5EHksAemR.3HjDjkI1n6JIeJIk1 --iscrypted --gecos="endy"

この先の操作はお好みで実施ください。

(任意) シンボリックリンクの作成

以下のコマンドで、centos_streamというシンボリックリンクを作成します。

今後何らかの事情でバージョン違いのCentOS Streamをインストールする機会があるかもしれません。
その際、バージョンごとにKickstartファイルを個別に作成して管理するのは手間がかかります。
実際、CentOS Stream9で動作するKickstartファイルは、CentOS Stream8でもほぼ動作します。
そこで、今後CentOS StreamをKickstartでインストールする際は、バージョンに関わらずcentos_streamを参照する運用とします。
これによりKickstartファイルの管理が楽になるだけでなく、centos_streamが実際にどのバージョンを参照しているのか後から追うこともできます。

ln -s centos_stream9 centos_stream

(任意) 元ファイルのバックアップ

この後のセクションで、上記Kickstartファイルを一部書き換えます。
書き換える前に、上記書き換え前のファイルをoriginals/などの別フォルダにバックアップしておきましょう。

こうすることで、Kickstartをどう書き換えたか後から追うことができます。

mkdir originals
cp centos_stream9 originals/centos_stream9

(参考) Kickstartファイルの読み方

ファイルの各行にはインストール時に選択したオプション値が記述されていますが、全てを完璧に理解する必要はありません。
どういった内容かはなんとなく想像できると思いますので、気になったコマンドの仕様を調べて書き換える程度で一旦は良いと思います。

重要なコマンドについては、この後のセクションで紹介します。
コマンドの仕様をより詳細に知りたい場合は、以下のマニュアルをご確認ください。

• RHEL8 - Performing an advanced RHEL installation - B. Kickstart commands and options reference

Kickstartファイルの書き換え

本セクションでは、自動生成したKickstartファイルのうち、パーティションやLVMのサイズを書き換えます。

他にもカスタマイズすることでもっと便利にできますが、こちらは任意でご反映ください。
その他のカスタマイズについては、#(参考) その他のKickstartコマンドにて紹介します。

パーティションサイズの書き換え

自動生成したKickstartファイルには、パーティションやLogical Volumeのサイズが固定値で記述されています。
この部分を動的な表現に書き換えることで、ディスクサイズに応じたサイズの指定が可能となります。

パーティションサイズはpart、LVMのLogical Volumeのサイズはlogvolコマンドで設定されています。
該当箇所を以下に抜き出します。

# Disk partitioning information
part pv.111 --fstype="lvmpv" --ondisk=vda --size=39935
part /boot --fstype="ext4" --ondisk=vda --size=1024
volgroup cs --pesize=4096 pv.111
logvol / --fstype="ext4" --size=38908 --name=root --vgname=cs
logvol swap --fstype="swap" --size=1024 --name=swap --vgname=cs

今回はルートファイルシステムの設定行について、partの--size=xxxを--growに、logvolの--size=xxxを--percent=100に変更します。
これによって、インストール対象のVMのディスクサイズがどのようなサイズであっても、空き容量を全てルートファイルシステムに割り当てることができます。

/以外の/bootやswapのサイズは1GiBだとすると、全体のディスクサイズとルートファイルシステム (/) のサイズの関係は以下のようになります。

ディスクサイズ	/のサイズ
20GiB	18GiB
40GiB	38GiB

上記の実装とするには、以下の2行を変更します。
それぞれの行で--sizeが動的な表現に置き換わっています。

# part pv.111 --fstype="lvmpv" --ondisk=vda --size=39935
part pv.111 --fstype="lvmpv" --ondisk=vda --grow

# logvol / --fstype="ext4" --size=38908 --name=root --vgname=cs
logvol / --fstype="ext4" --percent=100 --name=root --vgname=cs

書き換え後のKickstartファイル

partとlogvolの2行を書き換えた後のKickstartファイルを以下に示します。

# Generated by Anaconda 34.25.0.25
# Generated by pykickstart v3.32
#version=RHEL9
# Use graphical install
graphical
repo --name="AppStream" --baseurl=file:///run/install/sources/mount-0000-cdrom/AppStream

%addon com_redhat_kdump --enable --reserve-mb='auto'

%end

# Keyboard layouts
keyboard --vckeymap=jp --xlayouts='jp'
# System language
lang en_US.UTF-8

# Network information
network  --bootproto=dhcp --device=enp1s0 --ipv6=auto --activate
network  --hostname=cs

# Use CDROM installation media
cdrom

%packages
@^minimal-environment

%end

# Run the Setup Agent on first boot
firstboot --enable

# Generated using Blivet version 3.4.0
ignoredisk --only-use=vda
# Partition clearing information
clearpart --none --initlabel
# Disk partitioning information
part pv.111 --fstype="lvmpv" --ondisk=vda --grow
part /boot --fstype="ext4" --ondisk=vda --size=1024
volgroup cs --pesize=4096 pv.111
logvol / --fstype="ext4" --percent=100 --name=root --vgname=cs
logvol swap --fstype="swap" --size=1024 --name=swap --vgname=cs

# System timezone
timezone Asia/Tokyo --utc

# Root password
rootpw --iscrypted $6$GMEsgHeNZwjJWb.d$BuP/sn9FX6xKEFGYo8KzNmLB5jPl7RhFQyHnklgrK2CkQntcsT2aOCz4Ozzcefc5J7gXO7IXVvj7KdQOddpv81
user --groups=wheel --name=endy --password=$6$qtY89ARpZJNqk8ap$1u6e3CplnSGpqBppAyd/.f9fheOt74TA.fqMdPsROa3kmSSlHuOyXurBWSr5EHksAemR.3HjDjkI1n6JIeJIk1 --iscrypted --gecos="endy"

Kickstartファイルのアップロード

#書き換え後のKickstartファイルで準備したKickstartファイルをHTTP、FTP、またはNFSサーバにアップロードします。

今回はHTTPサーバを建てて、そこにKickstartファイルをアップロードする手順を紹介します。
今回の手順は初期状態のRHEL系ディストリビューション (RHEL/CentOS Stream/Fedora) を想定しています。

まずはHTTPサーバをインストールします。
今回はApache httpdを使用します。

sudo dnf install httpd

HTTPサーバ上にKickstartファイルをアップロードします。
アップロード先のパスは、わかりやすい名称であれば何でも良いと思います。

今回はCentOS Stream用のKickstartファイルを作成するため、/var/www/html/kickstarts/centos_stream9というパスにてファイル作成します。
今後他のディストリビューション用のKickstartファイルを作成したときは、同じ階層にrhel8やfedora35などのファイル名で格納する想定です。

sudo mkdir /var/www/html/kickstarts
sudo vi /var/www/html/kickstarts/centos_stream9

centos_stream9ファイルの中身は、#書き換え後のKickstartファイルの内容を貼り付けます。

firewalldが有効な場合は、HTTP通信を許可しておきます。
デフォルトではcockpitやssh通信は許可されますが、http (TCP80) は拒否されます。

HTTP通信を許可するには、以下のコマンドを実行します。
重要なのは「変更」と「設定反映」の部分です。

# 事前確認。serviceにhttpがないこと
sudo firewall-cmd --list-all

# 変更
sudo firewall-cmd --add-service http --permanent

# 差分比較
diff -u <(sudo firewall-cmd --list-all) <(sudo firewall-cmd --list-all --permanent)
# -public (active)
# +public
#    target: default
#    icmp-block-inversion: no
# -  interfaces: enp1s0
# +  interfaces: 
#    sources: 
# -  services: cockpit dhcpv6-client ssh
# +  services: cockpit dhcpv6-client http ssh
#    ports: 
#    protocols: 
#    forward: yes

# 設定反映
sudo firewall-cmd --reload

# 事後確認
sudo firewall-cmd --list-all

HTTPサーバを起動、及び有効化します。

# sudo systemctl enable httpd; sudo systemctl start httpd と同じ
sudo systemctl enable httpd --now

Kickstartの実行

ここまでの作業で準備は整いました。
いよいよ初期状態の仮想マシンを用意してKickstartを開始します。

(参考) 仮想マシンの作成

KVM配下に仮想マシンを作成する場合を例に、パラメータの例を示します。
詳細はKVMの基本操作集 - #VMの作成をご覧ください。

CockpitからVMを作成する際は、下図のようにパラメータを指定します。
通常のインストール時と同様に、ISOファイルと仮想ディスクをセットします。

virt-installコマンドで仮想マシンを作成する場合は、例えば以下のようなコマンドを実行します。
今回は直ちにコンソール画面を操作したいので、--noautoconsoleを省略しつつ、コマンド末尾に&をつけることでバックグラウンド実行にしています。

virt-install \
--name test \
--memory 2048 \
--vcpus 2 \
--disk size=10 \
--graphics vnc \
--graphics spice \
--os-variant centos-stream9 \
--cdrom /home/shared/libvirt/images/isos/centos/CentOS-Stream-9-latest-x86_64-dvd1.iso &

インストール手順を何度か試したいとも思いますので、作成したVMを停止して削除するコマンドも添えておきます。
--os-variantの指定を省いた場合は、--storage vdaの部分が--storage hdaになることもあります。
詳細はKVMの基本操作集 - #VMの削除を参照してください。

virsh destroy test ; virsh undefine test --storage vda --snapshots-metadata --managed-save

Kickstartによる自動インストール

初回起動時はISOファイルから起動することで、Linuxのインストール画面が表示されます。

ここで "↑" キーを押してxxxにカーソルを合わせ、Tabキーを押下します。
するとブートパラメータが表示されるので、末尾にinst.ks=http://x.x.x.x/kickstarts/centos_stream9を追記します。
x.x.x.xには、構築したWEBサーバのIPアドレスを入力してください。
このパラメータを指定することで、インストール処理の冒頭でKickstartファイルをcurlコマンドでダウンロードします。

パラメータ指定の際は、以下の点をご留意ください。

• キーボードは英字配列
• URL部分は自身の環境に合わせて適切なIPアドレスとファイルパスを指定すること
• inst.ksの部分は、既存のパラメータと半角スペースで区切ること

うまく行けばインストールが自動的に開始され、再起動を促す画面まで一気に進みます。
一部のパラメータ指定に不備があった場合は、その部分のみ手動操作を求められます。

以上でKickstartによる自動インストールは完了です。

残りは参考情報ですので、興味がある部分のみお読みいただければと思います。

(参考) Kickstartでエラーが発生したときの対処法

Kickstartの処理途中でエラーがあった場合、エラーのない箇所のみインストールを進めたところで停止します。

以下の画像のように、追加の操作が必要な箇所には目印が付きます。
問題のある箇所のみ手動でパラメータ指定することでインストール処理が継続します。

Kickstartのエラーが発生した場合は、以下のように対処します。

• GUI画面からエラーの原因を読み解く
• Kickstartファイルを修正する
• Kickstartをリトライする

(参考) その他のKickstartコマンド

#パーティションサイズの書き換え以外にも、Kickstartファイルには色々なカスタマイズが可能です。
全ては紹介しきれませんが、特に興味深いコマンドのみピックアップして説明します。

EULAとfirstbootの無効化

デスクトップ環境などのGUI付きでインストールする場合のみに影響します。
CLI環境には影響ありません。

デフォルトでは、Linuxを初回起動したときにEULA (End User License Agreement) やFirstboot (ウィザード形式の初期設定画面) が表示されます。
これらの画面を無効化するには、eula --agreedを追記し、firstboot --enableを書き換えます。

# Run the Setup Agent on first boot
# firstboot --enable
firstboot --disable
eula --agreed

EULAとFirstbootの画面がどういったものかは、以下のサイトから確認できます。

• RHEL6 - インストールガイド - 第34章 Firstboot
• Red Hat Developer - RHEL 8 Bare Metal Quick Install - #System registration

私の環境ではLinuxをGUI付きで初期インストールすることは滅多にありませんが、これらのオプションは指定しています。

SSH鍵の登録

Kickstartファイル内にSSH公開鍵の情報を記載することで、SSH公開鍵を自動登録できます。
この設定を活用することで、量産したVMにssh-copy-idを実行することなく鍵認証でSSHログインできるので非常に便利です。

鍵の指定は以下のように行います。
sshkeyコマンドに対してSSH鍵登録先のユーザー名、そして登録したい公開鍵の文字列を指定します。
SSH鍵ペアを作成済みであれば、Linuxマシンの場合は~/.ssh/配下にid_rsa.pubなどのファイル名で公開鍵ファイルが存在すると思います。
SSH鍵ペアを未作成の場合は、ssh-keygenコマンドで作成できます。

(※) 以下の公開鍵は既に破棄済みですのでご心配なく...

sshkey --username=root "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCmVHbllSO6gpk4KmzZgWFnPfxiiW2v8zYg+FssH4WRWAg1BZrroKWdsjdMLq1WjJvBdbxEvqD6x6tjSQ1nT4+QIVqLGztNK1A39KOzTDENPSdhVK5EfJMWviquG3u0BonZnBSdn3/mv8ociQ1aZFFAijncNSeZQdkgqzhL5cpched25eyMEjdh3XbRHbbb6LGpIPf/R+V9BVsUYtONOR4YPs0b5RF8K/N09L3yQ3YWmiPAP+3ywsW7U5k9Y81gQyf2yyk3Ci6ZuEHwzdepsFCpAJBSh9wgzR8TufxZTqs2c5kf9hMgw29+id9mwhfj4xc5cnSdCZu9qVByjYEjrT16SwCQQlvDytezMv4Hv9g3/q3nkXuDRmEy0KpvlRLGQeBbrL8m4fGGD9WQ2yMTPJ0BsahfcCHXbTozXODi0a15Eqf1nhslHXAotA+rGomH78wB4PRrZixzKfv0ZtgCVs91BaOrOiwwbGRaTVkio3WaApfUXUWRIwjWgd3HI+EiV1k= endy@pc"

sshkey --username=endy "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCmVHbllSO6gpk4KmzZgWFnPfxiiW2v8zYg+FssH4WRWAg1BZrroKWdsjdMLq1WjJvBdbxEvqD6x6tjSQ1nT4+QIVqLGztNK1A39KOzTDENPSdhVK5EfJMWviquG3u0BonZnBSdn3/mv8ociQ1aZFFAijncNSeZQdkgqzhL5cpched25eyMEjdh3XbRHbbb6LGpIPf/R+V9BVsUYtONOR4YPs0b5RF8K/N09L3yQ3YWmiPAP+3ywsW7U5k9Y81gQyf2yyk3Ci6ZuEHwzdepsFCpAJBSh9wgzR8TufxZTqs2c5kf9hMgw29+id9mwhfj4xc5cnSdCZu9qVByjYEjrT16SwCQQlvDytezMv4Hv9g3/q3nkXuDRmEy0KpvlRLGQeBbrL8m4fGGD9WQ2yMTPJ0BsahfcCHXbTozXODi0a15Eqf1nhslHXAotA+rGomH78wB4PRrZixzKfv0ZtgCVs91BaOrOiwwbGRaTVkio3WaApfUXUWRIwjWgd3HI+EiV1k= endy@pc"

私の環境でも検証環境へのログインを簡略化するため、このオプションを活用しています。

パスワードの変更

ここでは、Kickstartによって自動作成するユーザーのパスワード文字列を変更する方法をご説明します。
rootpwとuserコマンドの後に指定されているパスワード文字列を変更します。
元々は以下のようにハッシュ文字列でパスワードが記述されています。

# Root password
rootpw --iscrypted $6$GMEsgHeNZwjJWb.d$BuP/sn9FX6xKEFGYo8KzNmLB5jPl7RhFQyHnklgrK2CkQntcsT2aOCz4Ozzcefc5J7gXO7IXVvj7KdQOddpv81
user --groups=wheel --name=endy --password=$6$qtY89ARpZJNqk8ap$1u6e3CplnSGpqBppAyd/.f9fheOt74TA.fqMdPsROa3kmSSlHuOyXurBWSr5EHksAemR.3HjDjkI1n6JIeJIk1 --iscrypted --gecos="endy"

パスワード文字列は--isencryptedを--plaintextオプションに書き換えることで平文で表現できます。
しかし、セキュリティの観点からハッシュ文字列でパスワード表記することをおすすめします。
平文に対応するハッシュ文字列を調べるには、以下のコマンドを実行します。
対話式でパスワード入力を2度求められるので入力すると、入力した文字列に対応するハッシュ値が得られます。
以下はパスワード文字列としてmypasswordと入力したときの結果です。

python -c 'import crypt,getpass;pw=getpass.getpass();print(crypt.crypt(pw) if (pw==getpass.getpass("Confirm: ")) else exit())'
# python -c 'import crypt,getpass;pw=getpass.getpass();print(crypt.crypt(pw) if (pw==getpass.getpass("Confirm: ")) else exit())'
# Password: 
# Confirm: 
# $6$roXC8Mf0XMhtK5k5$4a5V/qBhNAoFKDXnWbbMNy4jfCYUmg3cTo0FxpIespWhzEQ/be9AxzgO8tF.hDK89X7LI9b0ZHd8iwywBijzL0

上記スクリプトにはSaltを加えてからハッシュ計算するため、同じ入力値を渡して複数回実行した場合も異なるハッシュ値を得られます。
実際は2つのユーザーに対して同じパスワードを設定する場合も、異なるハッシュ値を渡すことで見かけ上はセキュアにできます。
攻撃者があるユーザーのパスワード文字列を特定した場合、同じパスワード文字列を別のユーザーにも試すと思うので結局意味はありませんが...。

もう一度スクリプトを実行してmypasswordを入力し、以下の文字列を得られたとします。

# $6$D3K4t69AP7mf2VSH$A/7neqAqFNusKz.4LOEUscfDlua.mavpRUgM9/c6kjhKw1XI8MqZjFY9FcBwUjjlcbBIjElyzvDwxpmcfGNAq1

これらの文字列をパスワードとして指定することで、rootユーザーとendyユーザーのパスワードをそれぞれmypasswordに変更します。

rootpw --iscrypted $6$roXC8Mf0XMhtK5k5$4a5V/qBhNAoFKDXnWbbMNy4jfCYUmg3cTo0FxpIespWhzEQ/be9AxzgO8tF.hDK89X7LI9b0ZHd8iwywBijzL0

user --groups=wheel --name=endy --iscrypted --gecos="endy" --password=$6$D3K4t69AP7mf2VSH$A/7neqAqFNusKz.4LOEUscfDlua.mavpRUgM9/c6kjhKw1XI8MqZjFY9FcBwUjjlcbBIjElyzvDwxpmcfGNAq1

最後に補足ですが、userコマンドに指定されている--gecosは、いわゆるfull nameのことです。
認証動作には直接影響しないパラメータですので、わかりやすい名前を設定すると良いでしょう。

インストール完了後の電源オフ、再起動

以下のキーワードによって、インストール完了後の動作を変更することができます。
いずれか一つのみ指定してください。

• halt: 手動インストールの時と同じく、"Reboot"ボタンを表示して停止する
• shutdown: シャットダウンする (poweroffよりも時間がかかる)
• poweroff: 電源を落とす
• reboot: 再起動する

デフォルトはhaltです。
別のパラメータを指定することで、インストールをより完全自動化に近づけることができます。

rebootを指定する場合は注意してください。
起動の優先順位の設定はデフォルトで "disk" がトップになっていると思いますが、CDROMなどがトップに設定されている場合は再起動ループになる可能性があります。
再起動ループになったら気付ける仕組みがあり、その後手動でも良いので強制的に電源OFFできる環境がある場合はrebootにしても問題ないのかなと思います。
そうではない場合は、poweroffかshutdownが便利だと思います。

ただ私のKVM環境では、poweroffを指定した場合も何故かVMが直ちに起動することがありました。
つまり、rebootと同じ挙動になりました。
インストール完了後にshutdown -P nowとpoweroff相当のコマンドを実行した場合は直ちに電源が切れ、再起動することはありませんでした。
poweroffの挙動はハードウェア (仮想マシンの場合はエミュレートされた仮想ハードウェア) に依存するとのことなので、たまに不思議な挙動をしても「そういったものだ」と割り切ることにしています。
参考: poweroff

逆に不思議な挙動が絶対に嫌な場合は、他の選択肢を取るのが良いと思います。
つまり電源を落としたいならshutdown、再起動したいならreboot、ユーザーの操作をはさみたいならhaltということになります。
お使いの環境でpoweroffが安定するかどうかは、実機で何度か検証してご確認ください。

私の環境ではrebootを使用しています。

Post install scriptの追加

Kickstartの処理の最後にスクリプトによる自動処理を混ぜることも可能です。
デフォルトのインタープリタは/bin/shですが、%post --interpreter=/bin/pythonのようにインタープリタを指定することが可能です。
参考: %postセクション

指定方法は簡単で、以下のように%postセクション内にスクリプトを記述するだけです。
以下に例を示します。

最初の2行のtouchコマンドでそれぞれファイルを生成します。
その後、3行目のコマンドで/interpreterファイルを生成し、中に%postセクション内の処理を実行中のシェルコマンドを記述します。

%post
touch /hello
touch /its_a_beautiful_day
echo `ps -p $$ -o comm | tail -1` > /interpreter
%end

上記の処理をKickstartファイルに追記してインストールしたLinuxには、スクリプトに記述したとおりファイルが生成しています。

ls /hello 
# /hello

ls /its_a_beautiful_day 
# /its_a_beautiful_day

cat /interpreter 
# /bin/sh /tmp/ks-script-1rh4gjta

Ansibleのようなオーケストレーションツールを使えば、初期インストール後の処理を記述することは容易です。
ですがKickstartファイルでも同じ処理ができることを知っておくと、検証環境を即席で量産するときに便利なこともあるかもしれませんね。

RHELの場合、%postセクションにsubscription-managerコマンドを記述することでシステムの登録まで自動化する使い方が便利そうです。

私はまっさらなMinimum Installの環境がほしいので、Post install scriptはあまり利用していません。

(参考) DVD ISOファイルが必要な理由

#ISOファイルの入手の補足です。

DVD ISOファイルの場合、ISOファイルの内部にRPMパッケージリポジトリを含みます。
そのため、ISOファイル単体でインストール処理全てを完結できます。

一方で、Boot ISOファイルにはRPMパッケージリポジトリを含みません。
CentOS Stream8/RHEL8以降はAppStreamリポジトリからRPMパッケージをインストールします。
Boot ISOの場合は、オンラインリポジトリを指定する必要があります。
手動インストールの場合は "Closest Repository" を選択することでオンラインリポジトリのURLを意識することなくインストール処理を進めることができます。
ところが、Kickstartファイルには "Closest Repository" 相当のオプションが存在しません。

"Closest Repository" を選択した場合のanaconda-ks.cfgファイルのリポジトリ指定がどのように記載されるかと言うと、現状は「何も記載されません」。
具体的には、repoによるAppStreamリポジトリの指定や、urlやcdromによるRPMインストールソースの指定が何も書いていない状態になります。

通常であればanaconda-ks.cfgファイルをそのままKickstart処理に利用してもKickstartは成功するはずですが、 "Closest Repository" オプションを利用した場合は例外的に失敗します。

"Closest Repository" 相当のKickstartの指定が存在しないことは2013年から指摘されていますが、2022年現在も実装されていません。
したがって、この挙動は今後も変わることはないと思います。
参考: Bugzilla #972265

以上の理由から、Kickstartを実行する際にはRPMパッケージを内包しているDVD ISOファイルを使用してインストールを行います。

参考URL

Red Hat社のマニュアルに一通りの情報が書いてあります。
RHEL8 - Performing an advanced RHEL installation

上記マニュアルの中でも、本記事に特に関連するセクションを抜粋して下表にリンクをまとめました。
一次情報を確認したい方は、以下からご覧ください。

"B. Kickstart commands and options reference" にはKickstartファイルに出てくるコマンドが全て説明されています。
このセクションは、Kickstartファイルを書く方はにとって特に役に立つでしょう。

URL	内容
4. Creating Kickstart files	Kickstartファイルの作り方 今回は4.2のanaconda-ks.cfgを書き換える手法を選択
5. Making Kickstart files available to the installation program	Kickstartファイルの配置方法 今回は5.3のHTTPサーバを利用
7. Starting Kickstart installations	初期状態のサーバを起動後、Kickstartを開始する手順 今回は7.1の手動起動の手順を実施
9. Maintaining Kickstart files	ksvalidatorコマンドのインストール方法、及び使い方
16. Boot options	初期状態のサーバを起動後、Boot Optionを指定する方法 今回は "Editing the > prompt" の手順を実施
A. Kickstart script file format reference	Kickstartファイルの構造 %がセクション、#がコメント 他は知らなくてもほぼ困らない
B. Kickstart commands and options reference	Kickstartファイルに出てくるCommandの意味 本記事で取り扱わなかったコマンドも全て書いてある

まとめ

Kickstartを手動でトリガーし、HTTPを介して外部サーバと連携してインストールを自動化する構成を紹介しました。

Kickstartを手動トリガーするために、インストーラを起動した後にinst.ks=http://xxxという文字列をコンソール画面で入力するのが若干の手間です。
しかし、この構成はどのような環境においても簡単に実現できます。
構築も簡単です。

Kickstartに始めて挑戦するときのお試し構成として、こちらの構成をまずは組んでみるのはいかがでしょうか？
Linuxの手動インストールに比べると、この構成でも十分便利です。
ぜひご活用ください。

関連記事

• KickstartによるLinuxインストール自動化 (自動トリガー・ローカルディスク接続)
• KickstartによるLinuxインストール自動化 (自動トリガー・PXEブート連携)