From Fedora Project Wiki
No edit summary
(62 intermediate revisions by 30 users not shown)
Line 1: Line 1:
== Fedora Server SIG ==
== Fedora Server SIG ==
Welcome on the home of Fedora Server/OldSchool/Classic SIG. We are the people you have been warned off - we don't need 3D desktop effects, but we like iSCSI, etc.
 
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 ==
== Rationale ==
There is a lot of work being done for one group of Fedora users, but it looks like that the second one is being omitted. The first one is covered by the Desktop team and the second one, let's call it Server, Classic, OldSchool, etc, has no formal representation in the Fedora community.
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.


You can object that there are no Fedora Server users, but they are there - either running Fedora itself or derivates of Fedora called RHEL, CentOS etc. But we think that the main problem is the lack of communication between these groups and we want to help here.  
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.


In an ideal world they will complement each other, but in the real life there will be conflicts, so we must try to find a technical solution - by maintaining compatibility, with possibility to enable/disable features, etc.


We would like to help to improve emerging rather desktop-oriented applications to better cooperate with the current server-oriented parts of the system.
== Team ==
{|
! name !! irc nick !! role
|-
| [[User:sharkcz|Dan Horák]] || sharkcz || founder
|-
| Daniel Mach || dmach || Fedora Server spin rel-eng
|-
|}


== Participants ==
== Fan Club ==
* Dan Horák (sharkcz)
* Milan Broz (mbroz)
* [[User:Buc|Dmitry Butskoy]]
* [[User:limb|Jon Ciesla]]
* [[User:Pghmcfc|Paul Howarth]]
* [[User:Heffer|Felix Kaechele]]
* DavidKovalský (dkovalsk)
* Doug Ledford (dledford)
* [[User:mmaslano|Marcela Mašláňová]]
* [[User:jcm|Jon Masters]] (jcm, IRC:jonmasters)
* [[User:Kanarip|Jeroen van Meeuwen]]
* [[User:Rathann|Dominik Mierzejewski]]
* [[User:Renich|Renich]]
* [[User:mattdm|Matthew Miller]]
* Tomáš Mráz (tmraz)
* Tomáš Mráz (tmraz)
* [[User:Ascenseur|Joe O'Dell]]
* [[User:Dramsey|David Ramsey (Dramsey)]]
* Smooge (smooge)
* [[User:johe|Joerg Stephan]]
* Adam Tkac (atkac)
* [[User:Cweyl|Chris Weyl]]
* [[User:rvokal|Radek Vokal]]
* Karel Zak (kzak)
* Karel Zak (kzak)
* Adam Tkac (atkac)
* [[User:Oliverkrystal|OliverK]]
* Daniel Mach (dmach)
* [[User:borgan|Brock Organ]]
* Milan Broz (mbroz)
* [[User:Lsm5|Lokesh Mandvekar]]
* [[User:gomix|Guillermo Gómez]]
* [[User:ezq|Ezequiel Cardinali]]
* [[User:dbruno|Daniel Bruno]]
* [[User:Kusterjr|Geraldo Kuster]]
* [[User:dnncastle|Danny Castle]]
...
...
== Our infrastructure ==
mailing list -{{fplist|server}}
IRC meetings - [irc://chat.freenode.net/fedora-server #fedora-server] (time to be decided)
tracking bug - [https://bugzilla.redhat.com/show_bug.cgi?id=FedoraServerTracker FedoraServerTracker]
=== Server Spin ===
Daniel Mach started to work on a kickstart generator for a future Server Spin. The script and accompanying comps file are on his [http://dmach.fedorapeople.org/server-spin/ fedorapeople space]


== 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),
* collaborate with the installer team so we can enable different spins, desktop versus server builds
* 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),
* work on CLI equivalents of misc GUI tools (eg. write new frontends for existing backends),
* work on CLI equivalents of misc GUI tools (eg. write new frontends for existing backends),
Line 29: Line 72:
* 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
* provide support for systems with large storage devices and with thousands of volumes (physical/logical) and various multipath configurations
* implement "report-app-crashes-to-bugzilla" feature on a system level and allow desktop plugins to connect there
* encourage community members to (co-)maintain packages containing server software
* ...
* ...
== Work Areas ==
=== Installer ===
* work with the anaconda team to keep anaconda suitable for server installs (text mode, kickstarts, ...)
** if necessary implement configuration for Anaconda at runtime to control defaults and behavior
** ensure server-specific defaults continue to be available (LVM, RAID, etc.)
* (sharkcz) create a lightweight installer/bootstraper
=== Server services ===
* bring more server packages into Fedora
** (sharkcz) [http://www.tryton.org Tryton] - ERP - imported, now working on the application modules
* encourage creation of EPEL branches for existing packages
* [[SIGs/Server/ServersOverview_alpha|overview of available servers]]
=== Kernel ===
* everything about the kernel side of servers
=== Admins corner ===
* place for administration and monitoring technologies available in Fedora
** ''Customizing installation trees''
*** Inclusion of customized, updated kernels, hardware drivers
*** Inclusion of rebuilt stage2.img or install.img images with customized or updated software
*** Inclusion of kickstarts for automated installations
*** Slipstreaming the necessary updated packages and/or custom packages in the payload
*** Integration with provisioning systems
** ''Provisioning for real and virtual systems''
*** Integration with compose tools
*** Cobbler
*** Slipstreaming Configuration Management utilities
** ''Configuration Management''
*** CFEngine, Puppet, Augeas, Func
** ''Monitoring''
*** Nagios, Zabbix, ZenOS, Monit
*** Integration with Configuration Management utilities
* collects pointers to how-tos and other docs useful for administrators
* work on the TUI counterparts of GUI system-config-* tools, should go in hand with the backend/frontend separation
=== Security ===
* improve/monitor the security standards for current server software
* help the desktop developers with the security aspects of their work
=== Network ===
* let initscripts and NetworkManager play nicely together, move network support from initscripts into a separate package
* add more interface types to NetworkManager
=== QA ===
* testing
== Standardization ==
* Determine ways to enhance existing standards compliance and continue to have a strong focus on standardization.


== Random questions ==
== Random questions ==
Line 35: Line 132:
* should be desktop paradigm of a user session used on servers?
* should be desktop paradigm of a user session used on servers?
* should exist a lightweight network configuration mechanism for servers or eth0-only workstations?
* should exist a lightweight network configuration mechanism for servers or eth0-only workstations?
== FAQ ==
Q: does more server orientation mean an extended lifetime too?<br>
A: no, extended lifetime is covered by the derivates like RHEL, CentOS, etc.
[[Category:SIGs]]
[[Category:Fedora special-interest groups|Server]]

Revision as of 19:39, 26 February 2014

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.


Team

name irc nick role
Dan Horák sharkcz founder
Daniel Mach dmach Fedora Server spin rel-eng

Fan Club

...

Our infrastructure

mailing list -server

IRC meetings - #fedora-server (time to be decided)

tracking bug - FedoraServerTracker

Server Spin

Daniel Mach started to work on a kickstart generator for a future Server Spin. The script and accompanying comps file are on his fedorapeople space

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),
  • collaborate with the installer team so we can enable different spins, desktop versus server builds
  • 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
  • provide support for systems with large storage devices and with thousands of volumes (physical/logical) and various multipath configurations
  • implement "report-app-crashes-to-bugzilla" feature on a system level and allow desktop plugins to connect there
  • encourage community members to (co-)maintain packages containing server software
  • ...

Work Areas

Installer

  • work with the anaconda team to keep anaconda suitable for server installs (text mode, kickstarts, ...)
    • if necessary implement configuration for Anaconda at runtime to control defaults and behavior
    • ensure server-specific defaults continue to be available (LVM, RAID, etc.)
  • (sharkcz) create a lightweight installer/bootstraper

Server services

  • bring more server packages into Fedora
    • (sharkcz) Tryton - ERP - imported, now working on the application modules
  • encourage creation of EPEL branches for existing packages
  • overview of available servers

Kernel

  • everything about the kernel side of servers

Admins corner

  • place for administration and monitoring technologies available in Fedora
    • Customizing installation trees
      • Inclusion of customized, updated kernels, hardware drivers
      • Inclusion of rebuilt stage2.img or install.img images with customized or updated software
      • Inclusion of kickstarts for automated installations
      • Slipstreaming the necessary updated packages and/or custom packages in the payload
      • Integration with provisioning systems
    • Provisioning for real and virtual systems
      • Integration with compose tools
      • Cobbler
      • Slipstreaming Configuration Management utilities
    • Configuration Management
      • CFEngine, Puppet, Augeas, Func
    • Monitoring
      • Nagios, Zabbix, ZenOS, Monit
      • Integration with Configuration Management utilities
  • collects pointers to how-tos and other docs useful for administrators
  • work on the TUI counterparts of GUI system-config-* tools, should go in hand with the backend/frontend separation

Security

  • improve/monitor the security standards for current server software
  • help the desktop developers with the security aspects of their work

Network

  • let initscripts and NetworkManager play nicely together, move network support from initscripts into a separate package
  • add more interface types to NetworkManager

QA

  • testing

Standardization

  • Determine ways to enhance existing standards compliance and continue to have a strong focus on standardization.

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?

FAQ

Q: does more server orientation mean an extended lifetime too?
A: no, extended lifetime is covered by the derivates like RHEL, CentOS, etc.