From Fedora Project Wiki

< Releases

Revision as of 16:28, 24 May 2008 by Ravidiip (talk | contribs) (1 revision(s))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Fedora Server spin (FSS)

  • Last modified: [[Date(2007-01-03T19:44:41Z)]
  • Owners: JesseKeating, DaveJones, DavidLutterkort
  • Targeted release: Fedora 7

Current status

After meeting and discussing this at FUDCon, it was determined that a server spin has little value to offer vs massive ammounts of confusion and differeing opinions over what should be in the server spin. We're dropping it for Fedora 7.


We need a server release of Fedora 7.

Usage cases/rationale

  • Manfred runs a 20-server farm of apache web servers and needs an operating system. Manfred has a black belt in Linux administration, and is very concerned about getting the absolute minimum installed on his web servers (and the firewall sitting in front of them)
  • Bill needs to set up a DNS server, and his boss told him to use FSS; Bill has no Linux/Unix experience but is a proficient admin of that other OS
  • Akira needs a simple mailserver; he doesn't speak a word of English (or any other Western language) and needs a UI that is fully localized for Japanese.


Requires determining a package set, generating a distribution profile, and doing testing.

Test Plan

Test installs of Fedora server, as well as the default apps in the way that we would test any Fedora release.


Depends on the introduction of pungi to build, and distribution customization support .


We will create the server spin in several steps:

1. Decide on a core set of packages, based on packages that own files in /etc/init.d/, call that the 'server list'. That list is tracked here 2. Add packages that support packages on the server list, things like system-config-* and sendmail-cf etc. by querying for the dependants of the server list packages. 3. Look at the @core and @base groups in the current comps.xml and see if the minimal install for servers can be pruned down. Tracked here 4. Figure out how server list and supporting packages should be grouped in the server comps.xml and what should be default/mandatory/optional

A couple package list attempts will be posted here, composes will be attempted to see what it really looks like.