4.19. Miscellaneous hardware and system components

4.19. Miscellaneous hardware and system components
	Chapter 4. Configuration and Installation Options

In addition to the core component configuration, like network authentication and security, AutoYaST2 offers a wide range of hardware and system configuration which is 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 YaST2.

Any new configuration options that will be added to YaST2 will be automatically available as an auto-installation resource.

4.19.1. Printer

The YaST printer module was made anew from scratch for openSUSE 11.1 and SUSE Linux Enterprise Server/Desktop 11. Currently the AutoYaST support for printing is limited to basic settings how the CUPS printing system is used on a client workstation to print via network.

Currently there is no AutoYaST support to set up local print queues. In particular when a USB printer is connected to a client workstation it is no longer possible to have a predefined configuration because USB printers are no longer accessed via a generic USB device node like "/dev/usb/lp0" but via a model specific device URI like "usb://ACME/FunPrinter?serial=1a2b3c". There is a serial number included so that a USB printer device URI works only for one particular device. Usually it is not possible to know the correct USB device URI in advance because it is determined by the CUPS backend "usb" during runtime when the particular device is connected depending on the actual values which the printer reports via the USB.

Intrinsic design of CUPS for printing in the network:

The CUPS daemon process (cupsd) of a CUPS network print server sends information about its print queues to a list of IP addresses (host addresses and/or broadcast addresses).

On client workstations (hosts that only send print jobs to servers) also a cupsd runs which listens to information from servers. There is a list of servers from which information is accepted. By default, information is accepted from all servers.

In this way, the queues of the server are available on the clients. Users on the clients can browse the queues on various servers. Therefore it is called "Browsing" and all what is to do on a client workstation to use CUPS in its default Browsing mode is to run the cupsd. The matching settings in the cupsd configuration file (/etc/cups/cupsd.conf) are "Browsing On" and "BrowseAllow all".

To limit from which CUPS servers browsing information is accepted, a setting like "BrowseAllow @LOCAL" accepts browsing information only from CUPS servers in the local network.

Multiple "BrowseAllow" entries like "BrowseAllow 192.168.100.1" and "BrowseAllow 192.168.200.0/255.255.255.0" can be used to accept browsing information only from particular hosts and/or networks.

CUPS Browsing information is recieved via UDP port 631. You may have to check firewall settings accordingly.

Alternatively if there is only one single CUPS server in the network, there is no need to use CUPS Browsing and have a CUPS daemon running on each client workstation.

Instead it is simpler to specify the CUPS server and access it directly by an entry like "ServerName 192.168.100.99" in /etc/cups/client.conf (only one such entry can be set). In this case the specified server is directly accessed so that a local running cupsd on a client workstation is no longer used so that it does no longer make sense to have it running.

The following is an example of a configuration section. The <cups_remote_server> entry contains the value of a ServerName entry in /etc/cups/client.conf. The <server_settings> section contains all values of the cupsd configuration file (/etc/cups/cupsd.conf) so that a complete <server_settings> section is required to get a reasonable cupsd configuration installed.

Example 4.36. Printer configuration

  <printer>
    <cups_remote_server>192.168.100.99</cups_remote_server>
    <server_settings>
      <Browsing config:type="list">
        <listentry>On</listentry>
      </Browsing>
      <BrowseAllow config:type="list">
        <listentry>@LOCAL</listentry>
        <listentry>192.168.100.1</listentry>
        <listentry>192.168.200.0/255.255.255.0</listentry>
      </BrowseAllow>
      <BrowseOrder config:type="list">
        <listentry>allow,deny</listentry>
      </BrowseOrder>
      <LogLevel config:type="list">
        <listentry>info</listentry>
      </LogLevel>
      <Listen config:type="list">
        <listentry>localhost:631</listentry>
        <listentry>/var/run/cups/cups.sock</listentry>
      </Listen>
      <DefaultAuthType config:type="list">
        <listentry>Basic</listentry>
      </DefaultAuthType>
      <SystemGroup config:type="list">
        <listentry>sys root</listentry>
      </SystemGroup>
      <sections config:type="list">
        <section>
          <Key>Location</Key>
          <Value>/</Value>
          <Allow config:type="list">
            <listentry>127.0.0.2</listentry>
          </Allow>
          <Order config:type="list">
            <listentry>allow,deny</listentry>
          </Order>
        </section>
        <section>
          <Key>Location</Key>
          <Value>/admin</Value>
          <Encryption config:type="list">
            <listentry>Required</listentry>
          </Encryption>
          <Order config:type="list">
            <listentry>allow,deny</listentry>
          </Order>
        </section>
        <section>
          <Key>Location</Key>
          <Value>/admin/conf</Value>
          <AuthType config:type="list">
            <listentry>Default</listentry>
          </AuthType>
          <Require config:type="list">
            <listentry>user @SYSTEM</listentry>
          </Require>
          <Order config:type="list">
            <listentry>allow,deny</listentry>
          </Order>
        </section>
        <section>
          <Key>Policy</Key>
          <Value>default</Value>
          <subsection config:type="list">
            <listentry>
              <Key>Limit</Key>
              <Value>Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job CUPS-Move-Job</Value>
              <Require config:type="list">
                <listentry>user @OWNER @SYSTEM</listentry>
              </Require>
              <Order config:type="list">
                <listentry>deny,allow</listentry>
              </Order>
            </listentry>
            <listentry>
              <Key>Limit</Key>
              <Value>CUPS-Add-Modify-Printer CUPS-Delete-Printer CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default</Value>
              <AuthType config:type="list">
                <listentry>Default</listentry>
              </AuthType>
              <Require config:type="list">
                <listentry>user @SYSTEM</listentry>
              </Require>
              <Order config:type="list">
                <listentry>deny,allow</listentry>
              </Order>
            </listentry>
            <listentry>
              <Key>Limit</Key>
              <Value>Pause-Printer Resume-Printer Enable-Printer Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer Startup-Printer Promote-Job Schedule-Job-After CUPS-Accept-Jobs CUPS-Reject-Jobs</Value>
              <AuthType config:type="list">
                <listentry>Default</listentry>
              </AuthType>
              <Require config:type="list">
                <listentry>user @SYSTEM</listentry>
              </Require>
              <Order config:type="list">
                <listentry>deny,allow</listentry>
              </Order>
            </listentry>
            <listentry>
              <Key>Limit</Key>
              <Value>Cancel-Job CUPS-Authenticate-Job</Value>
              <Require config:type="list">
                <listentry>user @OWNER @SYSTEM</listentry>
              </Require>
              <Order config:type="list">
                <listentry>deny,allow</listentry>
              </Order>
            </listentry>
            <listentry>
              <Key>Limit</Key>
              <Value>All</Value>
              <Order config:type="list">
                <listentry>deny,allow</listentry>
              </Order>
            </listentry>
          </subsection>
        </section>
      </sections>
    </server_settings>
  </printer>

4.19.2. Sound devices

An example of sound configuration created using the configuration system is shown below.

Example 4.37. Sound configuration

....
    <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>

....

4.19.3. Kernel dumps

	Note
	This feature is only available since SLES 11 (not openSUSE 11.1). It is not available on the zSeries (s390x) architecture!

With kdump the system is able to create crashdump files if the whole system (i.e., the kernel) crashes. That crash dump files contain the memory contents while the system crashed. Such core files can be analyzed later by the support or a (kernel) developer to find the reason why the system crashed. It's mostly useful for servers where you cannot easily reproduce such crashes on another system and where it's important that the problem gets fixed.

The only downside of enabling kdump is that this costs you between 64 MiB and 128 MiB of System RAM (on "normal" sized systems) that needs to be reserved to be used by kdump in the case the system crashes and the dump needs to be generated.

This section only describes how to setup kdump with AutoYaST. It does not describe how kdump works in general and also does not describe each small detail. Refer to the kdump(7) manual page which is in the package named kdump or to the openSUSE Kdump documentation.

At first, let's present an overall example for the kdump configuration:

Example 4.38. 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>bwalle@suse.de</KDUMP_NOTIFICATION_TO>
    <KDUMP_NOTIFICATION_CC></KDUMP_NOTIFICATION_CC>
    <KDUMP_SMTP_SERVER>mail.suse.de</KDUMP_SMTP_SERVER>
    <KDUMP_SMTP_USER></KDUMP_SMTP_USER>
    <KDUMP_SMTP_PASSWORD></KDUMP_SMTP_PASSWORD>

    <!-- kdump 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>

4.19.3.1. Memory Reservation

As already mentioned above, it's necessary to reserve some memory at bootup for kdump. Because that memory must be reserved very early during the boot process, the configuration is done via a kernel command line parameter called crashkernel. That memory will be used to load a second kernel in that memory that will be executed without rebooting if the first kernel crashes. That kernel also has a special initrd which contains all programs that are necessary to save the dump to network or disk, send the notification email and finally reboot.

You can enable or disable that the crashkernel parameter is written for the default boot kernel with the add_crash_kernel tag and you can specify the value of the crashkernel parameter using the crash_kernel tag.

For the memory reservation there are two things to specify: The amount of reserved memory (such as 64M to reserve 64 MiB of memory from the RAM) and the offset. The syntax is crashkernel=AMOUNT@OFFSET. Luckily the kernel is able to auto-detect the right offset for you nowadays (with the exception of the Xen hypervisor where you have to specify 16M as offset), so you don't have to worry about that too much. You can just specify <crash_kernel>crashkernel=64M</crash_kernel> and the right thing will happen.

For the amount of memory, following values are recommended:

Table 4.16. Recommended values for the reserved memory amount

Platform	Recommended values
i386 and x86-64	`64M` for small machines (about 2 GiB of RAM, 4 cores) and `128M` for larger machines
PPC64	`128M` for small machines and `256M` for larger machines
IA64	`256M` for small machines, `512M` for medium machines and `1G` and more for really large machines (mostly SGI Altix systems)

To make things even more complicated, there's a so-called extended command line syntax where you can specify the amount of reserved memory dependent of the System RAM. That is good if you share one AutoYaST profile for multiple installations or when 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

In that syntax 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 (and can be empty in case "infinity" should be assumed) and so on. So for example 256M-2G:64M,2G-:128M means to reserve 64 MiB of crashkernel memory when the system has between 256 MiB and 2 GiB RAM and to reserve 128 MiB of crashkernel memory when the system has above 2 GiB RAM.

The following table contains the settings that are necessary for the memory reservation:

Table 4.17. XML representation of the memory reservation settings

Element	Description	Comment
add_crash_kernel	If the memory should be reserved, that basically enables or disables kdump. <add_crash_kernel config:type="boolean">true</add_crash_kernel>	required
crash_kernel	The syntax of the crashkernel command line as discussed above. <crash_kernel>256M:64M</crash_kernel>	required

4.19.3.2. Dump Saving

4.19.3.2.1. Target

The element KDUMP_SAVEDIR holds an URL to where the dump is saved. Following methods are possible:

file to save to the local disk
ftp to save to an FTP server (without encryption)
sftp to save to an SSH2 SFTP server
nfs to save to a NFS location and
cifs to save the dump to a CIFS/SMP export from Samba or Microsoft Windows.

For details see the kdump(5) manual page. Two examples are: file:///var/crash (which is the default location according to FHS) and ftp://user:password@host:port/incoming/dumps. Below that directory, a directory name that contains a time stamp will be created in which the dumps are saved.

When the dump is saved to the local disk, KDUMP_KEEP_OLD_DUMPS can be used to delete old dumps automatically. This setting takes a number that specifies how much old dumps should be kept. If the partition has less than KDUMP_FREE_DISK_SIZE megabytes free disk space after saving the dump, the dump is not copied at all.

If you would not like only to save the dump but also the whole kernel and (if installed) the debug information of the kernel to that directory to have everything you need (except all kernel modules and the debugging information of all kernel modules) to analyze the dump in one directory, you can set KDUMP_COPY_KERNEL to true.

4.19.3.2.2. Filtering and Compression

The size of kernel dumps is uncompressed and unfiltered as large as your system has RAM. To get smaller files (for example, to send it to support), you can compress the whole dump file afterwards. However, the drawback is that the dump has to be uncompressed afterwards before opening, so the disk space needs to be there in any case.

To use page compression which compresses every page and allows dynamic decompression with the crash(8) debugging tool, set KDUMP_DUMPFORMAT to compressed (which is actually the default).

To filter the dump, you have to set the KDUMP_DUMPLEVEL. Then not all memory is saved to disk but only memory that does not fulfill some criteria. I.e. you may want to leave out pages that are completely filled by zeroes as they don't contain any useful information. 0 produces a full dump and 31 is the smallest dump. The manual page kdump(5) and makedumpfile(8) contain a table that lists for each value which pages will be saved.

4.19.3.2.3. Summary

Table 4.18. XML representation of the dump target settings

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	If not only the dump itself should be saved to `KDUMP_SAVEDIR` but also the kernel and its debugging information (if installed). <KDUMP_COPY_KERNEL>false</KDUMP_COPY_KERNEL>	optional
KDUMP_FREE_DISK_SIZE	The number of megabytes that should always be free after saving the dump. If that space would be below that value, the dump will not be copied. <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_SAVEDIR` points to a local directory. Specify 0 if you don't want to delete dumps at all and specify -1 if all dumps (except the one that is just saved) should be deleted. <KDUMP_KEEP_OLD_DUMPS>4</KDUMP_KEEP_OLD_DUMPS>	optional

4.19.3.3. Email Notification

It's useful to get notified via email that a machine has crashed and a dump has been saved. That way you can for example setup a dump server in a company and trigger some actions by that email automatically like calling the administrator from home to check if everything runs again.

Because the dump is saved in a special initrd environment, we cannot use a local mail server just to send that notification email. However, it's better to send that email in the initrd just because it's more likely that we have a working network connection here (which we need in the netdump case to save the dump away anyway) compared that the server comes up again and everything is working.

You have to provide at least exactly one address in KDUMP_NOTIFICATION_TO and zero, one or more addresses in KDUMP_NOTIFICATION_CC. Please note that you can only specify the address here, not a real name or some other fancy stuff.

To actually send the email, we need KDUMP_SMTP_SERVER and (if the server needs authentication) KDUMP_SMTP_USER and KDUMP_SMTP_PASSWORD. Please note that TSL or SSL are not supported. That may be added in future.

Table 4.19. XML representation of the email notification settings

Element	Description	Comment
KDUMP_NOTIFICATION_TO	Exactly one email address (and only an address) to which the mail should be sent. Additional recipients can be specified in `KDUMP_NOTIFICATION_CC`. <KDUMP_NOTIFICATION_TO>bwalle@suse.de</KDUMP_NOTIFICATION_TO>	optional (email notification is disabled if empty)
KDUMP_NOTIFICATION_CC	Zero, one or more recipients that are in the Cc line of the notification mail. <KDUMP_NOTIFICATION_CC>spam@suse.de devnull@suse.de</KDUMP_NOTIFICATION_CC>	optional
KDUMP_SMTP_SERVER	Host name of the SMTP server that will be used for the mail delivery. Please note that the SMTP authentication is supported (see `KDUMP_SMTP_USER` and `KDUMP_SMTP_PASSWORD`) but TSL and SSL are not supported. <KDUMP_SMTP_SERVER>email.suse.de</KDUMP_SMTP_SERVER>	optional (email notification is disabled if empty)
KDUMP_SMTP_USER	User name that is used together with `KDUMP_SMTP_PASSWORD` for SMTP authentication. <KDUMP_SMTP_USER>bwalle</KDUMP_SMTP_USER>	optional
KDUMP_SMTP_PASSWORD	Password that is used together with `KDUMP_SMTP_USER` for SMTP authentication. <KDUMP_SMTP_PASSWORD>geheim</KDUMP_SMTP_PASSWORD>	optional

4.19.3.4. Kdump kernel settings

As already mentioned, a special kernel is booted to save the dump. If you don't want to use the auto-detection 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 that 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 even specify the command line which will be used to boot the kdump kernel. Normally the boot command line is used minus some settings that hurt in the kdump case (like the crashkernel parameter itself) plus some settings that are needed in the kdump case (see the manual page kdump(5)). If you just want some additional parameters like a overwritten console setting then use KDUMP_COMMANDLINE_APPEND. If you know what you're doing and you want to specify the whole command line, set KDUMP_COMMANDLINE.

Table 4.20. XML representation of the kernel settings

Element	Description	Comment
KDUMP_KERNELVER	Version string for the kernel that will be 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. Normally `KDUMP_COMMANDLINE_APPEND` is the setting you're looking for. <KDUMP_COMMANDLINE_APPEND>root=/dev/sda5 maxcpus=1 irqpoll</KDUMP_COMMANDLINE>	optional (email notification is disabled if empty)

4.19.3.5. Expert settings

Table 4.21. XML representation of the expert settings

Element	Description	Comment
KDUMP_IMMEDIATE_REBOOT	`true` if the system should be rebooted automatically after the dump has been saved, `false` otherwise. The default is to reboot the system automatically. <KDUMP_IMMEDIATE_REBOOT>true</KDUMP_IMMEDIATE_REBOOT>	optional
KDUMP_VERBOSE	Bitmask that specifies how to 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

4.19.4. Ask the user for values during installation

This feature is only available since SUSE Linux 10.1 and SLES10.

You have the option to let the user decide the values of specific parts of the profile during the installation. If you use that feature, a popup will come up during the installation and will ask the user to enter a specific part of the profile. So if you want a full auto installation but you want the user to set the password of the local account, you can do this via the ask directive in the profile.

The following elements must be between the <ask-list config:type="list"><ask> ... </ask></ask-list> tags in the <general> section.

Table 4.22. XML representation

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 I recommend to enter a question)
default	you can set a pre-selection for the user. A textentry will be filled out with this value, a checkbox will be "true" or "false" and a selection will have this default "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 "symbol","boolean","string" and "integer". The filesystem in the partition section is a symbol, while the "encrypted" element in the user configuration is a boolean. You can see the type of that element if you look in your profile at the config:type="...." attribute. Since openSUSE 11.2 (not SLES11) you can use "static_text" as type too. A static_text is just a text that does not require any user input and can be used to show information if it's not wanted in the help text. <type>symbol</type>	optional. The defaul is string. If type is "symbol" you must provide the selection element too (see below)
password	if this boolean is set to "true", a password dialog pops up instead of a simple text entry. Setting this to "true" makes only sense if "type" is string. <password config:type="boolean">true</password>	optional. The default is "false"
path (deprecated since openSUSE 11.0 - use pathlist)	The path to the element in the profile. It's a comma seperated list of elements that describes the path to the element you want to change. For example, the ldap server element can be found in the profile in the <ldap><ldap_server> section. So if you want to change that value, you have to set the path to "ldap,ldap_server". If you want to change the password of the first user in the profile, you have to set the path to "users,0,user_password". The "0" indicates the first user in the <users config:type="list"> list of users in the profile. <path>networking,dns,hostname</path>	this information is optional but you should at least provie path or file
pathlist (available since openSUSE 11.0 and replaces path)	a list of path elements (see above) <pathlist config:type="list"><path>networking,dns,hostname</path><path>...</path>	this information is optional but you should at least provie path or file
file (available since SLES10 SP1 and SL 10.2)	you can store the answer to a question in a file, to use it in one of your scripts later. If you ask during stage=inital and you want to use the answer in stage2, then you have to copy the answer-file in a chroot script that is running as chrooted=false. Do it like this "cp /tmp/my_answer /mnt/tmp/". The reason for that is, that /tmp in stage1 is just in the RAM disk and will get lost after the reboot but the installed system is already mounted at /mnt/ <file>/tmp/answer_hostname</file>	this information is optional but you should at least provie path or file
password	if this boolean is set to "true", a password dialog pops up instead of a simple text entry. Setting this to "true" makes only sense if "type" is string. <password config:type="boolean">true</password>	optional. The default is "false"
stage	stage configures the installation stage where the question pops up. You can set this value to "cont" or "initial". "initial" means the popup comes up very early in the installation, short after the pre-script has run. "cont" means, that the dialog with the question comes after the first reboot, when the system boots for the very first time. Questions you answer during the "inital" stage, will write their answer into the profile on the harddisk. You should know that if you enter cleartext passwords during "initial". Of course it does not make sense to ask for a filesystem to use in the "cont" phase. The harddisk is already partitioned at that stage and the question will have no effect. <stage>cont</stage>	optional. The default is "initial"
selection	the selection element contains a list of <entry> elements. Each entry represents a possible option for the user to choose. So the user can't enter a value in a textfield, but he can choose from a list of values. <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 type=string, not possible for type=boolean and a must have for type=symbol
dialog (available since SL 10.3 and SLES10 SP2)	Since OpenSUSE 10.3 you can have more than one question per dialog. To make that possible you have to specifiy the dialog-id with an integer. All questions with the same dialog-id are on the same dialog. The dialogs are sorted by the id too. <dialog config:type="integer">3</dialog>	optional
element (available since SL 10.3 and SLES10 SP2)	Since OpenSUSE 10.3 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 on a dialog are sorted by the id. <element config:type="integer">1</element>	optional (see dialog>
frametitle (available since SL 10.3 and SLES10 SP2)	Since OpenSUSE 10.3 you can have more than one question per dialog. Each question on a dialog has a frame that can have a frametitle. A small caption for each question if you want so. Since openSUSE 11.3 you can put multiple elements into one frame. They have to have the same frametitle then. <frametitle>User data</frametitle>	optional (default is no frametitle)
script (available since SL 10.3 not in SLES10 SP1)	with 10.3 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 (available in openSUSE 11.2 (not SLES11)	You can change the Label on the "Ok" button. The last element that specifies the label for a dialog wins. <ok_label>Finish</ok_label>	optional
back_label (available in openSUSE 11.2 (not SLES11)	You can change the Label on the "Back" button. The last element that specifies the label for a dialog wins. <back_label>change values</back_label>	optional
timeout (available in openSUSE 11.2 (not SLES11)	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/changes any widget in the dialog, the timeout is turned off and the dialog has to be confirmed by the ok-button. <timeout config:type="integer">30</timeout>	optional. A missing value is interpreted as 0 which means that there is no timeout
default_value_script (available since openSUSE 11.2 but not in SLES11)	with 11.2 you can run scripts to set the default value for a question(see the table below for detailed instructions about default value scripts). It's useful if you can "calculate" a useful default value, especially in combination with the "timeout" option. <default_value_script>...</default_value_script>	optional (default is no script)

The following elements must be between the <ask-list config:type="list"><ask><default_value_script>...</default_value_script>...</ask></ask-list> tags in the <general> section. It's available since 11.2 (not SLES11).

Table 4.23. XML representation

Element	Description	Comment
source	the source code of the script. Whatever you echo to STDOUT will be used as default value for the ask-dialog. If your script has an exit code other than 0, the normal default element is used. Take care you echo with "echo -n" to suppress the '\n' and that you echo reasonable values and not "okay" for a boolean <source>...</source>	this value is required. Otherwise nothing would be executed
interpreter	the interpreter to use <interpreter>perl</interpreter>	default is shell (you can set "/bin/myinterpreter" as value too)

The following elements must be between the <ask-list config:type="list"><ask><script>...</script>...</ask></ask-list> tags in the <general> section. It's available since 10.3 (not SLES10 SP1).

Table 4.24. XML representation

Element	Description	Comment
filename	the filename of the script <filename>my_ask_script.sh</filename>	default is ask_script.sh
source	the source code of the script. Together with "rerun_on_error" on you check the value that was entered for sanity (since 11.0 only). Your script can create a file "/tmp/next_dialog" with a dialog id in it. That's the next dialog autoyast will raise then. A value of -1 terminates the ask sequence. If that file is not created, autoyast will run the dialogs in a normal order (since 11.0 only) <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 "VAL". <environment config:type="boolean">true</environment>	optional (default is "false").
feedback	a boolean that turns on feedback for the script execution. That means that STDOUT will be shown in a popup box that must be confirmed after the script execution. <feedback config:type="boolean">true</feedback>	optional (default is "false").
debug	a boolean that turns on debugging for the script execution <debug config:type="boolean">true</debug>	optional (default is "true"). This value needs feedback to be turned on too.
rerun_on_error (available since openSUSE 11.0)	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 popup an error with the "feedback" option. <rerun_on_error config:type="boolean">true</rerun_on_error>	optional (default is "false"). This value should be used together with the feedback option.

Below you can see an example of the usage of the "ask" feature.

<general>
  <ask-list config:type="list">
      <ask>
          <!-- deprecated since openSUSE 11.0; use pathlist instead
          <path>ldap,ldap_server</path>
          -->
          <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>
          <!-- deprecated since openSUSE 11.0; use pathlist instead
          <path>networking,dns,hostname</path>
          -->
          <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>
          <!-- deprecated since openSUSE 11.0; use pathlist instead
          <path>partitioning,0,partitions,0,filesystem</path>
          -->
          <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 is a nice way to choose between autoyast profiles. Autoyast will read the "modified.xml" file again after the ask-dialogs are done. So we can fetch a complete new profile.

      <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>

Since openSUSE 11.0 you can verify the answer of a question with a script like this:

     <ask>
          <script>
            <filename>my.sh</filename>
            <rerun_on_error config:type="boolean">true</rerun_on_error>
            <environment config:type="boolean">true</environment>
            <source><![CDATA[
if [ "$VAL" = "myhost" ]; then
    echo "Illegal Hostname!";
    exit 1;
fi
exit 0
]]>
            </source>
            <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>
          <!-- deprecated since openSUSE 11.0; use pathlist instead
          <path>networking,dns,hostname</path>
          -->
          <pathlist config:type="list">
              <path>networking,dns,hostname</path>
          </pathlist>
          <question>Enter Hostname</question>
          <default>enter your hostname here</default>
      </ask>


4.18. Adding complete configurations		Chapter 5. Network Based Installation