I'm sure this argument has been had before, but what I'd like to see in FC4 is the ol server install, being just that, install has bare minimum stuff instlaled, FC1,2 and 3 seems to load a lot of not needed crap.
I mean loomk at a min server install for RH9 or even current slackware, then look at it on FC, guys a server install should be exactly that, WTF has cannaserver got to do with being a server, it doesnt! nor does several other things, the least stuff instlaled and run on a server is paramount, the more crap that runs that clearly is not needed = more and higher risks
Lets not end up like m$ huh!
flame away :P
Res wrote:
I'm sure this argument has been had before, but what I'd like to see in FC4 is the ol server install, being just that, install has bare minimum stuff instlaled, FC1,2 and 3 seems to load a lot of not needed crap.
I mean loomk at a min server install for RH9 or even current slackware, then look at it on FC, guys a server install should be exactly that, WTF has cannaserver got to do with being a server, it doesnt! nor does several other things, the least stuff instlaled and run on a server is paramount, the more crap that runs that clearly is not needed = more and higher risks
Lets not end up like m$ huh!
flame away :P
Unfortunately nobody is getting serious about that problem. Last time I asked for the REAL minimal install they told me to propose the package list that I think is minimal. I honestly don't know. I would rather prefer Fedora people do that but don't put all the crap in your minimal installation or don't call it minimal.
Minimal installation for me is the following: packages that are barely needed for booting the system. (kernel,glibc,etc...) yum,up2date?,rpm to add more packages at will. maybe some basic utility commands. (shadow_utils,mount)
That's all.
I don't want to beleive that nobody is able to identify the packages that are needed to only boot the system.
Look at alternatives: Debian, has base install Gentoo, has base install FreeBSD, has base install OpenBSD, has base install. Solaris, has base install.
And please don't tell me that fedora is a desktop OS.
On Sat, 2005-02-05 at 13:41 +0100, Arjan van de Ven wrote:
I'm not telling you. I posted this list of packages to this mailinglist a few weeks ago.
Arjan's right. Also see:
http://www.simpaticus.com/linux/barebones-server-howto.php
for my approach to trimming the fat from a Fedora minimal install. I am (slowly) trying to create a comps.xml file that can be submitted for testing. It goes SLOWLY because I am having trouble understanding what to modify and what not to... I am not really a programmer.
The intent (and I wouldn't mind some help here...) is to submit this comps.xml file to the Fedora team. If they agree, it will replace the current minimal install. The "weight loss" from current minimal is not trivial... I was very conservative about eliminating stuff, and even so I got rid of nearly 160MB of cruft.
We go through this discussion frequently, but very few people step up the plate and help. Anyone have a tiny bit of knowledge and some free time, to help put my modifications into the comps.xml file? With that one change, we can take a big step forward!
And remember this discussion the next time you hear people whining about Red Hat not giving control to the community. The problem is that it's hard to get the community to participate! Thank God for Red Hat's gradual process of including the community while ensuring that Fedora maintains forward progress.
Cheers,
On Sat, 05 Feb 2005 08:00:42 -0600, Rodolfo J. Paiz rpaiz@simpaticus.com wrote:
We go through this discussion frequently, but very few people step up the plate and help. Anyone have a tiny bit of knowledge and some free time, to help put my modifications into the comps.xml file? With that one change, we can take a big step forward!
Do you have a specific list or forum or whatever I need to use to point people at your comps.xml effort when they pipe up on the lists?
You might think about posting a status report about it.. periodically to this list and 'releasing' what you have so far so people can test it and give you incremental feedback. I know there are people who have experience rebuilding an installer image with alternative package sets lurking around.
-jef
Arjan van de Ven wrote:
On Sat, 2005-02-05 at 15:16 -0300, Vano Beridze wrote:
I don't want to beleive that nobody is able to identify the packages that are needed to only boot the system.
I'm not telling you. I posted this list of packages to this mailinglist a few weeks ago.
I could not find that list. Could you please post the topic title or direct link to the post?
Thanks
On Sat, 2005-02-05 at 17:53 -0300, Vano Beridze wrote:
Arjan van de Ven wrote:
On Sat, 2005-02-05 at 15:16 -0300, Vano Beridze wrote:
I don't want to beleive that nobody is able to identify the packages that are needed to only boot the system.
I'm not telling you. I posted this list of packages to this mailinglist a few weeks ago.
I could not find that list. Could you please post the topic title or direct link to the post?
how about I just repost the list :) it's attached to this mail
On Sat, Feb 05, 2005 at 04:01:50PM +0100, Arjan van de Ven wrote:
glibc-common
That's one that bothers me, for its size and not much usefulness for bare systems. (And I'm in pt_PT.)
Could glibc's dependency on glibc-common be removed and an explicit dependency added to the core (base?) group?
Regards, Luciano Rocha
Arjan van de Ven wrote:
how about I just repost the list :) it's attached to this mail
filesystem termcap basesystem glibc-common mktemp zlib libtermcap cracklib words iproute mount e2fsprogs libattr pcre bzip2-libs mingetty iputils ncurses grep gpm findutils pam which SysVinit modutils rpm sysklogd setup rpmdb-fedora libgcc tzdata glibc chkconfig shadow-utils bash popt cracklib-dicts beecrypt net-tools ethtool libacl elfutils-libelf db4 info sed psmisc gawk coreutils dev util-linux procps initscripts mkinitrd libstdc++ glib2 tar gzip dev cpio dev lvm2 kernel libselinux module-init-tools less device-mapper rpm-libs libsepol udev readline MAKEDEV hotplug hwdata usbutils fedora-release db4-utils
Great!!!
Will this list be included in fc4 as a minimal install?
On Sat, 2005-02-05 at 10:37 -0500, seth vidal wrote:
You know you can do that all yourself just using kickstart, right?
Bzzzt! Thank you for playing. You're going to have to try to prove that one, Seth, because several of us have been very repeatedly unsuccessful.
Even selecting just @core and adding "--no-base", or any other attempt to reduce the size of the stock install, has still resulted in somewhat under 300 packages installed (~570MB). See Bugzilla for a good example:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139364
Aleksandar has been more thorough than I about documenting his work to the Fedora team... but that one Bugzilla should at least provide a good illustration of some of the problems.
Cheers,
On Sat, 2005-02-05 at 13:23 -0600, Rodolfo J. Paiz wrote:
On Sat, 2005-02-05 at 10:37 -0500, seth vidal wrote:
You know you can do that all yourself just using kickstart, right?
Bzzzt! Thank you for playing. You're going to have to try to prove that one, Seth, because several of us have been very repeatedly unsuccessful.
Even selecting just @core and adding "--no-base", or any other attempt to reduce the size of the stock install, has still resulted in somewhat under 300 packages installed (~570MB). See Bugzilla for a good example:
%packages
%post yum remove stuff-you-don't-want
is that proof enough?
-sv
On Sat, 2005-02-05 at 14:47 -0500, seth vidal wrote:
%packages %post yum remove stuff-you-don't-want
is that proof enough?
No, definitely not. Using another tool in the %post section to remove packages is (other than by automation) no different at all from installing a minimal install via kickstart and then running a simple script to use yum or rpm to remove the packages. You have not used *kickstart* to select the packages... you have accepted whatever kickstart would give you and then trimmed "manually."
You are no farther ahead than we. Note, for example, that you will need the full 570MB of space available for this install, even if you then trim it down to 200MB. You could not install onto a 256MB flash card, for example, or even onto a 512MB flash card.
What we seek is, ideally, a much slimmer minimal install package list in the first place. Failing that, or pending that, we seek to actually be able to use kickstart to install fewer packages such that Anaconda actually only installs the 200MB you want, instead of installing 570MB then deleting 370MB.
Care to try again? You have no idea how happy I'd be if you succeed, but sadly (AFAIAC) your first attempt is most definitely not a success.
Cheers,
No, definitely not. Using another tool in the %post section to remove packages is (other than by automation) no different at all from installing a minimal install via kickstart and then running a simple script to use yum or rpm to remove the packages. You have not used *kickstart* to select the packages... you have accepted whatever kickstart would give you and then trimmed "manually."
You mean i've taken a diverse set of tools and adequately accomplished the task you suggested? Sounds like the right way to me :)
You are no farther ahead than we. Note, for example, that you will need the full 570MB of space available for this install, even if you then trim it down to 200MB. You could not install onto a 256MB flash card, for example, or even onto a 512MB flash card.
I never claimed I was farther ahead - you said it was impossible, I disagreed. :)
Care to try again? You have no idea how happy I'd be if you succeed, but sadly (AFAIAC) your first attempt is most definitely not a success.
If you really want to try again - all you need to do is add an installclass to anaconda. Go read up on the installclasses - I think you'll see that's all that is necessary.
-sv
On Sat, 5 Feb 2005, seth vidal wrote:
%post yum remove stuff-you-don't-want
is that proof enough?
this seems to me to be the wrong approach to the problem. for a barebones server install fedora shouldnt install the extra junk in the first place.
as others have mentioned it makes it impossible to install barebones fedora even on a 512mb flash. the answers "just buy a bigger flash" or "just install onto a hd, remove a hundred packages or so, then copy it over to flash" are what drive people to other distros. :-/
-Dan
On Sat, 2005-02-05 at 18:09 -0800, Dan Hollis wrote:
On Sat, 5 Feb 2005, seth vidal wrote:
%post yum remove stuff-you-don't-want
is that proof enough?
this seems to me to be the wrong approach to the problem. for a barebones server install fedora shouldnt install the extra junk in the first place.
Like I explained to Rodolfo - you can get where you want to get to by replacing an install class.
I just asked if it would be possible to make it so anaconda looks for extras install classes from the repository or target location for network installs.
as others have mentioned it makes it impossible to install barebones fedora even on a 512mb flash. the answers "just buy a bigger flash" or "just install onto a hd, remove a hundred packages or so, then copy it over to flash" are what drive people to other distros. :-/
then they should probably go to other distros. I don't remember anything in the goals of fedora which read like "be able to install in tiny tiny amounts of disk space"
I understand what you're driving for but I'm not sure it's worth it.
though I do recommend you read up on how anaconda works internally esp with regard to install classes. -sv
On Sat, 5 Feb 2005, seth vidal wrote:
as others have mentioned it makes it impossible to install barebones fedora even on a 512mb flash. the answers "just buy a bigger flash" or "just install onto a hd, remove a hundred packages or so, then copy it over to flash" are what drive people to other distros. :-/
then they should probably go to other distros. I don't remember anything in the goals of fedora which read like "be able to install in tiny tiny amounts of disk space" I understand what you're driving for but I'm not sure it's worth it.
Adding a barebones install option isn't worth it?
Part of it is increasing the flexibility of fedora by allowing it to be installed on a wider array of embedded platforms. The other part is just install efficiency, not having to waste time removing hundreds of rpms which are useless for headless ISP servers.
In the end it comes down to fedora being flexible and easily deployable across a wider array of constrained hardware.
I don't see why fedora should aim for regression vs. RH9 in this respect.
-Dan
Adding a barebones install option isn't worth it?
Part of it is increasing the flexibility of fedora by allowing it to be installed on a wider array of embedded platforms. The other part is just install efficiency, not having to waste time removing hundreds of rpms which are useless for headless ISP servers.
I think that's part of it, too - fedora's not really targeting the server infrastructure, is it :)
In the end it comes down to fedora being flexible and easily deployable across a wider array of constrained hardware.
I don't see why fedora should aim for regression vs. RH9 in this respect.
Since you can do the install classes now I don't really see it as a regression but <shrug> spin it however you'd like.
-sv
On Sun, 6 Feb 2005, seth vidal wrote:
Adding a barebones install option isn't worth it? Part of it is increasing the flexibility of fedora by allowing it to be installed on a wider array of embedded platforms. The other part is just install efficiency, not having to waste time removing hundreds of rpms which are useless for headless ISP servers.
I think that's part of it, too - fedora's not really targeting the server infrastructure, is it :)
I guess not. It isnt accomodating embedded or constrained hardware either.
desktop-4-evar?
Anyone know a good server distro then? debian I guess?
-Dan
On Sat, 5 Feb 2005, Dan Hollis wrote:
On Sun, 6 Feb 2005, seth vidal wrote:
Adding a barebones install option isn't worth it? Part of it is increasing the flexibility of fedora by allowing it to be installed on a wider array of embedded platforms. The other part is just install efficiency, not having to waste time removing hundreds of rpms which are useless for headless ISP servers.
I think that's part of it, too - fedora's not really targeting the server infrastructure, is it :)
I guess not. It isnt accomodating embedded or constrained hardware either.
desktop-4-evar?
Anyone know a good server distro then? debian I guess?
debian eeeww ;P slackware :)
-Dan
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
On Sun, 6 Feb 2005, Dan Hollis wrote:
On Sun, 6 Feb 2005, Res wrote:
On Sat, 5 Feb 2005, Dan Hollis wrote:
Anyone know a good server distro then? debian I guess?
debian eeeww ;P slackware :)
no x86_64 there, maybe gentoo then?
never played with it, know ppl who have and like it, debian has issues with x86_64, problems with some onboard gigabit ethernets from what iver heard
-Dan
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
On Sat, 2005-02-05 at 23:01 -0800, Dan Hollis wrote:
On Sun, 6 Feb 2005, seth vidal wrote:
Adding a barebones install option isn't worth it? Part of it is increasing the flexibility of fedora by allowing it to be installed on a wider array of embedded platforms. The other part is just install efficiency, not having to waste time removing hundreds of rpms which are useless for headless ISP servers.
I think that's part of it, too - fedora's not really targeting the server infrastructure, is it :)
I guess not. It isnt accomodating embedded or constrained hardware either.
desktop-4-evar?
Anyone know a good server distro then? debian I guess?
We use centos for servers.
-sv
On Sat, 5 Feb 2005, Dan Hollis wrote:
On Sat, 5 Feb 2005, seth vidal wrote:
as others have mentioned it makes it impossible to install barebones fedora even on a 512mb flash. the answers "just buy a bigger flash" or "just install onto a hd, remove a hundred packages or so, then copy it over to flash" are what drive people to other distros. :-/
then they should probably go to other distros. I don't remember anything in the goals of fedora which read like "be able to install in tiny tiny amounts of disk space" I understand what you're driving for but I'm not sure it's worth it.
Adding a barebones install option isn't worth it?
it used to be... and it used to be called Server :)
On Sat, 05 Feb 2005 23:43:48 -0500, seth vidal skvidal@phy.duke.edu wrote:
then they should probably go to other distros. I don't remember anything in the goals of fedora which read like "be able to install in tiny tiny amounts of disk space"
I understand what you're driving for but I'm not sure it's worth it.
So far my understanding is... it isn't worth it to Red Hat... but that there is an opportunity for community to contribute a solution to make the minimal install smaller. Unfortunately there seems to be an expectation when these discussions usually crop up that the burden should be on Red Hat to provide the solution.. and that community shouldn't have to contribute it. If everyone who was complaining about the lack of a barebones install would go help Rodolfo in his efforts, there might be a community solution sooner. Then again, maybe the fun is in the complaining.
-jef
On Sun, Feb 06, 2005 at 09:04:51AM -0500, Jeff Spaleta wrote:
Unfortunately there seems to be an expectation when these discussions usually crop up that the burden should be on Red Hat to provide the solution..
There are two problems here which tend to push strongly in direction. One is that documentation explaining internals of an installation process is not exactly abundant. I had an opportunity to hack instalation images for CDs and servers and quite a bit of that was a guesswork.
The other issue is a dependency creep. Over time everything tend to depend on everything and you drop in into your set something seemingly innocuous and boom - you are installing half of KDE and artsd daemon even if you do not really have a sound card in that box (that is a description of a general trend so do not take program names too literally). IIRC Rodolfo bumped into that a number of times. This is not something you can solve "outside" if dependencies are not guarded carefuly in the first place.
Michal
Michal Jaegermann wrote:
The other issue is a dependency creep. Over time everything tend to depend on everything and you drop in into your set something seemingly innocuous and boom - you are installing half of KDE and artsd daemon even if you do not really have a sound card in that box (that is a description of a general trend so do not take program names too literally). IIRC Rodolfo bumped into that a number of times. This is not something you can solve "outside" if dependencies are not guarded carefuly in the first place.
This is an inevitable consequence of the UNIX tradition of compile-time, rather than runtime, configuration. Until that changes, it will be basically impossible to create binary packages that are both functional enough for a general purpose/desktop distribution and minimal enough for a "stripped down" server.
Gentoo represents one approach to this issue; the only other one I can think of would be to created a large number of duplicate packages -- foo-desktop and foo-server, bar-desktop and bar-server, etc.
On Sat, 5 Feb 2005, Arjan van de Ven wrote:
On Sat, 2005-02-05 at 15:16 -0300, Vano Beridze wrote:
I don't want to beleive that nobody is able to identify the packages that are needed to only boot the system.
I'm not telling you. I posted this list of packages to this mailinglist a few weeks ago.
The fact remains if we select bare bones server isntall it *SHOULD* be that, if people want all hte lovely other junk, let THEM add it under custom or do a workstation isntall.
Why have we strayed from this? I tell you now this is the main reason I have been told never to install fedora ino ur data center, I a couple aging RH9 boxes left because they were true server instla setups, the rest looks ilke from your comments will continue to be slackware.
On Sun, 2005-02-06 at 10:04 +1000, Res wrote:
I tell you now this is the main reason I have been told never to install fedora ino ur data center, I a couple aging RH9 boxes left because they were true server instla setups, the rest looks ilke from your comments will continue to be slackware.
Not a very good argument, I think, since you can customize any distro to be anything you want, really. I personally have a few Fedora servers on trimmed minimal installs and I am quite happy with them. Most of what I like to do to a new server to make it slim and secure is detailed here:
http://www.simpaticus.com/linux/barebones-server-howto.php
Not finished yet, but at least useful to some degree.
Cheers,
On Sat, 5 Feb 2005, Rodolfo J. Paiz wrote:
On Sun, 2005-02-06 at 10:04 +1000, Res wrote:
I tell you now this is the main reason I have been told never to install fedora ino ur data center, I a couple aging RH9 boxes left because they were true server instla setups, the rest looks ilke from your comments will continue to be slackware.
Not a very good argument, I think, since you can customize any distro to
Is RH going to pay for our time to sit back and strip it ? teach any new techs what needs to be removed when we install? nope, I didn't think so :)
A bare bones RH9 server install, and a bare bones slackware install are just that, minimal and perfect, slackware tops out RH9 still in this field by only a couple of things so its no biggie, but like I asked in my previous post, why have we strayed from this? I agree a lot of it is nice....for a desktop install, and desktop is where fedora leaves other distros in its wake, no doubt about it, but if we are heading into hte desktop only direction, then looks like times are a changing, for teh worse in some cases.
Also Arj's list is still a tad bloated, I mean I can't for the life of me see how I need gpm for instance on a mail/web/dns/database/radius server, etc etc etc...
Cheers
On Saturday 05 February 2005 19:21, Res wrote:
Also Arj's list is still a tad bloated, I mean I can't for the life of me see how I need gpm for instance on a mail/web/dns/database/radius server, etc etc etc...
Heck even I can answer that! How else are you going to be able to use the mouses cut & paste operations when configureing things? You have a photographic memory or something?
On Sat, 5 Feb 2005, Gene Heskett wrote:
On Saturday 05 February 2005 19:21, Res wrote:
Also Arj's list is still a tad bloated, I mean I can't for the life of me see how I need gpm for instance on a mail/web/dns/database/radius server, etc etc etc...
Heck even I can answer that! How else are you going to be able to use the mouses cut & paste operations when configureing things? You have a photographic memory or something?
A mouse in a server ? So we have to run a mouse lead to every box? come on be realistic, im not tlaking about a handfull of machines here, im talking a substantial number.
Lot of configuring is done from desktops anyway, where gpm is handy.
On Sun, Feb 06, 2005 at 07:50:50PM +1000, Res wrote:
On Sat, 5 Feb 2005, Gene Heskett wrote:
Heck even I can answer that! How else are you going to be able to use the mouses cut & paste operations when configureing things? You have a photographic memory or something?
A mouse in a server ? So we have to run a mouse lead to every box?
Ahem... Some people noticed many years ago that you do not have do display such things on a machine you are working on. Your mouse, an a keyboard, and a display can be physically attached far, far away. How desirable is a use of such tools in a particular case is a separate topic.
Michal
On Sun, 6 Feb 2005, Michal Jaegermann wrote:
On Sun, Feb 06, 2005 at 07:50:50PM +1000, Res wrote:
On Sat, 5 Feb 2005, Gene Heskett wrote:
Heck even I can answer that! How else are you going to be able to use the mouses cut & paste operations when configureing things? You have a photographic memory or something?
A mouse in a server ? So we have to run a mouse lead to every box?
Ahem... Some people noticed many years ago that you do not have do display such things on a machine you are working on. Your mouse, an a keyboard, and a display can be physically attached far, far away. How desirable is a use of such tools in a particular case is a separate topic.
That was my point had you read on :)
On Sat, 5 Feb 2005, Gene Heskett wrote:
Heck even I can answer that! How else are you going to be able to use the mouses cut & paste operations when configureing things? You have a photographic memory or something?
workstation xterm ssh
=)
Regards James
-
Arjan van de Ven -
Dan Hollis -
Gene Heskett -
Ian Pilcher -
James Bourne -
Jef Spaleta -
Luciano Miguel Ferreira Rocha -
Michal Jaegermann -
Res -
Rodolfo J. Paiz -
seth vidal -
Vano Beridze