Understanding Autoyast in SUSE

SUSE Linux Enterprise
Server
www.suse.com 11 SP2
February21,2012 AutoYaST
AutoYaST
Contents
1 Introduction 1
1.1 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Overview and Concept . . . . . . . . . . . . . . . . . . . . . . . 3
2 The Control File 5
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 RELAX NG - a schema language for XML . . . . . . . . . . . . . . . 9
3 Creating A Control File 11
3.1 Collecting Information . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Using the Confguration Management System (CMS) . . . . . . . . . . 11
3.3 Creating/Editing a Control File Manually . . . . . . . . . . . . . . . 13
3.4 Creating a Profle (Control File) via Script with XSLT . . . . . . . . . . 14
4 Confguration and Installation Options 17
4.1 General Options . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3 The Boot Loader . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4 Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.6 Services and Runlevels . . . . . . . . . . . . . . . . . . . . . . 63
4.7 Network Confguration . . . . . . . . . . . . . . . . . . . . . . 64
4.8 NIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.9 LDAP client . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.10 NFS Client and Server . . . . . . . . . . . . . . . . . . . . . . . 69
4.11 NTP Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.12 Mail Confguration (Sendmail or Postfx) . . . . . . . . . . . . . . . 71
4.13 Security settings . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.14 Monitor and X11 Confguration . . . . . . . . . . . . . . . . . . . 75
4.15 Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.16 Custom User Scripts . . . . . . . . . . . . . . . . . . . . . . . . 77
4.17 System Variables (Sysconfg) . . . . . . . . . . . . . . . . . . . . 93
4.18 Adding Complete Confgurations . . . . . . . . . . . . . . . . . . 93
4.19 Ask the user for values during installation . . . . . . . . . . . . . . 95
4.20 Kernel dumps . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.21 Miscellaneous Hardware and System Components . . . . . . . . . . 115
5 Network-based Installation 121
5.1 Confguration Server . . . . . . . . . . . . . . . . . . . . . . . 121
6 Rules and Classes 123
6.1 Rules-based Automatic Installation . . . . . . . . . . . . . . . . . 123
6.2 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.3 Mixing Rules and Classes . . . . . . . . . . . . . . . . . . . . . 136
6.4 The Merging of Rules and Classes . . . . . . . . . . . . . . . . . 136
7 The Auto-Installation Process 139
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 139
7.2 Choosing the Right Boot Medium . . . . . . . . . . . . . . . . . 140
7.3 Invoking the Auto-Installation Process . . . . . . . . . . . . . . . 143
7.4 System Confguration . . . . . . . . . . . . . . . . . . . . . . 150
A Handling Rules 153
B Advanced Linuxrc Options 155
B.1 Passing parameters to Linuxrc . . . . . . . . . . . . . . . . . . . 155
B.2 info fle format . . . . . . . . . . . . . . . . . . . . . . . . . 156
B.3 Advanced Network Setup . . . . . . . . . . . . . . . . . . . . . 159
1 Introduction
AutoYaST2 is a system for installing one or more SUSE Linux systems automatically
and without user intervention. AutoYaST2 installations are performed using an Auto-
YaST profle with installation and confguration data. That profle can be created using
the confguration insterface of AutoYaST2 and can be provided to YaST2 during instal-
lation in different ways.
1.1 Availability
AutoYaST2 is available with recent SUSE products starting from SUSE Linux 8.0 and
business products starting from SLES 8.
Products prior to SuSE Linux 8.0 and business products based on SLES 7 have an auto-
installation system based on YaST1. A confguration management system is provided
by ALICE for these products.
NOTE: Updated documentation
Updated documentation can always be found at the following URL: http://
www.suse.com/~ug
Introduction 1
1.2 Motivation
The Linux Journal [http://www.linuxjournal.com/], in an article in issue
78 [http://www.linuxjournal.com/categories.php?op=newindex
&catid=178] writes:
Astandard Linux installation asks many questions about what to install, what hardware
to confgure, how to confgure the network interface, etc. Answering these questions
once is informative and maybe even fun. But imagine a system engineer who has to set
up a new Linux network with a large number of machines. Now, the same issues need
to be addressed and the same questions answered repeatedly. This makes the task very
ineffcient, not to mention a source of irritation and boredom. Hence, a need arises to
automate this parameter and option selection.
The thought of simply copying the hard disks naturally crosses one's mind. This can
be done quickly, and all the necessary functions and software will be copied without
option selection. However, the fact is that simple copying of hard disks causes the indi-
vidual computers to become too similar. This, in turn, creates an altogether newmission
of having to reconfgure the individual settings on each PC. For example, IP addresses
for each machine will have to be reset. If this is not done properly, strange and inexpli-
cable behavior results.
Regular installation of SuSE Linux is semi-automated by default. The user is requested
to select the necessary information at the beginning of the installation (In most cases
language only), YaST2 then generates a proposal for the underlying system depending
on different factors and systemparamters. In most cases, and especially for newsystems,
such a proposal can be used to install the system and provides a usable installation.
The steps following the proposal are fully automated and the user is only prompted at
the end of the installation to confgure hardware and network services.
AutoYaST2 can be used where no user intervention is required or where customization
is required. Using an AutoYaST profle, YaST2 prepares the systemfor a custominstal-
lation and avoids any interaction with the user, unless specifed in the fle controling
the installation.
AutoYaST2 is not an automated GUI system. This means that in most cases many
screen will be skipped, i.e. you will never see the language selection interface. Auto-
2 AutoYaST
YaST2 will simply pass the language parameter to the sub-system without displaying
any language related interface.
1.3 Overview and Concept
Using AutoYaST2, multiple systems sharing the same environment and similar but not
necesserily identical hardware and performing similar tasks, can easily be installed in
parallel and quickly. A confguration flereferred to as "AutoYaST profle"is cre-
ated using existing confguration resources. The profle fle can be easily tailored for
any specifc environment.
Unlike autoinstallation systems available with older SUSE releases, AutoYaST2 is
fully integrated and provides various options for installing and confguring a system.
The main advantage over older systems and other auto-installation systems is the pos-
sibility to confgure a computer by using existing modules and avoiding using custom
scripts which are normally executed at the end of the installation.
This document will guide you through the three steps of auto-installation:
Preparation: All relevant information about the target systemare collected and turned
into the appropriate directives of the profle. The profle fle is transferred onto the
target systemwhere its directives will be parsed and transformed to YaST2 conforming
data.
Installation: Follows the instructions given in the profle and installs the base system.
Confguration: YaST2 in addition to user-defned post-install scripts, complete the
system confguration.
The complete and detailed process is illustrated in the following fgure:
Introduction 3
Figure 1.1 Auto-installation process
4 AutoYaST
2 The Control File
2.1 Introduction
The control fle is in most cases a confguration description for a single system. It
consists of sets of resources with properties including support for complex structures
representations such as lists, records, trees and large embedded or referenced objects.
2.2 Format
The XML confguration format provides a consistent fle structure, which is easier to
learn and remember when attempting to confgure a new system.
Using XML, you can eliminate (nearly) all of the confguration fle parsing and error
handling an external XML parser can do that instead (especially if it is a validating
parser). To make sure the control fle is well-formatted and the syntax valid, you can
run the control fle through a validating parser before it is actually used for automatic
installation. This is especially required if you prefer to edit the profle manually.
The following example shows a control fle in XML format:
The Control File 5
Example 2.1 XML Control File (Profle)
<?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> 
<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> 
<configure> 
<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> 
</profile>
6 AutoYaST
2.3 Structure
Below is an example of a basic control fle container, the actual content of which is
explained later on in this chapter.
Example 2.2 Control fle container
<!DOCTYPE profile>
<profile

</profile>
The profle element (root node) contains one or more distinct resource elements. The
permissible resource elements are specifed in the schema fles
2.3.1 Resources and Properties
Aresource element either contains multiple and distinct property and resource elements,
or multiple instances of the same resource element, or it is empty. The permissible
content of a resource element is specifed in the schema fles.
A property element is either empty or contains a literal value. The permissible property
elements and values in each resource element are specifed in the schema fles
An element can be either a container of other elements (a resource) or it has a literal
value (a property); it can never be both. This restriction is specifed in the schema fles.
A confguration component with more than one value must either be represented as
some kind of embedded list in a property value or as a nested resource.
2.3.2 Nested Resources
Nested resource elements allow a tree-like structure of confguration components to be
built to any level.
The Control File 7
Example 2.3 Nested Resources
...
<drive>
<partition>
<size>1000mb</size>
<mount>/</mount>
</partition>
<partition>
<size>250mb</size>
<mount>/tmp</mount>
</partition>
</partitions>
</drive>
....
In the example above the disk resource consists of a device property and a partitions
resource. The partitions resource contains multiple instances of the partition resource.
Each partition resource contains a size and mount property.
In the schema fles is specifed that the partitions resource contains multiple instances,
but it is still required to specify this to avoid wrong data typing in YaST2. Using the
example above, if having a drive with only one partition this would result in interpreting
the partition resource as a property. To avoid this, the following syntax must be used
when defning multiple instances. For more information about type attributes, see the
next section.
Example 2.4 Nested Resources with Type Attributes
...
<drive>
<partition>
<size>1000</size>
<mount>/</mount>
</partition>
<partition>
<size>250</size>
<mount>/tmp</mount>
</partition>
</partitions>
</drive>
....
8 AutoYaST
2.3.3 Attributes
Global profle attributes are used to defne meta-data on resources and properties. At-
tributes are used to defne context switching. They are also used for naming and typing
properties as shown in the previous sections. Profle attributes are in a separate
namespace so they do not have to be treated as reserved words in the default namespace.
New ones can then be added without having to potentially alter existing profles.
Profle attributes are defned in the confguration namespace and must always be prefxed
with confg: . All profle attributes are optional. Most can be used with both resource
and property elements but some can only be used with one type of element which is
specifed in the schema fles.
The type of an element is defned using the confg:type attribute. The type of a resource
element is always RESOURCE, although this can also be made explicit with this attribute
(to ensure correct identifcation of an empty element, for example, when there is no
schema fle to refer to). Aresource element cannot be any other type and this restriction
is specifed in the schema fle. The type of a property element determines the interpre-
tation of its literal value. The type of a property element defaults to STRING, as specifed
in the schema fle. The full set of permissible types is specifed in the schema fle.
2.4 RELAX NG - a schema language
for XML
2.4.1 Introduction
A RELAX NG schema specifes a pattern for the structure and content of an XML
document. A RELAXNGschema thus identifes a class of XML documents consisting
of those documents that match the pattern. A RELAX NG schema is itself an XML
document.
Verffy your AutoYaST XML fle
/usr/bin/xmllint --noout --relaxng
/usr/share/YaST2/schema/autoyast/rng/profile.rng myAutoYaSTProfile.xml
The Control File 9
3 Creating A Control File
3.1 Collecting Information
In order to create the control fle, you need to collect information about the systems
your are going to install. This includes hardware data and network information among
other things. Make sure you have the following information about the machines you
want to install:
Hard disk types and sizes
Graphical interface and attached monitor, if any
Network interface and MAC address if known (for example, when using DHCP)
With these parameters you are ready to go and create a profle of your systems to control
the auto-installation process.
3.2 Using the Confguration
Management System (CMS)
In order to create the control fle for one or more computers, a confguration interface
based on YaST2 is provided. This system depends on existing modules which are usu-
ally used to confgure a computer in regular operation mode, for example, after SUSE
Linux is installed.
Creating A Control File 11
The confguration management system lets you create control fles easily and lets you
manage a repository of confgurations for the use in a networked environment with
multiple clients.
Figure 3.1 Confguration System
3.2.1 Creating a New Profle
With some exceptions, almost all resources of the control fle can be confgured using
the confguration management system. The systemoffers fexibility and the confguration
of some resources is identical to the one available in the YaST2 Control Center. In ad-
dition to the existing and familiar modules new interfaces were created for special and
complex confgurations, for example for partitioning, general options and software.
Furthermore, using a CMS guarantees the validity of the resulting control fle and its
direct use for starting automated installation.
Make sure the confguration system is installed (package autoyast2) and call it using
the YaST2 Control Center or as root with the following command (make sure the DIS-
PLAY variable is set correctly to start the graphical user interface instead of the text
based one):
/sbin/yast2 autoyast
12 AutoYaST
3.3 Creating/Editing a Control File
Manually
If editing the control fle manually, make sure it has a valid syntax. To check the syntax,
use the tools already available on the distribution. For example, to verify that the fle
is well-formed, use the utility xmllint available with the libxml2 package:
xmllint <control file>
If the control fle is not well formed, for example, if a tag is not closed, xmllint will
report about the errors.
Before going on with the autoinstallation, fx any errors resulting from such checks.
The autoinstallation process cannot be started with an invalid and not well-formed
control fle.
You can use any XML editor available on your system or your favorite text editor with
XML support (for example, Emacs, Vim). However, it is not optimal to create the
control fle manually for a large number of machines and it should only be seen as an
interface between the autoinstallation engine and the Confguration Management System
(CMS).
Figure 3.2 Editing the control fle with kxmledit
3.4 Creating a Profle (Control File)
via Script with XSLT
If you have a template and want to change a few things via script or command line, use
an XSLT processor like sablot. For example, if you have an AutoYaST profle and
want to fllout the hostname via script for any reason (if doing this so often, you want
to script it)
First, create an XSL fle
14 AutoYaST
Example 3.1 Example fle for replacing hostname/domain by script
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:y2="http://www.suse.com/1.0/yast2ns"
xmlns:config="http://www.suse.com/1.0/configns"
version="1.0">
<xsl:output method="xml" encoding="UTF-8" indent="yes"
omit-xml-declaration="no" cdata-section-elements="source"/>

<xsl:param name="hostname"/>
<xsl:param name="domain"/>
<xsl:template match="/">
<xsl:apply-templates select="@*|node()"/>
</xsl:template>
<xsl:template match="y2:dns">
<xsl:copy>

<domain><xsl:value-of select="string($domain)"/></domain>
<hostname><xsl:value-of select="string($hostname)"/></hostname>
</xsl:copy>
</xsl:template>
<xsl:template match="@*|node()" >
<xsl:copy>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
This fle expects the "hostname" and the "domain" as parameters from the user.
<xsl:param name="hostname"/>
<xsl:param name="domain"/>
There will be a copy of those parameters in the dns section of the control fle. That
means, if there already is a domain element in the dns section, you will get a second
one (no good).
If you want to create a new AutoYaST profle now from the template plus the XSL fle,
run the following command:
sabcmd add_hostname.xsl \$hostname=myHost \$domain=my.domain template.xml
You will get a flled out AutoYaST profle then on STDOUT.
If you have multiple XSL fles you want to apply to a template, do the following:
sabcmd add_hd_vg.xsl \$device=/dev/sda \$partition=p2 \$vg=system \
| sabcmd add_harddisk.xsl \$device=/dev/system \$lvm=true \
| sabcmd ....
| sabcmd add_hostname.xsl \$hostname=myHost \$domain=my.domain
Pipe the output of each sabcmd to the next sabcmd.
For more information about XSLT, go to the offcial Web page www.w3.org/TR/xslt
[http://www.w3.org/TR/xslt]
16 AutoYaST
4
Confguration and Installation
Options
This chapter introduces important parts of a control fle for standard purposes. To learn
about other available options, use the confguration management system.
Note that for some of the confguration options to work, additional packages have to
be installed, depending on the software selection you have confgured. If you choose
to install Minimal then some packages might be missing and have to be added to the
individual package selection.
YaST will install packages required in the second phase of the installation and before
the post-installation phase of AutoYaST has started. However, if necessary YaST
modules are not available in the system, important confguration steps will be skipped.
For example, no security settings will be confgured if yast2-security is not installed.
4.1 General Options
General options include all the settings related to the installation process and the envi-
ronment of the installed system.
Confguration and Installation Options 17
Example 4.1 General Options
The mode section confgures the behavior of AutoYaST with regard to confrmation
and rebooting. The following has to be in the <general><mode> section.
By default, the user must confrm the auto-installation process. This option allows the
user to view and change the settings for a target system before they are committed and
can be used for debugging. confrm is set to "true" by default to avoid recursive installs
when the systemschedules a reboot after initial systemsetup. Only disable confrmation
if you want to carry out a fully unattended installation.
With halt you cause AutoYaST to shut down the machine after all packages have been
installed. Instead of a reboot into stage two, the machine is turned off. The bootloader
is alreay installed and all your chroot scripts have run.
fnal_halt and fnal_reboot have been introduced with openSUSE 11.0 and SLES11.
You can reboot or halt the machine after installation and confguration are fnished at
the end of stage 2.
openSUSE 11.0 uses the kexec feature and does not reboot anymore between stage1
and stage2. With the forceboot option you can force the reboot in case you need it for
some reason. The value "true" will reboot, "false" will not reboot and a missing forceboot
option uses the product's default.
<general>
<signature-handling>
<accept_unsigned_file
config:type="boolean">true</accept_unsigned_file>
<accept_file_without_checksum
config:type="boolean">true</accept_file_without_checksum>
<accept_verification_failed
config:type="boolean">true</accept_verification_failed>
<accept_unknown_gpg_key
config:type="boolean">true</accept_unknown_gpg_key>
<import_gpg_key
config:type="boolean">true</import_gpg_key>
<accept_non_trusted_gpg_key
config:type="boolean">true</accept_non_trusted_gpg_key>
</signature-handling>
<mode>
<halt config:type="boolean">false</halt>
<forceboot config:type="boolean">false</forceboot> <! -- since
11.0 -->
<final_reboot config:type="boolean">false</final_reboot> <! -- since
11.0 -->
18 AutoYaST
<final_halt config:type="boolean">false</final_halt> <! -- since
11.0 -->
<confirm config:type="boolean">true</confirm>
<second_stage config:type="boolean">true</second_stage>
</mode>
<proposals config:type="list"> 
<proposal>partitions_proposal</proposal>
</proposals>
<wait> 
<pre-modules config:type="list">
<module>
<name>networking</name>
<sleep>
<time config:type="integer">10</time>
<feedback config:type="boolean">true</feedback>
</sleep>
<script>
<source>
sleep 5
</source>
<debug config:type="boolean">false</debug>
</script>
</module>
</pre-modules>
<post-modules config:type="list">
<module>
<name>networking</name>
<sleep>
<time config:type="integer">3</time>
</sleep>
<script>
<source>
sleep 7
</source>
</script>
</module>
</post-modules>
</wait>

<storage>

<partition_alignment
config:type="symbol">align_cylinder</partition_alignment>
</storage>
</general>
AutoYaST in openSUSE 11.1 allows you to confgure the proposal screen with the
<proposals confg:type="list"> option in the profle. All proposals that are listed in that
section are shown in the proposal screen if you set the confrm option to "true".
This is the proposal list openSUSE 11.1, which you can also fnd in the control.xml
fle on the installation source:
partitions_proposal
bootloader_proposal
country_simple_proposal
timezone_proposal
users_proposal
hwinfo_proposal
mouse_proposal
software_proposal
runlevel_proposal
deploying_proposal
The wait section has been introduced with openSUSE 11.1 and SLES11. You can let
AutoYaST sleep before and after each module run during the second stage. You can
run scripts and/or pass a value (in seconds) for AutoYaST to sleep. In the example
above AutoYaST will sleep for 15 seconds (10+5) before the network confguration
starts and 10 seconds (3+7) after the network confguration is done. The scripts in the
20 AutoYaST
example don't really make a lot of sense because you could pass that value as "time"
value too. They are only used to show how scripts in the wait section work now.
NOTE: Changes since SUSE Linux 10.1/SLES10
The language, keyboard and clock properties in the general resource were
moved to the root (profle) element of the autoyast profle. Do not use them
in the general section anymore.
Now you can use the second_stage property to turn off AutoYaST after the
frst reboot (set to "false"). Then the complete second stage is a manual instal-
lation. Default is "true", which means AutoYaST is doing a complete installation.
Since openSUSE 11.0 you can set the boolean fnal_reboot and fnal_halt to
reboot or turn off the machine at the end of stage 2.
For signature handling, read the Section 4.5, Software (page 55).
4.2 Reporting
The report resource manages three types of popups that may appear during installation:
message popups (usually non-critical, informative messages),
warning popups (if something might go wrong),
error popups (in case an error occurs).
Example 4.2 Reporting Behavior
<report>
<messages>
<show config:type="boolean">true</show>
<timeout config:type="integer">10</timeout>
<log config:type="boolean">true</log>
</messages>
<errors>
</errors>
<warnings>
</warnings>
</report>
Depending on your experience, you can skip, log and show (with timeout) those mes-
sages. It is recommended to show all messages with timeout. Warnings can be skipped
in some places but should not be ignored.
The default setting in auto-installation mode is to show all messages without logging
and with a timeout of 10 seconds.
WARNING: Critical System Messages
Note that not all messages during installation are controlled by the report re-
source. Some critical messages concerning package installation and partitioning
will show up ignoring your settings in the report section. Mostly those messages
will have to be answered with Yes or No.
4.3 The Boot Loader
This documentation is for yast2-bootloader and applies to SLE11 and openSUSE 11.0+.
For older versions, use the documentation that comes with your distribution in
/usr/share/doc/packages/autoyast2/
General scope of AutoYaST profle only bootloader part.
22 AutoYaST
<bootloader>
<device_map config:type="list">
- info about order of devices in device.map
</device_map>
<global>
- info about configuration of installation (installation settings for GRUB
and generic boot code)
</global>
<initrd_modules config:type="list">
- list of initrd modules
</initrd_modules>
<loader_type>grub</loader_type> - type of bootloader
<sections config:type="list">
- bootloader sections in menu.lst
</sections>
</bootloader>
4.3.1 Device map
You can defne devices and their order in device.map, but it is not necessary. yast2-
bootloader checks the devices during installation and proposes a device.map. It can
happen that the order of the devices is wrong or you have defned a different order than
the one set in the BIOS. Take care when you make changes there. The system might
not boot afterwards.
<device_map config:type="list">
<device_map_entry>
<firmware>hd0</firmware> 
<linux>/dev/disk/by-id/ata-ST3500418AS_6VM23FX0</linux> 
</device_map_entry>
</device_map>
4.3.2 Globals
This is an important if optional part. Defne here where to install GRUB and how the
boot process will work. Again, yast2-bootloader proposes a confguration if you don't
defne one. Usually the AutoYaST profle includes only this part and all other parts are
added automatically during installation by yast2-bootloader. Unless you have some
special requirements, don't specify the bootloader confg in the XML fle.
<global>
<activate>true</activate>
<default>openSUSE 11.2 - 2.6.31.5-0.1</default>
<gfxmenu>(hd0,1)/boot/message</gfxmenu>
<lines_cache_id>4</lines_cache_id>
</global>
De-
scrip-
tion
Values Attribute
Set the boot fag on the boot partition. The boot partition
can be "/" if there is no separate /boot partition. If the boot
activate
partition is on a logical partition, the boot fag is set to the
extended partition.
<activate>true</activate>
Name (title) of the default boot section from menu.lst.
default
<default>openSUSE 11.2 - 2.6.31.5-0.1</default>
Path to the graphical boot menu (/boot/message). Set to
'none' if you do not want to use a graphical boot menu.
gfxmenu
<gfxmenu>(hd0,1)/boot/message</gfxmenu>
The timeout in seconds for automatically booting the de-
fault boot section from menu.lst.
timeout
Write generic boot code to MBR, will be ignored if
boot_mbr is set to "true".
generic_mbr
<generic_mbr>false</generic_mbr>
Write GRUB to MBR of the frst disk in the order (de-
vice.map includes order of disks).
boot_mbr
<boot_mbr>false</boot_mbr>
Write GRUB to separate /boot partition. If no separate
/boot partition exists, GRUB will be written to "/".
boot_boot
<boot_boot>false</boot_boot>
24 AutoYaST
De-
scrip-
tion
Values Attribute
Write GRUB to "/" partition. boot_root
<boot_root>false</boot_root>
Write GRUB to the extended partition (important if you
want to use a generic boot code and the "boot" partition is
boot_extended
logical). NOTE: if the boot partition is logical, it should
use boot_mbr (write GRUB to MBR) instead of gener-
ic_mbr.
<boot_extended>false</boot_extended>
Write GRUB to custom device. boot_custom
<boot_custom>/dev/sda3</boot_custom>
Use trusted GRUBinstead of the classical GRUB(gfxmenu
is deleted automatically if this option is true). Do not use
trusted GRUB if your hardware does not support it.
trusted_grub
<trusted_grub>false</trusted_grub>
Internal option specifying the cache id for perl-Bootloader.
Do not use or change it in a cloned XML fle.
lines_cache_id
4.3.3 Initrd modules
A list of initrd modules. Do not create your own list if you do not fully understand the
impact. AutoYaST will take care of it for you.
4.3.4 Loader Type
Defne which boot loader to use: grub, lilo, ppc or elilo.
<loader_type>grub</loader_type>
4.3.5 Sections
The confguration of the boot sections in the menu.lst is added automatically here by
yast2-bootloader during installation. yast2-bootloader deletes boot sections with no
valid kernel and initrd path.
<section>
<append>resume=/dev/disk/by-id/raid-sil_ajacccbhejai-part2 splash=silent
quiet showotps</append>
<image>(hd0,0)/vmlinuz-2.6.31-10-default</image>
<initial>1</initial>
<initrd>(hd0,0)/initrd-2.6.31-10-default</initrd>
<name>openSUSE 11.2 Milestone 8 - 2.6.31-10 (default)</name>
<original_name>linux</original_name>
<root>/dev/mapper/sil_ajacccbhejai_part3</root>
<type>image</type>
<vgamode>0x31a</vgamode>
</section>
<section>
<append>resume=/dev/disk/by-id/raid-sil_ajacccbhejai-part2 splash=silent
quiet showopts</append>
<image>(hd0,0)/vmlinuz-2.6.31-10-xen</image>
<initrd>(hd0,0)/initrd-2.6.31-10-xen</initrd>
<name>Xen -- openSUSE 11.2 Milestone 8 - 2.6.31-10</name>
<nounzip>0</nounzip>
<original_name>xen</original_name>
<type>xen</type>
<xen>(hd0,0)/xen.gz</xen>
<xen_append></xen_append>
</section>
<section>
<blockoffset>1</blockoffset>
<chainloader>/dev/fd0</chainloader>
<name>Floppy</name>
<noverifyroot>true</noverifyroot>
<original_name>floppy</original_name>
<type>other</type>
</section>
</sections>
26 AutoYaST
4.3.6 Options
Available options depend on the type.
4.3.6.1 Options for Section Type: image and xen
De-
scrip-
tion
Values Attribute
List of kernel args but without(!) vga= and root=. append
<append>splash=silent quiet showopts</append>
Path to the kernel. image
<image>(hd0,0)/vmlinuz-2.6.31-10</image>
Path to the initrd. initrd
<initrd>(hd0,0)/my-initrd</initrd>
Internal option specifying the cache id for perl-Bootload-
er. Do not use or change it in a cloned XML fle.
lines_cache_id
Name of section. name
<name>Productive System</name>
Internal name of section parsed by YaST from a com-
ment in the confguration fle. There are some rules for
original_name
names, and original_name helps to determine if the boot
section is "linux" or "failsafe". For chainloader it helps
to determine if it is "windows" or other (linux, foppy,
etc). Use a simple original_name: linux, xen, windows,
foppy, etc.
De-
scrip-
tion
Values Attribute
Location of the root partition ("/"). root
Type of section (image/xen/other/menu). type
<type>xen</type>
Kernel arg for vga (vga=). vgamode
Path to xen.gz. xen
<xen>(hd0,0)/xen.gz</xen>
Kernel args for XEN. xen_append
<xen_append></xen_append>
4.3.6.2 Options for Section Type: other (chainloader)
De-
scrip-
tion
Values Attribute
lines_cache_id
Name or title of the section. name
<name>Floppy</name>
Internal name of the section parsed by YaST from a
comment in the confguration fle. There are some rules
original_name
28 AutoYaST
De-
scrip-
tion
Values Attribute
for names and original_name helps to determine if the
boot section is "linux" or "failsafe". For the chainloader
it helps to determine if it is "windows" or other (linux,
foppy, etc). Use a simple original_name: linux, xen,
windows, foppy etc.
<type>other</type>
Offset in chainloader (used only in grub). blockoffset
<blockoffset>1</blockoffset>
Partition part for chainloader (so chainloader+blockoffset
get fnal chainloader item in grub).
chainloader
<chainloader>/dev/fd0</chainloader>
With or without checking root. noverifyroot
<noverifyroot>true</noverifyroot>
Windows-specifc option for remapping hard disks, for
example switch the frst and second disk: map (hd0) (hd1)
map (hd1) (hd0)
remap
<remap>false</remap>
Add the makeactive argument for the chainloader section. makeactive
<makeactive>false</makeactive>
4.3.6.3 Options for section type: menu (confgfle)
De-
scrip-
tion
Values Attribute
lines_cache_id
Name or title of section. name
<name>Floppy</name>
Internal name of section parsed by YaSTfroma comment
in the confguration fle. There are some rules for names
original_name
and original_name helps to determine if the boot section
is "linux" or "failsafe". For the chainloader it helps to
determine if it is "windows" or other (linux, foppy etc).
Use a simple original_name: linux, xen, windows, foppy
etc.
<type>other</type>
Path to menu.lst confg fle. confgfle
<configfile>1</configfile>
Device name for loading menu.lst from another installa-
tion of Linux.
root
<root>/dev/sda1</root>
30 AutoYaST
4.4 Partitioning
4.4.1 Drive Confguration
WARNING: EVMS Support Dropped in openSUSE 11.1 and SLES11
Since openSUSE 11.1 and SLES11, EVMS is no longer supported in the installation
system. That means all support for EVMS in AutoYaST was dropped as well.
Alll EVMS documentation here is only valid for SLES10 (all service packs) and
openSUSE versions prior to openSUSE 11.1.
The following elements must be between the <partitioning confg:type="list"><drive>
... </drive></partitioning> tags in the <profle> section.
Description Values Attribute
Optional. If left out, Auto-
YaST tries to guess the de-
The device you want to confgure in this
section. Since SUSE Linux 10.1 and
device
vice. ARAIDmust always
have "/dev/md" as device.
SLES10, you can use persistent device
names via id, like /dev/disk/by-id/ata-
WDC_WD3200AAKS-75L9A0_WD-
WMAV27368122. With SLES10 SP1 and
SUSE Linux 10.2, by-path is possible
too, like /dev/disk/by-path/pci-
0001:00:03.0-scsi-0:0:0:0.
Optional. The default is
"false".
If set to "true", the partition table gets
wiped out before AutoYaST starts the
partition calculation.
initialize
<initialize config:type="boolean"
>true</initialize>
Deprecated since
SLES10SP1 and SL10.2.
Specifes if a device is not a physical de-
vice but a LVM volume group (see LVM
confguration below).
is_lvm_vg
Use type instead. Must be
<is_lvm_vg config:type="boolean"
>true</is_lvm_vg>
"true" if this device is a
LVM volume group. The
default is "false".
Deprecated since
SLES10SP1 and SL10.2.
Specifes if a device is not a physical de-
vice but an EVMS volume group (see
EVMS confguration below).
is_evms_vg
Use type instead. Must be
<is_evms_vg config:type="boolean"
>true</is_evms_vg>
"true" if this device is an
EVMS volume group. The
default is "false".
Optional. If no partitions
are specifed, AutoYaST
A list of <partition> entries (see table
below).
partitions
will create a reasonable
<partition>...</partition>
partitioning (see Automat-
ed Partitioning below).
...
</partitions>
Optional. Default is 4Mfor
EVMS/LVM volume
groups.
This value makes only sense with
LVM/EVMS.
<pesize>8M</pesize>
pesize
This parameter should be
provided.
Specifes the strategy AutoYaST will use
to partition the hard disk.
use
Choose between:
all (uses the whole device while calcu-
lating the new partitioning),
linux (only existing linux partitions are
used),
32 AutoYaST
free (only unused space on the device
is used, no other partitions are
touched),
1,2,3 (a list of comma separated parti-
tion numbers to use).
Optional. Default is
CT_DISK for a normal
physical hard disk.
Specify the type of the drive (This param-
eter replaces is_lvm_vg and is_evms_vg
in SLES10 and SL10.1)
type
Choose between:
CT_DISK for physical hard disks (de-
fault),
CT_LVM for LVM volume groups,
CT_EVMS for EVMS volume groups.
<type
config:type="symbol">CT_LVM</type>
Optional and available
since openSUSE 12.1 and
Describes the type of the partition table.
Choose between:
disklabel
SLES11 SP2. By default
YaST decides what makes
msdos,
sense (msdos in most cas-
es).
gpt.
<disklabel>gpt</disklabel>
Optional and available
since openSUSE 12.1 and
This value only makes sense for
type=CT_LVMdrives. If you are reusing
keep_un-
known_lv
SLES11 SP2. The default
is "false".
a LVG and you set this to "true", all ex-
isting LVs in that VGwill not be touched
unless they are specifed in the <partition-
ing> section. So you can keep existing
LVs without specifying them.
<keep_unknown_lv
config:type="boolean"
>false</keep_unknown_lv>
4.4.2 Partition Confguration
The following elements must be between the <partitions confg:type="list"><partition>
... </partition></partitions> tags in the <drive> section.
If set to
"false", pro-
Specify if this partition must be created or if it already exists.
<create config:type="boolean"
>false</create>
create
vide informa-
tion for Auto-
YaST which
partition this
is (like with
partition_nr).
You should
have at least
The mountpoint of this partition.
<mount>/</mount>
mount
a root parti-
<mount>swap</mount>
tion (/) and a
swap parti-
tion.
See man
mount for
Mount options for this partition.
<fstopt
>ro,noatime,user,data=ordered,acl,user_xattr</fstopt>
fstopt
available
mount op-
tions.
34 AutoYaST
See man
e2label
The label of the partition (useful for the "mountby" parameter;
see below).
<label>mydata</label>
label
for an exam-
ple.
See man
uuidgen.
The uuid of the partition (only useful for the "mountby" pa-
rameter; see below).
<uuid
>1b4e28ba-2fa1-11d2-883f-b9a761bde3fb</uuid>
uuid
The size of the partition, e.g. 4G, 4500M, etc. The /boot
partition and the swap partition can have "auto" as size. Then
size
AutoYaST calculates a reasonable size. One partition can
have the value "max" to use all remaining space.
With SUSE Linux 10.2 and SLES10 SP1, you can specify
the the size in percentage. So 10% will use 10% of the size
of the hard disk or VG. You can mix auto, max, size, and
percentage as you like.
<size>10G</size>
If you set
"create" to
Specify if AutoYaST should format the partition.
<format config:type="boolean">false</format>
format
"true", then
you likely
want this is
option set to
"true" as
well.
Optional.
The default is
reiser
Specify the flesystem to use on this partition: flesystem
reiser,
ext2,
ext3,
xfs,
jfs,
swap.
<filesystem config:type="symbol"
>reiser</filesystem>
In most cas-
es, numbers 1
The partition number of this partition. If you have set cre-
ate=false or if you use LVM, then you can specify the parti-
partition_nr
to 4 are pri- tion via partition_nr. You can force AutoYaST to only create
primary partitions by assigning numbers below 5. mary parti-
<partition_nr config:type="integer"
>2</partition_nr>
tions while 5
and higher
are logical
partitions.
The default is
131 for linux
The partition_id sets the id of the partition. If you want dif-
ferent identifers than 131 for Linux partition or 130 for swap,
confgure them with partition_id.
partition_id
partition and
130 for swap.
<partition_id config:type="integer"
>131</partition_id>
Since 10.1
and SLES10
See partition_id above. For historical reasons they represent
the same.
flesys-
tem_id
it is recom-
<filesystem_id config:type="integer"
>131</filesystem_id>
mended to
use parti-
tion_id in-
stead.
See "label"
and "uuid"
Instead of a partition number, you can tell AutoYaST to
mount a partition by label, uuid, path or id, which are the
udev path and udev id (see /dev/disk/...).
mountby
36 AutoYaST
documenta-
tion above.
<mountby config:type="symbol"
>label</mountby>
If this partition is in a logical volume in a volume group
(LVM or EVMS) specify the logical volume name here (see
is_lvm_vg or is_evms_vg parameter in drive confguration).
lv_name
<lv_name>opt_lv</lv_name>
An integer that confgures LVMstriping. Specify across how
many devices you want to stripe (spread data).
stripes
<stripes config:type="integer">2</stripes>
Specify the size of each block in kb. stripesize
<stripesize config:type="integer"
>4</stripesize>
If this is a physical partition used by (part of) a volume group
(LVM), you have to specify the name of the volume group
here.
lvm_group
<lvm_group>system</lvm_group>
If this physical partition is used by a volume group (EVMS),
you have to specify the name of the volume group here.
evms_group
<evms_group>system</evms_group>
If this physical volume is part of a RAID, specify the name
of the RAID.
raid_name
<raid_name>/dev/md0</raid_name>
Specify the type of the RAID. raid_type
<raid_type>raid1</raid_type>
Specify RAID options, see below. raid_options
<raid_options>...</raid_options>
The resize
only works
This parameter is available since SLES10 SP1 and Open-
SUSE 10.2. This boolean must be "true" if an existing parti-
resize
with physical tion should be resized. In this case, you want to set create to
disks. Not false and in most cases you don't want to format the partition.
with You need to tell AutoYaST the partition_nr and the size. The
LVM/EVMS
volumes.
size can be in percentage of the original size or a number,
like 800M. max and auto do not work as size here.
<resize config:type="boolean"
>false</resize>
4.4.3 RAID Options
The following elements must be between the <partition><raid_options> ... </raid_op-
tions></partition> tags.
<chunk_size>4</chunk_size>
chunk_size
Possible values are: left_asymmetric, left_symmet-
ric, right_asymmetric, right_symmetric. Since
parity_algo-
rithm
SLES11 SP2 and openSUSE 12.1 you can use:
parity_frst, parity_last, left_asymmetric_6,
left_symmetric_6, right_asymmetric_6, right_sym-
metric_6, parity_frst_6, n2, o2, f2, n3, o3, f3 for
RAID6 and RAID10
<parity_algorithm
>left_asymmetric</parity_algorithm>
38 AutoYaST
The default
is raid1.
Possible values are: raid0,raid1 and raid5.
raid_type
4.4.4 Automated Partitioning
For automated partitioning, you only need to provide the sizes and mount points of
partitions. All other data needed for successful partitioning is calculated during instal-
lationunless provided in the control fle.
If no partitions are defned and the specifed drive is also the drive where the root par-
tition should be created, the following partitions are created automatically:
/boot
The size of the /boot partition is determined by the architecture of the target system.
swap
The size of the swap partition is determined by the amount of memory available in
the system.
/ (root partition)
The size of the root partition is determined by the space left after creating swap and
/boot.
Depending on the initial status of the drive and how it was previously partitioned, it is
possible to create the default partitioning in the following ways:
Use free space
If the drive is already partitioned, it is possible to create the new partitions using the
free space on the hard drive. This requires the availability of enough space for all
selected packages in addition to swap.
Reuse all available space
Use this option to delete all existing partitions (Linux and non-Linux).
Reuse all available Linux partitions
This option deletes all existing Linux partitions. Other partitions (i.e. Windows) remain
untouched. Note that this works only if the Linux partitions are at the end of the de-
vice.
Reuse only specifed partitions
This option allows you to select specifc partitions to delete. Start the selection with
the last available partition.
Repartitioning only works if the selected partitions are neighbors and located at the end
of the device.
NOTE: Important Notice
The value provided in the use property determines how existing data and par-
titions are treated. The value all means that ALL data on the disk will be erased.
Make backups and use the confrm property if you are going to keep some
partitions with important data. During automated installation, no popups will
notify you about partitions being deleted.
If multiple drives are present in the target system, identify all drives with their device
names and specify how the partitioning should be performed.
Partition sizes can be given in gigabytes, megabytes or can be set to a fexible value
using the keywords auto and max. max uses all available space on a drive, therefore
should only be set for the last partition on the drive. With auto the size of a swap or
boot partition is determined automatically, depending on the memory available and the
type of the system.
A fxed size can be given as shown below:
1GB will create a partition of the size 1 GB. 1500MB will create a partition of the size
1.5 GB.
40 AutoYaST
Example 4.3 Automated Partitioning
The following is an example of a single drive system, which is not pre-partitioned and
should be automatically partitioned according to the described pre-defned partition
plan. If you do not specify the device, it will be automatically detected. You do not
have to create different profles for /dev/sda or /dev/hda systems.
<drive>
<use>all</use>
</drive>
</partitioning>
Amore detailed example shows howexisting partitions and multiple drives are handled.
Example 4.4 Detailed Automated Partitioning
<drive>
<partition>
<mount>/</mount>
<size>5gb</size>
</partition>
<partition>
<mount>swap</mount>
<size>1gb</size>
</partition>
</partitions>
</drive>
<drive>
<device>/dev/hdb</device>
<use>all</use>
<partition>
<mount>/data1</mount>
<size>15gb</size>
</partition>
<partition>
<filesystem config:type="symbol">jfs</filesystem>
<mount>/data2</mount>
<size>auto</size>
</partition>
</partitions>
<use>free</use>
</drive>
</partitioning>
4.4.5 Advanced Partitioning Features
4.4.5.1 Wipe out Partition Table
In most cases this is not needed because AutoYaST can delete partitions one by one
automatically, but you have the option to let AutoYaST clear the partition table instead
of deleting partitions individually.
Go to the "drive" section and add:
<initialize config:type="boolean">true</initialize>
With this setting AutoYaST will delete the partition table before it starts to analyse the
actual partitioning and calculates its partition plan. Of course this means, that you cannot
keep any of your existing partitions.
4.4.5.2 Mount Options
By default a fle system to be mounted is identifed in /etc/fstab by the device
name. This identifcation can be changed so the fle system is found by searching for
a UUID or a volume label. Note that not all fle systems can be mounted by UUID or
a volume label. To specify how a partition is to be mounted, use the mountby property
which has the symbol type. Possible options are:
device (default),
label,
UUID.
If you choose to mount the partition using a label, the name entered for the label prop-
erty is used as the volume label.
Add any legal mount option in the fourth feld of /etc/fstab. Multiple options are
separated by commas. Possible fstab options:
Mount read-only (ro): No write access to the fle system. Default is "false".
No access time (noatime): Access times are not updated when a fle is read. Default
is "false".
42 AutoYaST
Mountable by User (user): The fle systemcan be mounted by a normal user. Default
is "false".
Data Journaling Mode (ordered, journal, writeback): Specifes the journaling mode
for fle data.
journal
All data is committed to the journal prior to being written to the main fle system.
ordered
All data is directly written to the main fle systembefore its meta data is commit-
ted to the journal.
writeback
Data ordering is not preserved.
Access Control List (acl): Enable access control lists on the fle system.
Extended User Attributes (user_xattr): Allow extended user attributes on the fle
system.
Example 4.5 Mount Options
<partition>
<format config:type="boolean">true</format>
<fstopt>ro,noatime,user,data=ordered,acl,user_xattr</fstopt>
<mount>/local</mount>
<mountby config:type="symbol">uuid</mountby>
<partition_id config:type="integer">131</partition_id>
<size>10gb</size>
</partition>
</partitions>
4.4.5.3 Keeping Specifc Partitions
In some cases you may want to leave partitions untouched and only format specifc
target partitions, rather than creating themfromscratch. For example, if different Linux
installations coexist, or you have another operating system installed, likely you do not
want to wipe these out. Or you may want to leave data partitions untouched.
Such scenarios require certain knowledge about the target systems and hard drives.
Depending on the scenario, you might need to know the exact partition table of the
target hard drive with partition ids, sizes and numbers. With this data you can tell
AutoYaST to keep certain partitions, format others and create new partitions if needed.
The following example will keep partitions 1, 2 and 5 and delete partition 6 to create
two new partitions. All remaining partitions will only be formatted.
Example 4.6 Keeping partitions
<drive>
<device>/dev/hdc</device>
<partition>
<create config:type="boolean">false</create>
<mount>/</mount>
<partition_nr config:type="integer">1</partition_nr>
</partition>
<partition>
<mount>/space</mount>
</partition>
<partition>
<filesystem config:type="symbol">swap</filesystem>
<mount>swap</mount>
</partition>
<partition>
<mount>/space2</mount>
<size>50mb</size>
</partition>
<partition>
<mount>/space3</mount>
<size>max</size>
</partition>
</partitions>
<use>6</use>
</drive>
</partitioning>
44 AutoYaST
The last example requires exact knowledge of the existing partition table and the partition
numbers of those partitions that should be kept. In some cases however, such data may
not be available, especially in a mixed hardware environment with different hard drive
types and confgurations. The following scenario is for a system with a non-Linux OS
with a designated area for a Linux installation.
Figure 4.1 Keeping partitions
In this scenario, shown in fgure Figure 4.1, Keeping partitions (page 45), AutoYaST
will not create newpartitions. Instead it searches for certain partition types on the system
and uses themaccording to the partitioning plan in the control fle. No partition numbers
are given in this case, only the mount points and the partition types (additional confgu-
ration data can be provided, for example fle system options, encryption and flesystem
type).
Example 4.7 Auto-detection of partitions to be kept.
<drive>
<partition>
<mount>/</mount>
</partition>
<partition>
<mount>swap</mount>
</partition>
</partitions>
</drive>
</partitioning>
4.4.6 Using Existing Mount Table (fstab)
NOTE: New Feature
This option will allow AutoYaST to use an existing /etc/fstab and use the
partition data from a previous installation. All partitions are kept and no new
partitions are created. The partitions will be formatted and mounted as specifed
in /etc/fstab on a Linux root partition.
Although the default behaviour is to format all partitions, it is also possible to leave
some partitions untouched and only mount them, for example data partitions. If multiple
installations are found on the system (multiple root partitions with different fstab fles,
the installation will abort, unless the root partition is confgured in the control fle. The
following example illustrates how this option can be used:
46 AutoYaST
Example 4.8 Reading existing /etc/fstab
<partitioning_advanced>
<fstab>


<use_existing_fstab config:type="boolean">true</use_existing_fstab>

<partition>
<mount>/bootmirror</mount>
</partition>
</partitions>
</fstab>
</partitioning_advanced>
4.4.7 Logical Volume Manager (LVM)
To confgure LVM, frst create a physical volume using the normal partitioning method
described above.
Example 4.9 Create LVM Physical Volume
The following example shows how to prepare for LVM in the partitioning resource:
<drive>
<device>/dev/sda</device>
<partition>
<partition_type>primary</partition_type>
<size>max</size>
</partition>
</partitions>
<use>all</use>
</drive>
</partitioning>
In the last example, a non-formatted partition is created on device /dev/sda1 of the
type LVM and with the volume group system. This partition will use all space available
on the drive.
Example 4.10 LVM Logical Volumes (New syntax)
<drive>
<partition>
<size>max</size>
</partition>
</partitions>
<use>all</use>
</drive>
<drive>
<device>/dev/system</device>
<is_lvm_vg config:type="boolean">true</is_lvm_vg>
<partition>
<lv_name>user_lv</lv_name>
<mount>/usr</mount>
<size>500mb</size>
</partition>
<partition>
<mount>/opt</mount>
<size>1500mb</size>
</partition>
<partition>
<lv_name>var_lv</lv_name>
<mount>/var</mount>
<size>200mb</size>
</partition>
</partitions>
<pesize>4M</pesize>
<use>all</use>
</drive>
</partitioning>
With SUSE Linux 10.1 and all following versions, it is possible to set the size to max
for the logical volumes. Of course, you can only use max for one(!) logical volume.
You cannot set two logical volumes in one volume group to sizemax
48 AutoYaST
4.4.8 Enterprise Volume Management
System (EVMS) SLES10 only!
SLES10 AutoYaST has EVMS support. SLES11 has not!
Using EVMS is quite similar to using LVM(see above). Switching fromLVMto EVMS
is just a small change in the AutoYaST profle. Change the "is_lvm_vg" element to
"is_evms_vg" and the "lvm_group" element to "evms_group".
With AutoYaST it is not possible to mix LVM and EVMS.
Using the LVM example from above for EVMS, looks like this:
Example 4.11 EVMS Logical Volumes
<drive>
<partition>
<evms_group>system</evms_group>
<size>max</size>
</partition>
</partitions>
<use>all</use>
</drive>
<drive>
<device>/dev/system</device>
<is_evms_vg config:type="boolean">true</is_evms_vg>
<partition>
<lv_name>user_lv</lv_name>
<mount>/usr</mount>
<size>500mb</size>
</partition>
<partition>
<mount>/opt</mount>
<size>1500mb</size>
</partition>
<partition>
<lv_name>var_lv</lv_name>
<mount>/var</mount>
<size>200mb</size>
</partition>
</partitions>
<pesize>4M</pesize>
<use>all</use>
</drive>
</partitioning>
4.4.9 Software RAID
Using AutoYaST, you can create and assemble software RAID devices. The supported
RAID levels are the following:
50 AutoYaST
RAID 0: This level increases your disk performance. There is no redundancy in this
mode. If one of the drives crashes, data recovery will not be possible.
RAID1:This mode offers the best redundancy. It can be used with two or more disks.
An exact copy of all data is maintained on all disks. As long as at least one disk is
still working, no data is lost. The partitions used for this type of RAID should have
approximately the same size.
RAID 5: This mode combines management of a larger number of disks and still
maintains some redundancy. This mode can be used on three disks or more. If one
disk fails, all data is still intact. If two disks fail simultaneously, all data is lost.
Multipath:This mode allows access to the same physical device via multiple controllers
for redundancy against a fault in a controller card. This mode can be used with at
least two devices.
As with LVM, you need to create all RAID partitions frst and assign the partitions to
the RAIDdevice you want to create. Additionally you need to specify whether a partition
or a device should be confgured in the RAID or if it should be confgured as a Spare
device.
The following example shows a simple RAID1 confguration:
Example 4.12 RAID1 confguration
<drive>
<partition>
<raid_type>raid</raid_type>
<size>4gb</size>
</partition>

</partitions>
<use>all</use>
</drive>
<drive>
<device>/dev/sdb</device>
<partition>
<raid_type>raid</raid_type>
<size>4gb</size>
</partition>
</partitions>
<use>all</use>
</drive>
<drive>
<device>/dev/md</device>
<partition>
<mount>/space</mount>
<raid_options>
<chunk_size>4</chunk_size>
<parity_algorithm>left-asymmetric</parity_algorithm>
</raid_options>
</partition>
</partitions>
<use>all</use>
</drive>
52 AutoYaST
</partitioning>
Consider the following when confguring raid:
The device for raid is always /dev/md
The property partition_nr is used to determine the MDdevice number. If partition_nr
is equal to 0, then /dev/md0 is confgured.
All RAID-specifc options are contained in the raid_options resource.
4.4.10 IBM System z Specifc Confguration
4.4.10.1 Confguring DASD Disks
The following elements must be between the
<dasd>
<devices config:type="list">
<listentry>
...
</listentry>
</devices>
</dasd>
tags in the <profle> section. Each disk needs to be confgured in a separate <listentry>
... </listentry> section.
DASD is the only value allowed
device
<device
>DASD</dev_name>
Optional but recom-
mended. If left out,
The device (dasdn) you want to confgure
in this section.
dev_name
AutoYaST tries to
guess the device.
<dev_name
>/dev/dasda</dev_name>
Mandatory. Channel by which the disk is accessed. channel
<channel>0.0.0150</channel>
Optional.
Enable or disable the use of DIAG. Possible
values are true (enable) or false (dis-
able).
diag
<diag
config:type="boolean">true</diag>
4.4.10.2 Confguring zFCP Disks
The following elements must be between the
<zfcp>
<devices config:type="list">
<listentry>
...
</listentry>
</devices>
</zfcp>
tags in the <profle> section. Each disk needs to be confgured in a separate <listentry>
... </listentry> section.
Channel number controller_id
<controller_id
>0.0.fc00</controller_id>
Logical unit number fcp_lun
<fcp_lun
>0x4010400400000000</fcp_lun>
World wide port number wwpn
54 AutoYaST
<wwpn
>0x500507630510473a</wwpn>
4.5 Software
4.5.1 Package Selections with Patterns
SLES10 no longer supports selections but uses patterns. AutoYaST cannot convert
selections to patterns. If you want to use a SLES9 AutoYaST profle to install a SLES10
server, you have to remove all addon entries and the base entry. Patterns are confgured
like this:
Example 4.13 Package Selection in Control File with Patterns
<software>
<patterns config:type="list">
<pattern>directory_server</pattern>
</patterns>
<packages config:type="list">
<package>apache</package>
<package>sendmail</package>
</packages>
<do_online_update config:type="boolean">true</do_online_update> 
</software>
The packages section is still the same as on a SLES9. Just the addon and base sections
are gone.
4.5.2 Deploying Images
This feature is available since openSUSE 11.1 but not in SLES11.
Since openSUSE11.0 you can use images during installation to speed up the installation.
This feature is available in openSUSE 11.1 as well.
Example 4.14 Activating Image Deployment


<deploy_image>
<image_installation config:type="boolean">false</image_installation>
</deploy_image>
4.5.3 Installing Additional and Customized
Packages
In addition to the packages available for installation on the CD-ROMs, you can add
external packages including customized kernels. Customized kernel packages must be
compatible to the SuSE packages and must install the kernel fles to the same locations.
Unlike in earlier in versions, you do not need a special resource in the control fle to
install customand external packages. Instead you need to re-create the package database
and update it with any new packages or new package versions in the source repository.
A script is provided for this task which will query packages available in the repository
and create the package database. Use the command
/usr/bin/create_package_descr. When creating the database, all languages
will be reset to English.
Example 4.15 Creating Package Database
cd /usr/local/CDs/LATEST/suse
create_package_descr -x PATH_TO_EXTRA_PROV -d /usr/local/CDs/LATEST/suse
NOTE: Change starting with SUSE Linux 9.1/SLES 9
To provide extra dependencies which can not be extracted from the rpm fles,
an extra fle with missing dependencies is available in the directory suse/
setup/descr. The fle EXTRA_PROV can be used when recreating the package
database using the -x option.
In the above example, the directory /usr/local/CDs/LATEST/suse contains
the architecture dependent and independent packages, i.e. noarch and i586. This might
look different on other architectures.
56 AutoYaST
The advantage of this method is that you can keep an up-to-date repository with fxed
and updated package (e.g. from SuSE FTP server). Additionally this method makes the
creation of custom CD-ROMs easier.
NOTE: Changes starting with SUSE Linux 10.1/SLES 10
With SLES10/SL10.1, the concept of adding your own RPMs to an installation
source has changed. Neither yast/order nor yast/instorder are supported any
longer by AutoYaST or by YaST. To add your own RPMs to an installation source
(or add-on products like the SDK), add a fle add_on_products to CD1 of the
main product.
media_url [path_on_media [product_1 [product_2 [....]]]
media_url is the URL of the media, path_on_media is the path to the catalog
on the media. If not present, / (root) is assumed. product_1 and following are
the names of products, which should be marked for installation. If no product
is specifed, all products found on the media are selected for installation. For
example:
http://192.168.66.6/SLES10/sdk/CD1
http://192.168.66.6/SLES10/CD1/updates
Besides the add_on_products fle, you can use the AutoYaST profle to specify
add-on products. For example:
<add-on>
<add_on_products config:type="list">
<listentry>
<media_url>http://192.168.66.6/SLES10/CD1/updates</media_url>
<product>SuSE-Linux-Updates</product>
<product_dir>/</product_dir>
<ask_on_error config:type="boolean">false</ask_on_error> 
<name>MyUpdates</name> 
</listentry>
</add_on_products>
</add-on>
With this entry in the AutoYaST profle, the add_on_products fle is not neces-
sary. Since openSUSE 11.0, AutoYaST can ask the user to make add-on products
available instead of reporting a time-out error when an add-on product cannot
be found at the given location. Set ask_on_error to "true" (the default is
"false"). Then your add-on product can be on a different CD/DVD than the
installation source.
YaST checks the signatures of fles on the installation source. If a content fle
is not signed, during a manual installation YaST asks the user what to do. During
an automatic installation, the installation source is rejected silently.
If you want to use unsigned installation sources with AutoYaST, turn off the checks
with the following confguration in your AutoYaST profle (part of the general section.
The following elements must be between the <general><signature-handling> ... </sig-
nature-handling></general> tags.
Optional. If left out,
AutoYaST lets YaST
decide what to do.
If set to "true", AutoYaST will accept
unsigned fles like the content fle.
>true</accept_unsigned_file>
accept_un-
signed_fle
AutoYaST lets YaST
decide what to do.
fles without a checksum in the content
fle.
accept_fle_with-
out_checksum
>true</accept_file_without_checksum>
AutoYaST lets YaST
decide what to do.
signed fles even when the verifcation of
the signature failed.
accept_verifca-
tion_failed
>true</accept_verification_failed>
58 AutoYaST
AutoYaST lets YaST
decide what to do.
new gpg keys on the installation source,
for example the key used to sign the con-
tent fle.
accept_un-
known_gpg_key
<accept_unknown_gpg_key
>true</accept_unknown_gpg_key>
AutoYaST lets YaST
decide what to do.
This basically means, we know the key,
but it is not trusted.
<accept_non_trusted_gpg_key
>true</accept_non_trusted_gpg_key>
accept_non_trust-
ed_gpg_key
AutoYaST lets YaST
decide what to do.
If set to "true", AutoYaST will accept and
import new gpg keys on the installation
source in its database.
import_gpg_key
<import_gpg_key config:type="boolean"
>true</import_gpg_key>
Since openSUSE 10.3, it is possible to confgure the signature handling for each add-
on product individually. The following elements must be between the <signature-han-
dling> section of the individual add-on product.
the global signature-
unsigned fles like the content fle for this
add-on product.
accept_un-
signed_fle
handing in the <gener-
al> section is used.
>true</accept_unsigned_file>
fles without a checksum in the content
fle for this add-on.
accept_fle_with-
out_checksum
>true</accept_file_without_checksum>
signed fles even when the verifcation of
the signature fails.
accept_verifca-
tion_failed
>true</accept_verification_failed>
new gpg keys on the installation source,
accept_un-
known_gpg_key
for example the key used to sign the con-
tent fle.
<accept_unknown_gpg_key>
<all
config:type="boolean">false</all>
<keys
config:type="list">
<keyid>3B3011B76B9D6523</keyid>
</keys>
</accept_unknown_gpg_key>
optional. If left out,
This basically means, we know the key,
but it is not trusted.
accept_non_trust-
ed_gpg_key
<accept_non_trusted_gpg_key>
<all
<keys
config:type="list">
</keys>
</accept_non_trusted_gpg_key>
60 AutoYaST
If set to "true", AutoYaST will accept and
import new gpg keys on the installation
source into its database.
import_gpg_key
<import_gpg_key>
<all
<keys
config:type="list">
</keys>
</import_gpg_key>
4.5.4 Kernel Packages
Kernel packages are not part of any selection. The required kernel is determined during
installation. If the kernel package is added to any selection or to the individual package
selection, installation will mostly fail due to conficts.
To force the installation of a specifc kernel, use the kernel property. The following is
an example of forcing the installation of the default kernel. This kernel will be installed
even if an SMP or other kernel is required.
Example 4.16 Package Selection in Control File
<software>
<kernel>kernel-default</kernel>
<package>apache2</package>
</packages>
</software>
4.5.5 Removing Automatically Selected
Packages
Some packages are selected automatically either because of a dependency or because
it is available in a selection.
Removing such packages might break the systemconsistency and it is not recommended
to remove basic packages unless a replacement which provides the same services is
provided. The best example for this case are MTA packages. By default, postfx will
be selected and installed. If you wish to use another MTA like sendmail, then postfx
can be removed from the list of selected package using a list in the software resource.
The following example shows how this can be done:
Example 4.17 Package Selection in Control File
<software>
<package>sendmail</package>
</packages>
<remove-packages config:type="list">
<package>postfix</package>
</remove-packages>
</software>
4.5.6 Installing Packages in Stage 2
If you want to install packages after the reboot during stage 2, instead of during the
normal installation process in stage 1, you can use the post-packages element for that:
<software>
<post-packages config:type="list">
<package>yast2-cim</package>
</post-packages>
</software>
4.5.7 Installing Patterns in Stage 2
Since SLES11 and openSUSE 11.1, you can also install patterns in stage 2. Use the
post-patterns element for that:
<software>
<post-patterns config:type="list">
<pattern>apparmor</pattern>
</post-patterns>
</software>
62 AutoYaST
4.5.8 Online Update in Stage 2
Since openSUSE 11.1, you can perform an online update at the end of the installation.
Set the boolean do_online_update to "true". Of course this makes only sense if you add
an online update repository in the suse-register/customer-center section, for example,
or in a post-script. If the online update repository was available in stage 1 already via
add-on section, then AutoYaST has already installed the latest packages available. If
a kernel update is done via online-update, a reboot at the end of stage 2 is triggered.
<software>
<do_online_update config:type="boolean">true</do_online_update>
</software>
4.6 Services and Runlevels
With the runlevel resource you can set the default runlevel and specify in detail which
system services you want to be started in which run-level.
The default property specifes the default runlevel of the system. Changes to the default
runlevel will take effect the next time you boot the system. After the installation is
completed, the system runs in runlevel 5, which is full multiuser with network and
XDM. If you have confgured a system with no X11, it is recommended to reboot the
system after stage 1, using the reboot property in the general resource.
Specify in which runlevels a service should run via a space separated list of the runlevels,
as shown in the following example. Alternatively change the status of the service by
either enabling or disabling it using the service_status property.
Example 4.18 Run-level Confguration
....
<runlevel>
<default>3</default>
<services config:type="list" >
<service>
<service_name>at</service_name>
<service_start>3 5</service_start>
</service>
<service>
<service_name>portmap</service_name>
<service_status>enable</service_status>
</service>
<service>
<service_name>hwscan</service_name>
<service_status>disable</service_status>
</service>
</services>
</runlevel>
....
4.7 Network Confguration
4.7.1 Network Devices, DNS and Routing.
Network confguration is used to connect a single SuSELinux workstation to an Ethernet-
based LANor to confgure a dial-up connection. More complex confgurations (multiple
network cards, routing, etc.) are also provided. With this module it is possible to con-
fgure and setup Ethernet controllers and Token-Ring controllers.
In the networking section, set this option to "true" (default is "false", available since
openSUSE 11.2 but not in SLES11):
<keep_install_network config:type="boolean">true</keep_install_network>
YaST will keep network settings created during installation (via Linuxrc) and/or merge
it with network settings from the AutoYaST profle (if defned). AutoYaST settings
have higher priority than already present confguration fles. YaST will write ifcfg-*
fles from profle without removing old ones. If there is an empty or no dns and routing
64 AutoYaST
section, YaST will keep already present values. Otherwise settings fromthe profle will
be applied.
To confgure network settings and activate networking automatically, one global resource
is used to store the whole network confguration.
Example 4.19 Network confguration
.....
<networking>
<dns>
<dhcp_hostname config:type="boolean">true</dhcp_hostname>
<dhcp_resolv config:type="boolean">true</dhcp_resolv>
<domain>local</domain>
<hostname>linux</hostname>
</dns>
<interfaces config:type="list">
<interface>
<bootproto>dhcp</bootproto>
<device>eth0</device>
<startmode>onboot</startmode>
</interface>
</interfaces>
<routing>
<ip_forward config:type="boolean">false</ip_forward>
<routes config:type="list">
<route>
<destination>default</destination>
<device>-</device>
<gateway>192.168.1.240</gateway>
<netmask>-</netmask>
</route>
</routes>
</routing>
<modules config:type="list">
<module_entry>
<device>eth0</device>
<module>e100</module>
<options></options>
</module_entry>
</modules>
</networking>
....
4.7.2 Proxy
Confgure your Internet proxy (caching) settings.
HTTP proxy is the name of the proxy server for your access to the world wide web
(WWW). FTP proxy is the name of the proxy server for your access to the fle transfer
services (FTP). No proxy domains is a list of domains for which requests should be
carried out directly without caching.
If you are using a proxy server with authorization, fll in Proxy user name and Proxy
password.
Example 4.20 Network confguration: Proxy
<!DOCTYPE profile>
<profile xmlns="http://www.suse.com/1.0/yast2ns"
<proxy>
<enabled config:type="boolean">true</enabled>
<ftp_proxy>http://192.168.1.240:3128</ftp_proxy>
<http_proxy>http://192.168.1.240:3128</http_proxy>
<no_proxy>localhost</no_proxy>
<proxy_password>testpw</proxy_password>
<proxy_user>testuser</proxy_user>
</proxy>
</profile>
4.7.3 (X)Inetd
The profle has elements to specify which superserver should be used (netd_service),
whether it should be enabled (netd_status) and how the services should be confgured
(netd_conf).
A service description element has two parts: key and non-key. When writing the conf-
guration, services are matched using the key felds; to the matching service, non-key
felds are applied. If no service matches, it is created. If more services match, a warning
is reported. The key felds are script, service, protocol and server.
service and protocol are matched literally. script is the base name of the confg fle:
usually a fle in/etc/xinetd.d, for example "echo-udp", or "inetd.conf". For
compatibility with 8.2, server is matched more loosely: if it is /usr/sbin/tcpd,
66 AutoYaST
the real server name is taken from server_args. After that, the basename of the frst
whitespace-separated word is taken and these values are compared.
Example 4.21 Inetd Example
<profile>
...
<inetd>
<netd_service config:type="symbol">xinetd</netd_service>
<netd_status config:type="integer">0</netd_status>
<netd_conf config:type="list">
<conf>
<script>imap</script>
<service>pop3</service>
</conf>
<conf>
<server>in.ftpd</server>
<server_args>-A</server_args>
</conf>
<conf>
<service>daytime</service>
<protocol>tcp</protocol>
</conf>
....
<conf>...</conf>
</netd_conf>
</inetd>
...
</profile>
4.8 NIS
Using the nis resource, you can confgure the target machine as a NIS client. The fol-
lowing example shows a detailed confguration using multiple domains.
Example 4.22 Network confguration: NIS
...
<nis>
<nis_broadcast config:type="boolean">true</nis_broadcast>
<nis_broken_server config:type="boolean">true</nis_broken_server>
<nis_by_dhcp config:type="boolean">false</nis_by_dhcp>
<nis_domain>test.com</nis_domain>
<nis_local_only config:type="boolean">true</nis_local_only>
<nis_options></nis_options>
<nis_other_domains config:type="list">
<nis_other_domain>
<nis_broadcast config:type="boolean">false</nis_broadcast>
<nis_domain>domain.com</nis_domain>
<nis_servers config:type="list">
<nis_server>10.10.0.1</nis_server>
</nis_servers>
</nis_other_domain>
</nis_other_domains>
<nis_servers config:type="list">
<nis_server>192.168.1.1</nis_server>
</nis_servers>
<start_autofs config:type="boolean">true</start_autofs>
<start_nis config:type="boolean">true</start_nis>
</nis>
...
4.9 LDAP client
The installed machine can be set up as an LDAP client to authenticate users with an
OpenLDAP; server. Required data are the name of the search base (base DN, e.g,
dc=mydomain,dc=com) and the IP address of the LDAP server (e.g., 10.20.0.2).
If LDAP is activated, NSS and PAM will be confgured accordingly to use LDAP for
user authentication.
68 AutoYaST
Example 4.23 Network confguration: LDAP client
...
<ldap>
<ldap_domain> dc=mydomain,dc=com</ldap_domain>
<ldap_server>10.10.0.1</ldap_server>
<ldap_tls config:type="boolean">true</ldap_tls>
<ldap_v2 config:type="boolean">true</ldap_v2>
<pam_password>crypt</pam_password>
<start_ldap config:type="boolean">true</start_ldap>
</ldap>
...
4.10 NFS Client and Server
Confguring a system as an NFS client or an NFS server is can be done using the con-
fguration system. The following examples show how both NFS client and server can
be confgured.
Up to SLE11 and openSUSE 11.2, the following structure of NFS client confguration
has been used:
Example 4.24 Network Confguration: NFS Client
...
<nfs config:type="list">
<nfs_entry>
<mount_point>/home</mount_point>
<nfs_options>defaults</nfs_options>
<server_path>192.168.1.1:/home</server_path>
</nfs_entry>
</nfs>
...
FromopenSUSE11.3 (SLE12 respectively) on, the structure of NFS client confguration
has changed. Some global confguration options were introduced: enable_nfs4 to switch
NFS4 support on/off and idmapd_domain to defne domain name for rpc.idmapd (this
only makes sense with enabled NFS4). Attention: the old structure is not compatible
with the new one and the profles with an NFS section created on older releases will
not work with newer products.
Example 4.25 Network Confguration: NFS Client - NewStyle (openSUSE 11.3 and
newer)
...
<nfs>
<enable_nfs4 config:type="boolean">true</enable_nfs4>
<idmapd_domain>suse.cz</idmapd_domain>
<nfs_entries config:type="list">
<nfs_entry>
<mount_point>/home</mount_point>
<nfs_options>sec=krb5i,intr,rw</nfs_options>
<server_path>saurus.suse.cz:/home</server_path>
<vfstype>nfs4</vfstype>
</nfs_entry>
<nfs_entry>
<mount_point>/work</mount_point>
<server_path>bivoj.suse.cz:/work</server_path>
<vfstype>nfs</vfstype>
</nfs_entry>
<nfs_entry>
<mount_point>/mnt</mount_point>
<server_path>fallback.suse.cz:/srv/dist</server_path>
<vfstype>nfs</vfstype>
</nfs_entry>
</nfs_entries>
</nfs>
...
Example 4.26 Network Confguration: NFS Server
....
<nfs_server>
<nfs_exports config:type="list">
<nfs_export>
<allowed config:type="list">
<allowed_clients>*(ro,root_squash,sync)</allowed_clients>
</allowed>
<mountpoint>/home</mountpoint>
</nfs_export>
<nfs_export>
<allowed config:type="list">
<allowed_clients>*(ro,root_squash,sync)</allowed_clients>
</allowed>
<mountpoint>/work</mountpoint>
</nfs_export>
</nfs_exports>
<start_nfsserver config:type="boolean">true</start_nfsserver>
</nfs_server>
....
70 AutoYaST
4.11 NTP Client
Select whether to start the NTP daemon when booting the system. The NTP daemon
resolves host names when initializing. The frst synchronization of the clock is performed
before the NTP daemon is started. To use this host for initial synchronization, confgure
the property initial_sync.
To run NTP daemon in chroot jail, set start_in_chroot. Starting any daemon in a chroot
jail is more secure and strongly recommended. To adjust NTP servers, peers, local
clocks, and NTP broadcasting, add the appropriate entry to the control fle. An example
of various confguration options is shown below.
Example 4.27 Network confguration: NTP Client
<!DOCTYPE profile>
<ntp-client>
<configure_dhcp config:type="boolean">false</configure_dhcp>
<peers config:type="list">
<peer>
<address>ntp1.example.com</address>
<initial_sync config:type="boolean">true</initial_sync>
<options></options>
<type>server</type>
</peer>
</peers>
<start_at_boot config:type="boolean">true</start_at_boot>
<start_in_chroot config:type="boolean">true</start_in_chroot>
</ntp-client>
</profile>
4.12 Mail Confguration (Sendmail or
Postfx)
For the mail confguration of the client, this module lets you create a detailed mail
confguration. The module contains various options. We recommended you use it at
least for the initial confguration.
Example 4.28 Mail Confguration
...
<mail>
<aliases config:type="list">
<alias>
<alias>root</alias>
<comment></comment>
<destinations>foo</destinations>
</alias>
<alias>
<alias>test</alias>
<comment></comment>
<destinations>foo</destinations>
</alias>
</aliases>
<connection_type config:type="symbol">permanent</connection_type>
<fetchmail config:type="list">
<fetchmail_entry>
<local_user>foo</local_user>
<password>bar</password>
<protocol>POP3</protocol>
<remote_user>foo</remote_user>
<server>pop.foo.com</server>
</fetchmail_entry>
<fetchmail_entry>
<local_user>test</local_user>
<protocol>IMAP</protocol>
<remote_user>test</remote_user>
<server>blah.com</server>
</fetchmail_entry>
</fetchmail>
<from_header>test.com</from_header>
<listen_remote config:type="boolean">true</listen_remote>
<local_domains config:type="list">
<domains>test1.com</domains>
</local_domains>
<masquerade_other_domains config:type="list">
<domain>blah.com</domain>
</masquerade_other_domains>
<masquerade_users config:type="list">
<masquerade_user>
<address>joe@test.com</address>
<comment></comment>
<user>joeuser</user>
</masquerade_user>
<masquerade_user>
<address>bar@test.com</address>
<comment></comment>
<user>foo</user>
</masquerade_user>
</masquerade_users>
72 AutoYaST
<mta config:type="symbol">postfix</mta>
<outgoing_mail_server>test.com</outgoing_mail_server>
<postfix_mda config:type="symbol">local</postfix_mda>
<smtp_auth config:type="list">
<listentry>
<server>test.com</server>
<user>foo</user>
</listentry>
</smtp_auth>
<use_amavis config:type="boolean">true</use_amavis>
<virtual_users config:type="list">
<virtual_user>
<alias>test.com</alias>
<comment></comment>
<destinations>foo.com</destinations>
</virtual_user>
<virtual_user>
<alias>geek.com</alias>
<comment></comment>
<destinations>bar.com</destinations>
</virtual_user>
</virtual_users>
</mail>
...
4.13 Security settings
Using the features of this module, you will be able to change the local security settings
on the target system. The local security settings include the boot confguration, login
settings, password settings, user addition settings, and fle permissions.
Confguring the security settings automatically corresponds to the Custom Settings in
the security module available in the running system which lets you create your own,
customized confguration.
Example 4.29 Security confguration
See the reference for the meaning and the possible values of the settings in the following
example.
...
<security>
<console_shutdown>ignore</console_shutdown>
<cwd_in_root_path>no</cwd_in_root_path>
<displaymanager_remote_access>no</displaymanager_remote_access>
<fail_delay>3</fail_delay>
<faillog_enab>yes</faillog_enab>
<gid_max>60000</gid_max>
<gid_min>101</gid_min>
<kdm_shutdown>root</kdm_shutdown>
<lastlog_enab>yes</lastlog_enab>
<encryption>md5</encryption>
<obscure_checks_enab>no</obscure_checks_enab>
<pass_max_days>99999</pass_max_days>
<pass_max_len>8</pass_max_len>
<pass_min_days>1</pass_min_days>
<pass_min_len>6</pass_min_len>
<pass_warn_age>14</pass_warn_age>
<passwd_use_cracklib>yes</passwd_use_cracklib>
<permission_security>secure</permission_security>
<run_updatedb_as>nobody</run_updatedb_as>
<uid_max>60000</uid_max>
<uid_min>500</uid_min>
</security>
...
4.13.1 Password Settings Options
Change various password settings. These settings are mainly stored in the /etc/login
.defs fle.
Use this resource to activate one of the encryption methods currently supported. If not
set, DES is confgured.
DES, the Linux default method, works in all network environments, but it restricts you
to passwords no longer than eight characters. MD5 allows longer passwords, thus pro-
vides more security, but some network protocols don't support this, and you may have
problems with NIS. Blowfsh is also supported.
74 AutoYaST
Additionally, you can setup the system to check for password plausibility and length
etc.
4.13.2 Boot Settings
Use the security resource, you can change various boot settings.
How to interpret Ctrl + Alt + Del
When someone at the console has pressed the CTRL + ALT + DEL key combination,
the systemusually reboots. Sometimes it is desirable to ignore this event, for example,
when the system serves as both workstation and server.
Shutdown behavior of KDM
Set who is allowed to shut down the machine from KDM.
4.13.3 Login Settings
Change various login settings. These settings are mainly stored in the '/etc/login.defs'
fle.
4.13.4 New user settings (useradd settings)
Set the minimum and maximum possible user ID and set the minimum and maximum
possible group ID.
4.14 Monitor and X11 Confguration
NOTE
Since openSUSE 11.2 there is not AutoYaST client for X11 confguration any-
more. You can still have the X11 section in your profle but it will be ignored.
SLES11 SP1 still has a X11 client.
FIXME
Example 4.30 X11 and Monitor confguration (deprecated since openSUSE 11.2)
...
<x11>
<color_depth>16</color_depth>
<configure_x11 config:type="boolean">true</configure_x11>
<display_manager>kde</display_manager>
<enable_3d config:type="boolean">false</enable_3d>
<monitor>
<display>
<frequency config:type="integer">60</frequency>
<max_hsync config:type="integer">97</max_hsync>
<max_vsync config:type="integer">180</max_vsync>
<min_hsync config:type="integer">30</min_hsync>
<min_vsync config:type="integer">50</min_vsync>
<width config:type="integer">1024</width>
</display>
<monitor_device>G90F</monitor_device>
<monitor_vendor>VIEWSONIC</monitor_vendor>
</monitor>
<resolution>1600x1200,1280x1024,1024x768,800x600,640x480</resolution>
<window_manager>kdm</window_manager>
</x11>
...
4.15 Users
The root user and at least one normal user can be added during install using data supplied
in the control fle. User data and passwords (encrypted or in clear text) are part of the
confgure resource in the control fle.
At least the root user should be confgured during auto-installation so you can login
after the installation is fnished. It will also ensure nobody else can login to the system
(in case the password is not set).
The two users in the following example are added during system confguration.
76 AutoYaST
Example 4.31 User Confguration
...
<users config:type="list">
<user>
<username>root</username>
<user_password>password</user_password>
<encrypted config:type="boolean">true</encrypted>
<forename/>
<surname/>
</user>
<user>
<username>nashif</username>
<user_password>password</user_password>
<encrypted config:type="boolean">true</encrypted>
<forename>Anas</forename>
<surname>Nashif</surname>
</user>
</users>
...
The last example shows the minimal information required for adding users. Additional
options are available for a more customized user account management. The data in
/etc/default/useradd is used to determine the home directory of the user to be
created as well as other parameters.
4.16 Custom User Scripts
By adding scripts to the auto-installation process you can customize the installation
according to your needs and take control in different stages of the installation.
In the auto-installation process, fve types of scripts can be executed and they will be
described here in order of "appearance" during the installation.
All scripts have to be in the <scritps> section.
pre-scripts (very early, before anything else really happens)
postpartitioning-scripts (after partitioning and mounting to /mnt but before RPM
installationsince openSUSE 11.2)
chroot-scripts (after the package installation, before the frst boot)
post-scripts (during the frst boot of the installed system, no services running)
init-scripts (during the frst boot of the installed system, all services up and running)
4.16.1 Pre-Install Scripts
Executed before YaST does any real change to the system (before partitioning and
package installation but after the hardware detection).
You can use a pre-script to modify your profle and let AutoYaST reread it. Find your
profle in "/tmp/profle/autoinst.xml". Adjust the fle and store the modifed version in
"/tmp/profle/modifed.xml". AutoYaST will read the modifed fle after the pre-script
fnishes.
With SUSE Linux 10.0 and all later versions, it is possible to change the partitioning
with fdisk in your pre-script. With pre-10.0 versions of SUSE Linux (like SLES9), this
was not possible.
NOTE: Pre-Install Scripts with Confrmation
Pre-scripts are executed at an early stage of the installation. This means if you
have requested to confrm the installation, the pre-scripts will be executed
before the confrmation screen shows up (profle/install/general/mode/confrm).
The following elements must be between the <scripts><pre-scripts con-
fg:type="list"><script> ... </script></pre-scripts>...</scripts> tags.
Table 4.1 Pre-script XML Representation
Comment Description Element
Either <location> or
<source> must be
defned.
Defne a location from where the script gets
fetched. Locations can be the same as for the
profle (http, ftp, nfs, etc.).
location
<location
>http://10.10.0.1/myPreScript.sh</location>
78 AutoYaST
<source> must be
defned.
The script itself (source code), encapsulated in a
CDATA tag. If you do not want to put the whole
shell script into the XML profle, refer to the lo-
cation parameter.
source
<source>
<![CDATA[
echo "Testing the pre script" >
/tmp/pre-script_out.txt
]]>
</source>
Optional (default is
"shell").
Specify the interpreter that must be used for the
script. Supported options are shell and perl.
interpreter
<interpreter>perl</interpreter>
the type of the script
The flename of the script. It will be stored in a
temporary directory under /tmp/...
flename
(pre-scripts in this
<filename>myPreScript5.sh</filename>
case). If you have
more than one
script, you should
set the flename to a
reasonable value.
Optional, default is
"false". This option
If this boolean is "true", stdout and stderr of the
script will be shown in a popup, which the user
feedback
was introduced with
SL 10.1/SLES10.
has to confrm via the OK button. If stdout and
stderr are empty, no popup is shown and therefore
no confrmation is needed.
<feedback config:type="boolean"
>true</feedback>
Optional, if missing,
an always blocking
This can be "message", "warning" or "error". Set
the timeout for these popups in the <report> sec-
tion.
feed-
back_type
popup is used. This
<feedback_type>warning</feedback_type>
option was intro-
duced with open-
SUSE 11.2 (not
SLES11).
"true". This option
If this is "true", every single line of a shell script
is logged. Perl scripts are run with warnings
turned on.
debug
was introduced with
SL 10.1/SLES10.
<debug config:type="boolean">true</debug>
Optional, if not con-
fgured, no notifca-
This text will be shown in a popup for the time
the script is running in the background.
notifca-
tion
tion popup will be
<notification>Please wait while script is
running...</notification>
shown. This option
was introduced with
openSUSE
11.3/SLES11 SP2
(not SLES10).
"false" (scripts only
run once).
A script is only run once. Even if you use
ayast_setup to run a XML fle multiple times, the
script is only run once. Change this default behav-
ior by setting this boolean to "true".
rerun
<rerun config:type="boolean">true</rerun>
4.16.2 Postpartitioning Scripts
NOTE
Available since openSUSE 11.2 only (not SLES11).
Executed after YaST has done the partitioning and written the fstab. The empty system
is mounted to /mnt already.
80 AutoYaST
The following elements must be between the <scripts><postpartitioning-scripts con-
fg:type="list"><script> ... </script></postpartitioning-scripts>...</scripts> tags
Table 4.2 Postpartitioning Script XML Representation
<source> must be de-
fned.
fetched. Locations can be the same as for the
profle (http, ftp, nfs, etc.).
location
<location
>http://10.10.0.1/myScript.sh</location>
fned.
The script itself (source code), encapsulated
in a CDATA tag. If you don't want to put the
whole shell script into the XML profle, refer
to the location parameter.
source
<source>
<![CDATA[
echo "Testing postpart script" >
/mnt/postpart_test.txt
]]>
</source>
"shell".
The interpreter that must be used for the script.
Supported options are shell and perl.
interpreter
Optional, default is the
type of the script (post-
The flename of the script. It will be stored in
a temporary directory under /tmp/...
flename
partitioning-scripts in
<filename>myScript5.sh</filename>
this case). If you have
more than one script,
set the flename to a
reasonable value.
Optional, the default is
"false". This option was
If this boolean is "true", stdout and stderr of
the script will be shown in a popup, which the
feedback
introduced with SL
10.1/SLES10.
user has to confrm via the OK button. If std-
out and stderr are empty, no popup is shown
and therefore no confrmation is needed.
>true</feedback>
Optional, if missing, an
always blocking popup
This can be "message", "warning" or "error".
Set the timeout for these popups in the <re-
port> section.
feed-
back_type
is used. This option was
introduced with open-
SUSE 11.2 (not
SLES11).
"true". This option was
If this is "true", every single line of a shell
script is logged. Perl scripts are run with
warnings turned on.
debug
added with SL
10.1/SLES10.
Optional, if not confg-
ured, no notifcation
This text will be shown in a popup for the time
the script is running in the background.
notifca-
tion
popup will be shown.
<notification>Please wait while script
is running...</notification>
This option was added
with openSUSE
11.3/SLES11 SP2 (not
SLES10).
false (scripts only run
once).
ayast_setup to run a XML fle multiple times,
the script is only run once. Set this boolean to
rerun
"true" if you want to change this default behav-
ior.
82 AutoYaST
4.16.3 Chroot Environment Scripts
Chroot scripts are executed before the machine reboots for the frst time. You can execute
chroot scripts before the installation chroots into the installed system and confgures
the boot loader or you can execute a script after the chroot into the installed system has
happened (look at the "chrooted" parameter for that).
The following elements must be between the <scripts><chroot-scripts con-
fg:type="list"><script> ... </script></chroot-scripts>...</scripts> tags
Table 4.3 Chroot Script XML Representation
Either <loca-
tion> or
Defne a location from where the script gets fetched.
Locations can be the same as for the profle (http,
ftp, nfs, etc.).
location
<source> must
be defned.
<location
>http://10.10.0.1/myChrootScript.sh</location>
Either <loca-
tion> or
source
<source> must
be defned.
shell script into the XML profle, use the location
parameter.
<source>
<![CDATA[
echo "Testing the chroot script" >
/tmp/chroot_out.txt
]]>
</source>
Optional, default
is "false".
This value can be "true" or "false". If set to "false",
the installed system remains mounted at "/mnt" and
chrooted
no chroot happens. The bootloader is not installed
either at this stage. Set to "true" means, a chroot into
/mnt is performed, where the installed system is
mounted. The bootloader is installed, and if you want
to change anything in the installed system, you don't
have to use the "/mnt/" prefx anymore.
<chrooted config:type="boolean"
>true</chrooted>
Optional, default
is shell.
The interpreter that must be used for the script. Sup-
ported options are shell and perl. If you are in a ch-
interpreter
rooted=true condition, you can also use python if in-
stalled.
Optional, default
is the type of the
The flename of the script. It will be stored in a tem-
porary directory under /tmp/...
flename
script (chroot-
<filename>myPreScript5.sh</filename>
scripts in this
case). If you
have more than
one script, you
should set the
flename to a
reasonable val-
ue.
Optional, default
is "false". This
If this boolean is "true", stdout and stderr of the script
will be shown in a popup, which the user has to
feedback
option was confrm via the OK button. If stdout and stderr are
added with SL
10.1/SLES10.
empty, no popup is shown and therefore no confrma-
tion is needed.
>true</feedback>
Optional, if
missing, an al-
This can be "message", "warning" or "error". Set the
timeout for these popups in the <report> section.
feed-
back_type
ways blocking
popup is used.
This option was
introduced with
84 AutoYaST
openSUSE 11.2
(not SLES11).
Optional, default
is "true". This
If this is true, every single line of a shell script is
logged. Perl scripts are run with warnings turned on.
debug
option was
added with SL
10.1/SLES10.
Optional, if not
confgured, no
This text will be shown in a popup for the time the
script is running in the background.
notifca-
tion
notifcation pop-
up will be
shown. This op-
tion was added
with openSUSE
11.3/SLES11
SP2 (not
SLES10).
Optional, default
is "false" (scripts
only run once).
Ascript is only run once. Even if you use ayast_setup
to run a XML fle multiple times, the script is only
run once. You can change the default behavior by
setting this boolean to "true".
rerun
4.16.4 Post-Install Scripts
These scripts are executed after AutoYaST has completed the systemconfguration and
after it has booted the system for the frst time.
It is possible to execute post scripts in an earlier phase while the installation network
is still up and before AutoYaST confgures the system. To run network-enabled post
scripts, the boolean property network_needed has to be set to "true".
The following elements must be between the <scripts><post-scripts con-
fg:type="list"><script> ... </script></post-scripts>...</scripts> tags.
Table 4.4 Post Script XML Representation
Either <location>
or <source> must
be defned.
fetched. Locations can be the same as for the pro-
fle (http, ftp, nfs, etc.).
location
<location
>http://10.10.0.1/myPostScript.sh</location>
Either <location>
or <source> must
be defned.
parameter.
source
<source>
<![CDATA[
echo "Testing the chroot script" >
/tmp/chroot_out.txt
]]>
</source>
Optional, default
is "false".
This value can be "true" or "false". On "false" the
script will run after the YaST modules like the user
net-
work_need-
ed confguration and everything else are done. The
network is confgured but not up and running yet.
With this value set to "true", the script runs before
all YaST modules are confgured. So there is no
local user and no network is confgured but the
installation network is still up and running (if you
did a network installation).
<network_needed config:type="boolean"
>true</network_needed>
Optional, default
is shell.
The interpreter that must be used for the script.
Supported options are shell, perl and python if in-
stalled.
interpreter
86 AutoYaST
Optional, default
is the type of the
flename
script (post-scripts
<filename>myPostScript5.sh</filename>
in this case). If
you have more
than one script, set
the flename to a
reasonable value.
Optional, default
is "false". This op-
If this boolean is "true", stdout and stderr of the
script will be shown in a popup, which the user has
feedback
tion was added to confrm via the OK button. If stdout and stderr
with SL
10.1/SLES10.
are empty, no popup is shown and therefore no
confrmation is needed.
>true</feedback>
Optional, if miss-
ing, an always
This can be "message", "warning" or "error". Set
the timeout for these popups in the <report> sec-
tion.
feed-
back_type
blocking popup is
used. This option
was added with
openSUSE 11.2
(not SLES11).
Optional, default
is "true". This op-
If this is "true", every single line of a shell script
is logged. Perl scripts are run with warnings turned
on.
debug
tion was added
with SL
10.1/SLES10.
Optional, if not
confgured, no no-
This text will be shown in a popup for the time the
script is running in the background.
notifcation
tifcation popup
will be shown.
This option was
introduced with
openSUSE
11.3/SLES11 SP2
(not SLES10).
Optional, default
is "false" (scripts
only run once).
rerun
4.16.5 Init Scripts
These scripts are executed when YaST has fnished, during the initial boot process after
the network has been initialized. These fnal scripts are executed using a special init.d
script executed only once.
Init scripts are confgured using the tag init-scripts and are run using the special purpose
init.d script /etc/init.d/autoyast.
The following elements must be between the <scripts><init-scripts con-
fg:type="list"><script> ... </script></init-scripts>...</scripts> tags
Table 4.5 Init script XML representation
Comment Description Ele-
ment
fned.
fetched. Locations can be the same as for the pro-
fle (http, ftp, nfs, etc.).
loca-
tion
<location
>http://10.10.0.1/myInitScript.sh</location>
88 AutoYaST
Comment Description Ele-
ment
fned.
parameter.
source
<source>
<![CDATA[
echo "Testing the init script" >
/tmp/init_out.txt
]]>
</source>
Optional, default is the
type of the script (init-
fle-
name
scripts in this case). If
<filename>mynitScript5.sh</filename>
you have more than
one script, set the fle-
name to a reasonable
value.
"false" (scripts only
run once).
rerun
When added to the control fle manually, scripts have to be included in a CDATA element
to avoid confusion with the fle syntax and other tags defned in the control fle.
4.16.6 Script Example
90 AutoYaST
Example 4.32 Post Script Confguration
<!DOCTYPE profile>
<scripts>
<chroot-scripts config:type="list">
<script>
<chrooted config:type="boolean">true</chrooted>
<filename>chroot.sh</filename>
<source><![CDATA[
#!/bin/sh
echo "Testing chroot (chrooted) scripts"
ls
]]>
</source>
</script>
<script>
<filename>chroot.sh</filename>
<source><![CDATA[
#!/bin/sh
echo "Testing chroot scripts"
df
cd /mnt
ls
]]>
</source>
</script>
</chroot-scripts>
<post-scripts config:type="list">
<script>
<filename>post.sh</filename>
<source><![CDATA[
#!/bin/sh
echo "Running Post-install script"
/etc/init.d/portmap start
mount -a 192.168.1.1:/local /mnt
cp /mnt/test.sh /tmp
umount /mnt
]]>
</source>
</script>
<script>
<filename>post.pl</filename>
<source><![CDATA[
#!/usr/bin/perl
print "Running Post-install script";
]]>
</source>
</script>
</post-scripts>
<pre-scripts config:type="list">
<script>
<location>http://192.168.1.1/profiles/scripts/prescripts.sh</location>
</script>
<script>
<filename>pre.sh</filename>
<source><![CDATA[
#!/bin/sh
echo "Running pre-install script"
]]>
</source>
</script>
</pre-scripts>
<postpartitioning-scripts config:type="list">
<script>
<filename>postpart.sh</filename>
<source><![CDATA[
touch /mnt/testfile
echo Hi
]]>
</source>
</script>
</postpartitioning-scripts>
</scripts>
</profile>
After installation is fnished, the scripts and the output logs can be found in the directory
/var/adm/autoinstall. The scripts are located in the subdirectory scripts
and the output logs in the log directory.
The log is the output when executing the shell scripts using the following command:
/bin/sh -x <script_name> 2&> /var/adm/autoinstall/logs/<script_name>.log
92 AutoYaST
4.17 System Variables (Sysconfg)
Using the sysconfg resource, it is possible to defne confguration variables in the
sysconfg repository (/etc/sysconfig) directly. Sysconfg variables, offer the
possibility to fne-tune many system components and environment variables exactly to
your needs.
The following example shows how a variable can be set using the sysconfg resource.
To confgure a variable in a sysconfg fle, the following syntax can be used:
Example 4.33 Sysconfg Confguration
<sysconfig config:type="list" >
<sysconfig_entry>
<sysconfig_key>XNTPD_INITIAL_NTPDATE</sysconfig_key>
<sysconfig_path>/etc/sysconfig/xntp</sysconfig_path>
<sysconfig_value>ntp.host.com</sysconfig_value>
</sysconfig_entry>
<sysconfig_entry>
<sysconfig_key>HTTP_PROXY</sysconfig_key>
<sysconfig_path>/etc/sysconfig/proxy</sysconfig_path>
<sysconfig_value>proxy.host.com:3128</sysconfig_value>
</sysconfig_entry>
<sysconfig_entry>
<sysconfig_key>FTP_PROXY</sysconfig_key>
<sysconfig_path>/etc/sysconfig/proxy</sysconfig_path>
<sysconfig_value>proxy.host.com:3128</sysconfig_value>
</sysconfig_entry>
</sysconfig>
Both relative and absolute pathes can be provided. If no absolute path is given, it is
treated as a sysconfg fle under the /etc/sysconfig directory.
4.18 Adding Complete Confgurations
For many applications and services you might have prepared a confguration fle which
should be copied to the appropriate location in the installed system, for example if you
are installing a web server and have a ready to go server confguration fle (httpd
.conf).
Using this resource, you can embed the fle into the control fle by specifying the fnal
path on the installed system. YaST will copy this fle to the specifed location.
This feature requires the autoyast2 package to be installed. If the package is missing,
AutoYaST will silently ignore the fles section. Since openSUSE 11.1 and SLES11,
AutoYaST will install the package automatically if it is missing.
Since openSUSE 11.1 and SLES11, you can specify the fle_location where the fle
should be retrieved from. For an HTTP server this would look like: <fle_loca-
tion>http://my.server.site/issue</fle_location>.
Since openSUSE 11.2 (not SLES11), you can create directories by specifying a fle_path
that ends with a slash.
Example 4.34 Dumping fles into the installed system
<files config:type="list">
<config_file>
<file_path>/etc/httpd/httpd.conf</file_path>
<file_contents>
<![CDATA[
some content
]]>
</file_contents>
</config_file>
</files>
<config_file>
<file_path>/mydir/a/b/c/</file_path> 
</config_file>
</files>
94 AutoYaST
A more advanced example is shown below. This confguration will create a fle using
the content supplied in fle_contents and change the permissions and ownership of the
fle. After the fle has been copied to the system, a script is executed, which can be used
to manipulate the fle and prepare it for the environment of the client.
Example 4.35 Dumping fles into the installed system
<config_file>
<file_path>/etc/someconf.conf</file_path>
<file_contents>
<![CDATA[
some content
]]>
</file_contents>
<file_owner>nashif.users</file_owner>
<file_permissions>444</file_permissions>
<file_script>
<source>
<![CDATA[
#!/bin/sh
echo "Testing file scripts" >> /etc/someconf.conf
df
cd /mnt
ls
]]>
</source>
</file_script>
</config_file>
</files>
4.19 Ask the user for values during
installation
This feature is only available since SUSE Linux 10.1 and SLES10.
You have the option to let the user decide the values of specifc parts of the profle
during the installation. If you use this feature, a popup will ask the user to enter a spe-
cifc part of the profle during installation. If you want a full auto installation, but the
user should set the password of the local account, you can do this via the ask directive
in the profle.
The following elements must be between the <ask-list confg:type="list"><ask> ...
</ask></ask-list> tags in the <general> section.
Table 4.6 XML representation
The default
value is the
The question you want to ask the user.
<question>Enter the LDAP server</question>
question
path to the ele-
ment (the
path often
looks strange,
so we recom-
mend to enter
a question)
Optional. Set a pre-selection for the user. Atextentry will be flled
out with this value. Acheckbox will be "true" or "false"
default
and a selection will have this default "value" pre-select-
ed.
<default>dc=suse,dc=de</default>
Optional. An optional helptext that is shown on the left side of
the question.
help
<help>Enter the LDAP server address.</help>
Optional. An optional title that is shown above the questions. title
<title>LDAP server</title>
96 AutoYaST
Optional. The
defaul is
The type of the element you want to change. Possible
values are "symbol","boolean","string" and "integer".
type
string. If type The flesystemin the partition section is a symbol, while
is "symbol", the "encrypted" element in the user confguration is a
you must pro- boolean. You can see the type of that element if you
vide the selec- look in your profle at the confg:type="...." attribute.
tion element Since openSUSE 11.2 and SLES11-SP2 you can use
too (see be-
low).
"static_text" as type too. A static_text is just a text that
does not require any user input and can be used to show
information if it's not wanted in the help text.
<type>symbol</type>
Optional. The
default is
"false".
If this boolean is set to "true", a password dialog pops
up instead of a simple text entry. Setting this to "true"
makes only sense if "type" is string.
password
<password config:type="boolean">true</password>
This informa-
tion is option-
The path to the element in the profle. It's a comma
seperated list of elements that describes the path to the
path(depre-
cated since
al, but you element you want to change. For example, the ldap openSUSE
should at least server element can be found in the profle in the 11.0 - use
pathlist) provide path
or fle.
<ldap><ldap_server> section. So if you want to change
that value, you have to set the path to "ldap,ldap_serv-
er". If you want to change the password of the frst user
in the profle, you have to set the path to "users,0,us-
er_password". The "0" indicates the frst user in the
<users confg:type="list"> list of users in the profle.
<path>networking,dns,hostname</path>
This informa-
tion is option-
A list of path elements (see above).
<pathlist config:type="list"
><path>networking,dns,hostname</path>
<path>...</path>
pathlist
(available
since open-
SUSE11.0
and re-
al but you
should at least
provide path
or fle.
places
path)
This informa-
tion is option-
You can store the answer to a question in a fle, to use
it in one of your scripts later. If you ask during
fle (avail-
able since
al, but you stage=inital and you want to use the answer in stage2, SLES10
should at least then you have to copy the answer-fle in a chroot script SP1 and
SL 10.2) provide path
or fle
that is running as chrooted=false. Use the commnad:
"cp /tmp/my_answer /mnt/tmp/". The reason is that
/tmp in stage1 is just in the RAM disk and will get lost
after the reboot, but the installed system is already
mounted at /mnt/.
<file>/tmp/answer_hostname</file>
Optional. The
default is
"false".
If this boolean is set to "true", a password dialog pops
up instead of a simple text entry. Setting this to "true"
makes only sense if "type" is string.
password
<password config:type="boolean">true</password>
Optional. The
default is "ini-
tial".
Stage confgures the installation stage in which the
question pops up. You can set this value to "cont" or
"initial". "initial" means the popup comes up very early
stage
in the installation, shortly after the pre-script has run.
"cont" means, that the dialog with the question comes
after the frst reboot when the systemboots for the very
frst time. Questions you answer during the "inital"
stage, will write their answer into the profle on the
harddisk. You should know that if you enter cleartext
passwords during "initial". Of course it does not make
sense to ask for the flesystem to use during the "cont"
phase. The harddisk is already partitioned at that stage
and the question will have no effect.
<stage>cont</stage>
98 AutoYaST
Optional for
type=string,
The selection element contains a list of <entry> ele-
ments. Each entry represents a possible option for the
selection
not possible user to choose. The user cannot enter a value in a
textfeld, but he can choose from a list of values. for
<selection config:type="list">
<entry>
type=boolean
and mandato-
<value>
ry for
type=symbol.
reiser
</value>
<label>
Reiser Filesystem
</label>
</entry>
<entry>
<value>
ext3
</value>
<label>
Extended3 Filesystem
</label>
</entry>
</selection>
Optional. Since OpenSUSE 10.3, you can ask more than one
question per dialog. To do so, specify the dialog-id
dialog
(available
with an integer. All questions with the same dialog-id since SL
belong to the same dialog. The dialogs are sorted by
the id too.
10.3 and
SLES10
SP2)
<dialog config:type="integer">3</dialog>
Optional (see
dialog>.
Since OpenSUSE 10.3, you can have more than one
question per dialog. To make that possible you have to
element
(available
specify the element-id with an integer. The questions
in a dialog are sorted by id.
since SL
10.3 and
<element config:type="integer">1</element>
SLES10
SP2)
Optional. De-
fault is no
frame title.
Since OpenSUSE 10.3, you can have more than one
question per dialog. Each question on a dialog has a
frame that can have a frame title, a small caption for
frametitle
(available
since SL
each question. Since openSUSE 11.3, you can put 10.3 and
multiple elements into one frame. They have to have
the same frame title.
SLES10
SP2)
<frametitle>User data</frametitle>
optional (de-
fault is no
script)
Since 10.3, you can run scripts after a question has been
answered (see the table below for detailed instructions
about scripts).
script
(available
since SL
<script>...</script>
10.3, not
in SLES10
SP1)
Optional. You can change the label on the "Ok" button. The last
element that specifes the label for a dialog wins.
ok_label
(available
<ok_label>Finish</ok_label>
since open-
SUSE11.2
and
SLES11
SP2
Optional. You can change the label on the "Back" button. The
last element that specifes the label for a dialog wins.
back_label
(available
<back_label>change values</back_label>
since open-
SUSE11.2
and
SLES11
SP2
Optional. A
missing value
You can specify an integer here that is used as timeout
in seconds. If the user does not answer the question
timeout
(available
is interpreted before the timeout, the default value is taken as answer. since open-
as 0, which When the user touches or changes any widget in the SUSE11.2
means that
100 AutoYaST
there is no
timeout.
dialog, the timeout is turned off and the dialog has to
be confrmed via the ok-button.
and
SLES11-
SP2
Optional. De-
fault is no
script.
You can run scripts to set the default value for a ques-
tion (see the table below for detailed instructions about
default value scripts). This feature is useful if you can
default_val-
ue_script
(available
"calculate" a useful default value, especially in combi-
nation with the "timeout" option.
since open-
SUSE11.2
<default_value_script>...</default_value_script>
and
SLES11-
SP2)
The following elements must be between the <ask-list confg:type="list"><ask><de-
fault_value_script>...</default_value_script>...</ask></ask-list>tags in the <general>
section. This is available since 11.2 and SLES11-SP2.
This value is required,
otherwise nothing would
be executed.
The source code of the script. Whatever you
echo to STDOUT will be used as default
value for the ask-dialog. If your script has
source
an exit code other than 0, the normal default
element is used. Take care you use echo
-n to suppress the \n and that you echo
reasonable values and not "okay" for a
boolean
<source>...</source>
The default is shell. You
can also set "/bin/myinter-
preter" as value.
The interpreter to use.
interpreter
The following elements must be between the <ask-list con-
fg:type="list"><ask><script>...</script>...</ask></ask-list> tags in the <general>
section. Available since 10.3 (not SLES10 SP1).
The default is
ask_script.sh
The flename of the script.
<filename>my_ask_script.sh</filename>
flename
This value is re-
quired, otherwise
The source code of the script. Together with "re-
run_on_error" activated, you check the value that
source
nothing would be
executed.
was entered for sanity (since 11.0 only). Your
script can create a fle "/tmp/next_dialog" with a
dialog id specifying the next dialog AutoYaST
will raise. A value of -1 terminates the ask se-
quence. If that fle is not created, AutoYaST will
run the dialogs in the normal order (since 11.0
only).
<source>...</source>
"false".
A boolean that passes the "value" of the answer
to the question as an environment variable to the
script. The variable is named "VAL".
environ-
ment
<environment
config:type="boolean">true</environment>
"false".
A boolean that turns on feedback for the script
execution. STDOUT will be displayed in a popup
feedback
window that must be confrmed after the script
execution.
<feedback
config:type="boolean">true</feedback>
"true". This value
A boolean that turns on debugging for the script
execution.
debug
102 AutoYaST
needs "feedback" to
be turned on too.
"false". This value
A boolean that keeps the dialog open until the
script has an exit code of 0 (zero). So you can
re-
run_on_er-
should be used to- parse and check the answers the user gave in the ror (avail-
gether with the
feedback option.
script and display an error with the "feedback"
option.
able since
open-
<rerun_on_error
config:type="boolean">true</rerun_on_error>
SUSE
11.0)
Below you can see an example of the usage of the "ask" feature.
<general>
<ask-list config:type="list">
<ask>

<pathlist config:type="list">
<path>ldap,ldap_server</path>
</pathlist>
<stage>cont</stage>
<help>choose your server depending on your department</help>
<entry>
<value>ldap1.mydom.de</value>
<label>LDAP for development</label>
</entry>
<entry>
<value>ldap2.mydom.de</value>
<label>LDAP for sales</label>
</entry>
</selection>
<default>ldap2.mydom.de</default>
<default_value_script>
<source> <![CDATA[
echo -n "ldap1.mydom.de"
]]>
</source>
</default_value_script>
</ask>
<ask>
-->
</pathlist>
<question>Enter Hostname</question>
<stage>initial</stage>
<default>enter your hostname here</default>
</ask>
<ask>
<path>partitioning,0,partitions,0,filesystem</path>
-->
<path>partitioning,0,partitions,0,filesystem</path>
</pathlist>
<question>Filesystem</question>
<type>symbol</type>
<entry>
<value config:type="symbol">reiser</value>
<label>default Filesystem (recommended)</label>
</entry>
<entry>
<value config:type="symbol">ext3</value>
<label>Fallback Filesystem</label>
</entry>
</selection>
</ask>
</ask-list>
...
</general>
The following example is a nice way to choose between AutoYaST profles. AutoYaST
will read the modified.xml fle again after the ask-dialogs are done. This way you
can fetch a complete new profle.
<ask>
<entry>
<value>part1.xml</value>
<label>Simple partitioning</label>
</entry>
<entry>
<label>encrypted /tmp</label>
</entry>
<entry>
<label>LVM</label>
</entry>
</selection>
104 AutoYaST
<title>XML Profile</title>
<question>Choose a profile</question>
<stage>initial</stage>
<default>part1.xml</default>
<script>
<filename>fetch.sh</filename>
<environment config:type="boolean">true</environment>
<source><![CDATA[
wget http://10.10.0.162/$VAL -O /tmp/profile/modified.xml 2>/dev/null
]]>
</source>
<feedback config:type="boolean">false</feedback>
</script>
</ask>
Since openSUSE 11.0, you can verify the answer of a question with a script like this:
<ask>
<script>
<filename>my.sh</filename>
<rerun_on_error config:type="boolean">true</rerun_on_error>
<environment config:type="boolean">true</environment>
<source><![CDATA[
if [ "$VAL" = "myhost" ]; then
echo "Illegal Hostname!";
exit 1;
fi
exit 0
]]>
</source>
</script>
<dialog config:type="integer">0</dialog>
-->
</pathlist>
<question>Enter Hostname</question>
<default>enter your hostname here</default>
</ask>
4.20 Kernel dumps
NOTE: Availability
This feature is only available since SLES 11 (not openSUSE 11.1). It is not avail-
able on the zSeries (s390x) architecture.
With kdump the system is able to create crashdump fles if the whole system (i.e., the
kernel) crashes. Crash dump fles contain the memory contents while the systemcrashed.
Such core fles can be analyzed later by support or a (kernel) developer to fnd the
reason for the system crash. Kdump is mostly useful for servers where you cannot
easily reproduce such crashes but it is important to get the problem fxed.
The only downside: enabling kdump costs you between 64 MiBand 128 MiBof system
RAM (on "normal" sized systems), reserved for kdump in case the system crashes and
the dump needs to be generated.
This section only describes how to set up kdump with AutoYaST. It does not describe
how kdump works. For details, refer to the kdump(7) manual page, contained in the
kdump package, or to openSUSE Kdump documentation [http://en.opensuse
.org/Kdump].
The following example shows a general kdump confguration.
106 AutoYaST
Example 4.36 Kdump confguration
<kdump>

<add_crash_kernel config:type="boolean">true</add_crash_kernel>
<crash_kernel>256M-:64M</crash_kernel>
<general>

<KDUMP_SAVEDIR>ftp://stravinsky.suse.de/incoming/dumps</KDUMP_SAVEDIR>
<KDUMP_COPY_KERNEL>true</KDUMP_COPY_KERNEL>
<KDUMP_FREE_DISK_SIZE>64</KDUMP_FREE_DISK_SIZE>
<KDUMP_KEEP_OLD_DUMPS>5</KDUMP_KEEP_OLD_DUMPS>

<KDUMP_DUMPFORMAT>compressed</KDUMP_DUMPFORMAT>
<KDUMP_DUMPLEVEL>1</KDUMP_DUMPLEVEL>

<KDUMP_NOTIFICATION_TO>bwalle@suse.de</KDUMP_NOTIFICATION_TO>
<KDUMP_NOTIFICATION_CC></KDUMP_NOTIFICATION_CC>
<KDUMP_SMTP_SERVER>mail.suse.de</KDUMP_SMTP_SERVER>
<KDUMP_SMTP_USER></KDUMP_SMTP_USER>
<KDUMP_SMTP_PASSWORD></KDUMP_SMTP_PASSWORD>

<KDUMP_KERNELVER></KDUMP_KERNELVER>
<KDUMP_COMMANDLINE></KDUMP_COMMANDLINE>
<KDUMP_COMMANDLINE_APPEND></KDUMP_COMMANDLINE_APPEND>

<KDUMP_IMMEDIATE_REBOOT>yes</KDUMP_IMMEDIATE_REBOOT>
<KDUMP_VERBOSE>15</KDUMP_VERBOSE>
<KEXEC_OPTIONS></KEXEC_OPTIONS>
</general>
</kdump>
4.20.1 Memory Reservation
The frst step is to reserve memory for kdump at boot-up. Because the memory must
be reserved very early during the boot process, the confguration is done via a kernel
command line parameter called crashkernel. The reserved memory will be used
to load a second kernel which will be executed without rebooting if the frst kernel
crashes. This second kernel has a special initrd, which contains all programs necessary
to save the dump over the network or to disk, send a notifcation e-mail, and fnally
reboot.
Enable or disable that the crashkernel parameter is written for the default boot
kernel with the add_crash_kernel tag. You can specify the value of the
crashkernel parameter using the crash_kernel tag.
To reserve memory for kdump, specify the amount (such as 64M to reserve 64 MiB of
memory from the RAM) and the offset. The syntax is
crashkernel=AMOUNT@OFFSET. The kernel can auto-detect the right offset (with
the exception of the Xen hypervisor, where you have to specify 16M as offset). Simply
specify <crash_kernel>crashkernel=64M</crash_kernel>and the right
thing will happen.
For the amount of memory, the following values are recommended:
Table 4.9 Recommended values for the reserved memory amount
Recommended values Platform
64M for small machines (about 2 GiB of RAM, 4 cores) and
128M for larger machines
i386 and x86-64
128M for small machines and 256M for larger machines
PPC64
256M for small machines, 512M for medium machines and
1G and more for really large machines (mostly SGI Altix
systems)
IA64
You can also use the extended command line syntax to specify the amount of reserved
memory depending on the System RAM. That is useful if you share one AutoYaST
profle for multiple installations or if you often remove or install memory on one ma-
chine. The syntax is:
BEGIN_RANGE_1-END_RANGE_1:AMOUNT_1,BEGIN_RANGE_2-END_RANGE_2:AMOUNT_2@OFFSET
BEGIN_RANGE_1 is the start of the frst memory range (for example: 0M) and
END_RANGE_1 is the end of the frst memory range (can be empty in case "infnity"
should be assumed) and so on. For example 256M-2G:64M,2G-:128M means to
reserve 64 MiB of crashkernel memory if the system has between 256 MiB and 2 GiB
RAMand to reserve 128 MiBof crashkernel memory if the systemhas more than 2 GiB
RAM.
108 AutoYaST
The following table shows the settings necessary to reserve memory:
Table 4.10 XML Representation of the Memory Reservation Settings
required Set to "true" if memory should be reserved and
kdump enabled.
add_crash_ker-
nel
<add_crash_kernel
config:type="boolean">true</add_crash_kernel>
required Use the syntax of the crashkernel command line as
discussed above.
crash_kernel
<crash_kernel>256M:64M</crash_kernel>
4.20.2 Dump Saving
4.20.2.1 Target
The element KDUMP_SAVEDIR specifes the URL to where the dump is saved. The
following methods are possible:
file to save to the local disk,
ftp to save to an FTP server (without encryption),
sftp to save to an SSH2 SFTP server,
nfs to save to a NFS location and
cifs to save the dump to a CIFS/SMP export from Samba or Microsoft Windows.
For details see the kdump(5) manual page. Two examples are: file:///var/crash
(which is the default location according to FHS) and
ftp://user:password@host:port/incoming/dumps. Asubdirectory, with
the time stamp contained in the name, will be created and the dumps saved there.
When the dump is saved to the local disk, KDUMP_KEEP_OLD_DUMPS can be used
to delete old dumps automatically. Set it to the number of old dumps that should be
kept. If the target partition would end up with less free disk space than specifed in
KDUMP_FREE_DISK_SIZE, the dump is not saved.
If you want to save the whole kernel and the debug information (if installed) to the
same directory, set KDUMP_COPY_KERNEL to true. You'll have everything you need
to analyze the dump in one directory (except kernel modules and their debugging infor-
mation).
4.20.2.2 Filtering and Compression
The kernel dump is uncompressed and unfltered. It can get as large as your system
RAM. To get smaller fles, compress the dump fle afterwards. The dump has to be
decompressed before opening.
To use page compression, which compresses every page and allows dynamic decom-
pression with the crash(8) debugging tool, set KDUMP_DUMPFORMATto compressed
(default).
You may not want to save all memory pages, for example those flled with zeroes. To
flter the dump, set the KDUMP_DUMPLEVEL. 0 produces a full dump and 31 is the
smallest dump. The manual pages kdump(5) and makedumpfle(8) list for each value
which pages will be saved.
4.20.2.3 Summary
Table 4.11 XML Representation of the Dump Target Settings
Com-
ment
Description Element
re-
quired
An URL that specifes the target to
which the dump and related fles will be
saved.
KDUMP_SAVEDIR
<KDUMP_SAVEDRIR
>file:///var/crash/</KDUMP_SAVEDIR>
110 AutoYaST
Com-
ment
Description Element
option-
al
Set to "true", if not only the dump should
be saved to KDUMP_SAVEDIR but also
KDUMP_COPY_KERNEL
the kernel and its debugging information
(if installed).
<KDUMP_COPY_KERNEL
>false</KDUMP_COPY_KERNEL>
option-
al
Disk space in megabytes that must re-
main free after saving the dump. If not
KDUMP_FREE_DISK_SIZE
enough space is available to write the
dump and keep the required disk space
free, the dump will not be saved.
<KDUMP_FREE_DISK_SIZE
>64</KDUMP_FREE_DISK_SIZE>
option-
al
The number of dumps that are kept (i.e.,
not deleted) if KDUMP_SAVEDIRpoints
KDUMP_KEEP_OLD_DUMPS
to a local directory. Specify 0 if you do
not want any dumps to be automatically
deleted, specify -1 if all dumps except
the current one should be deleted.
<KDUMP_KEEP_OLD_DUMPS
>4</KDUMP_KEEP_OLD_DUMPS>
4.20.3 Email Notifcation
Confgure email notifcation, if you want to be informed when a machine crashes and
a dump is saved.
Because kdump runs in the initrd, a local mail server cannot send the notifcation email.
An SMTP server needs to be specifed (see below).
You have to provide exactly one address in KDUMP_NOTIFICATION_TO. More ad-
dresses can be specifed in in KDUMP_NOTIFICATION_CC. Only use email addresses
in both cases, not a real name.
Specify KDUMP_SMTP_SERVER and (if the server needs authentication)
KDUMP_SMTP_USER and KDUMP_SMTP_PASSWORD. Support for TSL or SSL is
not available but may be added in the future.
Table 4.12 XML Representation of the Email Notifcation Settings
Com-
ment
Description Element
optional
(notifca-
Exactly one email address to which the email
should be sent. Additional recipients can be
specifed in KDUMP_NOTIFICATION_CC.
KDUMP_NOTIFICA-
TION_TO
tion dis-
abled if
empty)
<KDUMP_NOTIFICATION_TO
>tux@example.com</KDUMP_NOTIFICATION_TO>
optional Zero, one or more recipients that are in the cc
line of the notifcation email.
KDUMP_NOTIFICA-
TION_CC
<KDUMP_NOTIFICATION_CC
>spam@suse.de
devnull@suse.de</KDUMP_NOTIFICATION_CC>
optional
(notifca-
Host name of the SMTP server used for mail
delivery. SMTP authentication is supported
KDUMP_SMTP_SERV-
ER
tion dis-
(see KDUMP_SMTP_USER and
abled if
empty)
KDUMP_SMTP_PASSWORD) but TSL and
SSL are not.
<KDUMP_SMTP_SERVER
>email.suse.de</KDUMP_SMTP_SERVER>
optional User name used together with
KDUMP_SMTP_PASSWORDfor SMTPauthen-
tication.
KDUMP_SMTP_USER
<KDUMP_SMTP_USER
>bwalle</KDUMP_SMTP_USER>
112 AutoYaST
Com-
ment
Description Element
optional Password used together with
KDUMP_SMTP_USER for SMTP authentica-
tion.
KDUMP_SMTP_PASS-
WORD
<KDUMP_SMTP_PASSWORD
>geheim</KDUMP_SMTP_PASSWORD>
4.20.4 Kdump Kernel Settings
As already mentioned, a special kernel is booted to save the dump. If you don't want
to use the auto-detection mechanismto fnd out which kernel is used (see the kdump(5)
manual page that describes the algorithm which is used to fnd the kernel), you can
specify the version of a custom kernel in KDUMP_KERNELVER. If you set it to foo,
then the kernel located in /boot/vmlinuz-foo or /boot/vmlinux-foo (in
that order on platforms that have a vmlinuz fle) will be used.
You can specify the command line used to boot the kdump kernel. Normally the boot
command line is used minus some settings that make no sense with kdump (like the
crashkernel parameter) plus some settings needed by kdump (see the manual page
kdump(5)). If you just want some additional parameters like a overwritten console setting
then use KDUMP_COMMANDLINE_APPEND. If you know what you're doing and you
want to specify the whole command line, set KDUMP_COMMANDLINE.
Table 4.13 XML Representation of the Kernel Settings
Com-
ment
Description Element
optional
(auto-de-
Version string for the kernel used for kdump. Leave
it empty to use the auto-detection mechanism
(strongly recommended).
KDUMP_KER-
NELVER
tection if
empty)
<KDUMP_KERNELVER
>2.6.27-default</KDUMP_KERNELVER>
Com-
ment
Description Element
optional Additional command line parameters for the kdump
kernel.
KDUMP_COM-
MAND-
LINE_APPEND
<KDUMP_COMMANDLINE_APPEND
>console=ttyS0,57600</KDUMP_COMMANDLINE_APPEND>
optional Overwrite the automatically generated kdump com-
mand line. Use with care. In most cases,
KDUMP_COMMANDLINE_APPEND should suffce.
KDUMP_COM-
MANDLINE
<KDUMP_COMMANDLINE_APPEND
>root=/dev/sda5 maxcpus=1
irqpoll</KDUMP_COMMANDLINE>
4.20.5 Expert Settings
Table 4.14 XML Representation of the Expert Settings
optional
true if the systemshould be rebooted automat-
ically after the dump has been saved, false
KDUMP_IMMEDI-
ATE_REBOOT
otherwise. The default is to reboot the system
automatically.
<KDUMP_IMMEDIATE_REBOOT
>true</KDUMP_IMMEDIATE_REBOOT>
optional Bitmask that specifes how verbose the kdump
process should be. Read kdump(5) for details.
KDUMP_VER-
BOSE
<KDUMP_VERBOSE>3</KDUMP_VERBOSE>
optional Additional options that are passed to kexec when
loading the kdump kernel. Normally empty.
KEXEC_OPTIONS
<KEXEC_OPTIONS>--noio</KEXEC_OPTIONS>
114 AutoYaST
4.21 Miscellaneous Hardware and
System Components
In addition to the core component confguration, like network authentication and secu-
rity, AutoYaST offers a wide range of hardware and system confguration options, the
same as available by default on any system installed manually and in an interactive
way. For example, it is possible to confgure printers, sound devices, TV cards and any
other hardware components which have a module within YaST.
Any new confguration options added to YaST will be automatically available in
AutoYaST.
4.21.1 Printer
The YaST printer module has been rewritten from scratch for openSUSE 11.1 and
SUSE Linux Enterprise Server/Desktop 11. Currently, AutoYaST support for printing
is limited to basic settings for how the CUPS printing system is used on a client work-
station to print via network.
There is no AutoYaST support for setting up local print queues. In particular, when a
USB printer is connected to a client workstation, it is no longer possible to have a pre-
defned confguration, because USB printers are no longer accessed via a generic USB
device node like "/dev/usb/lp0" but via a model-specifc device URI like
"usb://ACME/FunPrinter?serial=1a2b3c". There is a serial number included so that a
USB printer device URI works only for one particular device. Usually it is not possible
to know the correct USB device URI in advance, because it is determined by the CUPS
backend "usb" during runtime when the particular device is connected, depending on
the actual values which the printer reports via the USB.
Intrinsic design of CUPS for printing in the network:
The CUPS daemon process (cupsd) of a CUPS network print server sends information
about its print queues to a list of IP addresses (host addresses and/or broadcast addresses).
On client workstations (hosts that only send print jobs to servers) a cupsd also runs and
listens to information from servers. There is a list of servers from which information
is accepted. By default, information is accepted from all servers.
The queues of the server are available on the clients. Users on the clients can browse
the queues on various servers. Therefore it is called "Browsing". A client workstation
only needs to run cupsd to use CUPS in its default Browsing mode. The matching set-
tings in the cupsd confguration fle (/etc/cups/cupsd.conf) are "Browsing On" and
"BrowseAllow all".
If you want to limit from which CUPS servers browsing information is accepted, use
"BrowseAllow". For example, "BrowseAllow@LOCAL" accepts browsing information
only from CUPS servers in the local network.
Multiple "BrowseAllow" entries like "BrowseAllow192.168.100.1" and "BrowseAllow
192.168.200.0/255.255.255.0" can be used to accept browsing information only from
particular hosts or networks.
CUPS browsing information is received via UDP port 631. You may have to check
frewall settings accordingly.
Alternatively, if there is only one single CUPS server in the network, there is no need
to use CUPS browsing and have a CUPS daemon running on each client workstation.
Instead it is simpler to specify the CUPS server and access it directly by an entry like
"ServerName 192.168.100.99" in /etc/cups/client.conf (only one such entry can be set).
A locally running cupsd on a client workstation is ignored. In this case it makes no
sense to have it running.
The following is an example of a confguration section. The <cups_remote_server>
entry contains the value of a ServerName entry in /etc/cups/client.conf. The <server_set-
tings> section contains all values of the cupsd confguration fle (/etc/cups/cupsd.conf).
Acomplete <server_settings> section is required to get a reasonable cupsd confguration
installed.
116 AutoYaST
Example 4.37 Printer confguration
<printer>
<cups_remote_server>192.168.100.99</cups_remote_server>
<server_settings>
<Browsing config:type="list">
<listentry>On</listentry>
</Browsing>
<BrowseAllow config:type="list">
<listentry>@LOCAL</listentry>
<listentry>192.168.100.1</listentry>
<listentry>192.168.200.0/255.255.255.0</listentry>
</BrowseAllow>
<BrowseOrder config:type="list">
<listentry>allow,deny</listentry>
</BrowseOrder>
<LogLevel config:type="list">
<listentry>info</listentry>
</LogLevel>
<Listen config:type="list">
<listentry>localhost:631</listentry>
<listentry>/var/run/cups/cups.sock</listentry>
</Listen>
<DefaultAuthType config:type="list">
<listentry>Basic</listentry>
</DefaultAuthType>
<SystemGroup config:type="list">
<listentry>sys root</listentry>
</SystemGroup>
<section>
<Key>Location</Key>
<Value>/</Value>
<Allow config:type="list">
<listentry>127.0.0.2</listentry>
</Allow>
<Order config:type="list">
</Order>
</section>
<section>
<Key>Location</Key>
<Value>/admin</Value>
<Encryption config:type="list">
<listentry>Required</listentry>
</Encryption>
</Order>
</section>
<section>
<Key>Location</Key>
<Value>/admin/conf</Value>
<AuthType config:type="list">
<listentry>Default</listentry>
</AuthType>
<Require config:type="list">
<listentry>user @SYSTEM</listentry>
</Require>
</Order>
</section>
<section>
<Key>Policy</Key>
<Value>default</Value>
<subsection config:type="list">
<listentry>
<Key>Limit</Key>
<Value>Send-Document Send-URI Hold-Job Release-Job Restart-Job
Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription
Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job
Suspend-Current-Job Resume-Job CUPS-Move-Job</Value>
<listentry>user @OWNER @SYSTEM</listentry>
</Require>
<listentry>deny,allow</listentry>
</Order>
</listentry>
<listentry>
<Key>Limit</Key>
<Value>CUPS-Add-Modify-Printer CUPS-Delete-Printer
CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default</Value>
</AuthType>
</Require>
</Order>
</listentry>
<listentry>
<Key>Limit</Key>
<Value>Pause-Printer Resume-Printer Enable-Printer
Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs
Release-Held-New-Jobs Deactivate-Printer Activate-Printer Restart-Printer
Shutdown-Printer Startup-Printer Promote-Job Schedule-Job-After
CUPS-Accept-Jobs CUPS-Reject-Jobs</Value>
</AuthType>
118 AutoYaST
</Require>
</Order>
</listentry>
<listentry>
<Key>Limit</Key>
<Value>Cancel-Job CUPS-Authenticate-Job</Value>
<listentry>user @OWNER @SYSTEM</listentry>
</Require>
</Order>
</listentry>
<listentry>
<Key>Limit</Key>
<Value>All</Value>
</Order>
</listentry>
</subsection>
</section>
</sections>
</server_settings>
</printer>
4.21.2 Sound devices
An example of the sound confguration created using the confguration systemis shown
below.
Example 4.38 Sound confguration
....
<sound>
<autoinstall config:type="boolean">true</autoinstall>
<modules_conf config:type="list">
<module_conf>
<alias>snd-card-0</alias>
<model>M5451, ALI</model>
<module>snd-ali5451</module>
<options>
<snd_enable>1</snd_enable>
<snd_index>0</snd_index>
<snd_pcm_channels>32</snd_pcm_channels>
</options>
</module_conf>
</modules_conf>
<volume_settings config:type="list">
<listentry>
<Master config:type="integer">75</Master>
</listentry>
</volume_settings>
</sound>
....
120 AutoYaST
5 Network-based Installation
AutoYaST provides a method to automatically and identically install groups of systems.
The frst step when preparing a AutoYaST installation is to decide how you want to
install the target systems. The following scenario is a good example for how to set up
and perform automated installations:
You need to install SuSE Linux on 50 new systems.
The development department owns 30 out of the 50 new dual processor and SCSI
systems, and these systems must be installed as clients with development software.
The sales department owns 20 out of the 50 new, uni-processor IDE based systems
and its systems must be installed as clients with end user software and offce tools.
Prerequisites:
a boot server on the same Ethernet segment,
an installation server with the SuSE Linux OS,
an AutoYaST confguration server that defnes rules and profles.
5.1 Confguration Server
A confguration repository holds the control fles for multiple machines. The control
fles can have any fle names, which have to be specifed at the boot time of a target
client. To avoid supplying the profle name for every client, you can defne the directory
Network-based Installation 121
of the control fles. If a directory is specifed, then the target client tries to load a fle
with a name matching its IP address in HEX mode. This has the advantage that you
will be dealing with consistent fle names rather than IPs as fle names which might
lead to some confusion.
The confguration repository is the same directory you specify when using the confgu-
ration system for creating control fles.
5.1.1 HTTP Repository
To be able to use the HTTP protocol to retrieve control fles while auto-installing, you
need a working HTTP server on the server side. Install Apache or your favorite web
server and enable it using YaST. Normally the web server root directory resides in
/srv/www/htdocs so you need to create a subdirectory which will serve your con-
fguration repository.
5.1.2 NFS Repository
Create a directory and export it via NFS to the target clients. This directory may the
same location where you have copied the CDs. (i.e. /usr/local/SuSE).
5.1.3 TFTP Repository
By default the TFTP directory is available under /tftpboot which can also contain
boot images if you are booting over network. Do not forget to enable TFTP in the Inetd
confguration fle (/etc/inetd.conf). Inetd confguration can be done via YaST.
122 AutoYaST
6 Rules and Classes
6.1 Rules-based Automatic
Installation
Rules offer the possibility to confgure a system depending on system attributes by
merging multiple control fles during installation. The rules-based installation is con-
trolled by a rules fle.
The rules fle is an XML fle 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 profle. Both the rules fle and the profles must be located in a
pre-defned and accessible location.
The rules fle is retrieved only if no specifc control fle is supplied using the autoyast
keyword. For example, if the following is used, the rules fle 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/profle/rules/rules.xml (the slash at the end of the direc-
tory name is important).
Rules and Classes 123
Figure 6.1 Rules
If more than one rule applies, the fnal profle for each group is generated on the fy
using a merge script. The merging process is based on the order of the rules and later
rules override confguration data in earlier rules.
The use of a rules fle is optional. If the rules fle is not found, system installation pro-
ceeds in the classic way by only using the supplied profle or by searching for the profle
depending on the MAC or the IP address of the system.
124 AutoYaST
6.1.1 Rules File Explained
Example 6.1 Simple Rules File
The following simple example illustrates how the rules fle is used to retrieve the con-
fguration for a client with known hardware.
<!DOCTYPE autoinstall>
<autoinstall xmlns="http://www.suse.com/1.0/yast2ns"
<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>
</disksize>
<result>
</result>
</rule>
</rules>
</autoinstall>
The last example defnes two rules and provides a different profle for every rule. The
rule used in this case is disksize. After parsing the rules fle, YaST attempts to match
the target system with the rules in the rules.xml fle. A rule match occurs when the
target system matches all system attributes defned in the rule. As soon as the system
matches a rule, the respective resource is added to the stack of profles AutoYaST will
use to create the fnal profle. The continue property tells AutoYaST whether it should
continue with other rules after a match has been found.
If the frst 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 confgurations for systems with
hard drives of different sizes. The frst rule checks if the device /dev/hdc is available
and if it is greater than 1 GB in size using the match property.
A rule must have at least one attribute to be matched. If you need to check more at-
tributes, i.e. memory or architectures, you can add more attributes in the rule resource
as shown in the next example.
Example 6.2 Simple Rules File
The following example illustrates howthe rules fle is used to retrieve the confguration
for a client with known hardware.
<!DOCTYPE autoinstall>
<autoinstall xmlns="http://www.suse.com/1.0/yast2ns"
<rule>
<disksize>
<match>/dev/hdc 1000</match>
</disksize>
<memsize>
<match>1000</match>
</memsize>
<result>
</result>
</rule>
<rule>
<disksize>
</disksize>
<memsize>
<match>256</match>
</memsize>
<result>
</result>
</rule>
</rules>
</autoinstall>
126 AutoYaST
The rules directory must be located in the same directory specifed via the autoyast
keyword at boot time. If the client was booted using autoyast=http://10.10.0.1/profles/,
AutoYaST will search for the rules fle in http://10.10.0.1/profles/rules/rules.xml.
6.1.2 Custom Rules
If the attributes AutoYaST provides for rules are not enough for your purposes, use
custom rules. Custom rules are more or less a shell script you have to write. Its output
to STDOUTspecifes which AutoYaSTprofle should be used. STDERRwill be ignored.
Here is an example for the use of custom rules:
<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>
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 flled between the two '@' characters, to determine the flename of the
profle to fetch. AutoYaST will read the output and fetch a fle with the name "intel.xml"
or "non_intel.xml". This fle can contain the AutoYaST profle 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 fve. So you can use custom1 to custom5.
6.1.3 Match Types for Rules
You can use fve different match_types:
exact (default),
greater,
lower,
range,
regex (available since 10.1 and SLES10), a simple "=~" operator like in bash.
"greater" and "lower" can be used for memsize or totaldisk for example. They can match
only with rules that return an integer value. 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 match substrings like "ntel" will match "Intel", "intel" and "intelligent".
6.1.4 Combine Attributes
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 exactly 512MB.
You can do this with the "operator" element in the rules.xml fle. Here is an example:
<rule>
<disksize>
</disksize>
<memsize>
<match>256</match>
</memsize>
<result>
</result>
<operator>or</operator>
</rule>
Just "and" and "or" are possible operators and the default operator is "and".
6.1.5 Rules File Structure
The rules.xml fle must:
128 AutoYaST
have at least one rule,
have the name rules.xml,

be located in the directory rules in the profle repository,
and have at least one attribute to match in the rule.
6.1.6 Predefned System Attributes
The following table lists the predefned system attributes you can match in the rules
fle.
If you are unsure about a value on your system, start an auto-installation with "confrm"
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.
Table 6.1 System Attributes
This attribute must always
match exactly.
IP address of the host hostaddress
match exactly.
The name of the host hostname
match exactly.
Domain name of host domain
match exactly.
The name of the product to be
installed.
installed_prod-
uct
match exactly.
The version of the product to be
installed.
installed_prod-
uct_version
match exactly.
network address of host network
match exactly. (MACaddresses
MAC address of host mac
should have the form
0080c8f6484c
This attribute can be 0 or more. Number of installed Linux parti-
tions on the system
linux
This attribute can be 0 or more. Number of installed non-Linux
partitions on the system
others
match exactly.
X Server needed for graphic
adapter
xserver
All match types are available. Memory available on host in
MByes
memsize
All match types are available. Total disk space available on
host in MBytes
totaldisk
Exact match required, 1 for
available PCMCIA or 0 for
none.
System has PCMCIA (i.e Lap-
tops)
haspcmica
Exact match required Hex representation of IP address hostid
Exact match required Architecture of host arch
Exact match required Kernel Architecture of host (i.e.
SMP kernel, Athlon Kernel)
karch
All match types are available. Drive device and size disksize
Exact match required The hardware product name as
specifed in SMBIOS
product
130 AutoYaST
Exact match required The hardware vendor as speci-
fed in SMBIOS
product_vendor
Exact match required The systemboard name as spec-
ifed in SMBIOS
board
Exact match required The system board vendor as
specifed in SMBIOS
board_vendor
All match types are available. Custom rules using shell scripts custom1-5
6.1.7 Rules with Dialogs
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 confg:type="list"><rule><dialog>
... </dialog></rule></rules> tags in the rules.xml fle.
Description Values At-
tribute
This element is optional and
the default for a missing dia-
All rules with the same dialog_nr are pre-
sented in the same popup dialog. The same
dialog_nr can appear in multiple rules.
dia-
log_nr
log_nr is always "0". If want
<dialog_nr
config:type="integer">3</dialog_nr>
to use one popup for all
rules, you don't need to
specify the dialog_nr.
Optional. If left out, Auto-
YaSTadds his own ids inter-
Each element needs a unique id. Even if
you have more than one dialog, you must
element
nally. Then you cannot not use the same id twice like an id "1" on
specify conficting rules (see
below).
dialog 1 and and id "1" on dialog 2. That's
different than with <ask> dialogs, where
Description Values At-
tribute
you can have the same <element> id on
multiple dialogs.
<element
config:type="integer">3</element>
Optional Caption of the popup dialog title
<title>Desktop Selection</title>
Optional. If you don't confg-
ure a text here, the name of
Question shown in the popup behind the
checkbox.
question
the XML fle that is trig-
<question>KDE Desktop</question>
gered by this rule will be
shown instead.
Optional. Amissing timeout
will stop the installation
Timeout in seconds after which the dialog
will automatically "press" the okay button.
timeout
process until the dialog is
confrmed by the user.
Useful for a non-blocking installation in
combination with rules dialogs.
<timeout
config:type="integer">30</timeout>
optional A list of element ids (rules) that confict
with this rule. If this rule matches or is se-
con-
ficts
lected by the user, all conficting rules are
deselected and disabled in the popup. Take
care that you do not create deadlocks.
<conflicts config:type="list">
<element
<element
...
</conflicts>
Here is an example of how to use dialogs with rules:
132 AutoYaST
<rule>
<custom1>
<script>
echo -n 100
</script>
<match>100</match>
</custom1>
<result>
<profile>rules/kde.xml</profile>
</result>
<dialog>
<question>KDE Desktop</question>
<title>Desktop Selection</title>
</conflicts>
<dialog_nr config:type="integer">0</dialog_nr>
</dialog>
</rule>
<rule>
<custom1>
<script>
echo -n 100
</script>
<match>101</match>
</custom1>
<result>
<profile>rules/gnome.xml</profile>
</result>
<dialog>
<dialog_nr config:type="integer">0</dialog_nr>
<question>Gnome Desktop</question>
</conflicts>
</dialog>
</rule>
<rule>
<custom1>
<script>
echo -n 100
</script>
<match>100</match>
</custom1>
<result>
<profile>rules/all_the_rest.xml</profile>
</result>
</rule>
</rules>
6.2 Classes
Classes represent confgurations for groups of target systems. Unlike rules, classes have
to be confgured in the control fle. Then classes can be assigned to target systems.
Here is an example of a class defnition:
<classes config:type="list">
<class>
<class_name>TrainingRoom</class_name>
<configuration>Software.xml</configuration>
</class>
</classes>
The fle Software.xml must be in the directory "classes/TrainingRoom/" then. It will
get fetched from the same place the AutoYaST profle and rules were fetched from.
If you have multiple profles and those profles share parts, better use classes for common
parts. You can also use XIncludes.
Using the confguration management system, you can defne a set of classes. A class
defnition consists of the following variables:
Name: class name
Descriptions: class description
Order: order (or priority) of the class in the stack of migration
134 AutoYaST
Figure 6.2 Defning 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 confguration systemconcise. For example,
the following sets of classes can be used:
site: classes describing a physical location or site,
machine: classes describing a type of machine,
role: classes describing the function of the machine,
group: classes describing a department or a group within a site or a location.
Afle saved in a class directory can have the same syntax and format as a regular control
fle but represents a subset of the confguration. For example, to create a new control
fle for a special computer with a specifc network interface, only the control fle resource
which controls the confguration of the network is needed. Having multiple network
types, you can merge the one needed for a special type of hardware with other class
fles and create a new control fle which suits the system being installed.
6.3 Mixing Rules and Classes
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 defnitions in them. The
process is described in the fgure Figure A.1, Rules Retrieval Process (page 154).
After retrieving the rules and merging them, the generated control fle is parsed and
checked for class defnitions. If classes are defned, then the class fles are retrieved
from the original repository and a new merge process is initiated.
6.4 The Merging of Rules and Classes
With classes and with rules, multiple XML fles get merged into one resulting XML
fle. This process of merging is often confusing for people, because it behaves different
than one would expect.
For example, the following two XML parts should be merged:
<drive>
<partition>
<mount>swap</mount>
<size>2000mb</size>
</partition>
<partition>
<filesystem config:type="symbol">xfs</filesystem>
<size>4Gb</size>
<mount>/data</mount>
</partition>
</partitions>
</drive>
</partitioning>
<drive>
<initialize config:type="boolean">false</initialize>
<partition>
<filesystem config:type="symbol">xfs</filesystem>
136 AutoYaST
<mount>/</mount>
<size>max</size>
</partition>
</partitions>
<use>all</use>
</drive>
</partitioning>
You might expect the profle to contain 3 partitions. This is not the case. You'll end up
with two partitions and the frst partition is a mixup of the swap and the root partition.
Settings confgured in both partitions, like mount or size, will be used from the second
fle. Settings that only exist in the frst 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 defned.
NOTE: 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 offcially supported by AutoYaST. For each partition in
one fle, 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 fles, you may need to add more attributes like dont-
merge="2", etc.
NOTE: 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 fle:
<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>
</dont_merge>
</result>
<board_vendor>
<match>PowerEdge [12]850</match>
<match_type>regex</match_type>
</board_vendor>
<result>
<profile>classes/smallswap.xml</profile>
</dont_merge>
</result>
</rule>
138 AutoYaST
7 The Auto-Installation Process
7.1 Introduction
After the system has booted into an automatic installation and the control fle has been
retrieved, YaST confgures the system according to the information provided in the
control fle. All confguration settings are summarized in a window that is shown by
default and should be deactivated if a fully automatic installation is needed.
By the time YaST displays the summary of the confguration, YaST has only probed
hardware and prepared the system for auto-installation. Nothing has been changed in
the system yet. In case of any error, you can still abort the process.
A system should be automatically installable without the need to have any graphic
adaptor or monitor. Having a monitor attached to the client machine is nevertheless
recommended so you can supervise the process and to get feedback in case of errors.
Choose between the graphical (Qt or GTK) and the text-based Ncurses interfaces. For
headless clients, system messages can be monitored using the serial console.
7.1.1 X11 Interface (graphical)
This is the default interface while auto-installing. No special variables are required to
activate it.
The Auto-Installation Process 139
7.1.2 Serial console
Start installing a system using the serial console by adding the keyword "console" (i.e.
console=ttyS0) to the command line of the kernel. This starts linuxrc in console mode
and later YaST in serial console mode.
7.1.3 Text-based YaST Installation
This option can also be activated on the command line. This will start YaST2 in
Ncurses mode. To start YaST in text mode, add textmode=1 on the command line.
Starting YaST in text mode is recommended when installing a client with less than 64
MB or when X11 is not being confgured at all, especially on headless machines.
7.2 Choosing the Right Boot Medium
There are different methods for booting the client. The computer can boot from its
network interface card (NIC) to receive the boot images via DHCP or TFTP. Alterna-
tively a suitable kernel and initrd image can be loaded from a foppy or a bootable CD-
ROM.
7.2.1 Booting from a foppy
For testing/rescue purposes or because the NIC does not have a PROM or PXE you
can build a boot foppy to use with AutoYaST. Using a foppy to initiate an auto-install
process is limited due to the size of the data a foppy can hold. However, it is still pos-
sible to use foppies when auto-installing a single, disconnected machine.
Floppies can also store the control fle, especially when using the original SuSE CD-
ROMs for a single, disconnected machine. Via the kernel command line, you can
specify the location of the control fle on the foppy.
Even without specifying any command line options, it is still possible to initiate the
auto-install process by placing a control fle on a foppy with the pre-defned fle name
autoinst.xml. YaST will check for autoinst.xml upon startup and if it was
found it will switch from interactive to automated installation.
140 AutoYaST
7.2.2 Booting from CD-ROM
You can use the original SuSECD-ROMs in combination with other media. For example,
the control fle can be provided via a foppy or a specifed location on the network.
Alternatively, create a customized CD-ROM that holds only the package you need and
the control fle. If you need to change the confguration, you'll have to create a new
CD-ROM.
7.2.3 Booting via PXE over the network
Booting via PXE requires a DHCP and a TFTP server in your network. The computer
will boot then without a physical media like a boot foppy or CDROM.
Here is an example of a /srv/tftp/pxelinux.cfg/default fle:
default SLES9
# install SLES9
label SLES9
kernel linux_sles9
append initrd=initrd_sles9 vga=0x0314 install=.... autoyast=...
language=de_DE
# boot harddisc
label hd
LOCALBOOT 0
We recommended you add the vga=... parameter with a valid value for graphical instal-
lations, to trigger an installation with the frame buffer device instead of the vesa driver
or ncurses mode.
Here is as an example of a /etc/dhcp.conf fle:
option domain-name-servers 192.168.66.1;
default-lease-time 600;
max-lease-time 7200;
ddns-update-style none; ddns-updates off;
log-facility local7;
option grub-menufile code 150 = text;
option grub-menufile "(nd)/menu.lst";
subnet 192.168.66.0 netmask 255.255.255.0 {
range 192.168.66.100 192.168.66.200;
# PXE related stuff ...
#
# "next-server" defines the tftp server which will
# serve the pxelinux image to the PXE clients.
next-server 192.168.66.1;
allow booting;
allow bootp;
option routers 192.168.66.1; # default gateway
#
# "filename" specifies the pxelinux image on the tftp server
# which will be served to the PXE clients.
# The configured tftp server on 192.168.100.1 runs in a
# "change-root jail" to /srv/tftpboot
filename "pxelinux.0";
}
A problem you might run into if you do installation via PXE is that the installation will
run into an endless loop, because after the frst reboot, the machine is doing PXE boot
again and restarts the installation instead of booting from hard disk for the second stage
of the installation.
This problemcan be solved in different ways. One way is to use an http server to provide
the AutoYaST profle. And, instead of a static profle, run a CGI script on the web
server that provides the profle and changes the TFTP server confguration for your
target host. Then the next PXE boot of the machine will be from hard disk by default.
Another way is to use AutoYaST to upload a new PXE boot confguration for the target
host via the profle:
<pxe>
<pxe_localboot config:type="boolean">true</pxe_localboot>
<pxelinux-config>
DEFAULT linux
LABEL linux
localboot 0
</pxelinux-config>
<tftp-server>192.168.66.1</tftp-server>
<pxelinux-dir>/pxelinux.cfg</pxelinux-dir>
<filename>__MAC__</filename> 
</pxe>
This entry will upload a new confguration for the target host to the tftp server shortly
before the frst reboot happens. In most installations the TFTP daemon runs as user
"nobody". You have to make sure this user has write permissions to the pxelinux
.cfg directory. So if your machine has the IP address "192.168.66.195", a fle
142 AutoYaST
C0A842C3 will be uploaded. When the machine reboots and receives the same IP ad-
dress via DHCP, the newconfguration will be used, telling the target host to book from
hard disk.
If you want to do another auto-installation on the same machine, you have to remove
the fle from the TFTP server.
Since openSUSE 11.2 (not SLES11), you can also confgure the flename that will be
uploaded. If you use the "magic" __MAC__ flename, the flename will be the mac
address of your machine like this "01-08-00-27-79-49-ee". If the flename setting is
missing, the IP address will be used for the flename.
7.3 Invoking the Auto-Installation
Process
7.3.1 Command Line Options
Adding the command line variable autoyast causes linuxrc to start in automated mode.
linuxrc searches for a confguration fle, which should be distinguished from the
main control fle in the following places:
in the root directory of the initial RAM disk used for booting the system,
in the root directory of the foppy.
The confguration fle used by linuxrccan have the following keywords (for a detailed
description of how linuxrc works and other keywords, see Appendix B, Advanced
Linuxrc Options (page 155) ):
Table 7.1 Keywords for linuxrc
Value Keyword
Network device to use for network setup (for BOOTP and
DHCP requests)
netdevice
Value Keyword
Server (NFS) to contact for source directory server
Directory on NFS Server serverdir
When empty, client sends BOOTP request, otherwise client
is confgured with entered IP confguration.
hostip
Netmask netmask
Gateway gateway
Nameserver nameserver
Kernel modules to load insmod
Location of the the control fle for automatic installation,
i.e. autoyast=http://192.168.2.1/profles/
autoyast
Location of the installation directory, i.e. in-
stall=nfs://192.168.2.1/CDs/
install
Installation mode, i.e. nfs, http etc. (not needed if install is
set)
instmode
Even with <confrm>no</confrm> in the profle, the con-
frm proposal comes up (available since SUSE Linux
10.1/SLES10).
y2confrm
These variables and keywords will bring the system up to the point where YaST can
take over with the main control fle. Currently, the source medium is automatically
discovered, which in some cases makes it possible to initiate the auto-install process
without giving any instructions to linuxrc.
The traditional linuxrc confguration fle (info) has the function of giving the client
enough information about the installation server and the location of the sources. In most
cases, this fle is not needed; it is however needed in special network environments
144 AutoYaST
where DHCP and BOOTP are not used or when special kernel modules have to be
loaded.
All linuxrc keywords can be passed to linuxrc using the kernel command line. The
command line can also be set when creating network bootable images or it can be passed
to the kernel using a specially confgured DHCP server in combination with Etherboot
or PXE.
The command line variable autoyast can be used in the format described in table Ta-
ble 7.2, Command Line Variables for AutoYaST (page 145)
Table 7.2 Command Line Variables for AutoYaST
Description Command line variable
Default auto-installation option. autoyast=default
Looks for control fle in specifed path (relative
to source root directory, i.e. fle:///autoinst.xml if
autoyast=fle://<path>
in the top directory of a CD-ROM and you did an
installation from CD).
Looks for control fle on a storage device (only
device name needed without full path, i.e.
autoyast=device://<de-
vice>/<fle>
/dev/sda1 is wrong, use only sda1 instead). Since
openSUSE 11.2 (not SLES11) you can omit
specifying the device and trigger AutoYaST to
search all devices (autoyast=device:///my.xml).
Looks for control fle on a foppy (useful when
booting from CD). Since SLES10 SP1 and later
the fallback is looking on USB devices.
autoyast=foppy://<path>
Looks for control fle on <server> autoyast=nfs://<server>/<path>
Retrieves the control fle from a web server using
the HTTP protocol.
autoyast=http://[user:pass-
word@]<server>/<path>
Description Command line variable
Retrieves the control fle from a web server using
HTTPS (encrypted connection) protocol (possible
since SL 10.1 and SLES10).
autoyast=https://[user:pass-
Retrieve the control fle via TFTP. autoyast=tftp://<server>/<path>
Retrieve the control fle via FTP. autoyast=ftp://[user:pass-
Retrieve the control fle from USB devices
(AutoYaST will search all connected USB de-
vices).
autoyast=usb://<path> (since
SLES10 SP1)
Retrieve the control fle from the installation
source (install=....).
autoyast=relurl://<path> (since
openSUSE 11.0)
Query the location of the profle from an SLP
server (service:autoyast:...). Since openSUSE11.3
autoyast=slp (since openSUSE
11.2, not SLES 11)
you can add a "description=" attribute so you can
"translate" the URLinto something more readable.
Looks for control fle on <server> with CIFS autoyast=cifs://<server>/<path>
(since openSUSE11.2, not SLES
11)
Searches for control fle on a device with the
specifed label
autoyast=label://<label>/<path>
(since openSUSE11.3, not SLES
11)
Several scenarios for auto-installation are possible using different types of infrastructure
and source media. The simplest way is to use the source media from SuSE. In that case
you have either a DVD with all SuSE packages or a set of CD-ROMs. To initiate the
auto-installation process however, the auto-installation command line variable should
be entered at system boot-up and the control fle should be accessible to YaST. The
following list of scenarios explains how the control fle can be supplied as well as the
setup needed for the auto-installation process to succeed.
146 AutoYaST
Using original CD-ROMs from SuSE:
To use the original CD-ROMs, you need a media with the control fle. The control
fle can reside in the following locations:
1. Floppy: Control fle accessible via the autoyast=foppy option. YaST also searches
upon startup for a fle named autoinst.xml. If such a fle is found, YaST2
will switch into auto-installation mode even if no special command line variables
were supplied. (See Section 7.3.2, Auto-installing a Single System (page 149).)
2. Network: Control fle accessible via the autoyast=nfs://.., autoyast=ftp://.., auto-
yast=http://.. or autoyast=tftp://.. options.
Using 'self-made' CD-ROMs:
In this case, you can include the control fle on the CD-ROM for easy access (using
the autoyast=fle:// option) or use one of the above mentioned methods used with
the original SuSE CD-ROMs.
When using CD-ROMs for auto-installation, it is necessary to instruct the installer
to use the CD-ROM for installation and not try to fnd the installation fles on the
network. This can be accomplished by adding the instmode=cd option to the kernel
command line (this can be done by adding the option to the isolinux.cfg fle on the
CD).
Using NFS and Floppy, Network or CD-ROM for system boot-up.
This option is the most important one due to the fact that installations of PC farms
are normally done using NFS servers and other network services like BOOTP and
DHCP. The control fle can reside in the following places:
1. Floppy/CD-ROM: Control fle accessible via the autoyast=fle://.. option.
2. Network: Control fle accessible via the autoyast=http://.., autoyast=ftp://.., auto-
yast=nfs://.. or autoyast=tftp://.. options.
NOTE: Disabling Network and DHCP
To disable the network during installations where it is not needed or unavailable,
for example when auto-installing from CD-ROMs, use the linuxrc option netsetup
to set the network confguration behavior. To disable network setup use net-
setup=0.
If autoyast=default is defned, YaST will look for a fle named autoinst.xml in
the following three places:
1. the root directory of the foppy disk,
2. the root directory of the installation medium,
3. the root directory of the initial RAM disk used to boot the system.
With all AutoYaST invocation options, excluding default, it is possible to specify the
location of the control fle in the following ways:
1. Specify the exact location of the control fle:
autoyast=http://192.168.1.1/control-files/client01.xml
2. Specify a directory where several control fles are located:
autoyast=http://192.168.1.1/control-files/
In this case the relevant control fle is retrieved using the hex digit representation of
the IP as described below.
If only the path prefx variable is defned, YaST will fetch the control fle from the
specifed location in the following way:
1. First, it will search for the control fle using its own IP address in upper case hexadec-
imal, e.g. 192.0.2.91 -> C000025B.
2. If this fle is not found, YaST will remove one hex digit and try again. This action
is repeated until the fle with the correct name is found. Ultimately, it will try looking
for a fle with the MAC address of the client as the fle name (mac should have the
following syntax: 0080C8F6484C) and if not found a fle named default (in
lower case).
As an example, for 192.0.2.91, the HTTP client will try:
C000025B
C000025
C00002
148 AutoYaST
C0000
C000
C00
C0
C
0080C8F6484C
default
in that order.
To determine the hex representation of the IP address of the client, use the utility called
/usr/sbin/gethostip available with the syslinux package.
Example 7.1 Determine HEX code for an IP address
# /usr/sbin/gethostip 10.10.0.1
10.10.0.1 10.10.0.1 0A0A0001
7.3.2 Auto-installing a Single System
The easiest way to auto-install a system without any network connection is to use the
original SuSE CD-ROMs and a foppy disk. You do o need to set up an installation
server nor the network environment.
Create the control fle and name it autoinst.xml. Copy the fle autoinst.xml
to a foppy by either mounting the foppy or by using the mtools.
mcopy autoinst.xml a:
7.3.3 Combining linuxrc info fle with YaST
control fle
If you choose to pass information to linuxrc using the info fle, it is possible to integrate
the keywords in the XML control fle. In this case the fle has to be accessible to linuxrc
and has to be named info.
Linuxrc will look for a string (start_linuxrc_conf in the control fle which represents
the beginning of the fle. If it is found, it will parse the content starting from that string
and will fnish when the string end_linuxrc_conf is found. The options are stored in the
control fle in the following way:
Example 7.2 Linxurc options in the control fle
....
<install>
....
<init>
<info_file>
<![CDATA[
#
# Don't remove the following line:
# start_linuxrc_conf
#
install: nfs://192.168.1.1/CDs/full-i386
textmode: 1
autoyast: file:///info
# end_linuxrc_conf
# Do not remove the above comment
#
]]>
</info_file>
</init>
......
</install>
....
Note that the "autoyast" keyword must point to the same fle. If it is on a foppy, then
the protocol foppy has to be used. If the info fle is stored in the initial RAM disk, the
fle option has to be used.
7.4 System Confguration
The system confguration during auto-installation is the most important part of the
whole process. Customizing a systemaccording to your environment and needs is what
makes an auto-installation system attractive, not the installation part.
As you have seen in the previous chapters, almost anything can be confgured automat-
ically on the target system. In addition to the pre-defned directives, you can always
use post-scripts to change other things in the system. Additionally you can change any
system variables, and if required, copy complete confguration fles into the target
system.
150 AutoYaST
7.4.1 Post-Install and System Confguration
The post-installation and systemconfguration are initiated directly after the last package
is installed on the target system and continue after the system has booted for the frst
time.
Before the systemis booted for the frst time, AutoYaST writes all data collected during
installation and writes the boot loader in the specifed location. In addition to these
regular tasks, AutoYaST executes the chroot-scripts as specifed in the control fle.
Note that these scripts are executed while the system is not yet mounted.
If a different kernel than the default is installed, a hard reboot will be required. A hard
reboot can also be forced during auto-installation, independent of the installed kernel.
Use the reboot property of the general resource (see General Options).
7.4.2 System Customization
Most of the system customization is done in the second stage of the installation. If you
require customizations that cannot be done using AutoYaST resources, use post-install
scripts for further modifcations.
You can defne an unlimited number of custom scripts in the control fle, either by
editing the control fle or by using the confguration system.
A Handling Rules
The following fgure illustrates how rules are handled and the processes of retrieval
and merge.
Figure A.1 Rules Retrieval Process
154 AutoYaST
B Advanced Linuxrc Options
Linuxrc is a program used for setting up the kernel for installation purposes. It allows
the user to load modules, start an installed system, a rescue system or an installation
via YaST.
Linuxrc is designed to be as small as possible. Therefore, all needed programs are linked
directly into one binary. So there is no need for shared libraries in the initdisk.
NOTE
If you run Linuxrc on an installed system, it will work slightly differently so as
not to destroy your installation. As a consequence you cannot test all features
this way.
B.1 Passing parameters to Linuxrc
Unless Linuxrc is in manual mode, it will look for an info fle in these locations: frst
/info on the foppy disk and if that does not exist, for /info in the initrd. After that
it parses the kernel command line for parameters. You may change the info fle Linuxrc
reads by setting the info command line parameter. If you do not want Linuxrc to read
the kernel command line (e.g. because you need to specify a kernel parameter that
Linuxrc recognizes as well), use linuxrc=nocmdline.
NOTE: Change since SUSE Linux 10.2
The info fle is no longer implicitly read. You have to make it explicit, like
'info=foppy:/info'.
Linuxrc will always look for and parse a fle /linuxrc.config. Use this fle to
change default values if you need to. In general, it is better to use the info fle instead.
Note that /linuxrc.config is read before any info fle, even in manual mode.
B.2 info fle format
Lines starting with '#' are comments, valid entries are of the form:
key: value
Note that value extends to the end of the line and therefore may contain spaces. key is
matched case insensitive.
You can use the same key-value pairs on the kernel command line using the syntax
key=value. Lines that do not have the form described above are ignored.
The table below lists Valid keys. The given values are only examples.
Table B.1 Advanced linuxrc keywords
Description Keyword/Value
set the language Language: de_DE
load this keytable Keytable: de-lat1-nd
set the menu color scheme Display: Color|Mono|Alt
install via NFS from server (note: you can give
username, password etc. in the URL, too)
Install: nfs://server/install/8.0-i386
set installation mode InstMode:
cd|hd|nfs|smb|ftp|http|tftp
156 AutoYaST
the client ip address HostIP: 10.10.0.2
network mask Netmask: 255.255.0.0
gateway Gateway: 10.10.0.1
installation server address Server: 10.10.0.1
nameserver Nameserver: 10.10.0.1
proxy (either ftp or http) Proxy: 10.10.0.1
proxy port ProxyPort: 10.10.0.1
partition with install sources for hard disk install Partition: hda1
base directory of the installation sources Serverdir: /install/8.0-i386
network interface to use Netdevice: eth0
sleep 5 seconds between network activation and
starting bootp
BOOTPWait: 5
10 seconds timeout for BOOTP requests BOOTPTimeout: 10
60 seconds timeout for DHCP requests DHCPTimeout: 60
10 seconds timeout for TFTP connection TFTPTimeout: 10
load the installation system into RAM disk ForceRootimage: 0|1
start YaST in text mode Textmode: 0|1
set user name (e.g. for FTP install) Username: name
set password (e.g. for FTP install) Password: password
Advanced Linuxrc Options 157
set work domain for SMB install WorkDomain: domain
use '-f' option when running insmod ForceInsmod: 0|1
start DHCP daemon now, but see UseDHCP DHCP: 0|1
use DHCP instead of BOOTP (DHCP is default) UseDHCP: 0|1
ask for swap if free memory drops below 10000
kB
MemLimit: 10000
run YaST in text mode if free memory is below
20000 kB
MemYaST: 20000
ask for swap before starting YaSTif free memory
is below 10000 kB
MemYaSTText: 10000
delete all modules before starting YaST if free
memory is below 20000 kB
MemModules: 20000
load installation system into ramdisk if free
memory is above 50000 kB
MemLoadImage: 50000
start Linuxrc in manual mode Manual: 0|1
do not start card manager NoPCMCIA: 0|1
set domain name (used for name server lookups) Domain: zap.de
installation system image RootImage: /suse/images/root
rescue system image RescueImage: /suse/images/rescue
installation system InstallDir: /suse/inst-sys
load rescue system; the URL variant specifes
the location of the rescue image explicitly
Rescue: 1|nfs://server/dir
158 AutoYaST
location of autoinstall fle; activates autoinstall
mode
AutoYaST: ftp://autoyastfle
setup VNC server VNC: 0|1
sets VNC server password VNCPassword: password
setup SSH server UseSSH: 0|1
sets SSH server password (this will not be the
fnal root password!)
SSHPassword: password
if 0, never ask for swap; if the argument is a
positive number n, activate the n'th swap parti-
AddSwap: 0|3|/dev/hda5
tion; if the argument is a partition name, activate
this swap partition
run command Exec: command
wait 4 seconds after loading USB modules USBWait: 4
load this module Insmod: module params
Enable remove logging via syslog Loghost: 10.10.0.22
overrides the confrm parameter in a profle and
requests confrmation of installation proposal
(available since SUSE Linux 10.1/SLES10)
y2confrm
B.3 Advanced Network Setup
The netsetup keyword allows advanced network confgurations and enables dialogs to
setup the network where required.
netsetup=1
Advanced Linuxrc Options 159
the normal network setup questions
netsetup=xxx,yyy
only xxx and yyy
netsetup=+xxx,-yyy
default, additionally xxx, but not yyy
netsetup can have the following values: dhcp, hostip, gateway, netmask, nameserver.
nameserverN asks for N nameservers (max. 4).
For example, the following can be entered on the command line:
netsetup=-dhcp,+nameserver3
160 AutoYaST

Understanding Autoyast in SUSE

Uploaded by

Copyright:

Available Formats

Understanding Autoyast in SUSE

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Understanding Autoyast in SUSE

Uploaded by

Copyright:

Available Formats

What is the control file and what is its purpose?

What are some ways to create a control file?

SUSE Linux Enterprise

file to save to the local disk,

ftp to save to an FTP server (without encryption),

sftp to save to an SSH2 SFTP server,

nfs to save to a NFS location and

have the name rules.xml,

You might also like