# Fedora Server Technical Specification Proposal 2022

*Draft 2*

[Abstract]
This document aims to describe the technical characteristics and properties of the Fedora Server Edition in detail. This includes provided services and APIs, 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
* **Specifically Supported Server Services**
describe various services which Fedora Server can validly and concurrently offer to users. Additionally, these are support by Ansible provided administratve assistance.

In terms of content, Fedora Base Specification and the work of the [Fedora Base Working Group](https://fedoraproject.org/wiki/Base) are the basis of this specification.

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.

There will be four official install media for the Fedora Server
* 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. It will be allowed a *maximum size of 720 mb*.
* 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. Therefore, it should not exceed a *maximum size of 2.5 gb*.
* 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 as well as protection against system-wide effects and incursions of local file system errors or other impairments – 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 (i.e. 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 standard efi or biosboot partition as required (GPT only)
* creates a /boot standard partition of 1 GB using XFS
* creates a Volume Group with one Logical Volume of 15 GB at maximum for 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 provides the option to skip the default partitioning at all and to create custom a partitioning from scratch according to one's own requirements and secure storage considerations without any restrictions.

The use of software raid storage requires a custom partitioning, even if the system administrator wants to use default partitioning otherwise.

The installer provides an option to enable disk encryption, too.

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

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

### 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 for local logging. For writing to logs, we recommend the syslog or journal APIs rather than managing application-specific log files.

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.

Fedora Server uses the recommended APIs to store log information locally in the journal database and forward automatically; other programs should include appropriate configuration for rsyslog such that their log output is included in the rsyslog-forwarded data stream.

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

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. Puppet, Chef, Satellite, Spacewalk, OpenLMI).

### 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. But is is not specifically supported or a requirement.

### 3.2 Containerization

Fedora Server Editions does support various differenz 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. Specifically Supported Server Services

The specifically supported server services 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 Supported Server Service 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 Specifically Supported Server Service Administration

Ansible is the projected administration tool.

### 4.4 Projected Specifically Supported Server Services

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

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

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

This is not yet scheduled for a Fedora release, but is a medium-term plan
* Centralized management
* OpenLMI will provide an API for reading the logs.
* The OpenLMI project will provide a public, external API to manage firewalld centrally.

## 6. Appendix

### 6.1 Core Package list

List the core packages of the product. This list includes all packages that will be shipping on the core media. This 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 ===

### 6.2 Authors

Contributors to this document include:

TBD