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.
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.
<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:
<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>
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.
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 Pattern | New 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.
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:
<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:
<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.
Supported (but deprecated) | Unsupported |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| |
| |
|
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.
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.
firewalld
zones #
| SuSEfirewall2 (SLE 12) |
---|---|
dmz | DMZ |
external |
EXT with |
public |
EXT with |
internal |
INT with |
trusted |
INT with |
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
.
<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>
<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.
<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>
<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
.
<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>
<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
.
<firewall> <FW_CONFIGURATIONS_EXT>dhcp dhcpv6 samba vnc-server</FW_CONFIGURATIONS_EXT> <FW_CONFIGURATIONS_DMZ>ssh</FW_CONFIGURATIONS_DMZ> </firewall>
<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:
SuSEfirewall2 Service Definitions: https://en.opensuse.org/SuSEfirewall2/Service_Definitions_Added_via_Packages
firewalld
RPM Packaging https://en.opensuse.org/firewalld/RPM_Packagingfirewalld
already provides support for the majority of important services in/usr/lib/firewalld/services
. Check this directory for an existing configuration before defining a new one.
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:
<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.
<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.