このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。ここに書いてある情報を利用する際には、ほかの文献、オフィシャルなサイトも確認して、自己責任にて利用してください。

KickStart

HOME

オフィシャルドキュメント[ja]： Red Hat Support

RHEL4ドキュメント： RHEL4 System Administration Guide
JF： RedHat Linux KickStart HOWTO (激しく時代遅れ)

KickStart

「キックスタート」とは、RedHat Linux や Fedora Core のインストールを自動化する仕組みのことであり、 Windows で言えば
Unattended Install (無人セットアップ) がこれに当たる。再び Windows に例えると、無人セットアップ応答ファイルに当たるのが
ks.cfg というテキストファイルで、このファイルは RedHat 系システムのインストーラである
anaconda (正体は python スクリプトを中心とした実行ファイル群) への指示書である。詳細は RedHat
サポートサイトにある「RedHat Enterprise Linux システム管理ガイド」 (現状では RHEL3 のものが分かりやすい)
であらかた説明されているが、ここでは、リファレンスガイドに不足している情報を並べることにする。

Table of Contents

system-config-kickstartユーティリティ

稼働中のシステム構成からキックスタートファイルを作る

system-config-kickstartで未サポートの項目と説明不足な項目

SELinuxの設定

LVMの構成

リモートインストールの指定方法

ポストインストールスクリプト記述のコツ

パッケージ選択

パッケージグループ定義の正体はXMLファイル

`Minimum'
パッケージ構成をキックスタート形式で表すと？

キックスタートインストールの実行方法

system-config-kickstart ユーティリティ

Fedora Core には system-config-kickstart というユーティリティ
(RHエンタープライズでは redhat-* ) が付属しており、 GUI
上でキックスタートファイルが生成できる。ただし、少なくとも Fedora Core 3 付属の system-config-kickstart では、実際の anaconda
インストーラ画面やキックスタートファイルでサポートされている項目のうち、幾つかが欠けている。とはいえ便利は便利なので、 system-config-kickstart
で一応の叩き台を作り、パースされたファイルをテキストエディタで煮詰めるという方法がお勧めだ。

なお、 RedHat や Fedora Core をインストールすると、 root のホームディレクトリに anaconda-ks.cfg
というファイルができ、その時のインストール構成がキックスタートファイルのフォーマットで残る。そのファイルを使ってキックスタートインストールを行えば全く同じ構成のシステムができるわけだが、キックスタートファイルの書き方の見本としても興味深い。

稼働中のシステムの構成からキックスタートファイルを作る

system-config-kickstart
には、現在稼働中のシステムの構成をキックスタートファイルとして書き出す機能もある。現在のシステムのインストール状態をカレントディレクトリの ks_curr.cfg というファイルに書き出すには：

/usr/sbin/system-config-kickstart --generate ks_curr.cfg

とコマンドする。 --generate オプションの時に限っては GUI は使われないので、
X-WIndow をインストールしていないシステムでも使える。こうして書き出されたキックスタートファイルのパッケージ (%packages)
セクションでは、グループ単位の記述は使われず、パッケージが全て個別にリストされる。依存関係を敢えて無視して煮詰めてきたパッケージ構成を、新しくインストールするシステムに正確に反映させるためには、
%packages の行を `%packages
--ignoredeps' と修正する必要があるだろう。

system-config-kickstart で未サポートの項目と説明不足な項目

SELinuxの設定

SELinux の設定はキックスタートファイル自体ではサポートされているのだが system-config-kickstart には呼応する項目がない。キックスタートファイルでの記述方法：

SELinux --disabled/--permissive/--enforcing

インストール画面での `WARN' は上記のうち --permissive に当たる。 SELinux 行を書かない場合のデフォルトは --enforcing。

LVMの構成

LVM 項目は system-config-kickstart にはないので、ファイルシステムに
LVM を導入したければ、手動でキックスタートファイルを編集しなければならない。キックスタートファイルでのパーティショニング部分の記述例を示す。

clearpart --linux
part /boot --fstype "ext3" --size=76 --ondisk=hda
part pv.2 --ondisk=hda --size=10240
part pv.3 --ondisk=hdb --size=1 --grow
volgroup VolGroup00 pv.2 pv.3
logvol / --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=3036
logvol /home --fstype ext3 --name=LogVol01 --vgname=VolGroup00 --size=4192
logvol /var --fstype ext3 --name=LogVol02 --vgname=VolGroup00 --size=2488
logvol swap --fstype swap --name=LogVol03 --vgname=VolGroup00 --size=512

上記は、いろいろなディレクティブが現れるようにほんの少し非現実的に構成した例。 1 番目のディスクにまず通常のプライマリパーティション /boot を作成。あとは全て LVM 構成で、 1 番目のディスクの残り部分には 10 GB のフィジカルボリューム、
2 番目のディスクには全域を使ってフィジカルボリュームを作成。それらふたつの PV をボリュームグループ VolGroup00 に束ねて、その中にロジカルボリュームを 4 つ切っている。

リモートインストールの指定方法

HTTP や FTP 経由でパッケージを引っ張ってくる場合、ディレクトリの指定には、 CD-ROM のルートディレクトリと同じ構造を持つ階層 -- つまり
Fedora/base
というディレクトリ構造のひとつ上の階層を指定する。実際のインストーラ画面での手順をおさらいしておくと：

最初の boot: プロンプトで `linux
askmethod' と打ち込み

インストール方法の選択画面で FTP か HTTP を選び

Site Name 欄に例えば `ftp.kddilabs.jp' をタイプし

Fedora Core Directory 欄に `/Linux/packages/fedora/core/3/i386/os' などと入れる。

という回りくどい手順を踏むわけだが、キックスタートファイルではたった 1 行のディレクティブとなる：

url --url http://ftp.kddilabs.jp/Linux/packages/fedora/core/3/i386/os

ポストインストールスクリプト記述のコツ

POSTインストールスクリプトとは、パーティショニングやパッケージのインストールが完了した後に走らせる処理のことで、キックスタートファイルでは %post というコマンド行から始まる。 %post
セクションを置くなら、必ずキックスタートファイルの最後でなければならない。そのセクションに書いた処理は、正規のポストインストール処理に先立って実行される。ポストインストールスクリプトを書く上でのポイントを幾つか挙げておく：

インストール先ディスクは /mnt/sysimage/ にマウントされた形になっている。

デフォルトでは、ポストインストール処理は /mnt/sysimage/ へ chroot
した状態で行われる。ちなみに PRE インストールスクリプトでは chroot は行われない。

上記の理由により、ソースメディアからファイルをコピーしたり RPM ファイルを読み込むような処理はできない (rpm コマンドによるパッケージのアンインストールは可能)。

フロッピーや CD-ROM など、ブロックデバイスを使ったマウントはできないようだ。ただし NFS 共有のマウントは可能。

インストール先にインストールしたプログラムのほとんどは利用できるが、この時点でのパス環境変数は基本的にインストーラ用のものなので、例えば chkconfig コマンドなら /sbin/chkconfig という風に、絶対パスで指定したほうが確実。実際に Fedora Core 3
のポストインストールスクリプトに set
コマンドを組み込んで環境変数を書き出してみた。その抜粋を載せておく。
HOME=/tmp
HOSTNAME=localhost.localdomain
PATH=/usr/bin:/bin:/sbin:/usr/sbin:/mnt/sysimage/bin:/mnt/sysimage/usr/bin:\
/mnt/sysimage/usr/sbin:/mnt/sysimage/sbin:/mnt/sysimage/usr/X11R6/bin
PWD=/
SHELL=/bin/bash
UID=0

ポストインストールスクリプトの標準のインタープリタは上記の $SHELL だが、 %post に
`--interpreter /PATH/TO/INTERPRETER ' オプションを付ければ、別のインタープリタ
(当然、インストールしたものに限る) で処理することが可能。例えば perl
で書いてみるのも面白い。ただしその場合、スクリプト全体のインタープリタが替わってしまう点に注意。一部だけ perl を使いたいなら --interpreter オプションは使わずに "/usr/bin/perl
-e '処理'"
で書いたほうがいいだろう。

インストール構成で自 IP アドレスとネームサーバを固定にした場合には、この時点で既に名前のリゾルブが可能。 DHCP
にした場合は、この時点ではまだ /etc/resolv.conf
が整備されていないので、その類の処理をしたいなら IP アドレスを直接指定する必要がある。

%post 行にオプションを付けて `%post
--nochroot' とすることによって、ポストインストールスクリプト全体を chroot
を無効にした状態で実行することもできる。しかし、インストール CD 自体やその中のブートイメージを極度にカスタマイズでもしていない限り、 --nochroot にすることの恩恵はほとんどない。参考までに、以下に %post --nochroot を指定した場合と普通に chroot された場合のマウント情報を挙げておく
(興味を惹きそうな行を赤で表示)。環境変数に関しては chroot
されている時と変わりなかった。

--nochroot の場合の mount 出力
/dev/root.old on / type ext2 (rw)
/proc on /proc type proc (rw,nodiratime)
/dev/pts on /dev/pts type devpts (rw)
/sys on /sys type sysfs (rw)
none on /tmp type ramfs (rw)
none on /tmp/ramfs type ramfs (rw)
/tmp/loop0 on /mnt/runtime type cramfs (ro)
/selinux on /selinux type selinuxfs (rw)
/tmp/hda3 on /mnt/sysimage type ext3 (rw)
/tmp/hda1 on /mnt/sysimage/boot type ext3 (rw)
none on /mnt/sysimage/proc type proc (rw,nodiratime)
none on /mnt/sysimage/sys type sysfs (rw)
/selinux on /mnt/sysimage/selinux type selinuxfs (rw)
/dev/root.old on /mnt/sysimage/dev type ext2 (rw)
/usbfs on /proc/bus/usb type usbfs (rw)
通常の chroot 状態での mount 出力
/dev/hda3 on / type ext3 (rw,defaults)
/dev/hda1 on /boot type ext3 (rw,defaults)
none on /dev/pts type devpts (rw,gid=5,mode=620)
none on /dev/shm type tmpfs (rw,defaults)
none on /proc type proc (rw,defaults)
none on /sys type sysfs (rw,defaults)

下は、インストールしたてのシステムの yum
環境を整備した時のポストインストールスクリプトの抜粋。もちろん、 --nochroot を付けて >/etc/yum.conf などを >/mnt/sysimage/etc/yum.conf としてもうまくいった。

%post
/bin/cat <<EOM >/etc/yum.conf
[main]
cachedir=/var/cache/yum
debuglevel=2
logfile=/var/log/yum.log
pkgpolicy=newest
distroverpkg=redhat-release
tolerant=0
exactarch=1
retries=5
gpgcheck=1
EOM
/bin/cat <<EOM >/etc/yum.repos.d/fedora-updates.repo
[updates-released]
name=Fedora Core \$releasever - \$basearch - Released Updates
baseurl=http://ring.riken.jp/archives/linux/fedora/linux/core/updates/\$releasever/\$basearch
http://ftp.kddilabs.jp/Linux/packages/fedora/core/updates/\$releasever/\$basearch
enabled=1
EOM
/bin/rpm --import http://ring.riken.jp/archives/linux/fedora/linux/core/3/i386/os/RPM-GPG-KEY-fedora

パッケージ選択

キックスタートファイルのパッケージセクションは、下記のようなフォーマットで書く：

%packages
@ base-x
@ gnome-desktop
@ editors
@ engineering-and-scientific
@ graphical-internet
-gaim
-gnomemeeting
-xchat
gftp
@ text-internet
-fetchmail
-slrn
ncftp

@ で始まるものはパッケージグループの指定。グループを指定すると、そのグループの構成要素のうち、必須
(mandatory) タイプのものとデフォルト (default) タイプのものがインストールされることになる (comps.xml
の解説を参照)。選択したグループの中のオプション (option)
タイプのパッケージをインストールしたい場合や、グループは選択しないけれども特定のパッケージだけを個別に選択したい場合には、上記の gftp や ncftp
のように頭に何も付けずにパッケージ名を記述する。 逆に、選択したグループの中にインストールしたくない default パッケージがある場合には `-' を付けて書くと除外指定になる (-gaim や -gnomemeeting がその例)。現在のところ、anaconda に `-@ group ' という指定方法は存在しない。

なお、パッケージの除外指定や個別指定は、記述する順番は問題でなく、上の例のようにグループ (@)
毎にまとめる理由はない。 anaconda の構成スクリプトのひとつ kickstart.py
を読んでみたところ、 anaconda
インストーラはキックスタートファイルを解析するにあたり、まず、マイナス指定パッケージと個別指定パッケージをそれぞれ配列に読み込んでおき、依存関係解決の結果「インストールすることになったグループ」各々に対してフィルター処理を掛けているようだからだ。

キックスタートファイルでのパッケージ設定は、実際にインストールしながら何度も試行錯誤しないと、なかなか思ったようなインストール結果が得られない。主な理由を挙げると下のようになる。詳しくは後述の
comps.xml
の分析結果を読むと理解できるだろう。

通常、インストールの際には、パッケージ間、グループ間での依存関係が解決されるので、他のパッケージ/グループにとって必要とされるパッケージ/グループは自ずとインストールされてしまう。かといって
`%packages --ignoredeps'
で依存関係を完全に無視してインストールするには、相当の熟考と覚悟が必要。

グループの中には、例えば japanese-support パッケージグループのように、見えない
(USERVISIBLE 属性が false にセットされている)
グループが存在する。そうしたグループは、パッケージセクション以外の要因に左右されたり、他のグループの選択によって暗黙的にインストールされたりする。

詳細は未確認だが、或るグループの構成パッケージをひとつでも選ぶと、 anaconda
的には、そのグループは選択されたことになるらしい。その結果、そのグループの要求する必須パッケージ、必要グループ、必須メタパッケージ (後述)
も引きずられてインストールされるようだ。

パッケージグループ定義の正体はXMLファイル

パッケージグループに属するパッケージや、パッケージグループ同士の依存関係などは、インストールソースの base/ ディレクトリにある comps.xml という
XML ファイルで定義されている。 XML 形式が用いられているのは、 anaconda がオブジェクト指向言語である python で書かれていて、 XML
のノードや属性がオブジェクトとして取り扱うのに都合がいいからだ。しかしこのファイル、そのまま読もうとすると、 XML
タグが邪魔なばかりか、数十カ国語に多言語化されているため非常に読みにくい。そこで、 comps.xml
を読みやすく表示するための HTML と XSL スタイルシートを作った。 Fedora Core 3 の CD に入っている comps.xml を基準に作成したが、 anaconda つまり comps
の規格が変更されない限り、Fedora Core 3 以降ならどのリリースでも使えるはず。 Fedora Core 4 の comps.xml でも確認済み。

サンプルページ (ここで読み込ませている comps.xml は
Fedora Core 4)

ほしい人はここからダウンロード (printcomps.zip)。使い方は printcomps.xsl の冒頭に書いておいたが、要は、 printcomps.xsl と printcomps.html を解凍したのと同じディレクトリに、インストールメディアの base/ ディレクトリにある comps.xml
をコピー。 comps.xml の冒頭附近にある：
<!DOCTYPE comps
PUBLIC "-//Red Hat, Inc.//DTD Comps info//EN"
"comps.dtd">
という行をコメントアウトするか削除してから、 printcomps.html をブラウザで開けばいい。

comps.xml
を分析してみると、パッケージやグループには以下のような規則があることが分かる：

全体は、ジャンル -> グループ -> パッケージ という階層構造になっている。ジャンルはインストーラや system-config-kickstart
ユーティリティのパッケージ選択ダイアログでは選択可能だが、キックスタートファイルで指定できるのはグループとパッケージ (及びメタパッケージ) のみ。

グループには「見えるもの (USERVISIBLE プロパティが true)」と「見えないもの (USERVISIBLE プロパティが
false)」とがある。見えないグループは、主として他グループや言語環境などからの依存関係によって自動的、半強制的に選択される種類のグループであり、インストーラ画面のパッケージ選択ダイアログには表示されない。キックスタートファイルでは「見えないグループ」も指定が可能。

グループの一種として、メタパッケージ (Metapkg) という集合が存在する。これは少数のパッケージから成るサブグループのようなもので、
anaconda 上の利便性から考案されたもののようだ。性格的には「見えないグループ」に近いもので、 USERVISIBLE プロパティはやはり
false。その好例として editors グループに属する emacs メタパッケージがある。

各々のグループは、ブール (真偽) 値である default 属性を持っている。 default=true
のグループは、通常のインストーラのパッケージ選択画面で初めからチェックが付いて示される。ただしキックスタートインストールにおいては、指定していないのに
default=true だからといって勝手にインストールされるわけではなく、大した意味は持たない。

各グループは、その構成要素に、パッケージ、メタパッケージ、他のグループ、のいずれかまたは全てを従える。パッケージとメタパッケージはそこで、
mandatory, default, optional のうちいずれかの `type' プロパティを指定される。 mandatory
は「必須」で、そのグループを選択すれば必ず入る。 default
なものは、グループを選択すれば自動的に選択されるが、インストーラの選択画面でチェックを外したりキックスタートファイルでマイナス指定すれば除外することもできる。
optional はデフォルトでは選択されず、インストーラで敢えてチェックを付けるかキックスタートファイルで個別指定しない限りインストールされない。グループ配下のグループは、そうしたプロパティは明示的には付加されないが、
mandatory なものとして扱われる。

一部のパッケージは、 requires というプロパティを持っている。 requires
属性で指定されるのは、そのパッケージが動作するために必須となる別パッケージ。

特定のパッケージが複数のグループに属していることがある。

`Minimum' パッケージ構成をキックスタート形式で表すと？

comps.xml
に Minimum という定義は存在しないため、キックスタートファイルに @minimum
とは書けない。実際にインストーラ画面で Minimum 構成を選択してインストールした際の anaconda_ks.cfg には、以下のパッケージ構成が記録された。

@ japanese-support
kernel
e2fsprogs
grub
lvm2

現実には、依存関係が解決されて、これよりすっとたくさんのパッケージがインストールされる。なお lvm2
パッケージは、この時パーティション構成に LVM を使ったため、依存関係によって自動的に追加された。同様に japanese-support
グループは、主言語にも「追加の言語」にも日本語を入れなければリストされなかったはずだ。

なお、逆に何でもかんでもインストールする @everything という指定方法は、comps.xml 内では定義されていないが使える。 Everything グループは anaconda
の構成スクリプトのひとつ comps.py の中で動的に定義されるからだ。

キックスタートインストールの実行方法

「RedHat
Enterprise Linux システム管理ガイド」を見るとインストールブート CD
を焼き直せなどといった難しいことが書かれているが、一番手っ取り早いのは、通常のインストール CD Vol.1
からブートして、キックスタートファイルだけをフロッピーから読み取らせる方法だ。フロッピーのフォーマットは vfat か ext2
でなければならない。キックスタートを開始するには、最初の boot: プロンプトで

boot: linux ks=floppy:/ks_hoge.cfg

と入力すればいい。また、

boot: linux ks=hd:fd0:/ks_hoge.cfg

でも同様の意味になる。このようにキックスタートファイルの名前も指定してやれば、ファイル名は必ずしも ks.cfg である必要はない。 1
枚のフロッピーにいろいろなセッティングのキックスタートファイルを保存しておき、マシン毎、用途毎に使い分けることも可能なわけだ。逆に、キックスタートファイルの名前が標準の
ks.cfg であれば、ファイル名の指定は特に必要でなく `linux ks=floppy' だけでも通用する。

TOP

HOME