From Fedora Project Wiki
Line 19: Line 19:


== Our goals ==
== Our goals ==
* improve communication between people around low-level system components and people around desktop,
* improve cross-team communication between people around low-level system components and people around desktop,
* maintaining the classic network configuration layer (/etc/sysconfig/network-scripts) as a longterm compatibility solution (move into a standalone package)
* maintain the standard network configuration layer (/etc/sysconfig/network-scripts) as a longterm compatibility solution (move into a standalone package)
* create a spin targeted at head-less servers, NAS and similar devices (running on both physical and virtual hardware),
* create a spin targeted at head-less servers, NAS and similar devices (running on both physical and virtual hardware),
* reduce the dependency on desktop packages to lower the attack surface of the server (work on more fine-graded dependencies),
* reduce the dependency on desktop packages to lower the attack surface of the server (work on more fine-graded dependencies),
Line 27: Line 27:
* serve as a community liason for Red Hat partners
* serve as a community liason for Red Hat partners
* create lightweight installer similar to creating buildroots by mock
* create lightweight installer similar to creating buildroots by mock
* ...
* offer minimal installation path for head-less servers or virtual machines
* ..


== Random questions ==
== Random questions ==

Revision as of 11:48, 10 November 2008

Fedora Server SIG

Welcome on the home of Fedora Server SIG. We are a group which would like to use Fedora as a server on bare metal or in virtual environment that may or may not provide graphical capabilities. Our focus is mainly on Fedora server components, and features like networking, head-less support, or iSCSI. You can object that there are no Fedora server users, but they are there - either running Fedora itself or distributions based on Fedora such as Red Hat Enterprise Linux or CentOS.

Rationale

Fedora can be deployed in many environments and for many purposes. However, not every typical deployment is represented by a group that focuses on needs of such particular deployment. One of typical deployments (Desktop) is covered by Desktop Team. We would like to cover typical server deployment, which raises few challenges and is represented by a unique set of requirements. Our goals are based on such requirements and current state of Fedora and are listed in the next section.

In an ideal world requirements of all deployments scenarios complement each other, but in the real life there are conflicts. Our main goal is to find a technical solution - by maintaining compatibility, with possibility to enable/disable certain features, etc. We think that the main problem is the lack of communication between groups and we would like to focus from the very beginning on improving it. The second goal is to help separate current and emerging desktop oriented applications from the base system and to help their developers to correctly integrate applications' features into base system.

Participants

  • Dan Horák
  • Tomáš Mráz (tmraz)
  • Karel Zak (kzak)
  • Adam Tkac (atkac)
  • Daniel Mach (dmach)
  • Milan Broz (mbroz)
  • Radek Vokal

...

Our goals

  • improve cross-team communication between people around low-level system components and people around desktop,
  • maintain the standard network configuration layer (/etc/sysconfig/network-scripts) as a longterm compatibility solution (move into a standalone package)
  • create a spin targeted at head-less servers, NAS and similar devices (running on both physical and virtual hardware),
  • reduce the dependency on desktop packages to lower the attack surface of the server (work on more fine-graded dependencies),
  • work on CLI equivalents of misc GUI tools (eg. write new frontends for existing backends),
  • help to better integrate new features into existing infrastructure
  • serve as a community liason for Red Hat partners
  • create lightweight installer similar to creating buildroots by mock
  • offer minimal installation path for head-less servers or virtual machines
  • ..

Random questions

  • why do we need plymouth to install new kernel?
  • should be desktop paradigm of a user session used on servers?
  • should exist a lightweight network configuration mechanism for servers or eth0-only workstations?