Bug 485995 - Minimal platform option
Summary: Minimal platform option
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: comps
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
URL:
Whiteboard:
Depends On: F11MinimalPlatform
Blocks: 519838 529384 554536 575256
TreeView+ depends on / blocked
 
Reported: 2009-02-17 20:30 UTC by Peter Vrabec
Modified: 2014-01-21 23:03 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
: 529384 (view as bug list)
Environment:
Last Closed: 2009-10-07 15:35:57 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Peter Vrabec 2009-02-17 20:30:30 UTC
Description of problem:
Could you please add new option to anaconda that will perform installation of a minimal platform.

Where will be this option placed?
Next by: Office and Productivity / Software Development / Web Server
(see attachment)
If you don't consider this a good place, I'm open to new ideas.

What will be installed?
@core
bash
kernel
passwd
policycoreutils
chkconfig
authconfig
rootfiles
grub
yum
dhclient
pam_passwdqc
sudo
audit
cronie
irqbalance
openssh-server
postfix
vsftpd
acpid
cpuspeed
iptables
iptables-ipv6


More details are at:
https://fedoraproject.org/wiki/Features/MinimalPlatform


Additional info:
Another group that find this feature useful:
https://fedoraproject.org/wiki/SIGs/Server

Comment 1 Steve Grubb 2009-02-17 20:51:10 UTC
Of this list, I think vsftpd could be dropped. We should require people to add that one.

Comment 2 Jeremy Katz 2009-02-18 03:45:49 UTC
From a UI point of view, this doesn't really work/make sense.  The things that are listed on the task selection screen are additive options beyond the desktop (checkboxes).  Adding a minimal platform option isn't additive, it's instead an orthogonal option (radio buttons).  Mixing these two things doesn't make any sense at all.

For the purpose of the people that we expect to be taking advantage of the minimal platform, does it not make more sense to have a canned kickstart config for them?

Comment 3 Peter Vrabec 2009-02-18 11:19:08 UTC
OK Jeremy, I agree with you that this is not the right place for this option. Maybe it might be on next screen, where is package/group selection. I think it used to be minimal/everything option. I don't see it as check box or radio button. It would be a button that will erase all selections and then select only what's specified by minimal platform. User will still have oportunity to tune their package selection.

Kickstart for sure, there is no doubt about it. I just don't know in which package we should include it. For example spin-kickstart, this might be good place, but are we going have this package in RHEL? I'm not sure. 
What about appliance-tools?, they have their own kickstart that is very different then ours. They have different look at security: no audit, no selinux and so on.

Back to this bug. So you argue that this is not a targeted group of users. Hmmm, I don't have any statistics :) But let's say that majority of users would prefer the kickstart. What should be the rate between anaconda(minimal platform) and kickstart(minimal platform) users so we can say it make sense to make this option (that is technically easy to implement). Let's ask our customers. :)

Comment 4 Peter Vrabec 2009-02-18 11:20:04 UTC
(In reply to comment #1)
> Of this list, I think vsftpd could be dropped. We should require people to add
> that one.
+1 
no problem :)

Comment 5 Peter Vrabec 2009-02-20 10:38:27 UTC
package list update! 
- vsftpd
- packages that are already in @core

@core
kernel
chkconfig
yum
dhclient
pam_passwdqc
sudo
audit
cronie
irqbalance
openssh-server
postfix
acpid
cpuspeed
iptables
iptables-ipv6

Comment 6 Joel Andres Granados 2009-02-20 14:40:26 UTC
Been giving this some though lately and here are my 2cents:

1.  The two screens that are in discussion (package selection and the one before) are both additive lists.  They do what is expressed in comment #2 and it just seems senseless to add some option that excludes a selection.

2.  From my point of view this could be viewed from two different places: a)minimal install discussion and b)customized package lists in installer.

    a) Couldn't we just tell the user to deselect everything?  my tests show that the final installation is 172 packages.  Moreover, its more logical to make anaconda have a specific behavior if all packages are deselected than having a "deselect everything and select specific list of packages" button.

    b)Issue here is that we don't currently have a place for these in anaconda installer.  And considering that we have the fedora spins project, this becomes less relevant.  however, having a list of predefined package lists does not completely displease me.  But we would have to have an additional screen for this.  And we would have to devise a way for installer to retrieve these lists from somewhere (could be a rpm).  And I would add, to be completely fair, a place in fedora for projects to put their personalized package list.

Comment 7 Steve Grubb 2009-02-20 15:10:06 UTC
Any chance that de-selecting all could leave just the package list above selected? And possibly adding help or text on screen that deselecting all creates a minimal install system?

Comment 8 Jeremy Katz 2009-02-20 15:56:27 UTC
Deselecting all groups leaves @core selected (plus things that are "required" for the install you're trying to do), which is a minimal system.  If you want to argue that some of the things in your list should be in @core, that debate can be opened... but be prepared for arguments from people who disagree about the meaning of "minimal" :-)

As for adding some text -- going beyond the "people do not read help text" (they don't... there's tons of usability research on the subject), adding text like that is kind of like putting "Putting the key in the off position turns off the car" on your car's dashboard.  Of course deselecting everything is a minimal system.  Otherwise, there'd be something else you could deselect.

Comment 9 Steve Grubb 2009-02-20 16:20:02 UTC
The goal of the minimal install project is that we are left with a working system. You need to be able to chkconfig services on/off, you have to have cron jobs for maintenance, because there are cron jobs you need mail delivery, you need to be able to update the system to replace vulnerable packages, and you need a couple security tools that isn't in core. acpid is needed for libvirt to work right if this is a VM. The cpuspeed and irqbalancers are needed because all new x86 systems are speedshifting multicore processors.

Comment 10 Jeremy Katz 2009-02-20 16:29:31 UTC
Then argue that those things should be part of @core.  I don't disagree with it as a definition but be prepared for those who do.

Also, fwiw, acpid should *NEVER EVER EVER* be required :)

Comment 11 Joel Andres Granados 2009-02-20 17:09:18 UTC
Also note that "minimal" without a specific context does not mean anything.  There could be minimal kde install, minimal gnome install, minimal security install, minimal web server install.... *to infinity* :)

Comment 12 Peter Vrabec 2009-02-20 17:21:45 UTC
How is @core defined?

Comment 13 Bill Nottingham 2009-02-20 17:43:04 UTC
"Enough to boot to a login prompt and get you yum.", essentially.

Comment 14 Steve Grubb 2009-02-23 20:34:16 UTC
Just wanted to categorize these packages so that we can make decisions about what stays in and out.

The following we are pretty sure we would like to have added to @core :
kernel
chkconfig
yum
dhclient
sudo
audit
cronie
openssh-server
iptables
iptables-ipv6

These could go away if its guaranteed that the kernel will always run optimally without these installed:
cpuspeed
irqbalance

This one we will try to implement as a wrapper for procmail:
postfix

We could do away with these:
pam_passwdqc
acpid

Comment 15 Jeremy Katz 2009-02-23 20:50:53 UTC
(In reply to comment #14)
> Just wanted to categorize these packages so that we can make decisions about
> what stays in and out.

And to clarify since some of these are already present...

> The following we are pretty sure we would like to have added to @core :
> kernel

anaconda will always select the "best" kernel for the system you're running on.  That could be kernel-PAE (eg, a paravirt Xen guest on x86) so having kernel listed explicitly is unwise.

> chkconfig

Required by initscripts, which is listed in @core

> yum

Listed in @core

> dhclient

Listed in @core

> sudo

Not currently in @core

> audit

Not currently in @core

> cronie

Not currently in @core

> openssh-server

Not currently in @core

> iptables
> iptables-ipv6

Not listed in any groups in comps.  Weird :)

Comment 16 Peter Vrabec 2009-02-26 17:18:52 UTC
would it be a problem in anaconda to have a option(button) that will deselect all groups/packages by one click. So, only core will be installed. And add similar text like "Enough to boot to a login prompt and get you yum." to it as Bill mentioned in comment #13?

Comment 17 Peter Robinson 2009-03-25 03:19:23 UTC
> This one we will try to implement as a wrapper for procmail:
> postfix

cronie will also pull in /usr/sbin/sendmail as a dep (see RHBZ 472710) so you'll get a MTA which ever way (which I personally don't think you need for a minimal platform).

Comment 18 Michael Monreal 2009-03-25 14:25:32 UTC
(In reply to comment #16)
> would it be a problem in anaconda to have a option(button) that will deselect
> all groups/packages by one click. So, only core will be installed. And add
> similar text like "Enough to boot to a login prompt and get you yum." to it as
> Bill mentioned in comment #13?  

Sounds like a good idea.

Comment 19 Chris Lumens 2009-03-26 19:11:07 UTC
We are considering a pretty thorough reworking of the UI throughout anaconda for the next release or two, so I don't want to commit to any specific UI changes right now (such as a "deselect all" option or button).  For the sake of getting this feature in as fast as possible, I think the best approach would still be to pursue this through comps changes and make sure Core contains only what it really needs to.  Otherwise, we are going to get hung up on all the back and forth of UI changes we're probably going to undo in the near future without ever tackling the underlying problem.

If you guys can agree to this plan of action, then this becomes a comps or packaging problem instead of an anaconda one (for now).

Comment 21 Steve Grubb 2009-09-16 14:31:58 UTC
Is this on track for F-12? Just curious. Thanks.

Comment 22 Bill Nottingham 2009-09-16 15:07:45 UTC
The comps bits are done, AFAIK (and have been for a while.)

Comment 23 Steve Grubb 2009-09-16 18:24:50 UTC
I think all that's left was a request to make this easier to select via the UI.

Comment 24 Bill Nottingham 2009-10-07 15:35:57 UTC
That would be a separate anaconda bug. Closing out this bug against comps.


Note You need to log in before you can comment on or make changes to this bug.