Applies to SUSE Linux Enterprise Server 15

D Main differences between SUSE Linux Enterprise Server 12 and 15 profiles

  • Filename: ay_12_migrate_15.xml
  • ID: appendix.ay_12vs15
Abstract

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 a profiles with SUSE Linux Enterprise Server 15, you need to adjust them as documented here.

D.1 Product selection

Starting with SUSE Linux Enterprise Server 15, all products are distributed using a single installation medium. Therefore you need to choose which product to install by using the product tag. In the following example SUSE Linux Enterprise Desktop is the chosen product:

<software>
  <products config:type="list">
    <product>SLED</product>
  </products>
</software>>

In special cases, the medium may contain only one product. If so there is not need to explicitly select a product as described above. AutoYaST will select the only available product automatically.

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. This heuristic is based on the package and pattern selection in the profile. However, whenever possible, avoid using this mechanism and adapt old profiles to use explicit product selection.

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

D.2 Software

The SUSE Linux Enterprise Server 15 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-Packages ISO containing all modules and extensions. Using this medium does not require access to a registration server during the installation. It can be shared on local the network via an installation server.

Note
Note: Maintenance Updates

Only using the registration server will grant the access to all maintenance update 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 installed.

Example D.1: Adding Modules and Extensions (online)
<suse_register>
 <addons config:type="list">
  <addon>
   <name>sle-module-basesystem</name>
   <version>15</version>
   <arch>x86_64</arch>
  </addon>
  <addon>
   <name>sle-module-server-applications</name>
   <version>15</version>
   <arch>x86_64</arch>
   </addon>
  <addon>
   <name>sle-module-live-patching</name>
   <version>15</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-Packages ISO

To add a module or extension using the SLE-15-Packages ISO create entries in the add-on section as shown in the example below. The following XML code adds the Basesystem module from a DVD created from the ISO:

Example D.2: Adding Modules and Extensions (offline)
<add-on>
 <add_on_products config:type="list">
  <listentry>
   <media_url><![CDATA[dvd:///]]></media_url>
   <product>sle-module-basesystem</product>
   <product_dir>/Module-Basesystem</product_dir>
  </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.

If you have multiple physical DVD drives you can select a specific device using devices parameter in the URL, for example dvd:///?devices=/dev/sr1.

Tip
Tip: >Using SLE-15-Packages Medium from a Local Server

You can share the DVD content on the local network via a NFS, FTP or HTTP server. In that case 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_packages/</media_url>

D.2.3 Renamed Software Patterns

Software patterns have also changed in SUSE Linux Enterprise Server 15. Some patterns have been renamed, a short summary is 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

Please, check carefully if all required packages are available in the defined patterns and adjust the profiles accordingly. Additionally, the required patterns and packages have 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, optionally use the packages tag to specify additional packages.

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

D.3 Registration of Module and Extension Dependencies

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

Also AutoYaST automatically adds the depending modules even though they are missing in the profile. That 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 that is designed to allow new capabilities that were not possible before. Despite of the back-end change, the AutoYaST, we managed not to change the XML syntax for profiles. However, SUSE Linux Enterprise Server 15 comes with some general changes, which are explained in the following.

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 would like to retain the old behavior, you could explicitly indicate this in the profile 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 in order to specify a partition to be reused. Refer to Section 4.5.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) setting the primary_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 at all) 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 behaviour, 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 the 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.5 Firewall configuration

In SUSE Linux Enterprise Server 15, SuSEfirewall2 has been replaced by firewalld as the default firewall. The configuration of both 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 updated profiles for SLE 15 as outlined below. If keeping SLE 12 profiles we recommend to check the final configuration to avoid an unexpected behavior or network security threats.

Table D.1: AutoYaST Firewall Configuration in SLE 15: Backwards 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 support by YaST and AutoYaST—you can make use of them with post installation scripts in your AutoYaST profile.a See Section 4.30, “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>true</enable_firewall>
 <start_firewall>true</start_firewall>
 ...
</firewall>

The following examples will 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 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>
    <interface>eth0</interface>
   </interfaces>
  </zone>
  <zone>
   <name>public</name>
   <interfaces>
    <interface>eth1</interface>
   </interfaces>
  </zone>
  <zone>
   <name>trusted</name>
   <interfaces>
    <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, 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} tag 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.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 SLE 12 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 2nd Stage

A regular installation is performed in single stage, while an installation performed via AutoYaST needs two stages in most of the cases. In order 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 a SLE 12 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, 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 cleanup 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 can not select a different migration target.

After upgrading a not registered system or skipping registration upgrade by ommitting the suse_register option, you might need to adjust the repository setup manually.

Print this page