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.
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
The features and properties specified here are the basis for the specification of Fedora Server release criteria and release blockers.
This section describes the basic properties and features of the platform and their intended use.
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.
===
[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
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]
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.
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).
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.
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.
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.
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.
System locale, timezone, hostname, etc. will be managed through the services provided by systemd for this purpose, specifically
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.
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.
The input method support for the Fedora Server console access is the LOCALE support in the command shell.
Accessibility support on the Fedora Server will be limited to devices supporting the vision-impaired on the console.
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).
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.
libvirt-daemon will be used to manage virtualization capabilities.
Fedora CoreOS KVM VM image must be installable in a KVM virtual machine.
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.
Fedora Server Editions does support various different container technologies.
Podman must be installable and usable right out of the box.
A systemd-nspawn container must be installable and usable right out of the box.
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.
Supported Server Services are supposed facilitate the following functions
Depending on practical experience, Fedora Server may additionally need:
Ansible is the projected administration tool.
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.
The Fedora Server Database Management Systemn is provided by the PostgreSQL project.
This Server Service is a blocker for the release of Fedora Server.
The Fedora Server Fileservice will be provided by the Samba project.
The Fedora Server Web Server will be provided by the Apache project.
The Fedora Server Web Applicationserver Service will be provided by the Wildfly project.
The Fedora Server Mail Service will be provided by the Postfix project and supporting projects like Dovecot, Spamassessin, Dkim, etc.
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 ===
Contributors to this document include:
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe