This chapter introduces important parts of a control file for standard purposes. To learn about other available options, use the configuration management system.
Note that for some of the configuration options to work, additional packages have to be installed, depending on the software selection you have configured. If you choose to install a minimal system 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 configuration steps will be skipped. For example, no security
settings will be configured if
yast2-security
is not
installed.
General options include all the settings related to the installation process and the environment of the installed system.
The mode section configures the behavior of AutoYaST with regard to confirmation and rebooting. The following has to be in the <general><mode> section.
By default, the user must confirm 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.
confirm
is set to true
by default
to avoid recursive installs when the system schedules a reboot after
initial system setup. Only disable confirmation 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 boot loader is alreay installed and
all your chroot scripts have run.
final_halt
and final_reboot
halts
or reboots the machine after the installation and the configuration are
finished at the end of stage 2.
max_systemd_wait
specifies how long AutoYaST waits at
most for systemd to set up the default target. Normally you do not need
to bother with this entry. If it is not preset a reasonable default (30
seconds) is used.
Attribute |
Values |
Description |
---|---|---|
confirm |
If this boolean is set to <confirm config:type="boolean">true</confirm> |
Optional. The default is true. |
halt |
Shuts down the machine after the first stage. So if you turn it on again, the machine boots and the second stage of the autoinstallation starts. <halt config:type="boolean">true</halt> |
Optional. The default is false. |
second_stage |
This boolean determines if AutoYaST will run in the second stage too
(after the partitioning, software and bootloader installation of
the first stage). If you set this to <second_stage config:type="boolean">true</second_stage> |
Optional. The default is true. |
final_reboot |
If you set this to <final_reboot config:type="boolean">true</final_reboot> |
Optional. The default is false. It makes no sense to set this and
|
final_halt |
If you set this to <final_halt config:type="boolean">true</final_halt> |
Optional. The default is |
AutoYaST allows you to configure the proposal screen with the <proposals
config:type="list"> option in the control file. All proposals that
are listed in that section are shown in the proposal screen if you set
the confirm
option to true
.
Proposals are also used during the regular installation and can be found
in the file control.xml
in the root directory of
the installation media.
<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> <final_reboot config:type="boolean">false</final_reboot> <final_halt config:type="boolean">false</final_halt> <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> <feedback config:type="boolean">true</feedback> </sleep> <script> <source>sleep 7</source> <debug config:type="boolean">false</debug> </script> </module> </post-modules> </wait> <storage> <!-- partition_alignment: align_optimal - That's the default. Partitions are aligned like the kernel suggests. This can lead to problem with some machines/bioses that are unable to boot with that alignment align_cylinder - Partitions always start on a cylinder boundary --> <partition_alignment config:type="symbol">align_cylinder</partition_alignment> </storage> </general>
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 configuration starts and 10 seconds
(3+7) after the network configuration is done. The scripts in the
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.
When installing on a network storage that is accessed via multiple
paths, you need to enable multipath for the installation with the
start_multipath
parameter that needs to be placed
within the following XML structure:
<general> <storage> <start_multipath config:type="boolean">true</start_multipath> </storage> </general>
Alternatively, you can pass the following parameter to linuxrc:
LIBSTORAGE_MULTIPATH_AUTOSTART=ON
The report
resource manages three types of pop-ups
that may appear during installation:
message pop-ups (usually non-critical, informative messages),
warning pop-ups (if something might go wrong),
error pop-ups (in case an error occurs).
<report> <messages> <show config:type="boolean">true</show> <timeout config:type="integer">10</timeout> <log config:type="boolean">true</log> </messages> <errors> <show config:type="boolean">true</show> <timeout config:type="integer">10</timeout> <log config:type="boolean">true</log> </errors> <warnings> <show config:type="boolean">true</show> <timeout config:type="integer">10</timeout> <log config:type="boolean">true</log> </warnings> </report>
Depending on your experience, you can skip, log and show (with timeout)
those messages. 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.
Note that not all messages during installation are controlled by the
report
resource. Some critical messages concerning
package installation and partitioning will show up ignoring your
settings in the report
section. In most cases those
messages will have to be answered with or
.
Registering the system with the can be configured within the
suse_register
resource. The following example
registers the system with the SUSE Customer Center. In case your organization provides
its own registration server, you need to specify the required data with
the reg_server*
properties. Refer to the table below
for details.
<suse_register> <do_registration config:type="boolean">true</do_registration> <email>tux@example.com</email> <reg_code>MY_SECRET_REGCODE</reg_code> <install_updates config:type="boolean">true</install_updates> <slp_discovery config:type="boolean">false</slp_discovery> </suse_register>
As an alternative to the fully automated registration, AutoYaST can also be configured to start the YaST registration module during the installation. this offers the possibility to enter the registration data manually. The following XML code is required:
<general> <semi-automatic config:type="list"> <semi-automatic_entry>scc</semi-automatic_entry> </semi-automatic> </general>
In case you need to use the same network settings that were used for the installation, AutoYaST needs to run the network setup in stage 1 right before the registration is started:
<networking> <setup_before_proposal config:type="boolean">true</setup_before_proposal </networking>
Element |
Description |
Comment |
---|---|---|
do_registration |
Specify whether the system should be registered or not. Can be set
to <do_registration config:type="boolean" >true</do_registration> |
If set to |
|
The e-mail address matching the registration code. <email>tux@example.com</email> |
Required value. |
reg_code |
The registration code. <reg_code>SECRET_REGCODE</reg_code> |
Required value. |
install_updates |
Defines if the update repositories provided by the registration
server are used during the installtion ( <install_updates config:type="boolean" >true</install_updates> |
Optional. The default value is |
slp_discovery |
Search for the registration server via SLP. <slp_discovery config:type="boolean" >true</slp_discovery> |
Optional. The default value is
Expects to find a single server. If more than one server is found,
the installation will fail. In case there is more than one
registration server available, you need to specify one with
Optional, If neither |
reg_server |
URl to the SMT server <reg_server> https://smt.example.com </reg_server> |
Optional, If neither |
reg_server_cert_fingerprint_type |
Fingerprint type. Can either be <reg_server_cert_fingerprint_type> SHA1 </reg_server_cert_fingerprint_type> |
Requires a checksum value provided with
|
reg_server_cert_fingerprint |
Fingerprint value in hexadecimal notion (case-insensitive). <reg_server_cert_fingerprint> 01:AB...:EF </reg_server_cert_fingerprint> |
Requires a fingerprint type value provided with
|
reg_server_cert |
Path to the SSL certificate on the server. <reg_server_cert> http://smt.example.com/smt.crt </reg_server_cert> |
Using this option is not recommended, since the certificate that is
downloaded is not verified. Use
|
addons |
Specify an extension from the registration server that should be added to the installation repositories. See Section 4.3.1, “Extensions” for details. |
The SUSE Customer Center provides a number of extensions, such as sle-sdk (Software
Development Kit - SDK) that can be added as additional installation
sources during the installation. Adding extensions can be configured
via the addons
property within the
suse_register
block. Below is a list of all
extensions available for SUSE Linux Enterprise on x86_64:
The availability of extensions is product and architecture dependent. All listed extensions are available for SUSE Linux Enterprise Server on the x86_64 architecture. Not all extensions are available on other architectures. The only extension available for SUSE Linux Enterprise Desktop is the sle-sdk.
Some extensions, such as the sle-we, sle-ha and sle-ha-geo require a registration code.
<addons config:type="list"> <addon> <arch>x86_64</arch> <name>sle-ha</name> <reg_code>YOUR_REG_CODE_HERE</reg_code> <release_type>nil</release_type> <version>12</version> </addon> <addon> <arch>x86_64</arch> <name>sle-ha-geo</name> <reg_code>YOUR_REG_CODE_HERE</reg_code> <release_type>nil</release_type> <version>12</version> </addon> <addon> <arch>x86_64</arch> <name>sle-module-web-scripting</name> <reg_code/> <release_type>nil</release_type> <version>12</version> </addon> <addon> <arch>x86_64</arch> <name>sle-module-adv-systems-management</name> <reg_code/> <release_type>nil</release_type> <version>12</version> </addon> <addon> <arch>x86_64</arch> <name>sle-module-legacy</name> <reg_code/> <release_type>nil</release_type> <version>12</version> </addon> <addon> <arch>x86_64</arch> <name>sle-we</name> <reg_code>YOUR_REG_CODE_HERE</reg_code> <release_type>nil</release_type> <version>12</version> </addon> <addon> <arch>x86_64</arch> <name>sle-sdk</name> <reg_code/> <release_type>nil</release_type> <version>12</version> </addon> <addon> <arch>x86_64</arch> <name>sle-module-public-cloud</name> <reg_code/> <release_type>nil</release_type> <version>12</version> </addon> </addons>
This documentation is for yast2-bootloader and applies to SLE
12. For older product versions, use the documentation that
comes with your distribution in
/usr/share/doc/packages/autoyast2/
The general structure of the AutoYaST boot loader part looks like the following:
<bootloader> <loader_type> <!-- boot loader type (grub2 or grub2-efi) --> </loader_type> <global> <!-- entries defining the installation settings for GRUB 2 and the generic boot code --> </global> <device_map config:type="list"> <!-- entries defining the order of devices --> </device_map> </bootloader>
Define which boot loader to use: grub2
or
grub2-efi
.
<loader_type>grub2</loader_type>
This is an important if optional part. Define here where to install GRUB 2 and how the boot process will work. Again, yast2-bootloader proposes a configuration if you don't define one. Usually the AutoYaST control file includes only this part and all other parts are added automatically during installation by yast2-bootloader. Unless you have some special requirements, do not specify the bootloader config in the XML file.
<global> <activate config:type="boolean">true</activate> <timeout config:type="integer">10</timeout> <suse_btrfs config:type="boolean">true</suse_btrfs> <terminal>gfxterm</terminal> <gfxmode>1280x1024x24</gfxmode> </global>
Attribute |
Description |
---|---|
activate |
Set the boot flag on the boot partition. The boot partition can be
<activate config:type="boolean">true</activate> |
append |
Kernel parameters added at the end of boot entries for normal and recovery mode. <append>nomodeset vga=0x317</append> |
boot_boot |
Write GRUB 2 to a separate /boot partition. If no separate /boot
partition exists, GRUB 2 will be written to
<boot_boot>false</boot_boot> |
boot_custom |
Write GRUB 2 to a custom device. <boot_custom>/dev/sda3</boot_custom> |
boot_extended |
Write GRUB 2 to the extended partition (important if you want to
use a generic boot code and the <boot_extended>false</boot_extended> |
boot_mbr |
Write GRUB 2 to MBR of the first disk in the order (device.map includes order of disks). <boot_mbr>false</boot_mbr> |
boot_root |
Write GRUB 2 to <boot_root>false</boot_root> |
generic_mbr |
Write generic boot code to MBR, will be ignored if boot_mbr is set
to <generic_mbr config:type="boolean">false</generic_mbr> |
gfxmode |
Graphical resolution of the GRUB 2 screen (requires
<terminal> to be set to <gfxmode>1280x1024x24</gfxmode> |
os_prober |
If set to <os_prober config:type="boolean">false</os_prober> |
suse_btrfs |
If set to <suse_Btrfs config:type="boolean">false</suse_btrfs> |
serial |
Command to execute if the GRUB 2 terminal mode is set to
<serial> serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1 </serials> |
terminal |
Specify the GRUB 2 terminal mode to use, Valid entries are
<terminal>serial</terminal> |
timeout |
The timeout in seconds until the default boot entry is booted automatically. <timeout config:type="integer">10</timeout> |
vgamode |
Adds the Kernel parameter
<vgamode>0x317</vgamode> |
xen-append |
Kernel parameters added at the end of boot entries for Xen guests. <append>nomodeset vga=0x317</append> |
xen-kernel-append |
Kernel parameters added at the end of boot entries for Xen kernels on the VM Host Server. <xen-append>dom0_mem=768M</xen-append> |
GRUB 2 avoids mapping problems between BIOS drives and Linux devices by using device ID strings (UUIDs) or file system labels when generating its configuration files. GRUB 2 utilities create a temporary device map on the fly, which is usually sufficient, particularly on single-disk systems. However, if you need to override the automatic device mapping mechanism, create your custom mapping in this section.
<device_map config:type="list"> <device_map_entry> <firmware>hd0</firmware> <!-- order of devices in target map --> <linux>/dev/disk/by-id/ata-ST3500418AS_6VM23FX0</linux> <!-- name of device (disk) --> </device_map_entry> </device_map>
The elements listed below must be placed within the following XML structure:
<profile> <partitioning config:type="list"> <drive> ... </drive> </partitioning> </profile>
Attribute |
Values |
Description |
---|---|---|
device |
The device you want to configure in this <drive> section.
You can use persistent device names via id, like
<device>/dev/sda</device> |
Optional. If left out, AutoYaST tries to guess the device. See Tip: Skipping Devices on how to influence guessing.
A RAID must always have |
initialize |
If set to <initialize config:type="boolean">true</initialize> |
Optional. The default is |
partitions |
A list of <partition> entries (see Section 4.5.2, “Partition Configuration”). <partitions config:type="list"> <partition>...</partition> ... </partitions> |
Optional. If no partitions are specified, AutoYaST will create a reasonable partitioning (see Section 4.5.4, “Automated Partitioning”). |
pesize |
This value only makes sense with LVM. <pesize>8M</pesize> |
Optional. Default is 4M for LVM volume groups. |
use |
Specifies the strategy AutoYaST will use to partition the hard disk. Choose between:
|
This parameter should be provided. |
type |
Specify the type of the Choose between:
<type config:type="symbol">CT_LVM</type> |
Optional. Default is CT_DISK for a normal physical hard disk. |
disklabel |
Describes the type of the partition table. Choose between:
<disklabel>gpt</disklabel> |
Optional. By default YaST decides what makes sense. |
keep_unknown_lv |
This value only makes sense for type=CT_LVM drives. If you are
reusing a logical volume group and you set this to
<keep_unknown_lv config:type="boolean" >false</keep_unknown_lv> |
Optional. The default is |
You can influence AutoYaST's device-guessing for cases where you don't specify a <device> entry on your own. Usually AutoYaST would use the first device it can find that looks reasonable but you can configure it to skip some devices like this:
<partitioning config:type="list"> <drive> <initialize config:type="boolean">true</initialize> <skip_list config:type="list"> <listentry> <!-- skip devices that use the usb-storage driver --> <skip_key>driver</skip_key> <skip_value>usb-storage</skip_value> </listentry> <listentry> <!-- skip devices that are smaller than 1GB --> <skip_key>size_k</skip_key> <skip_value>1048576</skip_value> <skip_if_less_than config:type="boolean">true</skip_if_less_than> </listentry> <listentry> <!-- skip devices that are larger than 100GB --> <skip_key>size_k</skip_key> <skip_value>104857600</skip_value> <skip_if_more_than config:type="boolean">true</skip_if_more_than> </listentry> </skip_list> </drive> </partitioning>
For a list of all possible <skip_key>, run yast2
ayast_probe
on an already installed system.
The elements listed below must be placed within the following XML structure:
<drive> <partitions config:type="list"> <partition> ... </partition> </partitions> </drive>
Attribute |
Values |
Description |
---|---|---|
create |
Specify if this partition must be created or if it already exists. <create config:type="boolean" >false</create> |
If set to |
mount |
The mountpoint of this partition. <mount>/</mount> <mount>swap</mount> |
You should have at least a root partition (/) and a swap partition. |
fstopt |
Mount options for this partition. <fstopt> ro,noatime,user,data=ordered,acl,user_xattr </fstopt> |
See |
label |
The label of the partition (useful for the
<label>mydata</label> |
See |
uuid |
The uuid of the partition (only useful for the
<uuid >1b4e28ba-2fa1-11d2-883f-b9a761bde3fb</uuid> |
See |
size |
The size of the partition, e.g. 4G, 4500M, etc. The /boot
partition and the swap partition can have You can also specify the the size in percentage. So 10% will use 10% of the size of the hard disk or volume group. You can mix auto, max, size, and percentage as you like. <size>10G</size> | |
format |
Specify if AutoYaST should format the partition. <format config:type="boolean">false</format> |
If you set |
filesystem |
Specify the filesystem to use on this partition:
<filesystem config:type="symbol" >ext3</filesystem> |
Optional. The default is |
mkfs_options |
Specifiy an option string that is added to the mkfs command. <mkfs_options>-I 128</mkfs_options> |
Optional. Only use this when you know what you are doing. |
partition_nr |
The partition number of this partition. If you have set
<partition_nr config:type="integer" >2</partition_nr> |
In most cases, numbers 1 to 4 are primary partitions while 5 and higher are logical partitions. |
partition_id |
The partition_id sets the id of the partition. If you want different identifiers than 131 for Linux partition or 130 for swap, configure them with partition_id. <partition_id config:type="integer" >131</partition_id> |
The default is 131 for Linux partition and 130 for swap. |
mountby |
Instead of a partition number, you can tell AutoYaST to mount a
partition by <mountby config:type="symbol" >label</mountby> |
See |
subvolumes |
List of subvolumes to create for a filesystem of type btrfs. This
key only makes sense for file systems of type btrfs. If there is a
default subvolume used for the distribution (for example
<subvolumes config:type="list"> <path>tmp</path> <path>opt</path> <path>srv</path> <path>var/crash</path> <path>var/lock</path> <path>var/run</path> <path>var/tmp</path> <path>var/spool</path> ... </subvolumes> | |
lv_name |
If this partition is in a logical volume in a volume group specify
the logical volume name here (see the <lv_name>opt_lv</lv_name> | |
stripes |
An integer that configures LVM striping. Specify across how many devices you want to stripe (spread data). <stripes config:type="integer">2</stripes> | |
stripesize |
Specify the size of each block in kb. <stripesize config:type="integer" >4</stripesize> | |
lvm_group |
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>system</lvm_group> | |
pool |
<pool config:type="boolean">false</pool> | |
used_pool |
The name of the LVM thin pool that is used as a data store for this thin logical volume. If this is set to something non-empty, it implies that the volume is a so-called thin logical volume. <used_pool>my_thin_pool</used_pool> | |
raid_name |
If this physical volume is part of a RAID, specify the name of the RAID. <raid_name>/dev/md0</raid_name> | |
raid_type |
Specify the type of the RAID. <raid_type>raid1</raid_type> | |
raid_options |
Specify RAID options, see below. <raid_options>...</raid_options> | |
resize |
This boolean must be <resize config:type="boolean" >false</resize> |
Resizing only works with physical disks, not with LVM volumes. |
The following elements must be placed within the following XML structure:
<partition> <raid_options> ... </raid_options> </partition>
Attribute |
Values |
Description |
---|---|---|
chunk_size |
<chunk_size>4</chunk_size> | |
parity_algorithm |
Possible values are:
For RAID6 and RAID10 the following values can be used:
<parity_algorithm >left_asymmetric</parity_algorithm> | |
raid_type |
Possible values are: <raid_type>raid1</raid_type> |
The default is raid1. |
device_order |
This list contains the optional order of the physical devices: <device_order config:type="list"> <device>/dev/sdb2</device> <device>/dev/sda1</device> ... </device_order> |
This is optional and the default is alphabetical order. |
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 installation—unless provided in the control file.
If no partitions are defined and the specified drive is also the drive where the root partition 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:
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 sufficient space for all selected packages in addition to swap.
Use this option to delete all existing partitions (Linux and non-Linux).
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 device.
This option allows you to select specific 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.
The value provided in the use
property determines
how existing data and partitions are treated. The value
all
means that the entire disk will be erased. Make
backups and use the confirm
property if you need to
keep some partitions with important data. Otherwise, no pop-ups 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
flexible 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 fixed size can be given as shown below:
1GB
, 1G
,
100MB
, or 1000M
will all create a
partition of the size 1 Gigabyte.
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-defined partition plan. If you do not specify the device, it will be automatically detected.
<partitioning config:type="list"> <drive> <device>/dev/sda</device> <use>all</use> </drive> </partitioning>
A more detailed example shows how existing partitions and multiple drives are handled.
<partitioning config:type="list"> <drive> <device>/dev/sda</device> <partitions config:type="list"> <partition> <mount>/</mount> <size>10G</size> </partition> <partition> <mount>swap</mount> <size>1G</size> </partition> </partitions> </drive> <drive> <device>/dev/sdb</device> <use>all</use> <partitions config:type="list"> <partition> <filesystem config:type="symbol">reiser</filesystem> <mount>/data1</mount> <size>15G</size> </partition> <partition> <filesystem config:type="symbol">jfs</filesystem> <mount>/data2</mount> <size>auto</size> </partition> </partitions> <use>free</use> </drive> </partitioning>
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.
By default a file system to be mounted is identified in
/etc/fstab
by the device name. This
identification can be changed so the file system is found by searching
for a UUID or a volume label. Note that not all file 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
property is used as the volume label.
Add any valid mount option in the fourth field of
/etc/fstab
. Multiple options are separated by
commas. Possible fstab options:
ro
)
No write access to the file system. Default is
false
.
noatime
)
Access times are not updated when a file is read. Default is
false
.
user
)
The file system can be mounted by a normal user. Default is
false
.
ordered
,
journal
, writeback
)
journal
All data is committed to the journal prior to being written to the main file system.
ordered
All data is directly written to the main file system before its meta data is committed to the journal.
writeback
Data ordering is not preserved.
acl
)Enable access control lists on the file system.
user_xattr
)Allow extended user attributes on the file system.
<partitions config:type="list"> <partition> <filesystem config:type="symbol">reiser</filesystem> <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>10G</size> </partition> </partitions>
In some cases you may want to leave partitions untouched and only format specific target partitions, rather than creating them from scratch. 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.
<partitioning config:type="list"> <drive> <device>/dev/sdc</device> <partitions config:type="list"> <partition> <create config:type="boolean">false</create> <format config:type="boolean">true</format> <mount>/</mount> <partition_nr config:type="integer">1</partition_nr> </partition> <partition> <create config:type="boolean">false</create> <format config:type="boolean">false</format> <partition_nr config:type="integer">2</partition_nr> <mount>/space</mount> </partition> <partition> <create config:type="boolean">false</create> <format config:type="boolean">true</format> <filesystem config:type="symbol">swap</filesystem> <partition_nr config:type="integer">5</partition_nr> <mount>swap</mount> </partition> <partition> <format config:type="boolean">true</format> <mount>/space2</mount> <size>5G</size> </partition> <partition> <format config:type="boolean">true</format> <mount>/space3</mount> <size>max</size> </partition> </partitions> <use>6</use> </drive> </partitioning>
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 configurations. The following scenario is for a system with a non-Linux OS with a designated area for a Linux installation.
In this scenario, shown in figure Figure 4.1, “Keeping partitions”, AutoYaST will not create new partitions. Instead it searches for certain partition types on the system and uses them according to the partitioning plan in the control file. No partition numbers are given in this case, only the mount points and the partition types (additional configuration data can be provided, for example file system options, encryption and filesystem type).
<partitioning config:type="list"> <drive> <partitions config:type="list"> <partition> <create config:type="boolean">false</create> <format config:type="boolean">true</format> <mount>/</mount> <partition_id config:type="integer">131</partition_id> </partition> <partition> <create config:type="boolean">false</create> <format config:type="boolean">true</format> <filesystem config:type="symbol">swap</filesystem> <partition_id config:type="integer">130</partition_id> <mount>swap</mount> </partition> </partitions> </drive> </partitioning>
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 specified
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
files, the installation will abort, unless
the root partition is configured in the control file. The following
example illustrates how this option can be used:
/etc/fstab
#<partitioning_advanced> <fstab> <!-- Read data from existing fstab. If multiple root partitions are found, use the one specified below. Otherwise the first root partition is taken --> <!-- <root_partition>/dev/sda5</root_partition> --> <use_existing_fstab config:type="boolean">true</use_existing_fstab> <!-- all partitions found in fstab will be formatted and mounted by default unless a partition is listed below with different settings --> <partitions config:type="list"> <partition> <format config:type="boolean">false</format> <mount>/bootmirror</mount> </partition> </partitions> </fstab> </partitioning_advanced>
To configure LVM, first create a physical volume using the normal partitioning method described above.
The following example shows how to prepare for LVM in the
partitioning
resource. 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.
<partitioning config:type="list"> <drive> <device>/dev/sda</device> <partitions config:type="list"> <partition> <lvm_group>system</lvm_group> <partition_type>primary</partition_type> <size>max</size> </partition> </partitions> <use>all</use> </drive> </partitioning>
<partitioning config:type="list"> <drive> <device>/dev/sda</device> <partitions config:type="list"> <partition> <lvm_group>system</lvm_group> <partition_type>primary</partition_type> <size>max</size> </partition> </partitions> <use>all</use> </drive> <drive> <device>/dev/system</device> <is_lvm_vg config:type="boolean">true</is_lvm_vg> <partitions config:type="list"> <partition> <filesystem config:type="symbol">reiser</filesystem> <lv_name>user_lv</lv_name> <mount>/usr</mount> <size>15G</size> </partition> <partition> <filesystem config:type="symbol">reiser</filesystem> <lv_name>opt_lv</lv_name> <mount>/opt</mount> <size>10G</size> </partition> <partition> <filesystem config:type="symbol">reiser</filesystem> <lv_name>var_lv</lv_name> <mount>/var</mount> <size>1G</size> </partition> </partitions> <pesize>4M</pesize> <use>all</use> </drive> </partitioning>
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 max
.
Using AutoYaST, you can create and assemble software RAID devices. The supported RAID levels are the following:
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.
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.
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.
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 first and assign them to the RAID device you want to create afterwards. Additionally you need to specify whether a partition or a device should be part of the RAID or if it should be a Spare device.
The following example shows a simple RAID1 configuration:
<partitioning config:type="list"> <drive> <device>/dev/sda</device> <partitions config:type="list"> <partition> <partition_id config:type="integer">253</partition_id> <format config:type="boolean">false</format> <raid_name>/dev/md0</raid_name> <raid_type>raid</raid_type> <size>4G</size> </partition> <!-- Insert a configuration for the regular partitions located on /dev/sda here (for example / and swap) --> </partitions> <use>all</use> </drive> <drive> <device>/dev/sdb</device> <partitions config:type="list"> <partition> <format config:type="boolean">false</format> <partition_id config:type="integer">253</partition_id> <raid_name>/dev/md0</raid_name> <raid_type>raid</raid_type> <size>4gb</size> </partition> </partitions> <use>all</use> </drive> <drive> <device>/dev/md</device> <partitions config:type="list"> <partition> <filesystem config:type="symbol">reiser</filesystem> <format config:type="boolean">true</format> <mount>/space</mount> <partition_id config:type="integer">131</partition_id> <partition_nr config:type="integer">0</partition_nr> <raid_options> <chunk_size>4</chunk_size> <parity_algorithm>left-asymmetric</parity_algorithm> <raid_type>raid1</raid_type> </raid_options> </partition> </partitions> <use>all</use> </drive> </partitioning>
Keep the the following in mind when configuring a RAID:
The device for raid is always /dev/md
The property partition_nr
is used to determine the
MD device number. If partition_nr
is equal to 0,
then /dev/md0
is configured.
All RAID-specific options are contained in the
raid_options
resource.
The elements listed below must be placed within the following XML structure:
<dasd> <devices config:type="list"> <listentry> ... </listentry> </devices> </dasd>
tags in the <profile> section. Each disk needs to be configured in a separate <listentry> ... </listentry> section.
Attribute |
Values |
Description |
---|---|---|
device |
<device >DASD</dev_name> | |
dev_name |
The device ( <dev_name >/dev/dasda</dev_name> |
Optional but recommended. If left out, AutoYaST tries to guess the device. |
channel |
Channel by which the disk is accessed. <channel>0.0.0150</channel> |
Mandatory. |
diag |
Enable or disable the use of <diag config:type="boolean">true</diag> |
Optional. |
The following elements must be placed within the following XML structure:
<profile> <zfcp> <devices config:type="list"> <listentry> ... </listentry> </devices> </zfcp> <profile>
Each disk needs to be configured in a separate
listentry
section.
Attribute |
Values |
---|---|
controller_id |
Channel number <controller_id >0.0.fc00</controller_id> |
fcp_lun |
Logical unit number <fcp_lun >0x4010400400000000</fcp_lun> |
wwpn |
World wide port number <wwpn >0x500507630510473a</wwpn> |
Patterns are configured like this:
<software> <patterns config:type="list"> <pattern>directory_server</pattern> </patterns> <packages config:type="list"> <package>apache</package> <package>postfix</package> </packages> <do_online_update config:type="boolean">true</do_online_update> </software>
In addition to the packages available for installation on the DVD-ROMs, you can add external packages including customized kernels. Customized kernel packages must be compatible to the SUSE packages and must install the kernel files to the same locations.
Unlike in earlier in versions, you do not need a special resource in the control file to install custom and 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.
cd /usr/local/DVDs/LATEST/suse create_package_descr -x PATH_TO_EXTRA_PROV -d /usr/local/CDs/LATEST/suse
In the above example, the directory
/usr/local/CDs/LATEST/suse
contains the
architecture dependent and independent packages, i.e.
noarch
. This might look different on other
architectures.
The advantage of this method is that you can keep an up-to-date repository with fixed and updated package. Additionally this method makes the creation of custom CD-ROMs easier.
To add your own RPMs to an installation source (or add-on products like
the SDK), add a file add_on_products
to the
installation source.
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 specified,
all products found on the media are selected for installation. For
example:
http://192.168.66.6/SLES/sdk/DVD1 http://192.168.66.6/SLES/DVD1/updates
As an alternative to adding the add_on_products
file to the installation source, you can use the AutoYaST control file to
specify add-on products. For example:
<add-on> <add_on_products config:type="list"> <listentry> <media_url>http://192.168.66.6/SLES/DVD1/updates</media_url> <product>SLES_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>
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.
If you want to use unsigned installation sources with AutoYaST, turn off the checks with the following configuration in your AutoYaST control file.
The elements listed below must be placed within the following XML structure:
<general> <signature-handling> ... </signature-handling> </general>
Default values for all options are false
. If an
option is set to false
and a package or repository
fails the respective test, it is silently ignored and will not be
installed. Note that setting any of these options to
true
is a potential security risk. Never do it when
using packages or repositories from third party sources.
Attribute |
Values |
---|---|
accept_unsigned_file |
If set to <accept_unsigned_file config:type="boolean" >true</accept_unsigned_file> |
accept_file_without_checksum |
If set to <accept_file_without_checksum config:type="boolean" >true</accept_file_without_checksum> |
accept_verification_failed |
If set to <accept_verification_failed config:type="boolean" >true</accept_verification_failed> |
accept_unknown_gpg_key |
If set to <accept_unknown_gpg_key config:type="boolean" >true</accept_unknown_gpg_key> |
accept_non_trusted_gpg_key |
This means, the key is known, but is not trusted by you. <accept_non_trusted_gpg_key config:type="boolean" >true</accept_non_trusted_gpg_key> |
import_gpg_key |
If set to <import_gpg_key config:type="boolean" >true</import_gpg_key> |
It is possible to configure the signature handling for each add-on
product individually. The following elements must be between the
signature-handling
section of the individual add-on
product. All settings are optional. If not configured, the global
signature-handling from the general
section is used.
Attribute |
Values |
---|---|
accept_unsigned_file |
If set to <accept_unsigned_file config:type="boolean" >true</accept_unsigned_file> |
accept_file_without_checksum |
If set to <accept_file_without_checksum config:type="boolean" >true</accept_file_without_checksum> |
accept_verification_failed |
If set to <accept_verification_failed config:type="boolean" >true</accept_verification_failed> |
accept_unknown_gpg_key |
If set to <accept_unknown_gpg_key> <all config:type="boolean">false</all> <keys config:type="list"> <keyid>3B3011B76B9D6523</keyid> </keys> </accept_unknown_gpg_key> |
accept_non_trusted_gpg_key |
This means, the key is known, but it is not trusted by you. <accept_non_trusted_gpg_key> <all config:type="boolean">false</all> <keys config:type="list"> <keyid>3B3011B76B9D6523</keyid> </keys> </accept_non_trusted_gpg_key> |
import_gpg_key |
If set to <import_gpg_key> <all config:type="boolean">false</all> <keys config:type="list"> <keyid>3B3011B76B9D6523</keyid> </keys> </import_gpg_key> |
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 conflicts.
To force the installation of a specific 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.
<software> <kernel>kernel-default</kernel> ... </software>
Some packages are selected automatically either because of a dependency or because it is available in a selection.
Removing such packages might break the system consistency 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 mail transfer agent (MTA) packages. By default,
postfix
will be selected and installed. If you
wish to use another MTA like sendmail
, then
postfix can be removed from the list of selected package using a list
in the software resource. However, note that sendmail is not shipped
with SUSE Linux Enterprise Server. The following example shows how this can be done:
<software> <packages config:type="list"> <package>sendmail</package> </packages> <remove-packages config:type="list"> <package>postfix</package> </remove-packages> </software>
If you want to install packages after the reboot during stage two,
instead of during the normal installation process in stage one, you can
use the post-packages
element for that:
<software> <post-packages config:type="list"> <package>yast2-cim</package> </post-packages> </software>
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>
You can perform an online update at the end of the installation. Set
the boolean do_online_update
to
true
. Of course this only makes 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
already available in stage one 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 two is triggered.
<software> <do_online_update config:type="boolean">true</do_online_update> </software>
With the services-manager
resource you can set the
default systemd target and specify in detail which system services you
want to start or deactivate.
The default-target
property specifies the default
systemd target into which the system boots. Valid options are
graphical
for a graphical login, or
multi-user
for a console login.
The <enable config:type="list"> and <disable config:type="list"> let you explicitly enable or disable services.
<services-manager> <default_target>multi-user</default_target> <services> <disable config:type="list"> <service>cups</service> </disable> <enable config:type="list"> <service>sshd</service> </enable> </services> </services-manager>
Network configuration is used to connect a single workstation to an Ethernet-based LAN or to configure a dial-up connection. More complex configurations (multiple network cards, routing, etc.) are also provided.
If the following setting is set to true
YaST will
keep network settings created during the installation (via Linuxrc)
and/or merge it with network settings from the AutoYaST control file (if
defined). AutoYaST settings have higher priority than already present
configuration files. YaST will write ifcfg-* files based on the
entries in the control file without removing old ones. If there is an
empty or no dns and routing section, YaST will keep already existing
values. Otherwise settings from the control file will be applied.
<keep_install_network config:type="boolean">true</keep_install_network>
To configure network settings and activate networking automatically, one global resource is used to store the whole network configuration.
<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>
Using IPv6 addresses in AutoYaST is fully supported.
Configure your Internet proxy (caching) settings.
Configure proxies for HTTP and FTP with http_proxy
and ftp_proxy
, respectively. Addresses or names that
should be directly accessible need to be specified with
no_proxy
(space separated values). If you are using
a proxy server with authorization, fill in
proxy_user
and proxy_password
,
<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>
The control file has elements to specify which superserver should be used (netd_service), whether it should be enabled (netd_status) and how the services should be configured (netd_conf).
A service description element has two parts: key and non-key. When writing the configuration, services are matched using the key fields; to the matching service, non-key fields are applied. If no service matches, it is created. If more services match, a warning is reported. The key fields are script, service, protocol and server.
service and protocol are
matched literally. script is the base name of the
configuration file: usually a file 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
, the real server
name is taken from server_args. After that, the
basename of the first whitespace-separated word is taken and these
values are compared.
<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> <enabled config:type="boolean">true</enabled> </conf> <conf> <server>in.ftpd</server> <server_args>-A</server_args> <enabled config:type="boolean">true</enabled> </conf> <conf> <service>daytime</service> <protocol>tcp</protocol> </conf> <conf>...</conf> </netd_conf> </inetd> </profile>
Using the nis
resource, you can configure the target
machine as a NIS client. The following example shows a detailed
configuration using multiple domains.
<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>
The following is a simple example for an LDAP user authentication. NSS
and PAM will automatically be configured accordingly. 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.
<auth-client> <sssd>yes</sssd> <nssldap>no</nssldap> <sssd_conf> <sssd> <config_file_version>2</config_file_version> <services>nss, pam, sudo</services> <domains>EXAMPLE</domains> </sssd> <auth_domains> <domain> <domain_name>EXAMPLE</domain_name> <id_provider>ldap</id_provider> <sudo_provider>ldap</sudo_provider> <ldap_uri>ldap://example.com</ldap_uri> <ldap_sudo_search_base>ou=sudoers,dc=example,dc=com</ldap_sudo_search_base> </domain> </auth_domains> </sssd_conf> </auth-client>
In order to use LDAP with native SSL (rather than TLS), add the
ldaps
resource:
<auth-client> <sssd_conf> <auth_domains> <domain> <ldaps config:type="boolean">true</ldaps> </domain> </auth_domains> </sssd_conf> </auth-client>
Configuring a system as an NFS client or an NFS server is can be done using the configuration system. The following examples show how both NFS client and server can be configured.
From SUSE Linux Enterprise 12 on, the structure of NFS client configuration has changed.
Some global configuration options were introduced:
enable_nfs4
to switch NFS4 support on/off and
idmapd_domain
to define domain name for rpc.idmapd
(this only makes sense when NFS4 is enabled). Attention: the old
structure is not compatible with the new one and the control files with
an NFS section created on older releases will not work with newer
products.
<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> <nfs_options>defaults</nfs_options> <server_path>bivoj.suse.cz:/work</server_path> <vfstype>nfs</vfstype> </nfs_entry> <nfs_entry> <mount_point>/mnt</mount_point> <nfs_options>defaults</nfs_options> <server_path>fallback.suse.cz:/srv/dist</server_path> <vfstype>nfs</vfstype> </nfs_entry> </nfs_entries> </nfs>
<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>
Select whether to start the NTP daemon when booting the system. The NTP
daemon resolves host names when initializing. The first synchronization
of the clock is performed before the NTP daemon is started. To use this
host for initial synchronization, configure 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 file. An example of various configuration options is shown
below.
<ntp-client> <configure_dhcp config:type="boolean">false</configure_dhcp> <peers config:type="list"> <peer> <address>ntp.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>
For the mail configuration of the client, this module lets you create a detailed mail configuration. The module contains various options. We recommended you use it at least for the initial configuration.
<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> <password>bar</password> <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> <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> <password>bar</password> <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>
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 configuration, login settings, password settings, user addition settings, and file permissions.
Configuring 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
configuration.
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> <gdm_shutdown>root</gdm_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>
Change various password settings. These settings are mainly stored in
the /etc/login.defs
file.
Use this resource to activate one of the encryption methods currently
supported. If not set, DES
is configured.
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
provides more security, but some network protocols don't support this,
and you may have problems with NIS. Blowfish
is also
supported.
Additionally, you can setup the system to check for password plausibility and length etc.
Use the security resource, to change various boot settings.
When someone at the console has pressed the Ctrl–Alt–Del key combination, the system usually reboots. Sometimes it is desirable to ignore this event, for example, when the system serves as both workstation and server.
Configure a list of users allowed to shut down the machine from GDM.
Change various login settings. These settings are mainly stored in the
/etc/login.defs
file.
useradd
settings) #Set the minimum and maximum possible user and group ID
The root
and at least one normal user can be added during install
using data supplied in the control file. User data and passwords
(encrypted or in clear text) are part of the
configure
resource in the control file.
At least the root
should be configured during auto-installation so
you can login after the installation is finished. 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 configuration.
<users config:type="list"> <user> <username>root</username> <user_password>password</user_password> <encrypted config:type="boolean">true</encrypted> <forename/> <surname/> </user> <user> <username>tux</username> <user_password>password</user_password> <encrypted config:type="boolean">true</encrypted> <forename>Tux</forename> <surname>Linux</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.
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, five types of scripts can be executed at different points in time 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 installation)
chroot-scripts
(after the package installation,
before the first boot)
post-scripts
(during the first boot of the
installed system, no services running)
init-scripts
(during the first boot of the
installed system, all services up and running)
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 control file and let AutoYaST
reread it. Find your control file in
/tmp/profile/autoinst.xml
. Adjust the file and
store the modified version in
/tmp/profile/modified.xml
. AutoYaST will read the
modified file after the pre-script finishes.
It is also possible to change the partitioning in your pre-script.
Pre-scripts are executed at an early stage of the installation. This
means if you have requested to confirm the installation, the
pre-scripts will be executed before the confirmation screen shows up
(profile/install/general/mode/confirm
).
Pre-Install Script elements must be placed as follows:
<scripts> <pre-scripts config:type="list"> <script> ... </script> </pre-scripts> </scripts>
Executed after YaST has done the partitioning and written the fstab.
The empty system is already mounted to /mnt
.
Postpartitioning script elements must be placed as follows:
<scripts> <postpartitioning-scripts config:type="list"> <script> ... </script> </postpartitioning-scripts> </scripts>
Chroot scripts are executed before the machine reboots for the first
time. You can execute chroot scripts before the installation chroots
into the installed system and configures 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).
Chroot Environment script elements must be placed as follows:
<scripts> <chroot-scripts config:type="list"> <script> ... </script> </chroot-scripts> </scripts>
These scripts are executed after AutoYaST has completed the system configuration and after it has booted the system for the first time.
It is possible to execute post scripts in an earlier phase while the
installation network is still up and before AutoYaST configures the system.
To run network-enabled post scripts, the boolean property
network_needed
has to be set to
true
.
Post-install script elements must be placed as follows:
<scripts> <post-scripts config:type="list"> <script> ... </script> </post-scripts> </scripts>
All XML elements described below can be used for each of the script
types described above. The only exceptions are
chrooted
and
network_needed
—they are only valid for chroot
and post-install srcipts.
Element |
Description |
Comment |
---|---|---|
location |
Define a location from where the script gets fetched. Locations can be the same as for the control file (HTTP, FTP, NFS, etc.). <location >http://10.10.0.1/myPreScript.sh</location> |
Either |
source |
The script itself (source code), encapsulated in a CDATA tag. If you do not want to put the whole shell script into the XML control file, refer to the location parameter. <source> <![CDATA[ echo "Testing the pre script" > /tmp/pre-script_out.txt ]]> </source> |
Either |
interpreter |
Specify the interpreter that must be used for the script. Supported options are shell and perl. <interpreter>perl</interpreter> |
Optional (default is |
filename |
The filename of the script. It will be stored in a temporary
directory under <filename>myPreScript5.sh</filename> |
Optional. Default is the type of the script (pre-scripts in this case). If you have more than one script, you should define different names for each script. |
feedback |
If this boolean is <feedback config:type="boolean">true</feedback> |
Optional, default is |
feedback_type |
This can be <feedback_type>warning</feedback_type> |
Optional, if missing, an always blocking pop-up is used. |
debug |
If this is <debug config:type="boolean">true</debug> |
Optional, default is |
notification |
This text will be shown in a pop-up for the time the script is running in the background. <notification>Please wait while script is running...</notification> |
Optional, if not configured, no notification pop-up will be shown. |
param-list |
It is possible to specifiy parameters given to the script being
called. You may have more than one <param-list> <param>par1</param> <param>par2 par3</param> <param>"par4.1 par4.2"</param> </param-list> |
Optional, if not configured, no parameters get passed to script. |
rerun |
A script is only run once. Even if you use
<rerun config:type="boolean">true</rerun> |
Optional, default is |
chrooted |
If set to <chrooted config:type="boolean" >true</chrooted> |
Optional, default is |
network_needed |
If set to <network_needed config:type="boolean" >true</network_needed> |
Optional, default is |
<?xml version="1.0"?> <!DOCTYPE profile> <profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns"> <scripts> <chroot-scripts config:type="list"> <script> <chrooted config:type="boolean">true</chrooted> <filename>chroot.sh</filename> <interpreter>shell</interpreter> <source><![CDATA[ #!/bin/sh echo "Testing chroot (chrooted) scripts" ls ]]> </source> </script> <script> <filename>chroot.sh</filename> <interpreter>shell</interpreter> <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> <interpreter>shell</interpreter> <source><![CDATA[ #!/bin/sh echo "Running Post-install script" systemctl start portmap.service mount -a 192.168.1.1:/local /mnt cp /mnt/test.sh /tmp umount /mnt ]]> </source> </script> <script> <filename>post.pl</filename> <interpreter>perl</interpreter> <source><![CDATA[ #!/usr/bin/perl print "Running Post-install script"; ]]> </source> </script> </post-scripts> <pre-scripts config:type="list"> <script> <interpreter>shell</interpreter> <location>http://192.168.1.1/profiles/scripts/prescripts.sh</location> </script> <script> <filename>pre.sh</filename> <interpreter>shell</interpreter> <source><![CDATA[ #!/bin/sh echo "Running pre-install script" ]]> </source> </script> </pre-scripts> <postpartitioning-scripts config:type="list"> <script> <filename>postpart.sh</filename> <interpreter>shell</interpreter> <debug config:type="boolean">false</debug> <feedback config:type="boolean">true</feedback> <source><![CDATA[ touch /mnt/testfile echo Hi ]]> </source> </script> </postpartitioning-scripts> </scripts> </profile>
After installation is finished, 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 consists of the output produced when executing the shell scripts using the following command:
/bin/sh -x SCRIPT_NAME 2&>/var/adm/autoinstall/logs/SCRIPT_NAME.log
Using the sysconfig resource, it is possible to define configuration
variables in the sysconfig repository
(/etc/sysconfig
) directly. Sysconfig variables,
offer the possibility to fine-tune many system components and
environment variables exactly to your needs.
The following example shows how a variable can be set using the sysconfig resource.
<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 paths can be provided. If no absolute path
is given, it is treated as a sysconfig file under the
/etc/sysconfig
directory.
For many applications and services you might have prepared a
configuration file 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 configuration file
(httpd.conf
).
Using this resource, you can embed the file into the control file by specifying the final path on the installed system. YaST will copy this file to the specified location.
This feature requires the autoyast2 package to be installed. If the package is missing, AutoYaST will automatically install the package if it is missing.
You can specify the file_location
where the file
should be retrieved from. This can also be a location on the newtork
such as an HTTP server:
<file_location>http://my.server.site/issue</file_location>
.
You can create directories by specifying a file_path
that ends with a slash.
<files config:type="list"> <file> <file_path>/etc/apache2/httpd.conf</file_path> <file_contents> <![CDATA[ some content ]]> </file_contents> </file> <file> <file_path>/mydir/a/b/c/</file_path> <!-- create directory --> </file> </files>
A more advanced example is shown below. This configuration will create a
file using the content supplied in file_contents
and
change the permissions and ownership of the file. After the file has
been copied to the system, a script is executed, which can be used to
manipulate the file and prepare it for the environment of the client.
<files config:type="list"> <file> <file_path>/etc/someconf.conf</file_path> <file_contents> <![CDATA[ some content ]]> </file_contents> <file_owner>tux.users</file_owner> <file_permissions>444</file_permissions> <file_script> <interpreter>shell</interpreter> <source> <![CDATA[ #!/bin/sh echo "Testing file scripts" >> /etc/someconf.conf df cd /mnt ls ]]> </source> </file_script> </file> </files>
You have the option to let the user decide the values of specific parts
of the control file during the installation. If you use this feature, a
pop-up will ask the user to enter a specific part of the control file
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 control file.
The elements listed below must be placed within the following XML structure:
<general> <ask-list config:type="list"> <ask> ... </ask> </ask-list> tags </general>
Element |
Description |
Comment |
---|---|---|
question |
The question you want to ask the user. <question>Enter the LDAP server</question> |
The default value is the path to the element (the path often looks strange, so we recommend entering a question). |
default |
Set a pre-selection for the user. A text entry will be filled out with this value. A checkbox will be true or false and a selection will have the given value pre-selected. <default>dc=suse,dc=de</default> |
Optional. |
help |
An optional helptext that is shown on the left side of the question. <help>Enter the LDAP server address.</help> |
Optional. |
title |
An optional title that is shown above the questions. <title>LDAP server</title> |
Optional. |
type |
The type of the element you want to change. Possible values are
<type>symbol</type> |
Optional. The default is |
password |
If this boolean is set to <password config:type="boolean">true</password> |
Optional. The default is |
pathlist |
A list of <pathlist config:type="list"> <path>networking,dns,hostname</path> <path>...</path> </pathlist> |
This information is optional but you should at least provide
|
file |
You can store the answer to a question in a file, to use it in one
of your scripts later. If you ask during
<file>/tmp/answer_hostname</file> |
This information is optional, but you should at least provide
|
password |
If this boolean is set to <password config:type="boolean">true</password> |
Optional. The default is |
stage |
Stage configures the installation stage in which the question pops
up. You can set this value to <stage>cont</stage> |
Optional. The default is |
selection |
The selection element contains a list of <selection config:type="list"> <entry> <value> reiser </value> <label> Reiser Filesystem </label> </entry> <entry> <value> ext3 </value> <label> Extended3 Filesystem </label> </entry> </selection> |
Optional for |
dialog |
You can ask more than one question per dialog. To do so, specifiy the dialog-id with an integer. All questions with the same dialog-id belong to the same dialog. The dialogs are sorted by the id too. <dialog config:type="integer">3</dialog> |
Optional. |
element |
you can have more than one question per dialog. To make that possible you have to specifiy the element-id with an integer. The questions in a dialog are sorted by id. <element config:type="integer">1</element> |
Optional (see dialog). |
width |
You can increase the default width of dialog. If there are multiple width specifications per dialog, the largest one is used. The number is roughly equivalent to the number of characters. <width config:type="integer">50</width> |
Optional. |
height |
You can increase default height of dialog. If there are multiple height specifications per dialog, largest one is used. The number is roughly equivalent to number of lines. <height config:type="integer">15</height> |
Optional. |
frametitle |
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 each question. You can put multiple elements into one frame. They have to have the same frame title. <frametitle>User data</frametitle> |
Optional. Default is no frame title. |
script |
You can run scripts after a question has been answered (see the table below for detailed instructions about scripts). <script>...</script> |
Optional (default is no script). |
ok_label |
You can change the label on the button. The last element that specifies the label for a dialog wins.<ok_label>Finish</ok_label> |
Optional. |
back_label |
You can change the label on the button. The last element that specifies the label for a dialog wins.<back_label>change values</back_label> |
Optional. |
timeout |
You can specify an integer here that is used as timeout in seconds. If the user does not answer the question before the timeout, the default value is taken as answer. When the user touches or changes any widget in the dialog, the timeout is turned off and the dialog has to be confirmed via the ok-button. <timeout config:type="integer">30</timeout> |
Optional. A missing value is interpreted as |
default_value_script |
You can run scripts to set the default value for a question (see
Section 4.19.1, “Default Value Scripts” for detailed
instructions about default value scripts). This feature is useful
if you can <default_value_script>...</default_value_script> |
Optional. Default is no script. |
You can run scripts to set the default value for a question. This
feature is useful if you can calculate
a default
value, especially in combination with the timeout
option.
The elements listed below must be placed within the following XML structure:
<general> <ask-list config:type="list"> <ask> <default_value_script> ... </default_value_script> </ask> </ask-list> </general>
Element |
Description |
Comment |
---|---|---|
source |
The source code of the script. Whatever you
<source>...</source> |
This value is required, otherwise nothing would be executed. |
interpreter |
The interpreter to use. <interpreter>perl</interpreter> |
The default value is |
You can run scripts after a question has been answered.
The elements listed below must be placed within the following XML structure:
<general> <ask-list config:type="list"> <ask> <script> ... </script> </ask> </ask-list> </general>
Element |
Description |
Comment |
---|---|---|
filename |
The filename of the script. <filename>my_ask_script.sh</filename> |
The default is ask_script.sh |
source |
The source code of the script. Together with
<source>...</source> |
This value is required, otherwise nothing would be executed. |
environment |
A boolean that passes the value of the answer to the question as
an environment variable to the script. The variable is named
<environment config:type="boolean">true</environment> |
Optional. Default is |
feedback |
A boolean that turns on feedback for the script execution. STDOUT will be displayed in a pop-up window that must be confirmed after the script execution. <feedback config:type="boolean">true</feedback> |
Optional, default is |
debug |
A boolean that turns on debugging for the script execution. <debug config:type="boolean">true</debug> |
Optional, default is |
rerun_on_error |
A boolean that keeps the dialog open until the script has an exit
code of 0 (zero). So you can parse and check the answers the user
gave in the script and display an error with the
<rerun_on_error config:type="boolean">true</rerun_on_error> |
Optional, default is |
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> <selection config:type="list"> <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 config:type="list"> <path>networking,dns,hostname</path> </pathlist> <question>Enter Hostname</question> <stage>initial</stage> <default>enter your hostname here</default> </ask> <ask> <pathlist config:type="list"> <path>partitioning,0,partitions,0,filesystem</path> </pathlist> <question>Filesystem</question> <type>symbol</type> <selection config:type="list"> <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 shows a to choose between AutoYaST control files.
AutoYaST will read the modified.xml
file again after
the ask-dialogs are done. This way you can fetch a complete new control
file.
<general> <ask-list config:type="list"> <ask> <selection config:type="list"> <entry> <value>part1.xml</value> <label>Simple partitioning</label> </entry> <entry> <value>part2.xml</value> <label>encrypted /tmp</label> </entry> <entry> <value>part3.xml</value> <label>LVM</label> </entry> </selection> <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> <debug config:type="boolean">false</debug> <feedback config:type="boolean">false</feedback> </script> </ask>tion> </ask-list> </general>
You can verify the answer of a question with a script like this:
<general> <ask-list config:type="list"> <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> <debug config:type="boolean">false</debug> <feedback config:type="boolean">true</feedback> </script> <dialog config:type="integer">0</dialog> <element config:type="integer">0</element> <pathlist config:type="list"> <path>networking,dns,hostname</path> </pathlist> <question>Enter Hostname</question> <default>enter your hostname here</default> </ask> </ask-list> </general>
This feature is not available on the IBM System z (s390x) architecture.
With Kdump the system is able to create crashdump files if the whole system (i.e., the kernel) crashes. Crash dump files contain the memory contents while the system crashed. Such core files can be analyzed later by support or a (kernel) developer to find 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 fixed.
The only downside: enabling Kdump costs you between 64 MiB and 128 MiB of 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.
The following example shows a general Kdump configuration.
<kdump> <!-- memory reservation --> <add_crash_kernel config:type="boolean">true</add_crash_kernel> <crash_kernel>256M-:64M</crash_kernel> <general> <!-- dump target settings --> <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> <!-- filtering and compression --> <KDUMP_DUMPFORMAT>compressed</KDUMP_DUMPFORMAT> <KDUMP_DUMPLEVEL>1</KDUMP_DUMPLEVEL> <!-- notification --> <KDUMP_NOTIFICATION_TO>tux@example.com</KDUMP_NOTIFICATION_TO> <KDUMP_NOTIFICATION_CC></KDUMP_NOTIFICATION_CC> <KDUMP_SMTP_SERVER>mail.example.com</KDUMP_SMTP_SERVER> <KDUMP_SMTP_USER></KDUMP_SMTP_USER> <KDUMP_SMTP_PASSWORD></KDUMP_SMTP_PASSWORD> <!-- kdump kernel --> <KDUMP_KERNELVER></KDUMP_KERNELVER> <KDUMP_COMMANDLINE></KDUMP_COMMANDLINE> <KDUMP_COMMANDLINE_APPEND></KDUMP_COMMANDLINE_APPEND> <!-- expert settings --> <KDUMP_IMMEDIATE_REBOOT>yes</KDUMP_IMMEDIATE_REBOOT> <KDUMP_VERBOSE>15</KDUMP_VERBOSE> <KEXEC_OPTIONS></KEXEC_OPTIONS> </general> </kdump>
The first step is to reserve memory for Kdump at boot-up. Because the
memory must be reserved very early during the boot process, the
configuration 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
first 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 notification e-mail, and finally reboot.
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). The amount
of memory that needs to be reserved depends on architecture and main
memory—refer to Section “Manual Kdump Configuration”, Chapter 16, Kexec and Kdump, System Analysis and Tuning Guide
for recommendations on the amount of memory to reserve for Kdump.
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 control file for multiple installations or if you often remove or install memory on one machine. 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 first memory range
(for example: 0M
) and END_RANGE_1
is the end of the first memory range (can be empty in case
infinity
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 RAM
and to reserve 128 MiB of crashkernel memory if the system has more
than 2 GiB RAM.
The following table shows the settings necessary to reserve memory:
Element |
Description |
Comment |
---|---|---|
add_crash_kernel |
Set to <add_crash_kernel config:type="boolean">true</add_crash_kernel> |
required |
crash_kernel |
Use the syntax of the crashkernel command line as discussed above. <crash_kernel>256M:64M</crash_kernel> |
required |
The element KDUMP_SAVEDIR
specifies 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 an 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
. A
subdirectory, 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 specified 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 information).
The kernel dump is uncompressed and unfiltered. It can get as large as your system RAM. To get smaller files, compress the dump file afterwards. The dump has to be decompressed before opening.
To use page compression, which compresses every page and allows
dynamic decompression with the crash(8) debugging tool, set
KDUMP_DUMPFORMAT
to compressed
(default).
You may not want to save all memory pages, for example those filled
with zeroes. To filter the dump, set the
KDUMP_DUMPLEVEL
. 0 produces a full dump and 31 is
the smallest dump. The manual pages kdump(5) and makedumpfile(8) list
for each value which pages will be saved.
Element |
Description |
Comment |
---|---|---|
KDUMP_SAVEDIR |
An URL that specifies the target to which the dump and related files will be saved. <KDUMP_SAVEDRIR >file:///var/crash/</KDUMP_SAVEDIR> |
required |
KDUMP_COPY_KERNEL |
Set to <KDUMP_COPY_KERNEL >false</KDUMP_COPY_KERNEL> |
optional |
KDUMP_FREE_DISK_SIZE |
Disk space in megabytes that must remain free after saving the dump. If not enough space is available, the dump will not be saved. <KDUMP_FREE_DISK_SIZE >64</KDUMP_FREE_DISK_SIZE> |
optional |
KDUMP_KEEP_OLD_DUMPS |
The number of dumps that are kept (i.e., not deleted) if
<KDUMP_KEEP_OLD_DUMPS >4</KDUMP_KEEP_OLD_DUMPS> |
optional |
Configure e-mail notification 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 notification e-mail. An SMTP server needs to be specified (see below).
You have to provide exactly one address in
KDUMP_NOTIFICATION_TO
. More addresses can be
specified in in KDUMP_NOTIFICATION_CC
. Only use
e-mail 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.
Element |
Description |
Comment |
---|---|---|
KDUMP_NOTIFICATION_TO |
Exactly one e-mail address to which the e-mail should be sent.
Additional recipients can be specified in
<KDUMP_NOTIFICATION_TO >tux@example.com</KDUMP_NOTIFICATION_TO> |
optional (notification disabled if empty) |
KDUMP_NOTIFICATION_CC |
Zero, one or more recipients that are in the cc line of the notification e-mail. <KDUMP_NOTIFICATION_CC >wilber@example.com geeko@example.com</KDUMP_NOTIFICATION_CC> |
optional |
KDUMP_SMTP_SERVER |
Host name of the SMTP server used for mail delivery. SMTP
authentication is supported (see
<KDUMP_SMTP_SERVER >email.suse.de</KDUMP_SMTP_SERVER> |
optional (notification disabled if empty) |
KDUMP_SMTP_USER |
User name used together with
<KDUMP_SMTP_USER >bwalle</KDUMP_SMTP_USER> |
optional |
KDUMP_SMTP_PASSWORD |
Password used together with <KDUMP_SMTP_PASSWORD >geheim</KDUMP_SMTP_PASSWORD> |
optional |
As already mentioned, a special kernel is booted to save the dump. If
you don't want to use the auto-detection mechanism to find out which
kernel is used (see the kdump(5) manual page that describes the
algorithm which is used to find 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
file) 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
.
Element |
Description |
Comment |
---|---|---|
KDUMP_KERNELVER |
Version string for the kernel used for Kdump. Leave it empty to use the auto-detection mechanism (strongly recommended). <KDUMP_KERNELVER >2.6.27-default</KDUMP_KERNELVER> |
optional (auto-detection if empty) |
KDUMP_COMMANDLINE_APPEND |
Additional command line parameters for the Kdump kernel. <KDUMP_COMMANDLINE_APPEND >console=ttyS0,57600</KDUMP_COMMANDLINE_APPEND> |
optional |
KDUMP_COMMANDLINE |
Overwrite the automatically generated Kdump command line. Use with
care. In most cases, <KDUMP_COMMANDLINE_APPEND >root=/dev/sda5 maxcpus=1 irqpoll</KDUMP_COMMANDLINE> |
optional |
Element |
Description |
Comment |
---|---|---|
KDUMP_IMMEDIATE_REBOOT |
<KDUMP_IMMEDIATE_REBOOT >true</KDUMP_IMMEDIATE_REBOOT> |
optional |
KDUMP_VERBOSE |
Bitmask that specifies how verbose the Kdump process should be. Read kdump(5) for details. <KDUMP_VERBOSE>3</KDUMP_VERBOSE> |
optional |
KEXEC_OPTIONS |
Additional options that are passed to kexec when loading the Kdump kernel. Normally empty. <KEXEC_OPTIONS>--noio</KEXEC_OPTIONS> |
optional |
In addition to the core component configuration, like network authentication and security, AutoYaST offers a wide range of hardware and system configuration options, the same as available by default on any system installed manually and in an interactive way. For example, it is possible to configure printers, sound devices, TV cards and any other hardware components which have a module within YaST.
Any new configuration options added to YaST will be automatically available in AutoYaST.
AutoYaST support for printing is limited to basic settings defining how the CUPS printing system is used on a client for printing via the network.
There is no AutoYaST support for setting up local print queues. Modern
printers are usually connected via USB. CUPS accesses USB printers by a
model-specific device URI like
usb://ACME/FunPrinter?serial=1a2b3c
. Usually it is
not possible to predict the correct USB device URI in advance, because
it is determined by the CUPS backend usb
during
runtime. Therefore it is not possible to set up local print queues with
AutoYaST.
Basics on how CUPS is used on a client workstation to print via network:
On client workstations application programs submit print jobs to the
CUPS daemon process (cupsd
).
cupsd
forwards the print jobs to a CUPS print
server in the network where the print jobs are processed. The server
sends the printer specific data to the printer device.
If there is only a single CUPS print server in the network, there is no
need to have a CUPS daemon running on each client workstation. Instead
it is simpler to specify the CUPS server in
/etc/cups/client.conf
and access it directly (only
one CUPS server entry can be set). In this case application programs
that run on client workstations submit print jobs directly to the
specified CUPS print server.
Example 4.33, “Printer configuration” shows a printer
configuration section. The cupsd_conf_content
entry
contains the whole verbatim content of the
cupsd
configuration file
/etc/cups/cupsd.conf
. The
client_conf_content
entry contains the whole
verbatim content of /etc/cups/client.conf
. The
printer
section contains the
cupsd
configuration but it
does not specify whether or not the cupsd should run.
<printer> <client_conf_content> <file_contents><![CDATA[ ... verbatim content of /etc/cups/client.conf ... ]]></file_contents> </client_conf_content> <cupsd_conf_content> <file_contents><![CDATA[ ... verbatim content of /etc/cups/cupsd.conf ... ]]></file_contents> </cupsd_conf_content> </printer>
/etc/cups/cups-files.conf
With release 1.6 the CUPS configuration file has been split into two
files: cupsd.conf
and
cups-files.conf
. As of SUSE Linux Enterprise Server 12, AutoYaST
only supports modifying cupsd.conf
since the
default settings in cups-files.conf
are
sufficient for usual printing setups.
An example of the sound configuration created using the configuration system is shown below.
<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>