KickStart  
  HOME  
オフィシャルドキュメント[ja]： Red Hat Support
オフィシャルドキュメント[en]： Red Hat Support
JF： RedHat Linux KickStart HOWTO (激しく時代遅れ)

KickStart

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

役に立つ文献：

Table of Contents

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

Fedora Core には system-config-kickstart というユーティリティ (RH Enterprise Linux では 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 で未サポートの項目と説明不足な項目

手っ取り早く...

実際のところ、キックスタートは、同じパッケージ構成のサーバを量産したい時に使うことが多い。一番手っ取り早いやり方は、最初の 1台だけ手動でインストールし、そのマシンの /root/anaconda-ks.cfg を雛形にして 2台目以降のキックスタートファイルを作ることだろう。それだけの目的なら、以下のちょっとした調整だけで事足りる。

SELinuxの設定

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

selinux {--disabled|--permissive|--enforcing}

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

キックスタートを使わなければ、どうしても SELinux が有効な状態でインストールが行なわれ、インストール完了後初回のブート時に起動される first-boot (設定エージェント) で SELinux を無効にしなければならない (しかも再起動を伴う) のだが、キックスタートで SELinux を無効にしておけば

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 というディレクトリ構造のひとつ上の階層を指定する。実際のインストーラ画面での手順をおさらいしておくと；

  1. 最初の boot: プロンプトで `linux askmethod' と打ち込み
  2. インストール方法の選択画面で FTP か HTTP を選び
  3. Site Name 欄に例えば `ftp.kddilabs.jp' をタイプし
  4. 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 セクションを置くなら、必ずキックスタートファイルの最後でなければならない。そのセクションに書いた処理は、正規のポストインストール処理に先立って実行される。ポストインストールスクリプトを書く上でのポイントを幾つか挙げておく。

下は、インストールしたてのシステムの 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 の分析結果を読むと理解できるだろう。

パッケージグループ定義の正体は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 を分析してみると、パッケージやグループには以下のような規則があることが分かる；

`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' だけでも通用する。

また、フロッピーから読み込ませる他によく使う方法として、NFSサーバから読み取らせるやり方がある。例えば、NFSサーバ (NFSv3 で IPが 192.168.0.1 だと仮定) の /var/local/ks/ ディレクトリにキックスタートファイル ks_hoge.cfg を置いて公開した場合、boot: プロンプトには下記のように打ち込めばいい；

boot: linux ks=nfs:192.168.0.1:/var/local/ks/ks_hoge.cfg

インストールソースもネットワークサーバから提供するネットワークブートインストールをしたければ、簡単にネットワークブート環境構築できる Cobbler というツールがある。筆者のサイトでも検証記事を掲載している -> PXEインストール (Cobbler)

  TOP  
  HOME