Product SiteDocumentation Site

2. Changes in Fedora for System Administrators

2.1. Fedora Modularity

Fedora Modularity is attempting to disconnect the lifecycles of applications from each other and also from that of the operating system, while still maintaining the ease of use of a typical Linux distribution. More information about this work is available in the Fedora Modularity documentation.

2.1.1. Modular Server Preview

Fedora 26 contains a "preview" release of a modular Fedora Server Edition.

Not for production use

The Fedora 26 Modular Server Preview is a working version of the Server Edition but it is still a prototype and so it should not be used in a production environment.
The purpose of this preview release is to request feedback from the user community. The Modularity Working Group would like to hear from anyone experimenting with the preview about how it does or does not meet their expectations. Contact details for the Modularity Working Group are on the Fedora Modularity home page.

2.2. Kernel

2.2.1. aarch64 48-bit Virtual Address Space

Before Fedora 26, the aarch64 kernel in Fedora used a 42-bit process virtual address (VA) space and due to the way aarch64 paging works, this constrained the maximum physical address as well. The 42-bit VA was fairly limiting for some applications, but aarch64 processors also have support for 48-bit VAs.
For Fedora 26, Fedora has introduced a 48-bit VA and so larger aarch64 processes won't be constrained by the virtual or physical limitations of a 42-bit VA. This change also helps with things like hugetlb's and potentially provides a performace boost. Additionally, it allows Fedora to boot on a class of machines that have the majority of their RAM higher in the address space.
Its unlikely a desktop user will notice the change, except possibly that Fedora might now boot on additional hardware. A server user might find that there is more RAM available for in-memory databases etc.

2.3. Installation

2.3.1. Anaconda Changes

This section covers changes in the Anaconda installer, including changes in the graphical and text mode interactive installers, Kickstart, and installer boot options.
2.3.1.1. Changes in the Graphical Interface
  • A new, alternate partitioning interface provided by the the blivet-gui tool is now available in the manual partitioning sceeen. Unlike the existing partitioning interface, blivet-gui allows you to configure partitioning from the "bottom up": for example, in case of LVM you first create physical volumes, then a volume group, and then logical volumes, while in the old interface, you start with logical volumes and everything else is created automatically at first.
    The previous partitioning interface continues to be available as alongside the new one. For additional information, see the Fedora Project Wiki.
  • The installer now shows more detailed indication of current progress during all phases of the installation.
2.3.1.2. Changes in the Text Mode Interface
  • The text mode interface now supports setting up IP over Inifiniband IPoIB connections in the Networking screen.
  • The built-in help system, which was previously available in the graphical installation interface, has been extended to the text mode interface.
  • The Initial Setup post-setup text mode interface now runs on all available consoles.
2.3.1.3. Kickstart Changes
  • A new command, snapshot, has been added to provide LVM snapshot support for devices in an LVM thin pool. The command has the following syntax:
    snapshot vg/lv --name snapshot_name --when [post-install|pre-install]
    
    Available options are:
    • --name= - provide a name for the snapshot.
    • --when= - controls when the snapshot will be created. Use pre-install to create the snapshot before the installation begins, but after commands in the %pre part of the Kickstart are executed, or use post-install to create the snapshot after the installation and after commands in the %post part of the Kickstart are executed.
  • Three new options are now available for the autopart command:
    • --nohome - do not create a separate /home partition or volume if one would be created under partitioning rules
    • --noboot - do not create a separate /boot partition or volume
    • --noswap - do not create any swap space
2.3.1.4. Changes in Anaconda Boot Options
  • The inst.waitfornet= boot option is now available. Use it to force the installer to wait for network connectivity before starting the installer interface for a specified number of seconds - for example, inst.waitfornet=30 to wait 30 seconds.
  • A new option named inst.ksstrict is available. You can use it during a Kickstart-based installation to treat Kickstart warnings and error, meaning they will be printed on the output and the installation will terminate. Without specifying this option, warnings are printed to the log and the installation proceeds.
2.3.1.5. Other Anaconda Changes
  • Driver Update Disks can now be loaded from local disk devices.
  • Installclass can now modify rules for storage checks and their constraints.

2.3.2. ARM Support in Fedora Media Writer

Fedora Media Writer has gained the ability to write ARM images to SD cards and other portable media. Users, including those on Windows and macOS as well as on Fedora, will now be able to write Fedora images easily for Raspberry Pi 2 and above and for other supported ARM devices. Please note that this applies only for ARM devices where there are no changes/tweaks that need to be done to the Fedora image.
More information about this latest release of Fedora Media Writer can be found in the FMW 4.1.0 Release Notes.

2.3.3. DNF Rebased to 2.0

DNF, Fedora's package manager, has been rebased to version 2.0, which brings many bugfixes and improvements over DNF 1.x, as well as changes required to fix incompatibilities with Yum, the predecessor of DNF. This required the introduction of certain incompatibilities between DNF 2.0 and DNF 1.x. See Changes in DNF-2 compared to DNF-1 for details.
DNF 2.0 provides usability improvements, including better messages during resolution errors, showing whether a package was installed as a weak dependency, better handling of obsolete packages, fewer tracebacks, and others.

2.4. Security

2.4.1. System-wide Crypto Policy

The security of network communications is a high priority for the Fedora project, with strong TLS providing the first line of defense against traffic inspection. Two systems negotiating a TLS connection must agree on a common cipher to encrypt their communications, and as ciphers become deprecated, it is important to exclude them.
The ciphers that an administrator might consider adequately secure are determined by vulnerabilities published against specific ciphers. The acceptable cipher suite applies to all communications on the internet, and is not specific to any one system or daemon. To ease administration and increase adminsitrator confidence in the system's security posture, Fedora has been configuring various software to use a system-global configuration so that TLS ciphers need only be updated in one place.
With Fedora 26, two more things will use the system-wide crypto policy, OpenSSH and Java.
OpenSSH Crypto
OpenSSH clients will use system preferred key exchange algorithms, encryption ciphers, and message authentication code (MAC) algorithms. This is enabled by an Include directive in /etc/ssh/ssh_config to include directives in /etc/ssh/ssh_config.d/*.conf, which pulls in /etc/crypto-policies/back-ends/openssh.config.
Java Crypto
OpenJDK has been modified to read additional security properties from the generated crypto policies file at /etc/crypto-policies/back-ends/java.config
This change may affect connections to legacy systems that do not support more strict crypto policies. While it is possible to switch the system profile from DEFAULT to LEGACY, or to set security.useSystemPropertiesFile=false in a project's java.security file (refer to https://docs.oracle.com/javase/8/docs/technotes/guides/security/PolicyFiles.html), it would be best to also update legacy applications to modern security standards.

2.4.2. OpenSSL 1.1.0

The introduction of OpenSSL 1.1.0 in Fedora 26 brings many big improvements, new cryptographic algorithms, and API changes that allow for keeping the ABI stable in future upgrades. There is also now a compat-openssl10 package in Fedora that provides OpenSSL 1.0.2 for dependent applications that cannot move to 1.1.0 yet.
There is more information about OpenSSL 1.1.0 in the OpenSSL wiki.

2.4.3. OpenSC Replaces Coolkey

Fedora 26 is not shipping the Coolkey PKCS#11 module in the NSS database by default. Instead, there will be the OpenSC PKCS#11 module, which supports more different Smart Cards. The Coolkey package will be removed in Fedora 27. If other applications were using Coolkey, they should be able to switch to OpenSC.
In case you still need Coolkey in the NSS DB, you can add it manually using modutil -dbdir /etc/pki/nssdb -add "CoolKey PKCS #11 Module (manual)" -libfile libcoolkeypk11.so -force (the different name is used to prevent automatic removals when updating coolkey package).
Soon (during F26 cycle) there will be fully-featured 0.17.0 update to OpenSC with all the tested features and cards that should serve as a complete replacement of Coolkey.

2.4.4. SSSD fast cache for local users

SSSD has shipped with a very fast memory cache in the last couple of Fedora releases. However, using this cache conflicts with nscd's caching and nscd has been disabled by default. That degrades performance, because every user or group lookup must open the local files.
From Fedora 26, a new SSSD "files" provider will resolve users from the local files. That way, the "sss" NSS module can be configured before the files module in nsswitch.conf and the system can leverage sss_nss caching for both local and remote users. As a result, user and group resolution in Fedora will be much faster.

2.4.5. Authconfig cleanup

Obsolete and unmaintainable code was removed from authconfig. Notably:
  • The graphical interface (system-config-authentication) and the interactive text mode, which relied on old and unmaintained libraries (GTK+2 and Glade) have been removed from the distribution.
  • The command line tool, which has been deprecated previously, continues to be part of the distribution for legacy reasons. However, some deprecated and obsolete functionality such as support for WINS and HESIOD has been removed in this release.
The removal effort is happening because current modern environments support automatic configuration of remote user identities using Realmd and SSSD and do not require manual configuration through an interactive interface such as system-config-authentication. Some of the existing authconfig command line functionality is being preserved due to it still retaining some usefulness in certain environments, and to support the auth command in Kickstart. Removing parts of the code base that are no longer maintainable makes it easier to continue providing this functionality.

2.5. Mail Servers

2.5.1. Cyrus IMAP Server Upgraded to Version 3

In Fedora 26, the Cyrus IMAP server (cyrus-imapd) has been upgraded to version 3. This version brings significant new functionality, but it also has some new internal database formats. It has also changed the defaults for some important configuration settings. For these reasons it is important that you read and follow upstream's upgrade documentation before you initiate an update to Fedora 26.
Important changes to note:
  • Cyrus version 3 has changed the defaults for two important configuration options: unixhierarchysep and altnamespace. You may need to add them with their previously default value of 0 if these are not present in your existing configuration.
  • Cyrus version 3 no longer supports the berkeley database type. If you have essential databases in that format, it is important that you convert them to a different format before you update your system. However, if you have already updated, don't panic. The default Fedora configuration does use this format, but only for non-essential databases which you will rebuild while following the update documentation linked above.

2.6. X.Org

2.6.1. Retire Synaptics Driver

xorg-x11-drv-synaptics has been the main X.Org touchpad driver for over a decade. Since Fedora 22, it has been superseded by xorg-x11-drv-libinput which aims to provide a better touchpad experience.
Starting with Fedora 26:
  • a fresh installation of Fedora will install xorg-x11-drv-libinput instead of xorg-x11-drv-synaptics;
  • an upgrade from an earlier Fedora will install xorg-x11-drv-libinput and remove xorg-x11-drv-synaptics;
  • users that need the synaptics driver will need to manually install xorg-x11-drv-synaptics-legacy, which will install the synaptics driver and give it precedence over the libinput driver;
  • removing xorg-x11-drv-synaptics-legacy will remove the synaptics driver and the system will automatically revert to the libinput driver.