キックスタートのテンプレート機能
このページは本家wikiのKickstartTemplatingを、作者である Michael DeHaan 氏に許可を得て、個人的に翻訳したものを公開しています。
あくまでも個人的な訳となっており、意訳・超訳的なところも多々ありますので、翻訳・記述の内容に不備やご意見等あればご指摘・ご連絡頂けると助かります。(翻訳日:2007/10/10)
概要
cobblerのプロファイル("cobbler profile add"で作成される)は、実際のキックスタートファイルではなく、キックスタートのテンプレートファイルを入力値としてとります。つまり、それらはキックスタートをどのように作成するか?という情報を含んでおり、任意のテンプレートがプロファイルごとやシステムごとに異なる変数により変更されうるということを意味しています。
これを使うと、キックスタートのテンプレートを複数のプロファイルや複数のシステム間で共有し、個々のマシンに対して個別にキックスタートを生成するということが可能になります。同じテンプレートを使用した場合でも、cobbler で --ksmeta に異なる変数が指定されていれば違った出力結果となります。
うさぎの穴を降りていってみる
テンプテート機能はとてもパワフルで、あなたが大量のプロファイルやシステムを管理しなければならないような場合なら特にそうでしょう。
ユーザは、テンプレートをキックスタートファイルと同じように扱えますし、この機能の存在を意識するなく使えますが、よりカスタマイズが必要な場合もサポートしています。
この記事は、多くの複雑な(そしてオプション的な)内容を取り上げますので、あなたが必要な部分だけを参照してください。もしあまりにも複雑に思えたとしても、全てを理解する必要はありません。
最初に
cobbler はキックスタートのテンプテートエンジンとして Cheetah を使用しています。Cheetah のページを参照すれば、あなたのキックスタートのテンプレートに実装できる、より多くの高度な機能を学ぶことができるでしょう。しかし、Cheetah の全ての機能について知っている必要ありません。基本的な変数の解決は自動的に行われ、どのようにテンプレートが機能しているかについての高度な知識は必要ありません。
階層構造
cobblerにおいて、キックスタートのテンプレート変数(--ksmeta)は以下の優先度で評価されます:
- ディストリビューションのパラメータが最初に評価されます。
- プロファイルのパラメータがディストリビューションのパラメータを上書きします。
- システムのパラメータがプロファイルのパラメータを上書きします。
例えば、ディストリビューションが"bar"という属性が指定されており、ディストリビューションの子であるプロファイルにはその指定がない場合でも、プロファイルは、キックスタートのテンプレートファイルにおいて"bar"の値を参照することができます。しかし、もしシステムに"bar"の値が指定されている場合は、ディストリビューションの値ではなく、システムの値が、そのシステムのキックスタートを生成するのに使用されます。
基本的な変数の置き換え
以下のコマンドを実行したとします。
# cobbler profile add --name=foo --distro=RHEL-5-i386 --kickstart=/opt/cobbler/templates/example # cobbler profile edit --name=foo --ksmeta="name=spot verb=run" # cobbler system add --name=bar --profile=foo --ksmeta="verb=jump"
そしてキックスタートのテンプレート /opt/cobbler/templates/example はこうなっているとします:
See $noun $verb
プロファイル foo に対して生成されるファイルは以下のようになります:
See spot run
そして、システム bar に対しての場合です:
See spot jump
もちろん、これは不自然な例ですが、ホスト名、サーバの場所、IPアドレス、タイムゾーンといったものが置き換えられるのが想像できるでしょう。
スニペット (Cobbler 0.5.2以降)
/var/lib/cobbler/snippets/スニペット名 という名前のファイルを作成しておくと、テンプレート内に SNIPPET::スニペット名 という記述があれば、/var/lib/cobbler/snippets/スニペット名 の内容がテキストでインクルードされます。その後、変数が普通に置き換えられます。
これを使うと、キックスタート間で共通してよく使うような内容を再利用することができます。
wget/%include を使ったトリック (cobbler固有の話ではありません)
cobbler 0.5.2以前では、異なるキックスタート間で内容を共有する為にwget/preのトリックが使われていました。
キックスタートの%preセクションがこうなっていて:
%pre wget -O /tmp/include http://publicwebserver/path/include.txt
キックスタートファイルのどこかにこう記載されていたとします。
%include /tmp/include
http:// のURLに直接 %include を使うことができないので、"preの中にwgetを指定する" というトリックが使われるという訳です。
また、%preの賢い使い方は他にもあって、例えば、pre で シェルスクリプトが動的に生成したものをインクルードするといった場合に使えます。このトリックは/var/lib/cobbler/snippets/partition_select というcobblerのスニペットで使われています — これはドライブのセットアップの前にハードドライブのパラメータを調査します。これはcobblerの全てのデフォルトのキックスタートで使用されています。
よくあるトリックの一つが、wgetを使ってCGIスクリプトの結果を取得するというものです。REMOTE_ADDRのような環境変数はリモートシステムのコンテンツを検出するのに使用することが出来きます。しかしながら、cobblerのテンプテート機能において、これは必要という訳ではなく、むしろよりトラブルになりやすいでしょう。
エスケープ
キックスタートファイルに $(list-harddrives) のようなシェルのマクロが含まれている場合は以下のようにエスケープしなければいけません:
¥$(list-harddrives)
これにより、Cheetah が $(list-harddrives) を置き換えようとするのを防がないと、最悪の場合、混同しエラーとなるでしょう。
一般的に、全くエスケープする必要がないといった場合にエスケープしたとしてもそれが問題になるということはありません。
例:
This is an $elephant
もし"elephant"というキックスタートの変数がない場合は、キックスタートのテンプレートエンジンはその文字列をそのまま "$elephant"として残します。
組み込み変数
cobblerには多くのキックスタート変数が組み込まれています。
0.5-1では、どんなコマンドラインのオプションもキックスタートファイルのテンプレート機能からアクセスすることが可能です。ドル文字の変数が何を参照するかは、/var/lib/cobbler/profiles/ か /var/lib/cobbler/systems/ 以下のファイルの内容を見てください。注意として、これらはシステムが使う内部的なディレクトリですので編集すべきではありませんが、これらを見れば、キックスタート変数を置き換える際に幅広いオプションが利用できることがわかるでしょう。これらの組み込み変数は --ksmeta で指定された値で上書きすることが出来ますので、使いたい変数名をメモしてください。
便利な組み込み変数としては$mac_address、$ip、$distro、$profile、$hostnameなどがあります。
もう少し明確にするために、cobbler 0.5.2の以下のシステムを追加するコマンドを見てください:
# cobbler system add --name=spartacus --profile=fc6webserver --ip=192.168.50.5 --mac=AA:BB:CC:DD:EE:FF --hostname=spartacus.example.org
上記のコマンドで、fc6webserberのキックスタートのテンプレートに以下の行が含まれていると想定してください:
echo "My ip is $ip_address and my MAC is $mac_address. I am reachable at $hostname" > /etc/motd
上記の行は以下のように置き換えられます。
echo "My ip is 192.168.50.5 and my MAC is AA:BB:CC:DD:EE:FF. I am reachable at spartacus.example.com." > /etc/motd
もう一度言いますが、上の例はちょっと不自然ですが、コマンドラインで指定された全ての変数にテンプレートからアクセスできるということを理解するに十分はでしょう。これはむしろ便利な機能で、多くのテンプレート変数を--ksmetaで追加するのを防ぎます。
なお、cobblerのバージョン0.5以前では--ksmetaで指定された値にしかアクセスできません。
存在しないかもしれない変数のチェック
システムオブジェクトに"foo"の値が定義されている場合があるのであれば、逆にない場合もあります。
以下のCheetahのテンプレートのトリックを使うと変数が存在する場合はアクセスする、存在しない場合はデフォルトの値を割り当てる、といったことが出来ます。
#set $selinux_mode = $getVar('selinux', 'enforcing')
または単に以下とします。
$getVar('selinux', 'enforcing')
変数が定義されている場合においてのみキックスタートファイルに特定の行を含める必要がある場合にこういったことは可能ですが、当然の結果として少し複雑になります。例えば、cobblerのプロファイルとシステム両方で使えるようなテンプレートが欲しいとしましょう。しかしながら、システムには変数"$ip_address"を定義しないような場合、文法的に間違った(変換されない)"$ip_address"文字列をキックスタートファイルに残してしまうことになります。これを避けるには以下のようなやり方があります。
#if $getVar("ip_address","none") == "none"
この行は$ip_addressが定義されている場合のみ表示されます。そうでない場合はここには何も含まれません。
#end if
これに対してもっときれいな提案があれば歓迎します。
Cobbler 0.5.2以降で利用可能な変数例の一覧
arch: x86 breed: redhat default_kickstart: /etc/cobbler/default.ks default_virt_type: xenpv depth: 2 dhcpd_bin: /usr/sbin/dhcpd dhcpd_conf: /etc/dhcpd.conf distro: FC-6-i386 dnsmasq_bin: /usr/sbin/dnsmasq dnsmasq_conf: /etc/dnsmasq.conf hostname: '' httpd_bin: /usr/sbin/httpd initrd: /var/www/cobbler/ks_mirror/FC-6/i386/os/images/pxeboot/initrd.img ip_address: '172.16.57.21' kernel: /var/www/cobbler/ks_mirror/FC-6/i386/os/images/pxeboot/vmlinuz kernel_options: 'ksdevice=eth0 lang= text syslog=mdehaan.rdu.redhat.com:25150 foo kssendmac ' kickstart: /var/lib/virt-factory/kick-fc6.ks mac_address: '00:16:41:14:b7:71' manage_dhcp: 0 manage_dhcp_mode: isc minimize_syncs: 1 name: '00:16:41:14:b7:71' netboot_enabled: 0 next_server: mdehaan.rdu.redhat.com parent: ~ profile: Container server: mdehaan.rdu.redhat.com snippetsdir: /var/lib/cobbler/snippets source_repos: [] syslog_port: 25150 tftpboot: /tftpboot tftpd_bin: /usr/sbin/in.tftpd tftpd_conf: /etc/xinetd.d/tftp virt_file_size: 0 virt_path: '' virt_ram: 0 virt_type: xenpv webdir: /var/www/cobbler xmlrpc_port: 25151 yum_core_mirror_from_server: 0
Raw エスケープ
cobblerはキックスタートのテンプレート機能にCheetahを使用しています。Cheetahは "$" を "この変数を含めなさい"と見なすので、キックスタートファイルのドルマークを¥$でエスケープすることは良いことです。しかしながら、これを繰り返すと読みづらくなります。そういった場合、"raw"ブロックを宣言すると、そのブロック全体が Cheetah で評価されなくなるので簡単になります。
#raw この $doller サインは --ksmeta でメタデータ変数がどのように定義されていたとしても、このまま表示されます。 #endraw
It is possible to cheat by assigning bash variables from the values of Cheetah variables, and use them inside raw blocks. This is useful if you want your shell scripts to be able to access templating variables but don't really want to make sure escaping is all super-correct.
%pre foo = $foo #raw This $foo will be evaluated and will not appear with a dollar sign and if you included funky shell scripts here you wouldn't have to worry about escaping anything. The $foo comes from bash and not Cheetah #endraw
Conditionals
Cheetah supports looping and if statements. For more of this, see the Cheetah web page.
(This section needs to be expanded)
"Stanza" Support
Stanzas are the precursor to Cobbler snippets. Certain built-in complex pieces of code are auto-generated by Cobbler, from within the Cobbler source code, that vary based upon the configuration of the cobbler object being rendered. These sections are not user extensible, unlike the newer snippet support. These are being explained here to give folks an idea of why they should leave these weird dollar sign variables in their kickstarts, but in general, more cobbler stanzas will not be added. The new snippets are the user-extensible way to go.
Certain blocks of kickstart code are substituted for the following variables:
- $yum_repo_stanza -- this is replaced with the code neccessary to set up any repos that are associated with the given cobbler profile, for use during install time. This should be present towards the top of a kickstart, but only for kickstarts that are RHEL5 and later or FC6 and later. Before those versions, kickstart/Anaconda did not support the "repo" directive.
- $yum_config_stanza -- this is replaced with the code neccessary to configure the installed system to use the yum repos set up during install time for regular operation. In other words, it sets up /etc/yum.repos.d on the provisioned system. This works for all machines that can have yum installed. If the value in /var/lib/cobbler/settings for "yum_core_repos_from_server" is set, in addition, the provisioned system will be pointed to the boot server as an install source for "core" packages as well as any additional repos.
- $kickstart_done -- this is replaced with a specially formatted wget, that places an entry in the cobbler and/or Apache (depending on how implemented at the time) log file, allowing "cobbler status" to better tell when kickstarts are fully complete. The implementation of what "kickstart_done" means may vary depending on the cobbler version, but it should always be placed in a kickstart template as the last line in %post.
Validation
Cobbler 0.5.2 and later contains a command "cobbler validateks" that will run ksvalidator (part of the pykickstart package) against all rendered kickstarts to see if Anaconda will likely like them. It should be noted that ksvalidator is not perfect, and in some cases, it will report false positives and/or negatives. However, it is still useful to make sure that your rendered output from the kickstart templates is still good.
Looking at results
As was said earlier, what is provided for --kickstart is a template, not a kickstart. Templates are used to generate kickstarts. Each time you add a cobbler object, or when you run "cobbler sync", cobbler generates (renders) kickstart files and stores them elsewhere. If you would like to see the output of cobbler first hand (for your own review), you can look at the following directories.
For profiles:
http://bootserver.example.com/cobbler/kickstarts/$profile_name
For systems:
http://bootserver.example.com/cobbler/kickstarts_sys/$system_name
It should be noted that since this directory is for rendering output, these files (which actually like in /var/www/cobbler) should not be hand or machine edited. They can change any time cobbler would like them to change. If you would like to change what these files look like, edit the kickstart templates instead, and then run "cobbler sync"
Calling Python Code
Cheetah lets you use python modules from inside the templates.
Example:
#import time
$time.strftime('%m/%d/%Y')
Comments
Cheetah makes comments with double hash marks "##". Any line starting with "##" will not show up in the rendered kickstart file at all.
Kickstart comments "#" will show up in the rendered output.
Both styles of comments may be mixed. You can use "##" to describe what you are doing in your templates, and those "##" comments won't show up when someone looks at the rendered kickstart file in /var/www/cobbler.
If this sounds complicated, it is. It's even more complicated in that Cheetah has special meanings for some things starting with "#" like "#if" or "#include". It's pretty much safe to just use the single "#" comment form everywhere though.
その他の情報源
- Kickstart-list は素晴らしい情報を含んでいるメーリングリストです。
- Cheetah ウェブサイト
- Cheetahのいくつかの機能についての記事です。 (devshed.com)
- RHEL 5 インストールガイド (キックスタートオプションのセクション)
- Chip Shabazian / キックスタートのコツとトリック

