# Fedora Server Technical Specification Proposal 2022

*Draft 5*

[Abstract]
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.

## Preamble

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.

## Overview

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](https://docs.fedoraproject.org/en-US/server-working-group/docs/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 support 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.

===

### 1.2 File System and Storage Organization

[Alternative 1]
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*. Any system maintenance must be possible with the least risk of endangering or compromising user data (e.g. making them isolated by temporarly unmounting). It encourages to further separate user data, e.g. by services, to make them independant and unimpaired from each other in terms of filesystem issues.

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 of other uses, common options are
* enlarge the one logical volume to accomodate custom data as well (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 should provide a custom partitioning interface to accommodate use cases beyond the scope of default partitioning.

The installer should provide an option to enable disk encryption.
[End Alternative 1]

### 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. There will be no option in the installer to install less than the Fedora Server Edition standard installation.

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.

##### **Special Case CoreOS VM**

Fedora CoreOS KVM VM image must be installable in a KVM virtual machine.

#### 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.

## 4. Server Roles
Server Roles are a high level set of software services with additional administrativ support to smoothless 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.

Specfically Supported Server Services are supposed to get developed in the Fedora 37 – 40 timeframe.

### 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, Fedora Server may additionally need:
* A query interface providing metadata information about the service (not all servicesmust implement all parts of this, bold lines are mandatory):
* 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.4 Projected Server Roles

#### 4.4.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.4.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.4.3 Local Network Fileserver Service

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

#### 4.4.4 WEB Server Service

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

#### 4.4.5 Web Applicationserver Service

The Fedora Server Web Applicationserver Service will be provided by the Wildfly project.

#### 4.4.6 Mail Service

The Fedora Server Mail Service will be provided by the Postfix project and supporting projects like Dovecot, Spamassessin, 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:

=== TBD ===

### 5.2 Authors

Contributors to this document include:

* Stephen Gallagher (sgallagh)
* Peter Boy (pboy)
* Chris Murphy (cmurf)
* (more to come, hopefully)