Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / SUSE Linux Enterprise Serverマニュアル / AutoYaST Guide / Appendixes / Differences between AutoYaST profiles in SLE 12 and 15
Applies to SUSE Linux Enterprise Server 15 SP3

D Differences between AutoYaST profiles in SLE 12 and 15

Significant changes in SUSE Linux Enterprise Server 15, like the new modules concept or replacing SuSEfirewall2 with firewalld, required changes in AutoYaST. If you want to reuse existing SUSE Linux Enterprise Server 12 profiles with SUSE Linux Enterprise Server 15, you need to adjust them as documented here.

D.1 Product selection

For backward compatibility with profiles created for pre-SLE 15 products, AutoYaST implements a heuristic that selects products automatically. This heuristic will be used when the profile does not contain a product element. Automatic product selection is based on the package and pattern selection in the profile. However, whenever possible, avoid relying on this mechanism and adapt old profiles to use explicit product selection.

For information about explicit product selection, refer to Section 4.9.1, “Product selection”.

If automatic product selection fails, an error is shown and the installation will not be continued.

D.2 Software

The SUSE Linux Enterprise Server 15 SP3 installation medium only contains a very minimal set of packages to install. This minimal set only provides an installation environment and does not include any server applications or advanced tools. Additional software repositories, providing more packages are offered as modules or extensions. They are provided via two alternatives:

  • via a registration server (the SUSE Customer Center or a local SMT/RMT proxy)

  • via the SLE-15-SP3-Full-ARCH-GM-media1.iso image containing all modules and extensions. Using this medium does not require access to a registration server during installation. It can be shared on the local network via an installation server.

Note
Note: Maintenance updates

Only using the registration server will grant access to all maintenance updates at installation time. Maintenance updates are not available when using the DVD medium without registration.

D.2.1 Adding modules or extensions using the registration server

To add a module or extension from the registration server, use the addons tag for each module/extension in the suse_register section. Extensions require an additional registration code, which can be specified with the reg_code tag.

The following XML code adds the Basesystem and Server Applications modules and the Live Patching extension. To get the respective values for the tags name, version, and arch, run the command SUSEConnect --list-extensions on a system that already has SLE 15 SP3 installed.

Example D.1: Adding modules and extensions (online)
<suse_register>
 <addons config:type="list">
  <addon>
   <name>sle-module-basesystem</name>
   <version>15.3</version>
   <arch>x86_64</arch>
  </addon>
  <addon>
   <name>sle-module-server-applications</name>
   <version>15.3</version>
   <arch>x86_64</arch>
   </addon>
  <addon>
   <name>sle-module-live-patching</name>
   <version>15.3</version>
   <arch>x86_64</arch>
   <reg_code>REGISTRATION_CODE</reg_code>
  </addon>
 </addons>
</suse_register>

Refer to Section 4.3, “System registration and extension selection” for more information.

D.2.2 Adding modules or extensions using the SLE-15-SP3-Full-ARCH-GM-media1.iso image

To add a module or extension using the SLE-15-SP3-Full-ARCH-GM-media1.iso image, create entries in the add-on section as shown in the example below. The following XML code adds the Basesystem module from a USB flash drive that contains the image:

Example D.2: Adding modules and extensions (offline)
<add-on>
 <add_on_products config:type="list">
  <listentry>
   <media_url><![CDATA[dvd:///?devices=/dev/sda%2C/dev/sdb%2C/dev/sdc%2C/dev/sdd]]></media_url>
   <product_dir>/Module-Basesystem</product_dir>
   <product>sle-module-basesystem</product>
  </listentry>
 </add_on_products>
</add-on>
Note
Note: Product name matching

The product tag must match the internal product name contained in the repository. If the product name does not match at installation AutoYaST will report an error.

Tip
Tip: Using the installation media image from a local server

You can share the content of the USB flash drive on the local network via an NFS, FTP or HTTP server. To do so, replace the URL in the media_url tag so it points to root of the medium on the server, for example:

<media_url>ftp://ftp.example.com/sle_15_sp3_full/</media_url>

D.2.3 Renamed software patterns

Software patterns have also changed since SUSE Linux Enterprise Server 15. Some patterns have been renamed; a short summary is provided in the following table.

Old SLE 12 PatternNew SLE 15 Pattern

Basis-Devel

devel_basis

gnome-basic

gnome_basic

Minimal

enhanced_base

printing

print_server

SDK-C-C++

devel_basis

SDK-Doc

technical_writing

SDK-YaST

devel_yast

Carefully check if all required packages are available in the defined patterns and adjust the profiles accordingly. Additionally, the required patterns and packages need to be available in the activated extensions or modules.

Notes
  • The pattern renames in the table above are not 1:1 replacements; the content of some patterns has been changed as well, some packages were moved to a different pattern or even removed from SUSE Linux Enterprise Server 15.

  • Check that the required packages are still included in the used patterns, and optionally use the packages tag to specify additional packages.

  • The list above might be incomplete, as some products have not been released for SUSE Linux Enterprise Server 15, yet.

D.3 Registration of module and extension dependencies

Starting with SUSE Linux Enterprise Server 15, AutoYaST automatically reorders the extensions according to their dependencies during registration. This means the order of the extensions in the AutoYaST profile is not important.

Also AutoYaST automatically adds the dependent modules even though they are missing in the profile. This means you are not required to specify all required modules. However, if an extension depends on another extension, it needs to be specified in the profile, including the registration key. Otherwise the registration would fail.

You can list the available extensions and modules in a registered system using the SUSEConnect --list-extensions command.

D.4 Partitioning

The partitioning back-end previously used by YaST, libstorage, has been replaced by libstorage-ng which is designed to allow new capabilities that were not possible before. Despite the back-end change, the XML syntax for profiles has not changed. However, SUSE Linux Enterprise Server 15 comes with some general changes, which are explained below.

D.4.1 GPT becomes the default partition type on AMD64/Intel 64

On AMD64/Intel 64 systems, GPT is now the preferred partition type. However, if you prefer to retain the old behavior, you can explicitly indicate this in the profile by setting the disklabel element to msdos.

D.4.2 Setting partition numbers

AutoYaST will no longer support forcing partition numbers, as it might not work in some situations. Moreover, GPT is now the preferred partition table type, so partition numbers are less relevant.

However, the partition_nr tag is still available to specify a partition to be reused. Refer to Section 4.5.3.2, “Partition configuration” for more information.

D.4.3 Forcing primary partitions

It is still possible to force a partition as primary (only on MS-DOS partition tables) by setting the partition_type to primary. However, any other value, like logical, will be ignored by AutoYaST, which will automatically determine the partition type.

D.4.4 Btrfs: Default subvolume name

The new storage layer allows the user to set different default subvolumes (or none) for every Btrfs file system. As shown in the example below, a prefix name can be specified for each partition using the subvolumes_prefix tag:

Example D.3: Specifying the Btrfs default subvolume name
<partition>
 <mount>/</mount>
 <filesystem config:type="symbol">btrfs</filesystem>
 <size>max</size>
 <subvolumes_prefix>@</subvolumes_prefix>
</partition>

To omit the subvolume prefix, set the subvolumes_prefix tag:

Example D.4: Disabling Btrfs subvolumes
<partition>
 <mount>/</mount>
 <filesystem config:type="symbol">btrfs</filesystem>
 <size>max</size>
 <subvolumes_prefix>@</subvolumes_prefix>
</partition>

As a consequence of the new behavior, the old btrfs_set_default_subvolume_name tag is not needed and, therefore, it is not supported anymore.

D.4.5 Btrfs: Disabling subvolumes

Btrfs subvolumes can be disabled by setting create_subvolumes to false. To skip the default @ subvolume, specify subvolumes_prefix.

<partition>
 <create_subvolumes config:type="boolean">false</create_subvolumes>
 <subvolumes_prefix><![CDATA[]]></subvolumes_prefix>
</partition>]]>

D.4.6 Reading an existing /etc/fstab is no longer supported

On SUSE Linux Enterprise Server 15 the ability to read an existing /etc/fstab from a previous installation when trying to determine the partitioning layout, is no longer supported.

D.4.7 Setting for aligning partitions has been dropped

As cylinders have become obsolete, the partition_alignment> tag makes no sense and it is no longer available. AutoYaST will always try to align partitions in an optimal way.

D.4.8 Using the type to define a volume group

The is_lvm_vg element has been dropped in favor of setting the type to the CT_LVM value. Refer to Section 4.5.5, “Logical volume manager (LVM)” for further details.

D.5 Firewall configuration

In SUSE Linux Enterprise Server 15, SuSEfirewall2 has been replaced by firewalld as the default firewall. The configuration of these two firewalls differs significantly, and therefore the respective AutoYaST profile syntax has changed.

Old profiles will continue working, but the supported configuration will be very limited. It is recommended to update profiles for SLE 15 as outlined below. If keeping SLE12 profiles, we recommend to check the final configuration to avoid unexpected behavior or network security threats.

Table D.1: AutoYaST firewall configuration in SLE 15: backward compatibility

Supported (but deprecated)

Unsupported

FW_CONFIGURATIONS_\{DMZ, EXT, INT}

FW_ALLOW_FW_BROADCAST_\{DMZ, EXT, INT}

FW_DEV_\{DMZ, EXT, INT}

FW_IGNORE_FW_BROADCAST_\{DMZ, EXT, INT}

FW_LOG_DROP_ALL

FW_IPSECT_TRUST

FW_LOG_DROP_CRIT

FW_LOAD_MODULES

FW_MASQUERADE

FW_LOG_ACCEPT_ALL

FW_SERVICES_\{DMZ, INT, EXT}_\{TCP, UDP, IP}

FW_LOG_ACCEPT_CRIT

FW_PROTECT_FROM_INT

FW_ROUTE

FW_SERVICES_\{DMZ, EXT, INT}_RPC

FW_SERVICES_ACCEPT_RELATED_\{DMZ, EXT, INT}

Configuration options from SuSEfirewall2 that are no longer available either have no equivalent mapping in firewalld or will be supported in future releases of SUSE Linux Enterprise Server. Some firewalld features are not yet supported by YaST and AutoYaST—you can use them with post installation scripts in your AutoYaST profile. See Section 4.31, “Custom user scripts” for more information.

Note
Note: Enabling and starting the firewall

Enabling and starting the systemd service for firewalld is done with the same syntax as in SLE 12. This is the only part of the firewall configuration syntax in AutoYaST that has not changed:

<firewall>
 <enable_firewall config:type="boolean">true</enable_firewall>
 <start_firewall config:type="boolean">true</start_firewall>
 ...
</firewall>

The following examples show how to convert deprecated (but still supported) profiles to the SLE 15 syntax:

D.5.1 Assigning interfaces to zones

Both SuSEfirewall2 and firewalld are zone-based, but have a different set of predefined rules and a different level of trust for network connections.

Table D.2: Mapping of SuSEfirewall2 and firewalld zones

firewalld (SLE 15)

SuSEfirewall2 (SLE 12)

dmz

DMZ

external

EXT with FW_MASQUERADE set to yes

public

EXT with FW_MASQUERADE set to no

internal

INT with FW_PROTECT_FROM_INT set to yes

trusted

INT with FW_PROTECT_FROM_INT set to no

block

N/A

drop

N/A

home

N/A

work

N/A

In SuSEfirewall2 the default zone is the external one (EXT) but it also allows the use of the special keyword any to assign all the interfaces that are not listed anywhere to a specified zone.

D.5.1.1 Default configuration

The following two examples show the default configuration that is applied for the interfaces eth0, eth1, wlan0 and wlan1.

Example D.5: Assigning zones: default configuration (deprecated syntax)
<firewall>
 <FW_DEV_DMZ>any eth0</FW_DEV_DMZ>
 <FW_DEV_EXT>eth1 wlan0</FW_DEV_EXT>
 <FW_DEV_INT>wlan1</FW_DEV_INT>
</firewall>
Example D.6: Assigning zones: default configuration (SLE 15 syntax)
<firewall>
 <default_zone>dmz</default_zone>
 <zones config:type="list">
  <zone>
   <name>dmz</name>
   <interfaces config:type="list">
    <interface>eth0</interface>
   </interfaces>
  </zone>
  <zone>
   <name>public</name>
   <interfaces config:type="list">
    <interface>eth1</interface>
   </interfaces>
  </zone>
  <zone>
   <name>trusted</name>
   <interfaces config:type="list">
    <interface>wlan1</interface>
   </interfaces>
  </zone>
 </zones>
</firewall>

D.5.1.2 Masquerading and protecting internal zones

The following two examples show how to configure the interfaces eth0, eth1, wlan0 and wlan1 with masquerading and protected internal zones.

Example D.7: Masquerading and protecting internal zones (deprecated syntax)
<firewall>
 <FW_DEV_DMZ>any eth0</FW_DEV_DMZ>
 <FW_DEV_EXT>eth1 wlan0</FW_DEV_EXT>
 <FW_DEV_INT>wlan1</FW_DEV_INT>
 <FW_MASQUERADE>yes</FW_MASQUERADE>
 <FW_PROTECT_FROM_INT>yes</FW_PROTECT_FROM_INT>
</firewall>
Example D.8: Masquerading and protecting internal zones (SLE 15 syntax)
<firewall>
 <default_zone>dmz</default_zone>
 <zones config:type="list">
  <zone>
   <name>dmz</name>
   <interfaces config:type="list">
    <interface>eth0</interface>
   </interfaces>
  </zone>
  <zone>
   <name>external</name>
   <interfaces config:type="list">
    <interface>eth1</interface>
   </interfaces>
  </zone>
  <zone>
   <name>internal</name>
   <interfaces config:type="list">
    <interface>wlan1</interface>
   </interfaces>
  </zone>
 </zones>
</firewall>

D.5.2 Opening ports

In SuSEfirewall2 the FW_SERVICES_\{DMZ,EXT,INT}_\{TCP,UDP,IP,RPC} tags were used to open ports in different zones.

For TCP or UDP, SuSEfirewall2 supported a port number or range, or a service name from /etc/services with a single tag for the respective zone and service. For IP services a port number or range, or a protocol name from /etc protocols could be specified with FW_SERVICES_ZONE_IP.

For firewalld each port, port range, and service requires a separate entry in the port section for the respective zone. IP services need separate entries in the protocol section.

RPC services, which were supported by SuSEfirewall2, are no longer supported with firewalld.

Example D.9: Opening ports (deprecated syntax)
<firewall>
 <FW_SERVICES_DMZ_TCP>ftp ssh 80 5900:5999</FW_SERVICES_DMZ_TCP>
 <FW_SERVICES_EXT_UDP>1723 ipsec-nat-t</FW_SERVICES_EXT_UDP>
 <FW_SERVICES_EXT_IP>esp icmp gre</FW_SERVICES_EXT_IP>
 <FW_MASQUERADE>yes</FW_MASQUERADE>
</firewall>
Example D.10: Opening ports (SLE 15 syntax)
<firewall>
 <zones config:type="list">
  <zone>
   <name>dmz</name>
   <ports config:type="list">
    <port>ftp/tcp</port>
    <port>ssh/tcp</port>
    <port>80/tcp</port>
    <port>5900-5999/tcp</port>
   <ports>
  </zone>
  <zone>
   <name>external</name>
   <ports config:type="list">
    <port>1723/udp</port>
    <port>ipsec-nat-t/udp</port>
   </ports>
   <protocols config:type="list">
    <protocol>esp</protocol>
    <protocol>icmp</protocol>
    <protocol>gre</protocol>
   </protocols>
  </zone>
 </zones>
</firewall>

D.5.3 Opening firewalld services

For opening a combination of ports and/or protocols, SuSEfirewall2 provides the FW_CONFIGURATIONS_\{EXT, DMZ, INT} tags which are equivalent to services in firewalld.

Example D.11: Opening Services (Deprecated Syntax)
<firewall>
 <FW_CONFIGURATIONS_EXT>dhcp dhcpv6 samba vnc-server</FW_CONFIGURATIONS_EXT>
 <FW_CONFIGURATIONS_DMZ>ssh</FW_CONFIGURATIONS_DMZ>
</firewall>
Example D.12: Opening services (SLE 15 syntax)
<firewall>
 <zones config:type="list">
  <zone>
   <name>dmz</name>
   <services config:type="list">
    <service>ssh</service>
   </services>
  </zone>
  <zone>
   <name>public</name>
   <services config:type="list">
    <service>dhcp</service>
    <service>dhcpv6</service>
    <service>samba</service>
    <service>vnc-server</service>
   </services>
  </zone>
 </zones>
</firewall>

The services definition can be added via packages in both cases:

D.5.4 More information

D.6 NTP configuration

The time server synchronization daemon ntpd has been replaced with the more modern daemon chrony. Therefore the configuration syntax for the time-keeping daemon in AutoYaST has changed. AutoYaST profiles from SLE12 that contain a section with ntp:client need to be updated.

Instead of containing low level configuration options, NTP is now configured by a set of high level options that are applied on top of the default settings:

Example D.13: NTP configuration (SLE 15 syntax)
<ntp-client>
 <ntp_policy>auto</ntp_policy>
 <ntp_servers config:type="list">
  <ntp_server>
   <iburst config:type="boolean">false</iburst>
   <address>cz.pool.ntp.org</address>
   <offline config:type="boolean">true</offline>
  </ntp_server>
 </ntp_servers>
 <ntp_sync>systemd</ntp_sync>
 </ntp-client>

D.7 AutoYaST packages are needed for the second stage

A regular installation is performed in a single stage, while an installation performed via AutoYaST usually needs two stages. To perform the second stage of the installation AutoYaST requires a few additional packages, for example autoyast2-installation and autoyast2. If these are missing, a warning will be shown.

D.8 The CA management module has been dropped

The module for CA Management (yast2-ca-management) has been removed from SUSE Linux Enterprise Server 15, and for the time being there is no replacement available. In case you are reusing SLE12 profile, make sure it does not contain a ca_mgm section.

D.9 Upgrade

D.9.1 Software

SLE 12 has two modes of evaluating which packages need to be upgraded. In SUSE Linux Enterprise Server 15 SP3, upgrades are always determined by the dependency solver, equivalent to using zypper dup.

This makes the option only_installed_packages in the software section obsolete.

D.9.2 Registration

When upgrading a registered system, all old repositories are removed. This is done to avoid possible conflicts between the new and old repositories and to clean-up the repositories for the dropped products. If you need to keep custom repositories, add them again using the add-on option.

Example D.14: Minimal registration configuration for upgrade
<suse_register>
  <do_registration config:type="boolean">true</do_registration>
</suse_register>

If the registration server returns more than one possible migration target, AutoYaST will automatically select the first one. Currently you cannot select a different migration target.

After upgrading an unregistered system or skipping registration upgrade by omitting the suse_register option, you might need to adjust the repository setup manually.