Five basic principles for Fedora, from a server perspective.

[seth vidal]

On Wed, 2010-09-01 at 20:14 -0400, Matthew Miller wrote:
> On Wed, Sep 01, 2010 at 01:09:36PM -0400, seth vidal wrote:
> > > > I would start with the @core comps group (even with a smaller set) and
> > > > then add groups of packages creating a server feature. This will build
> > > > the server platform from down will make possible to check the
> > > > dependencies and to validate whether the set works as expected.
> > > After all, "More with Less" is principle #1. :)
> > okay
> > http://skvidal.fedorapeople.org/misc/core-f14-resolved.txt
> > that's f14-core resolved into a bare chroot.
> > start there.
> 
> Cool. A few things strike me as potentially troublesome, like cairo, since
> that's prone to update-requirements-to-suit-the-latest-desktop-things. But
> paring down the list can happen over time.
> 
> How would this server branch interact with Fedora, um, core? Would we
> configure both the server repo and the main repo, with the server repo set
> to be a preferred source via yum crack^H^H^H^H^H magic?
> 
> >From the repo compose side, presumably the packages would inherit from the
> corresponding main Fedora release, and be forked only if we need to change
> them.
> 


my opinion:

a server 'spin' is a ks file like:
install
lang en_US.utf8
keyboard us
url --url fillinurlhere
network --device eth0 --onboot no --bootproto dhcp --hostname localhost
firewall --disabled
authconfig --enableshadow --passalgo=sha512
selinux --enforcing
timezone --utc America/New_York
bootloader --location=mbr --driveorder=sda --append=""


%packages --nobase
@core



and let the admin do the rest.

If you want to get clever you make the inverse of a yum plugin like
'appmarket'. You prune out all the stuff that no server should ever have
near it from search results.

-sv