2 AutoYaST 制御ファイル #Edit source
2.1 紹介 #Edit source
制御ファイル は プロファイル とも呼ばれ、単一のシステムに対する設定を記述します。このファイルにはリストやレコード、ツリーや巨大組み込み形式や参照オブジェクトなど、複雑な構造に対応したプロパティリソースから構成されています。
2.2 書式 #Edit source
設定ファイルの形式に XML を採用していることにより、ファイル構造の一貫性が保たれているほか、新しいシステムを設定しようとする場合でも、学びやすく覚えやすい仕組みになっています。
AutoYaST の制御ファイルでは、 XML を利用してシステムのインストールや設定を表現します。 XML は汎用目的のマークアップ言語で、多くのユーザが慣れ親しんでいる構造であるほか、 XML ファイルを処理するためのツールも多数用意されています。既存の制御ファイルを編集する場合でも、何もない状態から新しい制御ファイルを作成する場合でも、制御ファイルの構造が正しいことを検証しておくことを強くお勧めします。これは xmllint や jing のような検証型 XML パーサーを使用することで行うことができます (たとえば 3.3項 「手作業による制御ファイルの作成および編集」 をご覧ください) 。
下記は XML 形式での制御ファイルの例です:
例 2.1: AutoYaST の制御ファイル (プロファイル) #
<?xml version="1.0"?>
<!DOCTYPE profile>
<profile
xmlns="http://www.suse.com/1.0/yast2ns"
xmlns:config="http://www.suse.com/1.0/configns">
<partitioning config:type="list">
<drive>
<device>/dev/sda</device>
<partitions config:type="list">
<partition>
<filesystem config:type="symbol">btrfs</filesystem>
<size>10G</size>
<mount>/</mount>
</partition>
<partition>
<filesystem config:type="symbol">xfs</filesystem>
<size>120G</size>
<mount>/data</mount>
</partition>
</partitions>
</drive>
</partitioning>
<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>
</profile>2.3 構造 #Edit source
下記は制御ファイルのコンテナで、この中に実際の設定を書き込んでいくものです。
例 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.1 リソースとプロパティ #Edit source
リソース要素には複数の重複しないプロパティ要素や子リソース要素を含めることができるほか、同じ子リソース要素を複数インスタンスとして追加することもできます。もちろん何も含めない指定も行うことができます。リソース要素内に含めることのできる要素は、スキーマファイル内で指定されています。
プロパティ要素には値としてリテラルを指定することができます。もちろん値を指定しなくてもかまいません。それぞれのリソース要素内で指定可能なプロパティ要素とその値についても、スキーマファイル内で指定がされています。
要素は他の要素に対するコンテナとする (リソース) ことができるほか、値としてリテラルを持つ (プロパティ) こともできますが、両方を同時に使用することはできません。この制限についても、スキーマファイル内に記述されています。 1 つ以上の値を持つ設定のコンポーネントは、プロパティ値内で組み込みのリストとして表現するか、入れ子型のリソースとして表現します。
<foo></foo> や <bar/> のような空要素は、処理済みのデータモデル内に存在すべきでは ありません 。通常、これらには適切な既定値を設定すべきです。意図的に空要素を指定したい場合は、 CDATA セクションを使用して <foo><![CDATA[]]></foo> のように指定し、空文字列を設定してください。
2.3.2 入れ子になったリソース設定 #Edit source
入れ子になったリソース要素を使用することで、任意の階層構造からなるツリー状の設定コンポーネントを作成することができます。
入れ子になったリソースとしては、マップとリストの 2 種類が存在します。マップ (連想配列やハッシュ、辞書と呼ばれることもあります) にはタグ名とそれに対応する値の対を含めることができます。リスト (配列と呼ばれることもあります) には、単純に値の羅列を含めることができます。
例 2.3: 入れ子になったリソース設定 #
...
<drive>
<device>/dev/sda</device>
<partitions config:type="list">
<partition>
<size>10G</size>
<mount>/</mount>
</partition>
<partition>
<size>1G</size>
<mount>/tmp</mount>
</partition>
</partitions>
</drive>
....上記の例では、 drive リソースは device プロパティと partitions リソースから構成されるマップの形態になっています。 partitions リソースは複数の partition から構成されるリストで、その partition リソースは size と mount のプロパティを含むマップの形態になっています。
入れ子になったリソースの場合、既定ではマップとして処理されます。リストを使用したい場合は、 config:type="list" の属性を明示的に指定しなければなりません。
ヒント: 要素型の省略表記について
openSUSE Leap 15.3 およびそれ以降のバージョンでは、 config:type の代わりに t という属性を使用することで、要素の型を指定することができます。
<mode t="boolean">true</mode>
2.3.3 属性 #Edit source
グローバル属性は、リソースやプロパティ内のメタデータを定義する際に使用します。属性はコンテキストの切り替えを定義するために使用します。これらは上記の章に示されているプロパティの名前付けや型指定で使用されます。属性については独自のネームスペース内に存在していることから、既定のネームスペース内で予約語として扱う必要はありません。
config:type 属性は処理済みのデータモデル内で、リソースやプロパティの型を設定するためのものです。リソースの場合、リスト型を指定したい場合は list を設定する必要がありますが、マップ型の場合は既定の型であるため、属性の設定は不要となります。ただし、中身無しの (空の) マップを指定する場合は、単純な文字列として処理されてしまうことの無いよう、マップ型を指定しておく必要があります。
例 2.4: 空のマップ #
<general t="map" />
プロパティの場合、 boolean (ブール値) , symbol (シンボル) , integer (整数) の各型を指定することができます。こちらの場合の既定値は string (文字列) となります。
上記で説明したとおり、マップと文字列の例外を除いて、属性は基本的に任意指定ではありません。ただし、スキーマ内のさまざまな場所でさまざまな指定がされていて一貫性が無いことから、中には任意指定の属性も存在します。また、場所によっては、値を列挙するのにシンボルで表す場合があるほか、文字列を必要とするような場合も存在します。また一方のリソースでは config:type="integer" の指定が必要となるのに対して、他方では文字列属性で数値を処理する箇所もあります。またリソースによっては config:type="boolean" を使用するのに対して、他のリソースでは yes や 1 などを使用することもあります。詳しくはスキーマファイルをご覧ください。