多くの場合、制御ファイルは単一システムに対する設定内容を記すものです。 制御ファイルには、リストやレコード、ツリーのほか、内蔵型のオブジェクト 表記や、参照型のオブジェクト表記なども使用します。
制御ファイルは XML と呼ばれる方法で記述します。これにより、新しいシステムを 設定する際にも矛盾を発生させたりすることなく、学びやすく覚えやすい仕組みに なっています。
また XML を利用することで、設定ファイルの解析やエラー処理のうちのほぼすべてを XML パーサーと呼ばれる外部ソフトウエアに任せることができています。実際の インストールを行なう前に、制御ファイルの書式と文法が正しいかどうかを確認したい 場合は、制御ファイルに対して検証型のパーサを実行してください。この作業は、 特に手作業でプロファイルを編集するような場合に必要となります。
下記では、 XML 形式での制御ファイル例を示しています:
例2.1 XML 制御ファイル (プロファイル)
<?xml version="1.0"?>
<!DOCTYPE profile>
<profile
xmlns="http://www.suse.com/1.0/yast2ns"
xmlns:config="http://www.suse.com/1.0/configns">
<install> <!-- install は、 SUSE Linux 10.0 以降で廃止されています -->
<partitioning config:type="list">
<drive>
<device>/dev/hda</device>
<partitions config:type="list">
<partition>
<filesystem config:type="symbol">ext2</filesystem>
<size>520Mb</size>
<mount>/</mount>
</partition>
<partition>
<filesystem config:type="symbol">reiser</filesystem>
<size>1200Mb</size>
<mount>/data</mount>
</partition>
</partitions>
</drive>
</partitioning>
</install> <!-- install は、 SUSE Linux 10.0 以降で廃止されています -->
<configure> <!-- configure は、 SUSE Linux 10.0 以降で廃止されています -->
<scripts>
<pre-scripts>
<script>
<interpreter>shell</interpreter>
<filename>start.sh</filename>
<source>
<![CDATA[
#!/bin/sh
echo "Starting installation"
exit 0
]]>
</source>
</script>
</pre-scripts>
</scripts>
</configure> <!-- configure は、 SUSE Linux 10.0 以降で廃止されています -->
</profile>下記は基本的な制御ファイルコンテナの例です。実際の内容については、 本章で後ほど説明しています。
例2.2 制御ファイルコンテナ
<?xml version="1.0"?> <!DOCTYPE profile> <profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns"> <!-- リソース --> </profile>
profile 要素 (ルートノード) には、 1 つまたは複数の個別リソースが含まれます。 使用できるリソース要素は、スキーマファイル内に規定されています。
リソース要素には、複数の個別属性やリソース要素を含めるか、同一の リソース要素に対する複数のインスタンスを含めることができます。それ以外にも、 何も含めないようにもすることができます。リソース要素内で使用できるものは、 スキーマファイル内に規定されています。
属性要素には何も指定しないか、リテラル (値そのもの) を含めることができます。 属性内で使用できるものは、スキーマファイル内に規定されています。
それぞれの要素は、他のリソースに対するコンテナか、リテラル (属性) 値 のいずれかになることができます。両方を設定することはできません。この制限は スキーマファイル内に規定されています。複数の値を持つ設定コンポーネントの場合 は、属性値の内蔵リストとして表現するか、もしくは入れ子のリソースを設定 しなければなりません。
入れ子になったリソースを利用することで、設定コンポーネントを木構造で 表現することができます。
例2.3 入れ子になったリソースの例
...
<drive>
<device>/dev/hda</device>
<partitions config:type="list">
<partition>
<size>1000mb</size>
<mount>/</mount>
</partition>
<partition>
<size>250mb</size>
<mount>/tmp</mount>
</partition>
</partitions>
</drive>
....
上記の例では、 disk というリソースに対して device 属性が設定され、 その中に partitions というリソースが定義されています。 partitions リソースには複数の partition リソースが含まれていて、それぞれの partition リソース内に size と mount という属性が記述されています。
スキーマファイル内では、 partitions リソースには複数のインスタンスを 含めることができるが、 YaST2 内で 誤ったデータ型になることを防ぐように指定することが求められています。 上記の例では、ドライブに 1 つしかパーティションが存在しない場合、 partition リソースは属性として扱われます。これを避けるため、複数の インスタンスを定義する際には、下記のような書式を使用しなければ なりません。 type 属性について、詳しくは次の章をお読みください。
例2.4 type 属性の付いた入れ子の resource
...
<drive>
<device>/dev/hda</device>
<partitions config:type="list">
<partition>
<size>1000</size>
<mount>/</mount>
</partition>
<partition>
<size>250</size>
<mount>/tmp</mount>
</partition>
</partitions>
</drive>
....グローバルなプロファイル属性は、リソースや属性に対するメタデータを 定義する際に使用します。また、属性はコンテキスト (前後関係) を 切り替える際に使用します。これらは前述の章で説明している name や type の属性に対しても使用します。 プロファイルの属性はそれぞれ個別の名前領域 (ネームスペース) が用意 されていて、既定の名前領域は予約語として扱われます。これにより、 新しい名前を追加した場合も、既存のプロファイルを修正したりすること がないようになっています。
プロファイル属性は config という名前領域内で定義されていて、常に config: から始まる名前で記述します。すべての プロファイル属性は任意設定です。それらのうちの多くはリソースと 属性の両方で使用されますが、スキーマファイル内で定義された 1 つの要素内でしか使用できないものもあります。
要素のデータ型は、 config:type 属性を利用して定義します。 リソース要素に対する型は常に RESOURCE になりますが、この属性を 利用して明示的に指定することもできます (たとえば参照すべきスキーマ ファイルが何も設定されていない場合、空の要素に対して明示的に指定する 目的などが考えられます) 。リソース要素は、それ以外の型で設定する ことはできません。スキーマファイル内でその制限が設定されています。 属性要素の型は、そこに書かれたリテラル値の解釈結果から決定されます。 属性要素の型の既定値は STRING で、これは スキーマファイル内に規定されています。なお、利用できるデータ型の 一覧については、スキーマファイルをお読みください。
RELAX NG スキーマは、 XML 文書の構造や内容に対するパターンを定義するための ものです。そのため、 RELAX NG スキーマには、それらの文書をパターンに当てはめて 解釈するのに必要な情報が含まれています。 RELAX NG スキーマ自身も XML 文書 です。
AutoYaST の XML ファイルを検証するには、下記のように実行します:
/usr/bin/xmllint --noout --relaxng /usr/share/YaST2/schema/autoyast/rng/profile.rng
(プロファイルのファイル名).xml