Server/Technical Specification

From FedoraProject

< Server(Difference between revisions)
Jump to: navigation, search
(Firewall)
(Updates from technical spec working session)
Line 23: Line 23:
  
 
=== Logging ===
 
=== Logging ===
{{admon/warning | This is not yet approved! | This statement is a work-in-progress draft and has not been agreed upon yet. }}
 
  
 
Server will by default store log files locally, and to the maximum extent possible support sending full log data to an external server.  For writing to logs, we recommend the syslog or journal APIs, rather than managing application-specific log files.  An API for reading the logs will be provided through OpenLMI.
 
Server will by default store log files locally, and to the maximum extent possible support sending full log data to an external server.  For writing to logs, we recommend the syslog or journal APIs, rather than managing application-specific log files.  An API for reading the logs will be provided through OpenLMI.
Line 30: Line 29:
  
 
=== Networking ===
 
=== Networking ===
 
{{admon/warning | This is not yet approved! | This statement is a work-in-progress draft and has not been agreed upon yet. }}
 
  
 
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.
 
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.
Line 50: Line 47:
  
 
=== Problem reporting ===
 
=== Problem reporting ===
 
{{admon/warning | This is not yet approved! | This statement is a work-in-progress draft and has not been agreed upon yet. }}
 
  
 
Problems and error conditions (e.g. kernel oopses, Selinux AVCs, application crashes, OOM, disk errors) should all be reported in the systemd
 
Problems and error conditions (e.g. kernel oopses, Selinux AVCs, application crashes, OOM, disk errors) should all be reported in the systemd
Line 58: Line 53:
 
Support for sending this information to a central place (like abrt does for crashes today) is mandatory.
 
Support for sending this information to a central place (like abrt does for crashes today) is mandatory.
  
=== Session tracking ===
 
 
{{admon/warning | This is not yet approved! | This statement is a work-in-progress draft and has not been agreed upon yet. }}
 
 
Logind will be used as the session tracking facility.
 
 
Applications that need to interact with sessions can use the logind [http://www.freedesktop.org/software/systemd/man/sd_session_is_active.html library API], the [http://www.freedesktop.org/wiki/Software/systemd/logind/ D-Bus API], or a higher-level API
 
  
 
=== Account handling ===
 
=== Account handling ===
{{admon/warning | This is not yet approved! | This statement is a work-in-progress draft and has not been agreed upon yet. }}
 
  
 
SSSD is providing 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.
 
SSSD is providing 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.
 
The accountsservice is providing a D-Bus interface for user account information; this may be integrated into SSSD at some point.
 
 
Depending on their needs, application and services can either use the POSIX APIs (getpwent(), etc) or the accountsservice D-Bus interface to obtain
 
user information.
 
 
  
 
=== Software updates ===
 
=== Software updates ===
{{admon/warning | This is not yet approved! | This statement is a work-in-progress draft and has not been agreed upon yet. }}
 
  
 
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).
 
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).
  
 
=== Miscellaneous system information ===
 
=== Miscellaneous system information ===
{{admon/warning | This is not yet approved! | This statement is a work-in-progress draft and has not been agreed upon yet. }}
 
  
 
System locale, timezone, hostname, etc. will be managed through the services provided by systemd for this purpose.
 
System locale, timezone, hostname, etc. will be managed through the services provided by systemd for this purpose.
Line 92: Line 71:
  
 
=== Virtualization ===
 
=== Virtualization ===
{{admon/warning | This is not yet approved! | This statement is a work-in-progress draft and has not been agreed upon yet. }}
 
  
 
libvirt-daemon will be used to manage virtualization capabilities.
 
libvirt-daemon will be used to manage virtualization capabilities.
 
systemd-nspawn will be used to manage containerization capabilities.
 
systemd-nspawn will be used to manage containerization capabilities.
 
=== Display manager ===
 
{{admon/warning | This is not yet approved! | This statement is a work-in-progress draft and has not been agreed upon yet. }}
 
 
<Wording?>
 
  
  
 
=== Accessibility ===
 
=== Accessibility ===
{{admon/warning | This is not yet approved! | This statement is a work-in-progress draft and has not been agreed upon yet. }}
 
  
 
Accessibility support on the Fedora Server will be limited to devices supporting the vision-impaired on the console.
 
Accessibility support on the Fedora Server will be limited to devices supporting the vision-impaired on the console.
Line 111: Line 83:
  
 
=== Input Methods ===
 
=== Input Methods ===
{{admon/warning | This is not yet approved! | This statement is a work-in-progress draft and has not been agreed upon yet. }}
 
  
 
The input method support for the Fedora Server console access will be limited to LOCALE support in the command shell.
 
The input method support for the Fedora Server console access will be limited to LOCALE support in the command shell.
Line 117: Line 88:
 
Input method support in the optional graphical console will be aligned with the Fedora Workstation offering.
 
Input method support in the optional graphical console will be aligned with the Fedora Workstation offering.
  
=== Graphics ===
+
=== Graphics and Display Manager ===
{{admon/warning | This is not yet approved! | This statement is a work-in-progress draft and has not been agreed upon yet. }}
+
 
+
The optional graphical console will be aligned with the Fedora Workstation offering.
+
  
 +
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 ===
 
=== Appearance ===
  
{{admon/warning | This is not yet approved! | This statement is a work-in-progress draft and has not been agreed upon yet. }}
+
The default user-experience for the Fedora Server will be the bash shell on the console and the Cockpit web management console.
 
+
<Simo: do you want to talk about how the shell is configured, defaults, bash-completion, vim-enhanced/emacs/other plugins?>
+
 
+
Appearance of the optional graphical console will be aligned with the Fedora Workstation offering.
+
 
+
=== Application Integration ===
+
 
+
{{admon/warning | This is not yet approved! | This statement is a work-in-progress draft and has not been agreed upon yet. }}
+
 
+
Application integration into the graphical console will be aligned with the Fedora Workstation offering.
+
  
 
=== System Installer ===
 
=== System Installer ===
{{admon/warning | This is not yet approved! | This statement is a work-in-progress draft and has not been agreed upon yet. }}
 
  
 
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.
 
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.

Revision as of 18:29, 28 February 2014

Contents

Fedora Server Technical Specification

This document aims to describe the technical characteristics Fedora Server product in detail. This includes provided services and APIs, installed software, etc. 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 the spec 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 PRD for a functional justification.

Supported Architectures

Fedora Server will run on and provide install media for i686, x86_64 and armv7hl servers. In the future, Fedora Server will also support armv8 (64-bit) when the hardware becomes available.

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

Service management

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

Logging

Server will by default store log files locally, and to the maximum extent possible support sending full log data to an external server. For writing to logs, we recommend the syslog or journal APIs, rather than managing application-specific log files. An API for reading the logs will be provided through OpenLMI.

We will use rsyslog for forwarding data to a central server. Programs using the recommended APIs will have their logs locally stored in the journal database, and automatically forwarded; the other programs should include appropriate configuration for rsyslog so 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 port is SSH. 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.

A public, external API will be provided by the OpenLMI project 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 is providing 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).

Miscellaneous system information

System locale, timezone, hostname, etc. will be managed through the services provided by systemd for this purpose. See developer documentation for localed, timedated and hostnamed

Virtualization

libvirt-daemon will be used to manage virtualization capabilities. systemd-nspawn will be used to manage containerization capabilities.


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 following Server Roles 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.

Domain Controller

The Fedora Server Domain Controller Role will be provided by the FreeIPA project.

This Server Role is a blocker for the release of Fedora Server in Fedora 21.

Database Server

The Fedora Server Database Server will be provided by the PostgreSQL project.

This Server Role is a nice-to-have for the release of Fedora Server in Fedora 21.


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.

Package list

<TBD>