Red Hat Bugzilla – Bug 485995
Minimal platform option
Last modified: 2014-01-21 18:03:43 EST
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
If you don't consider this a good place, I'm open to new ideas.
What will be installed?
More details are at:
Another group that find this feature useful:
Of this list, I think vsftpd could be dropped. We should require people to add that one.
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?
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. :)
(In reply to comment #1)
> Of this list, I think vsftpd could be dropped. We should require people to add
> that one.
no problem :)
package list update!
- packages that are already in @core
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.
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?
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.
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.
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 :)
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* :)
How is @core defined?
"Enough to boot to a login prompt and get you yum.", essentially.
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 :
These could go away if its guaranteed that the kernel will always run optimally without these installed:
This one we will try to implement as a wrapper for procmail:
We could do away with these:
(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 :
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.
Required by initscripts, which is listed in @core
Listed in @core
Listed in @core
Not currently in @core
Not currently in @core
Not currently in @core
Not currently in @core
Not listed in any groups in comps. Weird :)
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?
> This one we will try to implement as a wrapper for procmail:
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).
(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.
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).
Is this on track for F-12? Just curious. Thanks.
The comps bits are done, AFAIK (and have been for a while.)
I think all that's left was a request to make this easier to select via the UI.
That would be a separate anaconda bug. Closing out this bug against comps.