Differences Between AutoYaST Profiles in SLE 42.3 and 15 | AutoYaST Guide

openSUSE Leap Documentation › AutoYaST Guide › Appendices › Differences Between AutoYaST Profiles in SLE 42.3 and 15

AutoYaST Guide

Navigation←→

Applies to openSUSE Leap 15.2

D Differences Between AutoYaST Profiles in SLE 42.3 and 15 #Edit source

Significant changes in openSUSE Leap 15, like the new modules concept or replacing SuSEfirewall2 with firewalld, required changes in AutoYaST. If you want to reuse existing openSUSE Leap 42.3 profiles with openSUSE Leap 15, you need to adjust them as documented here.

D.1 Partitioning
D.2 Firewall Configuration
D.3 NTP Configuration
D.4 AutoYaST Packages Are Needed for the Second Stage
D.5 The CA Management Module Has Been Dropped
D.6 Upgrade

D.1 Partitioning #Edit source

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, openSUSE Leap 15 comes with some general changes, which are explained below.

D.1.1 GPT Becomes the Default Partition Type on AMD64/Intel 64 #Edit source

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

D.1.2 Setting Partition Numbers #Edit source

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.4.3.2, “Partition Configuration” for more information.

D.1.3 Forcing Primary Partitions #Edit source

It is still possible to force a partition as primary (only on MS-DOS partition tables) by 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.1.4 Btrfs: Default Subvolume Name #Edit source

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.1: 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.2: 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.1.5 Btrfs: Disabling Subvolumes #Edit source

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.1.6 Reading an Existing `/etc/fstab` Is No Longer Supported #Edit source

On openSUSE Leap 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.1.7 Setting for Aligning Partitions Has Been Dropped #Edit source

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.1.8 Using the `type` to Define an Volume Group #Edit source

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

D.2 Firewall Configuration #Edit source

In openSUSE Leap 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 Leap 15 as outlined below. If keeping Leap 42.3 profiles, we recommend to check the final configuration to avoid unexpected behavior or network security threats.

Table D.1: AutoYaST Firewall Configuration in Leap 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 openSUSE Leap. 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.29, “Custom User Scripts” for more information.

Note: Enabling and Starting the Firewall

Enabling and starting the systemd service for firewalld is done with the same syntax as in Leap 42.3. 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 Leap 15 syntax:

D.2.1 Assigning Interfaces to Zones #Edit source

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` (Leap 15)	SuSEfirewall2 (Leap 42.3)
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.2.1.1 Default Configuration #Edit source

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

Example D.3: 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.4: Assigning Zones: Default Configuration (Leap 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.2.1.2 Masquerading and Protecting Internal Zones #Edit source

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

Example D.5: 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.6: Masquerading and Protecting Internal Zones (Leap 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.2.2 Opening Ports #Edit source

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.7: 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.8: Opening Ports (Leap 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.2.3 Opening `firewalld` Services #Edit source

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.9: 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.10: Opening Services (Leap 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:

SuSEfirewall2 Service Definitions: https://en.opensuse.org/SuSEfirewall2/Service_Definitions_Added_via_Packages
firewalld RPM Packaging https://en.opensuse.org/firewalld/RPM_Packaging
firewalld 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.2.4 For More Information #Edit source

Official firewalld Documentation

D.3 NTP Configuration #Edit source

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 Leap 42.3 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.11: NTP configuration (Leap 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.4 AutoYaST Packages Are Needed for the Second Stage #Edit source

A regular installation is performed in a single stage, while an installation performed via AutoYaST usually needs two stages. 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.5 The CA Management Module Has Been Dropped #Edit source

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

D.6 Upgrade #Edit source

D.6.1 Software #Edit source

Leap 42.3 has two modes of evaluating which packages need to be upgraded. In openSUSE Leap 15.2, 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.

Print this page