Rules offer the possibility to configure a system depending on system attributes by merging multiple control files during installation. The rules-based installation is controlled by a rules file.

The rules file is an XML file containing rules for each group of systems (or single systems) that you want to automatically install. A set of rules distinguish a group of systems based on one or more system attributes. After passing all rules, each group of systems is linked to a profile. Both the rules file and the profiles must be located in a pre-defined and accessible location.

The rules file is retrieved only if no specific control file is supplied using the autoyast keyword. For example, if the following is used, the rules file will not be evaluated:

autoyast=http://10.10.0.1/profile/myprofile.xml
autoyast=http://10.10.0.1/profile/rules/rules.xml

Instead use:

autoyast=http://10.10.0.1/profile/

which will load http://10.10.0.1/profile/rules/rules.xml (the slash at the end of the directory name is important).

Figure 6.1. Rules¶

If more than one rule applies, the final profile for each group is generated on the fly using a merge script. The merging process is based on the order of the rules and later rules override configuration data in earlier rules. Note that the names of the top sections in the merged xml files need to be in alphabetical order for the merge to succeed.

The use of a rules file is optional. If the rules file is not found, system installation proceeds in the classic way by only using the supplied profile or by searching for the profile depending on the MAC or the IP address of the system.

<?xml version="1.0"?>
<!DOCTYPE autoinstall>
<autoinstall xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns">
  <rules config:type="list">
    <rule>
       <disksize>
            <match>/dev/hdc 1000</match>
            <match_type>greater</match_type>
       </disksize>
       <result>
            <profile>machine1.xml</profile>
            <continue config:type="boolean">false</continue>
        </result>
    </rule>
    <rule>
       <disksize>
            <match>/dev/hda 1000</match>
            <match_type>greater</match_type>
       </disksize>
       <result>
            <profile>machine2.xml</profile>
            <continue config:type="boolean">false</continue>
        </result>
    </rule>
  </rules>
</autoinstall>

<?xml version="1.0"?>
<!DOCTYPE autoinstall> 
<autoinstall xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns">
  <rules config:type="list">
    <rule>
       <disksize>
            <match>/dev/hdc 1000</match>
            <match_type>greater</match_type>
       </disksize>
       <memsize>	    
            <match>1000</match>
            <match_type>greater</match_type>
       </memsize>
       <result>
            <profile>machine1.xml</profile>
            <continue config:type="boolean">false</continue>
        </result>
    </rule>
    <rule>
       <disksize>
            <match>/dev/hda 1000</match>
            <match_type>greater</match_type>
       </disksize>
       <memsize>	    
            <match>256</match>
            <match_type>greater</match_type>
       </memsize>
       <result>
            <profile>machine2.xml</profile>
            <continue config:type="boolean">false</continue>
        </result>
    </rule>
  </rules>
</autoinstall>

<rule>
    <custom1>
        <script>
if grep -i intel /proc/cpuinfo > /dev/null; then
echo -n "intel"
else
echo -n "non_intel"
fi;
        </script>
        <match>*</match>
        <match_type>exact</match_type>
    </custom1>
    <result>
         <profile>@custom1@.xml</profile>
         <continue config:type="boolean">true</continue>
    </result>
</rule>

<rule>
   <disksize>
        <match>/dev/hda 1000</match>
        <match_type>greater</match_type>
   </disksize>
   <memsize>	    
        <match>256</match>
        <match_type>greater</match_type>
   </memsize>
   <result>
        <profile>machine2.xml</profile>
        <continue config:type="boolean">false</continue>
   </result>
   <operator>or</operator>
</rule>

<dialog_nr config:type="integer">3</dialog_nr>

<element config:type="integer">3</element>

<title>Desktop Selection</title>

<question>KDE Desktop</question>

<timeout config:type="integer">30</timeout>

<conflicts config:type="list">
  <element config:type="integer">1</element>
  <element config:type="integer">5</element>
  ...
</conflicts>

<rules config:type="list">
    <rule>
        <custom1>
            <script>
echo -n 100
            </script>
           <match>100</match>
           <match_type>exact</match_type>
        </custom1>
        <result>
            <profile>rules/kde.xml</profile>
            <continue config:type="boolean">true</continue>
        </result>
        <dialog>
            <element config:type="integer">0</element>
            <question>KDE Desktop</question>
            <title>Desktop Selection</title>
            <conflicts config:type="list">
                <element config:type="integer">1</element>
            </conflicts>
            <dialog_nr config:type="integer">0</dialog_nr>
        </dialog>
    </rule>
    <rule>
        <custom1>
            <script>
echo -n 100
            </script>
           <match>101</match>
           <match_type>exact</match_type>
        </custom1>
        <result>
            <profile>rules/gnome.xml</profile>
            <continue config:type="boolean">true</continue>
        </result>
        <dialog>
            <element config:type="integer">1</element>
            <dialog_nr config:type="integer">0</dialog_nr>
            <question>Gnome Desktop</question>
            <conflicts config:type="list">
                <element config:type="integer">0</element>
            </conflicts>
        </dialog>
    </rule>
    <rule>
        <custom1>
            <script>
echo -n 100
            </script>
           <match>100</match>
           <match_type>exact</match_type>
        </custom1>
        <result>
            <profile>rules/all_the_rest.xml</profile>
            <continue config:type="boolean">false</continue>
        </result>
    </rule>
  </rules>

Classes represent configurations for groups of target systems. Unlike rules, classes have to be configured in the control file. Then classes can be assigned to target systems.

Here is an example of a class definition:

<classes config:type="list">
    <class>
        <class_name>TrainingRoom</class_name>
        <configuration>Software.xml</configuration>
    </class>
</classes>

The file Software.xml must be in the directory "classes/TrainingRoom/" then. It will get fetched from the same place the AutoYaST profile and rules were fetched from.

If you have multiple profiles and those profiles share parts, better use classes for common parts. You can also use XIncludes.

Using the configuration management system, you can define a set of classes. A class definition consists of the following variables:

Figure 6.2. Defining Classes

You can create as many classes as you need, however it is recommended to keep the set of classes as small as possible to keep the configuration system concise. For example, the following sets of classes can be used:

A file saved in a class directory can have the same syntax and format as a regular control file but represents a subset of the configuration. For example, to create a new control file for a special computer with a specific network interface, only the control file resource which controls the configuration of the network is needed. Having multiple network types, you can merge the one needed for a special type of hardware with other class files and create a new control file which suits the system being installed.

It is possible to mix rules and classes during an auto-installation session. For example you can identify a system using rules which contain class definitions in them. The process is described in the figure “Figure A.1, “Rules Retrieval Process””.

After retrieving the rules and merging them, the generated control file is parsed and checked for class definitions. If classes are defined, then the class files are retrieved from the original repository and a new merge process is initiated.

With classes and with rules, multiple XML files get merged into one resulting XML file. This process of merging is often confusing for people, because it behaves different than one would expect. First of all it is important to note that the names of the top sections in the merged xml files need to be in alphabetical order for the merge to succeed.

For example, the following two XML parts should be merged:

<partitioning config:type="list">
    <drive>
        <partitions config:type="list">
            <partition>
                <filesystem config:type="symbol">swap</filesystem>
                <format config:type="boolean">true</format>
                <mount>swap</mount>
                <partition_id config:type="integer">130</partition_id>
                <size>2000mb</size>
            </partition>
            <partition>
                <filesystem config:type="symbol">xfs</filesystem>
                <partition_type>primary</partition_type>
                <size>4Gb</size>
                <mount>/data</mount>
            </partition>
        </partitions>
    </drive>
</partitioning>

<partitioning config:type="list">
  <drive>
    <initialize config:type="boolean">false</initialize>
    <partitions config:type="list">
         <partition>
           <format config:type="boolean">true</format>
           <filesystem config:type="symbol">xfs</filesystem>
           <mount>/</mount>
           <partition_id config:type="integer">131</partition_id>
           <partition_type>primary</partition_type>
           <size>max</size>
         </partition>
    </partitions>
    <use>all</use>
  </drive>
</partitioning>

You might expect the profile to contain 3 partitions. This is not the case. You'll end up with two partitions and the first partition is a mixup of the swap and the root partition. Settings configured in both partitions, like mount or size, will be used from the second file. Settings that only exist in the first or second partition, will be copied to the merged partition too.

In this example, you do not want a second drive. The two drives should be merged into one. With regard to partitions, three separate ones should be defined.

	Workaround for SLES9/SL 10.0 and earlier
The following workaround only works for SLES9/SL 10.0 and earlier versions.

The following method is not officially supported by AutoYaST. For each partition in one file, add an attribute to the partition:

<partition dontmerge="1">
...
</partitions>

Because of the new attribute, the merge script will not detect the partitions as the same element type. If you have more files, you may need to add more attributes like dontmerge="2", etc.

	Solution for SLES 10/SL 10.1 and later
The following method solves the merging problem for SLES10, SUSE Linux 10.1 and later versions.

Use the dont_merge element in the rules or class file:

<classes config:type="list">
    <class>
        <class_name>swap</class_name>
        <configuration>largeswap.xml</configuration>
        <dont_merge config:type="list">
            <element>partition</element>
        </dont_merge>
    </class>
</classes>

<rule>
    <board_vendor>
        <match>ntel</match>
        <match_type>regex</match_type>
    </board_vendor>
    <result>
        <profile>classes/largeswap.xml</profile>
        <continue config:type="boolean">true</continue>
        <dont_merge config:type="list">
          <element>partition</element>
        </dont_merge>
    </result>
    <board_vendor>
        <match>PowerEdge [12]850</match>
        <match_type>regex</match_type>
    </board_vendor>
    <result>
        <profile>classes/smallswap.xml</profile>
        <continue config:type="boolean">true</continue>
        <dont_merge config:type="list">
          <element>partition</element>
        </dont_merge>
    </result>
</rule>