Fedora Server Technical Specification
|
This is an approved document
It was originally approved by the Server Working Group on January 17, 2014, and by FESCo on January 22, 2014. It is now archived and no longer valid. |
This document aims to describe the technical characteristics of the Fedora Server product in detail. This includes provided services and APIs, installed software, and the like. Some of the desired characteristics may not be entirely achievable in the first version of the Server product, and will be approximated.
The content of this specification unavoidably overlaps with the work of the Base Working Group, and needs to be aligned with their deliverables.
Core Services and Features
This section should describe the core services of the platform and their intended use. The items here should refer back to the Product Requirements Document (2014) for a functional justification.
Supported Architectures and Install Media
Fedora Server will run on and provide install media for i686, x86_64, and armv7hl servers.
There will be two official install media for the Fedora Server
-
A network installation media (either a traditional netinst.iso or a boot.fedoraproject.org style)
-
A local installation media providing the default package set as well as any featured roles that are meaningfully installed without a network connection.
-
The local installation media will be allowed a maximum size to fit on a 4.0GB USB device.
-
The local installation media can be pointed at network resources to make available a larger package set.
-
File system
The default file system type for Fedora Server installs will be XFS running atop LVM for all partitions except /boot. The /boot partition will remain a non-LVM partition due to technological limitations of the bootloader.
File-system layout will be discussed with the Anaconda team and reasonable defaults will be selected based on a combination of the number of available, selected disks and the available memory on the system (for determining SWAP space).
An option will be provided in the Fedora Server installer to enable disk encryption.
Service management
Systemd provides ways to control and monitor the activity and status of system services, resources they require, and the like. System services must provide systemd units to be included in the Fedora Server standard installation. See the systemd documentation.
Logging
Fedora Server will store log files locally by default and will also support sending full log data to an external server to the maximum extent possible. For writing to logs, we recommend the syslog or journal APIs rather than managing application-specific log files. OpenLMI will provide an API for reading the logs.
We will use rsyslog for forwarding data to a central server. The logs of programs using the recommended APIs will be locally stored in the journal database and automatically forwarded; other programs should include appropriate configuration for rsyslog such that their log output is included in the rsyslog-forwarded data stream.
Networking
Network devices and connections will be controlled by NetworkManager by default. Server Roles that may need to interact with the network configuration must do so through the public NetworkManager D-BUS API.
Firewall
A firewall in its default configuration may not interfere with the normal operation of programs installed by default.
On a pristine system, the only open incoming ports are SSH and Cockpit. When Roles are deployed, they may elect to open one or more ports based on the most likely need. Roles must provide an interface that describes which ports they want open and which ones they currently have opened. The admin must be able to easily modify this configuration.
Roles that open ports by default must have the set of ports approved by majority vote of the Server Working Group.
If the user hasn’t specified firewall status explicitly, interactive role deployment will inform the user whether the service’s ports have been opened by default. It must be possible to query the API for the required state of the firewall to support the role, which can then be compared to the active firewalld state.
The OpenLMI project will provide a public, external API to manage firewalld centrally. (This is not yet scheduled for a Fedora release, but is a medium-term plan.)
SELinux
SELinux will be enabled in enforcing mode, using the targeted policy. The Fedora Server standard install and all promoted Server Roles must operate in enforcing mode.
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.
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.
Software updates
Software updates on the Fedora Server must be possible to perform either locally using command-line tools (e.g. yum/dnf) or centrally by common management systems (e.g. Puppet, Chef, Satellite, Spacewalk, OpenLMI).
Accessibility
Accessibility support on the Fedora Server will be limited to devices supporting the vision-impaired on the console.
Accessibility support in the optional graphical environment will be aligned with the Fedora Workstation offering.
Input Methods
The input method support for the Fedora Server console access will be limited to LOCALE support in the command shell.
Input method support in the optional graphical console will be aligned with the Fedora Workstation offering.
Graphics and Display Manager
The Fedora Server does not mandate a graphical environment at this time. If the administrator elects to install a desktop, they should choose a display manager themselves at this time.
Appearance
The default user-experience for the Fedora Server will be the bash shell on the console and the Cockpit web management console.
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 should 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 standard installation. Options to install Fedora Server Roles will be provided, as well as a UI to install other software from the Fedora Project repositories.
Fedora Server will expect to be the sole citizen on the system. Support for coexisting with other operating systems is not a goal.
Fedora Server will use kickstart as implemented by pyKickstart and Anaconda as the unattended installation mechanism.
Server Roles
The Server Roles listed below are approved to be worked on in the Fedora 21 timeframe.
The public D-BUS API to support Server Roles will be provided from the Cockpit Project.
Role Definition Requirements
Roles will be required to provide both a D-BUS API and a web management plugin for the Cockpit management console. During the development of the first few Fedora Server Roles, the Cockpit project will drive the effort of designing this interface.
Roles will be required to support the following API:
-
A mechanism to install the packages necessary to deploy the role. This may include an API for specifying optional components at this time.
-
A mechanism to deploy a role whose packages are installed on the system by providing the necessary information to provision it.
-
A mechanism to install optional components of a role after deployment.
-
A configuration interface to modify high-level configuration options.
-
A query interface providing metadata information about the role (not all roles must implement all parts of this, bold lines are mandatory):
-
A list of system services provided by the role, 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 role operates on for some or all interfaces.
-
If the Role is designed to operate on the network, it should automatically open those ports (see firewall during deployment.
-
A list of files on the filesystem that should be included in a backup set.
-
An interface to set processor affinity, memory limits, etc. where sensible.
-
Whether the role is running in a container.
-
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 list will be the priority focus for QA and bug fixing.
Want to help? Learn how to contribute to Fedora Docs ›