Autoyast network install

About Us. Success Stories. Investor Relations. Social Impact. Merchandise Store. Communications Preferences. How to configure network parameters for AutoYaST network installation This document is provided subject to the disclaimer at the end of this document.

When network parameters such as speed and duplex cannot be configured through autonegotiation, they must be set manually. The two possible scenarios in which this would have to be done are for network installation via AuotYaST and for an existing installation.

Network Installation The ethtool boot parameter may be used to configure the network parameters for network installation via AutoYaST.

This boot parameter can be placed in an AutoYaST info file, or when booting from the installation media, entered into the boot options field of the boot menu.

Open Source Projects. SUSE Italia. SUSE Israel. SUSE Luxembourg. SUSE Nederland. SUSE Polska. SUSE Suomi. About Us. Success Stories. Investor Relations. Social Impact. This configuration is merged with the one defined in the AutoYaST profile. AutoYaST settings have higher priority than any existing configuration files. Otherwise, it applies the settings from the profile file. Asking AutoYaST to set up the network in the early stages is useful when installation on a network is needed, but the configuration is too complex to define it using linuxrc see Section 6.

If the configuration is written at the end of installation, it will not be applied until the system is rebooted. Network settings and service activation are defined under the profile networking global resource. Additionally, there are a few elements that allow modifying how the network configuration is applied:. As described in Section 4.

If you want to use just the configuration from the profile, set this element to false. The value is true by default. Use the network configuration defined in the profile during the installation process. Otherwise, AutoYaST relies on the configuration set by linuxrc.

In that, it shows a warning whose timeout is controlled by this element. If it is set to 0 , the installation is stopped. The interfaces section allows the user to define the configuration of interfaces, including how they are started, their IP addresses, networks, and more. It is required to specify the IP using the ipaddr element. This value is used for bridges and bonding slaves. Used only with static boot protocol.

It can include a network prefix, for example: Use prefixlen instead or include the network prefix in the ipaddr element. Use ipaddr with prefixlen instead. Useful for USB network cards, for example. Priority for ifplugd daemon.

It determines in which order the devices are activated. Required for bonding devices. Each slave needs to have a unique number. Space-separated list of bridge ports, for example, eth0 eth1. Used only with a bridge device and required for it. Spanning tree protocol. Possible values are on when enabled and off when disabled. Used only with bridge devices. Valid values are between 4 and The net-udev element allows to specify a set of udev rules that can be used to assign persistent names to interfaces.

For example: f0:de:fb:da for a MAC rule, c. When creating an incomplete udev rule set, the chosen device name can collide with existing device names.

For example, when renaming a network interface to eth0 , a collision with a device automatically generated by the kernel can occur.

AutoYaST tries to handle such cases in a best effort manner and renames colliding devices. The dns section is used to define name-service related settings, such as the host name or name servers. Host name, excluding the domain name part. For example: foo instead of foo. However, this is not the correct usage in the dns section of YaST. The resolver should determine the FQDN. The routing table allows to specify a list of routes and the packet forwarding settings for IPv4 and IPv6.

Required: Route destination. An address prefix can be specified, for example: The heading default can be used to indicate that the route is the default gateway in the same address family ipv4 or ipv6 as the gateway. Specifying the prefix as part of the destination value is preferred. Optional: Further route options like the metric , mtu or table.

Using the nis resource, you can configure the target machine as a NIS client. The following example shows a detailed configuration using multiple domains. You can configure the target machine as a NIS server. Values: auto. Select if your passwd file should be merged with the shadow file only possible if the shadow file exists.

A host address will be allowed if network is equal to the bitwise AND of the host's address and the netmask. The entry with netmask Also start the map transfer daemon. Fast Map distribution; it will speed up the transfer of maps to the slaves. Already existing entries will not be deleted. The following example shows details. Using the samba-client resource, you can configure membership of a workgroup, NT domain, or Active Directory domain.

A map of two maps keys: establish, revoke. Each map contains entries in the format key: domainname value: password. The configuration file must be in the JSON format. Verify that both autoyast2 and autoyast2-installation are installed. Click OK when done. The following examples show how both NFS client and server can be configured. 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.

The most common options are 'static' and 'auto' default. See man 8 netconfig for more details. When the offline option is set to true it will prevent the client from polling the time server if it is not available when chronyd is started. Polling will not resume until it is started manually with chronyc online. This command does not survive a reboot.

Setting it to false ensures that clients will always attempt to contact the time server, without administrator intervention. The following example illustrates an IPv6 configuration. You may use the server's IP address, host name, or both:.

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. These settings can be exported via the menu File. To run an Apache server correctly, make sure the firewall is configured appropriately. Each list entry contains the name, type, and additional options.

Use the YaST Squid configuration module to get an overview of possible entries. The Access Control table is checked in the order listed here. The first matching entry is used.

Host can contain a host name or IP address or remain empty. The refresh patterns are checked in the order listed here. Min determines how long in minutes an object should be considered fresh if no explicit expiry time is given. Max is the upper limit of how long objects without an explicit expiry time will be considered fresh. Percent is the percentage of the object's age time since last modification. An object without an explicit expiry time will be considered fresh.

Use the YaST Squid configuration module to get an overview about possible entries. Disallow downloading of files that were uploaded but not validated by a local admin. Specify the name of a file containing the text to display when someone connects to the server.

When enabled, local users will by default be placed in a chroot jail in their home directory after login. To allow anonymous users to upload, enable AnonReadOnly. This limits the number of clients allowed to connect from a single source Internet address. File creation mask, in the format umask for files : umask for directories. To specify octal values, remember the "0" prefix, otherwise the value will be treated as a base integer. By using virtual users, FTP accounts can be administrated without affecting system accounts.

Use this to enable a server for TFTP trivial file transfer protocol. The server will be started using the systemd socket. Boot Image Directory: Specify the directory where served files are located. The directory will be created if it does not exist.

The server uses this as its root directory using the -s option. On the first boot after the installation, users are guided through a series of steps that allow for easier configuration of a system.

YaST firstboot does not run by default and needs to be configured to run. Using the features of this module, you can 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 is similar to the Custom Settings in the security module available in the running system. This allows you create a customized configuration. See the reference for the meaning and the possible values of the settings in the following example. Change various password settings. 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 do not support this, and you may have problems with NIS. Blowfish is also supported. Additionally, you can set up the system to check for password plausibility and length etc.

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. Change various login settings. Configuring SELinux mode. Possible values are permissive,enforcing and disabled. This module allows the configuration of the audit daemon and to add rules for the audit subsystem.

This parameter tells how many records to write before issuing an explicit flush to disk. Set RAW to log all data store in a format exactly as the kernel sends it or NOLOG to discard all audit information instead of writing it to disk does not affect data sent to the dispatcher. If USER is set, the user-defined name is used.

NONE means no computer name is inserted. FQD uses the fully qualified domain name. You can edit the rules manually, which we only recommend for advanced users. For more information about all options, see man auditctl. To be able to log in, make sure that either the root users are set up or rootpassword is specified as a linuxrc option. The following example shows a more complex scenario. If not existing, the file will be created with the content specified. It is possible to specify rootpassword in linuxrc and have a user section for the root user.

If this section is missing the password, then the password from linuxrc will be used. Passwords in profiles take precedence over linuxrc passwords. Each user on a Linux system has a numeric user ID. You can either specify such a user ID within the AutoYaST control file manually by using uid , or let the system automatically choose a user ID by not using uid. User IDs should be unique throughout the system.

If not, some applications such as the login manager gdm may no longer work as expected. When doing so, unique IDs cannot be guaranteed. It should be a valid user name. Check man 8 useradd if you are not sure. User ID. It should be a unique and must be a non-negative number. Initial group ID. It must be a unique and non-negative number. Moreover it must refer to an existing group.

Absolute path to the user's home directory. Generates the home directory in a Btrfs subvolume. Disabled by default. If you choose another one, make sure that it is installed adding the corresponding package to the software section. If you enter an exclamation mark! A user's password can be written in plain text not recommended or in encrypted form.

To create an encrypted password, use mkpasswd. To enable or disable the use of encrypted passwords in the profile, see the encrypted parameter.

Considered false if not present. Indicates if the user's password in the profile is encrypted or not. AutoYaST supports standard encryption algorithms see man 3 crypt. See example below. The profile can specify a set of default values for new users like password expiration, initial group, home directory prefix, etc.

Default login shell. Location of the files to be used as skeleton when adding a new user. You can find more information in man 8 useradd.

Set the file creation mode mask for the home directory. By default useradd will use Check man 8 useradd and man 1 umask for further information. It should be a valid group name. Check man 8 groupadd if you are not sure. The group's password can be written in plain text not recommended or in encrypted form.

Check the encrypted to select the desired behavior. A list of users who belong to the group. User names must be separated by commas.

Two special login settings can be enabled through an AutoYaST profile: autologin and password-less login. Both of them are disabled by default. 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:. 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.

AutoYaST will read the modified file after the pre-script finishes. It is also possible to modify the storage devices in your pre-scripts. For example, you can create new partitions or change the configuration of certain technologies like multipath. AutoYaST always inspects the storage devices again after executing all the pre-install scripts.

Pre-scripts are executed at an early stage of the installation. 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.

These scripts are executed after AutoYaST has completed the system configuration and after it has booted the system for the first time. These scripts are executed when YaST has finished, during the initial boot process after the network has been initialized. Init scripts are configured using the tag init-scripts. Init scripts are different from the rest of script types because they are not executed by YaST, but after YaST has finished.

For this reason, their XML representation is different from other script types. Define a location from where the script gets fetched. If you do not want to put the whole shell script into the XML profile, use the location parameter. The file name of the script.

Optional in case you only have a single init script. The default name init-scripts is used in this case.

If having specified more than one init script, you must set a unique name for each script. Change this default behavior by setting this boolean to true. Default is false scripts only run once. When added to the control file manually, scripts need to be included in a CDATA element to avoid confusion with the file syntax and other tags defined in the control file. Most of the XML elements described below can be used for all the script types described above, except for init scripts , whose definitions can contain only a subset of these elements.

Either location or source must be defined. If you do not want to put the whole shell script into the XML control file, refer to the location parameter. Specify the interpreter that must be used for the script. Supported options are shell and perl. 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. If filename is not defined and location is defined, the file name from the location path will be used.

The user needs to confirm them via the OK button. This can be message , warning or error. If this is true , every single line of a shell script is logged. Perl scripts are run with warnings turned on. This only works for the deprecated keyword interpreter.

This text will be shown in a pop-up for the time the script is running in the background. It is possible to specify parameters given to the script being called. You may have more than one param entry. They are concatenated by a single space character on the script command line. If any shell quoting should be necessary for example to protect embedded spaces you need to include this. A script is only run once. Optional; default is false , meaning that scripts only run once.

If this parameter is set to false , AutoYaST does not run chroot and does not install the boot loader at this stage. Optional; default is false. This option is only available for chroot environment scripts. 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:.

Sysconfig variables, offer the possibility to fine-tune many system components and environment variables exactly to your needs. Both relative and absolute paths can be provided. For many applications and services you may have a configuration file which should be copied to the appropriate location on the installed system.

For example, if you are installing a Web server, you may have a server configuration file httpd. 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. A more advanced example is shown below.

After the file has been copied to the system, a script is executed. This can be used to modify the file and prepare it for the client's environment. 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 default value is the path to the element the path often looks strange, so we recommend entering a question. Set a preselection for the user.

A text entry will be filled out with this value. A check box will be true or false and a selection will have the given value preselected. The type of the element you want to change. Possible values are symbol , boolean , string and integer. The file system in the partition section is a symbol, while the encrypted element in the user configuration is a boolean. The default is string. If type is symbol , you must provide the selection element too see below.

If this boolean is set to true , a password dialog pops up instead of a simple text entry. Setting this to true only makes sense if type is string.

A list of path elements. A path is a comma separated list of elements that describes the path to the element you want to change. This information is optional but you should at least provide path or file. You can store the answer to a question in a file, to use it in one of your scripts later. This information is optional, but you should at least provide path or file. Stage configures the installation stage in which the question pops up.

You can set this value to cont or initial. Questions you answer during the initial stage will write their answer into the control file on the hard disk. You should know that if you enter clear text passwords during initial. Of course it does not make sense to ask for the file system to use during the cont phase. The hard disk is already partitioned at that stage and the question will have no effect.

The selection element contains a list of entry elements. Each entry represents a possible option for the user to choose. The user cannot enter a value in a text box, but they can choose from a list of values. You can ask more than one question per dialog.

To do so, specify 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. You can have more than one question per dialog. To make that possible you need to specify the element-id with an integer. The questions in a dialog are sorted by ID. You can increase the default width of the dialog. If there are multiple width specifications per dialog, the largest one is used.

The number is roughly equivalent to the number of characters. You can increase the default height of the dialog.

If there are multiple height specifications per dialog, the largest one is used. The number is roughly equivalent to the number of lines. 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 need to have the same frame title.

You can run scripts after a question has been answered. See the list below for detailed instructions about scripts. You can change the label on the Ok button. The last element that specifies the label for a dialog wins.

You can change the label on the Back button. 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 needs to be confirmed via Ok. Optional; a missing value is interpreted as 0 , which means that there is no timeout. You can run scripts to set the default value for a question see Section 4.

This feature is useful if you can calculate a default value, especially in combination with the timeout option. You can run scripts to set the default value for a question. The source code of the script.

If your script has an exit code other than 0, the normal default element is used. The default value is shell. A value of -1 terminates the ask sequence.

If that file is not created, AutoYaST will run the dialogs in the normal order since A boolean that passes the value of the answer to the question as an environment variable to the script. The variable is named VAL. A boolean that turns on feedback for the script execution.

Optional, default is true. This value needs feedback to be turned on, too. 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 feedback option. 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. The following example shows a to choose between AutoYaST control files. AutoYaST will read the modified. This way you can fetch a complete new control file. With Kdump the system can create crashdump files if the whole 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.

There is a downside to this. It does not describe how Kdump works. For details, refer to the kdump 7 manual page. 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.

The kernel can auto-detect the right offset except for the Xen hypervisor, where you need to specify 16M as offset. The amount of memory that needs to be reserved depends on architecture and main memory. Refer to Section 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:. On the other hand, it is possible to specify multiple values for the crashkernel parameter. For example, when you need to reserve different segments of low and high memory, use values like 72M,low and M,high :.