Fedora Server Technical Specification

Updated document as finalized at the Server Working Group IRC Meeting on August 17, 2022

This document aims to describe the technical characteristics and properties of the Fedora Server Edition in detail. This includes provided services, installed software, and the like. It also defines characteristics and features that are not yet or not fully implemented in the current Fedora Server Edition release.


Fedora Server provides a stable, flexible, and universally-adaptable base for the everyday provisioning of services and applications by organizations and individuals, based on the latest technology and available quickly after the upstream releases. It aims to empower users to deploy the services they need, whether using proven mature techniques or current technical developments, under their own control and adapted to their own needs. For this purpose, it provides a broad spectrum of available techniques from which users can choose completely independently and without predetermined valuations.


The specification defines implementation details, implementation variants, and especially extensions. They constitute a detailing and technical elaboration of the goals and principles as stated in the Fedora Server Product Requirements Document.

Specifically, it covers the following topics

  • Core Features

    describes the basic features and properities. They constitute the base system, which is installed by the (graphical) installer by default.

  • System Administration

    describes properties and capabilities of the default administration interface

  • Advanced Features

    describes additional features that are not part of the default (graphical) installation but require subsequent administrative action

  • Server Roles

    describe various services which Fedora Server can validly and concurrently offer to users. Additionally, these are specifically supported by Ansible provided administratve assistance.

The features and properties specified here are the basis for the specification of Fedora Server release criteria and release blockers.

1. Core Features

This section describes the basic properties and features of the platform and their intended use.

1.1 Supported Architectures and Install Media

Fedora Server will definitely run on and provide install media for x86_64 and aarch64 servers. The project may provide install media for additional architectures. But these are not part of standard quality management and may be available ephemerally.

  • A network installation media providing a minimal package set allowing to boot the system, connect to Internet and contact the Fedora media server to download packages to be installed.

  • A local installation media providing the default package set as well as any featured services that are meaningfully installed without a network connection.

    • It can additionally point at network resources to make available an ever larger package set.

    • Nevertheless, this media should be friendly to regions with limited Internet connection stability and performance. Thus, it is a trade-off between completeness and practical download size..

  • A virtual machine disk image for simplified installation of Fedora Server Edition in a KVM virtual environment. The image reproduces the Server Edition completely and without restrictions, as far as features are usable in a virtual environment.

  • A raw aarch64 disk image for installation on a Singe Board Computer (SBC).

1.2 File System and Storage Organization

Fedora Server gives the highest priority to maximum reliability and security of data with a maximum of possible performance.

To achieve this goal, Fedora Server encourages strict separation of system and user data and encourages to further isolate user data, e.g. by services. Any system maintenance must be possible with the least risk of endangering or compromising user data (e.g. by temporarly unmounting) and an error somewhere on the local disk storage should remain as isolated as possible and without system-wide impact.

Thus, Fedora Server Edition’s default installation

  • creates the necessary standard partitions to boot the server (BiosBoot, EFI, /boot)

  • creates a Volume Group with one Logical Volume of a reasonable minimal size to accomodate the root file system and system files using XFS

  • leaves the remaining space untouched for customization by the system administrator for user data, services or other uses. The installer must also support the following common options

    • enlarge the one logical volume to accomodate custom data as well without any separation (not recommended)

    • create one or more logical volumes to accomodate custom data

    • or even create an additional Volume Group dedicated to custom data

The installer also provides a custom partitioning interface to accommodate use cases beyond the scope of default partitioning.

Additionally, the installer shall provide an option to enable disk encryption.

1.3 Basic service and daemon management

Systemd provides ways to control and monitor the activity and status of system services, resources they require, and the like. All system services must provide systemd units to be included in the Fedora Server standard installation.

1.4 SELinux

SELinux will be enabled in enforcing mode, using the targeted policy. It must fully protect any installable system component and functional application.

Fedora Server Edition must include a user-friendly mechanism for identifying SELinux denials and find workarounds. Currently, Cockpit’s SELinux module provides this functionality.

Additionally, any Server Role we provide MUST also provide options to appropriately modify the system’s SELinux configuration (adjusting booleans, for example).

1.5 Networking

By default, NetworkManager controls and manages all network devices and connections. Any modifications or adjustments to the network configuration must use the NetworkManager configuration tools or the public NetworkManager D-BUS API.

Installation or First Boot must create a permanent configuration file for each physical network device found, or at least a stub configuratin file. Primarily, DHCP is to be used and enabled if available. Both must allow the system administrator to customize the default configuration without restriction.

1.6 Firewall

The default method in Fedora Server is firewalld. It is part of the basic initial installation and not deselectable.

The default initial configuration must provide the highest security possible with the ability of remote administration. But it may not interfere with the normal operation of programs installed by default.

Therefore, on a pristine default system, the only open incoming ports are SSH and Cockpit.

Configuration of ssh allows root access only with key-based login, if at all.

Additionally, any Server Role we provide MUST also provide options to appropriately display and modify firewalld’s configuration options.

1.7 Account handling

SSSD will provide the backing storage for identity management. The Fedora Server is expected to nearly always be configured for ‘centrally-managed’ user information; it must be possible to configure it to rely on a directory service for this information. Fedora Server will provide and support the realmd project for joining FreeIPA and Active Directory domains automatically. Interacting with other identity sources will remain a manual configuration effort.

1.8 Logging

Fedora Server uses systemd-journald and rsyslog for system logging. It’s recommended all applications submit logs to systemd-journald.

It stores log files locally by default and also supports sending full log data to an external server to the maximum extent possible. It uses rsyslog for forwarding data to a central server.

1.9 Miscellaneous System Information

System locale, timezone, hostname, etc. will be managed through the services provided by systemd for this purpose, specifically

  • localed: localectl

  • timedated: timedatectl

  • hostnamed: hostnamectl

1.10 System Installer

The desired installation experience for the Fedora Server product is to limit the pre-installation user interaction to the minimum. The storage configuration UI does provide a single sensible default and an alternative, fully customizable configuration UI.

Package selection will be supplementary.

Fedora Server expects to be the sole citizen on the system. Support for coexisting with other operating systems is not a goal.

Fedora Server supports kickstart as implemented by pyKickstart and Anaconda as the unattended installation mechanism.

2. System Administration

2.1 Appearance

The primary system management tool is CLI using bash on a system console. Locally, the default Fedora Server boots to a text terminal login screen. It expects the system administrator to type the required commands or using bash scripts or to use Ansible roles and plays.

The local login prompt must also display any appropriate information needed to establish remote administration of the system, in particular, Cockpit’s access URL (see next paragraph).

For remote installation, ssh and sftp are installed and activated by default. Additionally, Cockpit is installed and activated by default and provides a Web based graphical Interface to assist remote system administration.

The Fedora Server does not provide a local graphical environment. If the administrator elects to install a desktop, they should choose and install a display manager themselves.

2.2 Input Methods

The input method support for the Fedora Server console access is the LOCALE support in the command shell.

2.3 Accessibility

Accessibility support on the Fedora Server will be limited to devices supporting the vision-impaired on the console.

2.4 Software updates

Software updates on the Fedora Server must be possible to perform either locally using command-line tools (dnf), remote using ssh or Cockpit, or centrally by common management systems (e.g. Satellite, Ansible).

2.5 Problem reporting

Problems and error conditions (e.g. kernel oopses, Selinux AVCs, application crashes, OOM, disk errors) should all be reported in the systemd journal. Support for sending this information to a central place (like abrt does for crashes today) is mandatory.

3. Advanced Features

3.1 Virtualization

3.1.1 KVM / Libvirt

libvirt-daemon will be used to manage virtualization capabilities.

3.1.2 XEN based Virtualization

XEN based Virtualisation is available in Fedora and installable with Fedora Server. While it may work, Xen virtualization is not officially supported on Fedora Server.

3.2 Containerization

Fedora Server Editions does support various different container technologies.

3.2.1 Podman Application Container

Podman must be installable and usable right out of the box.

3.2.2 Systemd-nspawn System- and Application Container

A systemd-nspawn container must be installable and usable right out of the box.

3.2.3 Libvirt LXC System Container

A Libvirt LXC container must be installable and usable right out of the box.

4. Server Roles

Server Roles are a high level set of software services with additional administrative support to smoothness integrate into Fedora Server Edition and validated to operate concurrently and conflict-free in Fedora Server. An example is Mail Service, that includes various system services as postfix, dovecot and alike.

Server Roles are supposed to get developed in the Fedora 37 – 40 time frame.

4.1 Server Roles Requirements

Supported Server Services are supposed facilitate the following functions

  • A mechanism to install the packages necessary to deploy the service.

  • A mechanism to deploy a service whose packages are already installed on the system by providing the necessary information and procedures to provision it.

  • A mechanism to install optional components of a service after deployment.

  • A configuration interface to modify high-level configuration options.

  • A helper tool (preferrable based on LVM snapshot) to perform a backup or alternativ a list of files on the filesystem that should be included in a backup set.

Depending on practical experience, Server Roles may additionally need a query interface providing metadata information about the service (not all services must implement all parts of this):

  • A list of system services provided by the Supported Server Service, as well as data about whether those services are currently running (or enabled, in the case of socket-activated services)

  • A list of the ports that the role operates on, as well as data about whether those ports are currently firewalled.

  • A mechanism to open and close ports that the server service operates on for some or all interfaces.

  • If the Server Service is designed to operate on the network, it should automatically open those ports (see Firewall) during deployment.

  • An interface to set processor affinity, memory limits, etc. where sensible.

4.2 Server Role Administration

Ansible is the projected administration tool.

4.3 Projected Server Roles

4.3.1 Domain Controller

The Fedora Server Domain Controller Service will be provided by the FreeIPA project. This Server Service is a blocker for the release of Fedora Server.

4.3.2 Database Management System (DBMS)

The Fedora Server Database Management Systemn is provided by the PostgreSQL project. This Server Service is a blocker for the release of Fedora Server.

4.3.3 Local Network File Server service

The Fedora Server Fileservice will be provided by the Samba project.

4.3.4 WEB Server service

The Fedora Server Web Server will be provided by the Apache project.

4.3.5 Web Application Server service

The Fedora Server Web Application Server service will be provided by the Wildfly project.

4.3.6 Mail Service

The Fedora Server Mail Service will be provided by the Postfix project and supporting projects like Dovecot, Spamassassin, Dkim, etc.

5. Appendix

5.1 Core Package list

This list includes all packages the core media are shipping with the current release. It is the mandatory minimal list of packages that needs to be installed on a system at all times for it to qualify as a Fedora Server install. This package lists the priority focus for QA and bug fixing. To produce the list, issue the following command:


5.2 Authors

Contributors to this document include:

  • Stephen Gallagher (sgallagh)

  • Peter Boy (pboy)

  • Jason Beard (cooltshirtguy)

  • John Himpel (jwhimpel)

  • Chris Murphy (cmurf)

  • Emmanuel Seyman (eseyman)

  • Adam Williamson (adamw)