From emap@svn2.opensuse.org Mon Nov 7 13:54:00 2011 From: emap@svn2.opensuse.org To: yast-commit@lists.opensuse.org Subject: [yast-commit] r66738 - /trunk/autoinstallation/doc/xml/RulesAndClasses.xml Date: Mon, 07 Nov 2011 13:53:58 +0000 Message-ID: <20111107135359.3DF8432C30@svn2.opensuse.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8231806072710474229==" --===============8231806072710474229== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Author: emap Date: Mon Nov 7 14:53:58 2011 New Revision: 66738 URL: http://svn.opensuse.org/viewcvs/yast?rev=3D66738&view=3Drev Log: edited by emap Modified: trunk/autoinstallation/doc/xml/RulesAndClasses.xml Modified: trunk/autoinstallation/doc/xml/RulesAndClasses.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/Rule= sAndClasses.xml?rev=3D66738&r1=3D66737&r2=3D66738&view=3Ddiff =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- trunk/autoinstallation/doc/xml/RulesAndClasses.xml (original) +++ trunk/autoinstallation/doc/xml/RulesAndClasses.xml Mon Nov 7 14:53:58 20= 11 @@ -4,47 +4,48 @@
- Rule based auto-installation + Rules-based Automatic Installation Rules offer the possibility to configure a system depending on system - attributes by merging multiple control file during installation. The - rules based installation is controlled by a rules file. + attributes by merging multiple control files during installation. The + rules-based installation is controlled by a rules file. - The rules file is an XML based file that contains + 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 b= ased on - one or more system attributes, after passing all rules, it links each - group of rules to a profile. Both the rules file and the profiles must= be + one or more system attributes. After passing all rules, each + group of systems is linked to a profile. Both the rules file and the p= rofiles must be located in a pre-defined and accessible location. - The rules file is retrieved only if no specific control is supplied + The rules file is retrieved only if no specific control file= emap 2011-11-07: Should this read 'profile'? is supplied using the autoyast keyword. For example, if the - following is used, the rules file wont be evaluated: + following is used, the rules file will not be evaluated: autoyast=3Dhttp://10.10.0.1/profile/myprofile.xml autoyast=3Dhttp://10.10.0.1/profile/rules/rules.xml - instead use + Instead use: autoyast=3Dhttp://10.10.0.1/profile/ - which will load http://10.10.0.1/profile/rules/rules.xml (the slas= h at the end is important) + which will load http://10.10.0.1/profile/rules/rules.xml (the slas= h at the end of the directory name is important).
Rules &rules;
- If more than one rule apply, the final profile for each group is gener= ated - 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 earl= ier 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. The use of a rules file is optional. If the rules file is not found, system installation proceeds in the=20 - classic way by just using the supplied profile or by searching for 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. =20 @@ -61,14 +62,14 @@ for the sales department, you would add a link to the profile, called sales.xml, that you created for the sales departm= ent. ---> +-->emap 2011-11-07: If the example is dropped here we better drop it= in NetworkInstall.xml as well. =20
- Rules File explained + Rules File Explained =20 - Simple rules file + Simple Rules File =09 =20 @@ -108,26 +109,23 @@ =20 =20 - The last example defines 2 rules and provides a different profile for + The last example defines two rules and provides a different profile for every rule. The rule used in this case is - disksize. After parsing the rules file, &yast2; - attempts to match the system being installed to the rules in the=20 - rules.xml file in the following order: first rule thro= ugh the - last rule. A rule match occurs when the system being installed matches - all of the system attributes defined in the rule. As soon as a system - matches a rule, the result resource is added to the - stack of profiles &autoyast; will be using to create the final - profile. The continue property tells &autoyast; if it= should - continue with other rules or not after a match has been found.=20 + disksize. After parsing the rules file, &yast; + attempts to match the target system with the rules in the=20 + rules.xml file. A rule match occurs when the target sy= stem matches all system attributes defined in the rule. As soon as the system + matches a rule, the respective resource is added to the + stack of profiles &ay; will use to create the final + profile. The continue property tells &ay; whether it = should continue with other rules after a match has been found.=20 - If the first rule does not match, next rule in the list is examined + If the first rule does not match, the next rule in the list is examined until a match is found. Using the disksize attribute, you can - provide different configurations for different hard drives with - different size. First rule checks if the device + provide different configurations for systems with hard drives of + different sizes. The first rule checks if the device /dev/hdc is available and if it is greater than 1 GB in size using the match property.=20 @@ -139,11 +137,11 @@ - Simple rules file + Simple Rules File =09 =20 - The following simple example illustrates how the rules file is used + The following example illustrates how the rules file is used to retrieve the configuration for a client with known hardware. @@ -187,9 +185,9 @@ =20 =20 - The rules directory must be located in the same referenced directory - used with the autoyast keyword on boot time, so - if the client was booted using autoyast=3Dhttp://10.10.0.1/profil= es/, + The rules directory must be located in the same directory specified via + the autoyast keyword at boot time. + If the client was booted using autoyast=3Dhttp://10.10.0.1/profil= es/, &autoyast; will search for the rules file in=20 http://10.10.0.1/profiles/rules/rules.xml. @@ -197,13 +195,13 @@
Custom Rules - If the attributes autoyast provides for rules are not enough for= you, - you can use custom rules. Custom rules are more or less a shell = script - you have to write has and whose output on STDOUT is being used t= o know - which autoyast profile should be fetched. STDERR will be ignored. + If the attributes &ay; provides for rules are not enough for you= r purposes, + use custom rules. Custom rules are more or less a shell script + you have to write.emap 2011-11-07: Is it a shell script = or not? Its output to STDOUT specifies + which &ay; profile should be used. STDERR will be ignored. - Here is an example for the use of a custom rules: + Here is an example for the use of custom rules: - The script in this rule can echo either "intel" or "non_intel" t= o STDOUT (the - output of the grep command must be directed to /dev/null in this= case). - Autoyast will catch that output and will fetch a file with the n= ame "intel.xml" - or "non_intel.xml". This file can contain the autoyast profile p= art for the - software selection for example, in the case you want to do a dif= ferent - software selection on intel hardware than on others. So the outp= ut of the rule - script will be filled between the two '@' characters, to determi= ne the filename of - the profile to fetch. + The script in this rule can echo either "intel" or "non_intel" to + STDOUT (the output of the grep command must be directed to + /dev/null in this case). The output of the rule script will be + filled between the two '@' characters, to determine the filename + of the profile to fetch. &ay; will read the output and fetch a + file with the name "intel.xml" or "non_intel.xml". This file can + contain the &ay; profile part for the software selection, for + example, in case you want a different software selection on intel + hardware than on others. - The number of custom rules is limited to 5. So you can use custo= m1 to custom5. + The number of custom rules is limited to five. So you can use cu= stom1 to custom5.
- Match Types for rules + Match Types for Rules - you can have five different match_types: + You can use five different match_types: =20 - exact - which is the default + exact (default), - greater + greater, - lower + lower, - range + range, - regex (available since 10.1 and SLES10). It's a simp= le "=3D~" operator like in bash + regex (available since 10.1 and SLES10), a simple "= =3D~" operator like in bash. =20 "greater" and "lower" can be used for memsize or totaldisk for - example. They can match only on rules which return an integer va= lue. + example. They can match only with rules that return an integer v= alue. A range is only possible for integer values too and has the form= of - "value1-value2", for example "512-1024". regex can be used to ma= tch substrings - like "ntel" will match "Intel","intel" and "intelligent". + "value1-value2", for example "512-1024". "regex" can be used to = match substrings + like "ntel" will match "Intel", "intel" and "intelligent".
Combine Attributes - It's possible to combine multiple attributes via a logical opera= tor. So it's + Multiple attributes can be combined via a logical operator. It is possible to let a rule match if disksize is greater than 1GB or = memsize - is exact 512MB (well, not the best example maybe). + is exactly 512MB. - You can do that with the "operator" element in the rules.xml fil= e. Here is + You can do this with the "operator" element in the rules.xml fil= e. Here is an example: =20 @@ -320,24 +319,24 @@
- Rules file structure + Rules File Structure - The rules.xml file must have: =20 + The rules.xml file must: =20 - At least one rule + have at least one rule, - It must have the name rules.xml + have the name rules.xml, - It must be located in the directory - rules in the profile repository + be located in the directory + rules in the profile repository, =20 - At least one attribute to match in the rule + and have at least one attribute to match in the rule.
@@ -349,11 +348,9 @@ match in the rules file. - If you are unsure about a value on your system, start an autoinstallat= ion. - If the proposal shows up, switch to the console via CTRL+ALT+F2 and run - /usr/lib/YaST2/bin/y2base ayast_probe ncurses. It m= ight help to to turn the confirmation on for this, so that - the installation does not start in the background while you are watchi= ng the - values. The textbox with the values is scrollable. + If you are unsure about a value on your system, start an auto-installa= tion with "confirm" set to "true". + When the proposal shows up, switch to the console via CTRL+ALT+F2 and = run + /usr/lib/YaST2/bin/y2base ayast_probe ncurses. The = text box displaying the detected values can be scrolled. System Attributes @@ -369,68 +366,68 @@ hostaddress IP address of the host - This attribute must always match exactly + This attribute must always match exactly. hostname The name of the host - This attribute must always match exactly + This attribute must always match exactly. domain Domain name of host - This attribute must always match exactly + This attribute must always match exactly. installed_product - The name of the product that is getting installed. For example "SUS= E LINUX" - This attribute must always match exactly + The name of the product to be installed. + This attribute must always match exactly. installed_product_version - The version of the product that is getting installed. For example "= 9.3" - This attribute must always match exactly + The version of the product to be installed. + This attribute must always match exactly. network network address of host - This attribute must always match exactly + This attribute must always match exactly. mac MAC address of host This attribute must always match exactly. (MAC addresses - to be matched should be in the form 0080c8f6484c + should have the form 0080c8f6484c linux - Number of installed Linux partitions on the system - This attribute can be 0 or more + Number of installed Linux partitions on the systeme= map 2011-11-07: already installed or to be installed? + This attribute can be 0 or more. others Number of installed non-Linux partitions on the system - This attribute can be 0 or more + This attribute can be 0 or more. xserver X Server needed for graphic adapter - This attribute must always match exactly + This attribute must always match exactly. memsize Memory available on host in MByes - All match types are available + All match types are available. totaldisk Total disk space available on host in MBytes - All match types are available + All match types are available. haspcmica System has PCMCIA (i.e Laptops) - Exact match required, 1 for available PCMCIA or 0 for none + Exact match required, 1 for available PCMCIA or 0 for none. hostid @@ -450,7 +447,7 @@ disksize Drive device and size - All match types are available + All match types are available. product @@ -475,7 +472,7 @@ custom1-5 Custom rules using shell scripts - All match types are available + All match types are available. @@ -484,7 +481,7 @@
Rules with Dialogs - Since openSUSE 11.3 (not SLES11 SP1) you can use dialog popups where= you can select which rules you want to match and which not by checkboxes. + Since openSUSE 11.3 (not SLES11 SP1) you can use dialog popups with = checkboxes to select rules you want matched. The following elements must be between the <rules config:type= =3D"list"><rule><dialog> ... </dialog></rule></= rules> tags in the rules.xml file. @@ -501,37 +498,37 @@
dialog_nr - all rules with the same dialog_nr are presented= on the same popup dialog so the same dialog_nr can appear in multiple rules. + All rules with the same dialog_nr are presented= in the same popup dialog. The same dialog_nr can appear in multiple rules. <dialog_nr config:type=3D"integer">3<= ;/dialog_nr> - This element is optional and the default for a missin= g dialog_nr is always "0". If you have one popup only anyway, you don't need = to specify the dialog_nr + This element is optional and the default for a missin= g dialog_nr is always "0". If want to use one popup for all rules, you don't = need to specify the dialog_nr. element - each element needs a uniq id. Even if you have = more than one dialog, you must not use the same id twice like an id "1" on di= alog 1 and and id "1" on dialog 2. That's different than with <ask> dia= logs, where you can have the same <element> id on multiple dialogs. + Each elementemap 2011-11-07: Rather eac= h rule needs a unique element id? needs a unique id. Even if you hav= e more than one dialog, you must not use the same id twice like an id "1" on = dialog 1 and and id "1" on dialog 2. That's different than with <ask> d= ialogs, where you can have the same <element> id on multiple dialogs.emap 2011-11-07: Do we need to explain the ask-dialog here? It's distra= cting. <element config:type=3D"integer">3</= element> - optional. If left out, autoyast adds his own id's int= ernally but you can't use conflicts then (see below) + Optional. If left out, &ay; adds his own ids internal= ly. Then you cannot specify conflicting rules (see below). title - the caption of the popup dialog + Caption of the popup dialog <title>Desktop Selection</title><= /screen> - optional + Optional question - the question text is shown in the popup behind = the checkbox. + Question shown in the popup behind the checkbox. <question>KDE Desktop</question><= /screen> - optional. If you don't configure a text here, the nam= e of the XML file that is triggered by this rule will be shown instead. + Optional. If you don't configure a text here, the nam= e of the XML file that is triggered by this rule will be shown instead. timeout - a timeout in seconds after which the dialog wil= l automatically "press" the okay button. Useful for a non blocking installati= on in combination with rules-dialogs. + Timeout in seconds after which the dialog will = automatically "press" the okay button. Useful for a non-blocking installation= in combination with rules dialogs. <timeout config:type=3D"integer">30<= /timeout> - optional. A missing timeout will stop the installatio= n process until the dialog is confirmed by the user. + Optional. A missing timeout will stop the installatio= n process until the dialog is confirmed by the user. conflicts - a list of element id's (rules) that conflict wi= th this rule. If this rule matches or is selected by the user, all conflictin= g rules are deselected and disabled in the popup. Take care that you don't cr= eate deadlocks. + A list of element ids (rules) that conflict wit= h this rule. If this rule matches or is selected by the user, all conflicting= rules are deselected and disabled in the popup. Take care that you do not cr= eate deadlocks. <conflicts config:type=3D"list"> <element config:type=3D"integer">1</element> <element config:type=3D"integer">5</element> @@ -616,10 +613,8 @@
Classes - You can assign a system to different classes which can be defined in t= he - control file. Unlike rules, classes have to be configured in the contr= ol - file and represent a configuration which is typical for a group of - systems. + 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: @@ -635,33 +630,34 @@ ]]> - The file Software.xml must be in the directory "classes/TrainingRoom= /" then and - it will get fetched from the same place like the autoyast profile an= d the rules were - fetched from. + The file Software.xml must be in the directory "classes/TrainingRoom/" + then. It will get fetched from the same place the &ay; profile and rules + were fetched from.emap 2011-11-07: Doesn't make much sense. Does + this mean the directory "classes/TrainingRoom" containing Software.xml + needs to be in the same location as the ay profile and rules? - If you have multiple kind of profiles and those profiles share parts= , it's recommended to - use classes for that. You just have to change the class and all prof= iles using that class - are fixed too. By the way, you can reach something similar by using = XIncludes. + If you have multiple profiles and those profiles share parts, better + use classes for common parts. emap 2011-11-07: Sent= ence doesn't make sense. You can also use XIncludes. - Using the configuration management system, you can define a set of - classes. The class definition consists of the following variable for = each class: + Using the configuration management system,emap 2011-11-07: Is = this the same as the configuration system? you can define a set of + classes. A class definition consists of the following variables: - =20 - Name: Class name + emap 2011-11-07: Should the following variables really be upp= er case? =20 + Name: class name =20 - Descriptions: Class description + Descriptions:emap 2011-11-07: Really plural or rather: Descriptio= n? class description =20 - Order: Order (or priority) of the class in the stack of migration + Order: order (or priority) of the class in the stack of migration= emap 2011-11-07: What migration? @@ -672,43 +668,43 @@ 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. As an example, the following set of + configuration system concise. For example, the following sets of classes can be used: - site: Classes describing a physical location or site. + site: classes describing a physical location or site, - machine: Classes describing a type of machine or make + machine: classes describing a type of machine, - role: Classes describing the function of the machine to be - installed + role: classes describing the function of the machine, - group: Classes describing a department or a group within a site + group: classes describing a department or a group within a site or a location. =20 - 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. Fo= r example, - to create a new control file for a special computer with a specific n= etwork - interface, only the resource in the control file, 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. + A fileemap 2011-11-07: What kind of file would that be? A class + 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.emap 2011-= 11-07: Not very clear. =20
@@ -718,26 +714,26 @@ It is possible to mix rules and classes during an auto-installation session. For example you can identify a system using rules which conta= in - class definitions in them. The process is described in the figures + class definitions in them. The process is described in the figure . After retrieving the rules and merging them, the generated control file - is parsed and the presence of class definitions is checked. If classes + 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.
- The merging process of Rules and Classes + The Merging of Rules and Classes - With classes and with rules, multiple XML files get merged to one resu= lting + With classes and with rules, multiple XML files get merged into one re= sulting XML file. This process of merging is often confusing for people, becau= se it behaves different than one would expect. - Let's take a look at two XML parts that we want to merge: + For example, the following two XML parts should be merged: <partitioning config:type=3D"list"> @@ -781,31 +777,23 @@ =20 - What you would expect is, that you'll end up in a profile with 3 parti= tions. - That 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. Stuff that is configure= d in both - partitions, like mount or size, will=20 - be used from the second file. - Stuff that only exists in the first or second partition, will be copie= d to the - merged partition too. + 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.emap 2011-11-07: A little confusing, why = not put the merged file here. - Sometimes this is what you want, but sometimes this is not what you wa= nt. Actually, - in my example above, this is both. You don't want a second d= rive - right? You want the two drives to be merged into one but for partition= s you want three seperate - ones. - So how can you achieve what you want? In this example, how do you get = three partitions but still - one drive? - - =20 - - FIXME Title - For SLES9/SUSE Linux 10.0 and earlier versions + In this example, you don't want a second drive. T= he two drives should be merged into one. With regard to partitions, three sep= arate ones should be defined.=20 + + Workaround for SLES9/SL 10.0 and earlier + The following workaround only works for SLES9/SL 10.0 and earl= ier versions. - =20 - you can only use a trick. It's - not official supported by autoyast and more a workaround than a nice s= olution. For each partition - in one file, add an attribute to the partition like this: + + The following method is not officially supported by &ay;. For ea= ch + partition in one file, add an attribute to the partition: =20 @@ -815,17 +803,15 @@ =20 - The trick is, that the merge script will not detect the partitions as = the same element type because of the - new attribute. If you have more files, it might be needed to to add mo= re attributes like dontmerge=3D"2". + Because of the new attribute, the merge script will not detect the par= titions as the same element type. If you have more files, you may need to add= more attributes like dontmerge=3D"2", etc. =20 - FIXME Title - For SLES10/SUSE Linux 10.1 and later + Solution for SLES 10/SL 10.1 and later + The following method solves the merging problem for SLES10, SU= SE Linux 10.1 and later versions. =20 - you can use the dont_merge element in the r= ules or classes file - like this: + Use the dont_merge element in the rules or = class file: =20 --=20 To unsubscribe, e-mail: yast-commit+unsubscribe@opensuse.org For additional commands, e-mail: yast-commit+help@opensuse.org --===============8231806072710474229==--