Hi
Something that keeps coming up is how far can we minimalise an Instance / Image / Installer before we cant call it CentOS anymore. In the past, what we have generally stuck with is: - CentOS Shipped kernel - Initscripts - functional yum - functional openssh-server - atleast all of @base
however, in some cases, openssh-server might not be needed, and initscripts has a fairly long dep tree, similarly making yum work needs a few things. Can we get away with losing yum as an example and replacing it with a script that says 'need yum? I can download and install it for you' and have it hit mirror.centos.org for static yum and yum dep urls ?
similarly, should nobase and nocore be acceptable ?
the aim being to setup a base image, that is under 150mb to download and deploy.
Karanbir Singh wrote:
the aim being to setup a base image, that is under 150mb to download and deploy.
I think there are (at least) two different types of "minimal" that could (and should) be provided.
1) "working server minimal" which would have at least yum and sshd -- this could be similar to what we do for minimal now, though I'm not totally opposed to shrinking it down a bit more.
2) "really really minimal -- and we mean minimal!" -- where the goal is to strip out as much as possible, no docs, no yum, no ssshd, etc.
I don't have a use for (2) personally, but use (1) -- or at least one of my own making -- quite frequently. I'd be happy if we could keep both.
-Jeff
I like the name server-minimal, or even just minimal for the purpose of what the current version is.
Perhaps this super skinny version ought to be called.. micro?
Dan
On 19 March 2014 16:41, Jeff Sheltren jeff@tag1consulting.com wrote:
Karanbir Singh wrote:
the aim being to setup a base image, that is under 150mb to download and deploy.
I think there are (at least) two different types of "minimal" that could (and should) be provided.
- "working server minimal" which would have at least yum and sshd --
this could be similar to what we do for minimal now, though I'm not totally opposed to shrinking it down a bit more.
- "really really minimal -- and we mean minimal!" -- where the goal is
to strip out as much as possible, no docs, no yum, no ssshd, etc.
I don't have a use for (2) personally, but use (1) -- or at least one of my own making -- quite frequently. I'd be happy if we could keep both.
-Jeff _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Hi,
On 03/19/2014 04:57 PM, Dan Porter wrote:
I like the name |server-minimal|, or even just |minimal| for the purpose of what the current version is.
Perhaps this super skinny version ought to be called.. |micro|?
ok, micro is interesting.
On 19 March 2014 16:41, Jeff Sheltren <jeff@tag1consulting.com mailto:jeff@tag1consulting.com> wrote:
Karanbir Singh wrote: > > the aim being to setup a base image, that is under 150mb to download and > deploy. > > I think there are (at least) two different types of "minimal" that could (and should) be provided. 1) "working server minimal" which would have at least yum and sshd -- this could be similar to what we do for minimal now, though I'm not totally opposed to shrinking it down a bit more.
Would the present minimal install be suiteable for this? we have an iso dedicated to the role ( and afaik, its the most downloaded iso and the most popular install mechanism on c6 ).
2) "really really minimal -- and we mean minimal!" -- where the goal is to strip out as much as possible, no docs, no yum, no ssshd, etc.
yeah - but no sshd might be a challenge since then we pre-assume that console is the way to get in.
On Wed, Mar 19, 2014 at 05:21:56PM +0000, Karanbir Singh wrote:
Hi,
On 03/19/2014 04:57 PM, Dan Porter wrote:
I like the name |server-minimal|, or even just |minimal| for the purpose of what the current version is.
Perhaps this super skinny version ought to be called.. |micro|?
ok, micro is interesting.
On 19 March 2014 16:41, Jeff Sheltren <jeff@tag1consulting.com mailto:jeff@tag1consulting.com> wrote:
Karanbir Singh wrote: > > the aim being to setup a base image, that is under 150mb to download and > deploy. > > I think there are (at least) two different types of "minimal" that could (and should) be provided. 1) "working server minimal" which would have at least yum and sshd -- this could be similar to what we do for minimal now, though I'm not totally opposed to shrinking it down a bit more.Would the present minimal install be suiteable for this? we have an iso dedicated to the role ( and afaik, its the most downloaded iso and the most popular install mechanism on c6 ).
I for one would like to see openssh-clients added, since it is missing scp :)
On 19/03/14 16:57, Dan Porter wrote:
I like the name |server-minimal|, or even just |minimal| for the purpose of what the current version is.
Perhaps this super skinny version ought to be called.. |micro|?
If it's an image without yum then I'd suggest we call it 'broken' and be done with it!
There are quite enough people running systems without updates without encouraging them to do so.
T
On 03/19/2014 02:05 PM, Trevor Hemsley wrote:
On 19/03/14 16:57, Dan Porter wrote:
I like the name |server-minimal|, or even just |minimal| for the purpose of what the current version is.
Perhaps this super skinny version ought to be called.. |micro|?
If it's an image without yum then I'd suggest we call it 'broken' and be done with it!
There are quite enough people running systems without updates without encouraging them to do so.
T
+1
How would a 'micro' installation suggest installing software so that the image does something useful without yum?
On Wed, Mar 19, 2014 at 3:10 PM, Pat Riehecky riehecky@fnal.gov wrote:
How would a 'micro' installation suggest installing software so that the
image does something useful without yum?
In the world of Docker, for instance, best practices like not mixing packaging systems go by the wayside, so you could use pip or gem or npm or whatever tickles you. Most of those can be installed by wget'ing a tarball or the ol' 'curl | bash' abomination.
Still, I prefer to have yum.
On 03/19/2014 07:13 PM, Chris St. Pierre wrote:
In the world of Docker, for instance, best practices like not mixing packaging systems go by the wayside, so you could use pip or gem or npm or whatever tickles you. Most of those can be installed by wget'ing a tarball or the ol' 'curl | bash' abomination.
Still, I prefer to have yum.
curl bash is tricky... wget and verify + rpm install is better :)
however, would this micro image be consumeable under docker ? I didnt think we need a single block type file for docker images ( also, this image will need a boot flag and grub to make it usable under virt, that again might get in the way of docker )
- KB
On Wed, Mar 19, 2014 at 4:30 PM, Karanbir Singh mail-lists@karan.orgwrote:
however, would this micro image be consumeable under docker ? I didnt
think we need a single block type file for docker images ( also, this image will need a boot flag and grub to make it usable under virt, that again might get in the way of docker )
I'm not entirely sure. On the one hand, you could surely bind mount it and do 'tar | docker import', but on the other hand, everything you said.
I guess I was thinking more of a general method to create a minimal install (a kickstart, or a tiny package group, or whatever) rather than just shipping an actual ISO. The word "image" has become overloaded in our brave new world. :) I feel like, if we're going to put in the work to create a 'micro' install, we should go the extra mile to make sure that at least part of that work is applicable to LXC.
On 03/19/2014 10:38 PM, Chris St. Pierre wrote:
On Wed, Mar 19, 2014 at 4:30 PM, Karanbir Singh <mail-lists@karan.org mailto:mail-lists@karan.org> wrote:
however, would this micro image be consumeable under docker ? I didnt think we need a single block type file for docker images ( also, this image will need a boot flag and grub to make it usable under virt, that again might get in the way of docker )I'm not entirely sure. On the one hand, you could surely bind mount it and do 'tar | docker import', but on the other hand, everything you said.
I guess I was thinking more of a general method to create a minimal install (a kickstart, or a tiny package group, or whatever) rather than just shipping an actual ISO. The word "image" has become overloaded in our brave new world. :) I feel like, if we're going to put in the work to create a 'micro' install, we should go the extra mile to make sure that at least part of that work is applicable to LXC.
amen, brother !
On 03/19/2014 07:10 PM, Pat Riehecky wrote:
How would a 'micro' installation suggest installing software so that the image does something useful without yum?
libguestfs does quite a bit of the post-image-instantiation work already, eg: running a ceph cluster inside a VM using micro instances to represent nodes would be fairly simple.
In the xen images, we already do guestfs injection of keys/passphrases etc.
- KB
On Wed, Mar 19, 2014 at 3:25 PM, Karanbir Singh mail-lists@karan.org wrote:
On 03/19/2014 07:10 PM, Pat Riehecky wrote:
How would a 'micro' installation suggest installing software so that the image does something useful without yum?
libguestfs does quite a bit of the post-image-instantiation work already, eg: running a ceph cluster inside a VM using micro instances to represent nodes would be fairly simple.
In the xen images, we already do guestfs injection of keys/passphrases etc.
So is this going to be a special-case just for VMs? Maybe there should be some post-install magic hook for salt/puppet/chef for non-VM central management.
On 03/19/2014 07:05 PM, Trevor Hemsley wrote:
On 19/03/14 16:57, Dan Porter wrote:
I like the name |server-minimal|, or even just |minimal| for the purpose of what the current version is.
Perhaps this super skinny version ought to be called.. |micro|?
If it's an image without yum then I'd suggest we call it 'broken' and be done with it!
There are quite enough people running systems without updates without encouraging them to do so.
so what you are saying is that having yum installed on the machine does not have an impact on them running updates ( for whatever reason! )
so then the thing is perhaps to have a 'this machine is XX days out of sync' or 'its been XX days since the last updates were checked/applied' somewhere on login....
On 03/19/2014 06:41 PM, Jeff Sheltren wrote:
Karanbir Singh wrote:
the aim being to setup a base image, that is under 150mb to download and deploy.
I think there are (at least) two different types of "minimal" that could (and should) be provided.
- "working server minimal" which would have at least yum and sshd --
this could be similar to what we do for minimal now, though I'm not totally opposed to shrinking it down a bit more.
As co-author of the initial minimal.iso shipped by CentOS, I've always considered the current minimal ( which mimics the DVD "minimal" option and bundles all @base ) way too bloated. Personally I always use a trimmed down version of the minimal-C6 kickstart which I have uploaded to nazar.karan.org ( along with other useful kickstart files it used to be available at https://nazar.karan.org/tree/bluecain.git). Incidentally the ks I use for servers includes %packages --nobase --excludedocs
- "really really minimal -- and we mean minimal!" -- where the goal is
to strip out as much as possible, no docs, no yum, no ssshd, etc.
I don't have a use for (2) personally, but use (1) -- or at least one of my own making -- quite frequently. I'd be happy if we could keep both.
Let's trim the current minimal to what it once was and call it "micro" :) However I am not very keen into not including yum and openssh-{clients, server} unless we also provided a script which brings those easily for those needing them. And I suggest that because installing all yum deps via rpm is a bit tedious.
On 03/19/2014 05:23 PM, Manuel Wolfshant wrote:
Let's trim the current minimal to what it once was and call it "micro" :) However I am not very keen into not including yum and openssh-{clients, server} unless we also provided a script which brings those easily for those needing them. And I suggest that because installing all yum deps via rpm is a bit tedious.
ok, we seem to have some tractino around the idea of a micro image, it does not need to be installable, just delivered as an image file backed, people can do whatever; in time we can even growroot inside it and have it deployable to raw block devices.
scripting the stubs would be awesome. can we do this without actually needing to trap the bin namespace ?
And we will need some level of server side capability ( so we dont need to have hardwired yum rpm and its deps listed inside the image, yet have someway to always have it usable, inspite of updates to these packages - and therefore name changes )
- KB
Hi Jeff,
How small have you made (1) ? do you have a kickstart file for it?
In my personal case I'd like to see (2) though, but I'll take what you have :)
cheers, Jaime
On Wed, Mar 19, 2014 at 5:41 PM, Jeff Sheltren jeff@tag1consulting.comwrote:
Karanbir Singh wrote:
the aim being to setup a base image, that is under 150mb to download and deploy.
I think there are (at least) two different types of "minimal" that could (and should) be provided.
- "working server minimal" which would have at least yum and sshd --
this could be similar to what we do for minimal now, though I'm not totally opposed to shrinking it down a bit more.
- "really really minimal -- and we mean minimal!" -- where the goal is
to strip out as much as possible, no docs, no yum, no ssshd, etc.
I don't have a use for (2) personally, but use (1) -- or at least one of my own making -- quite frequently. I'd be happy if we could keep both.
-Jeff _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Jaime Melis wrote:
Hi Jeff,
How small have you made (1) ? do you have a kickstart file for it?
In my personal case I'd like to see (2) though, but I'll take what you have :)
cheers, Jaime
Jamie, the minimal kickstart files that wolfy mentioned: https://nazar.karan.org/tree/bluecain.git are a great reference on how you can create your own "minimal" install to get it even smaller than the one shipped currently.
-Jeff
On 03/19/2014 07:33 PM, Jaime Melis wrote:
Hi Jeff,
How small have you made (1) ? do you have a kickstart file for it?
feel free to get inspiration from http://ur1.ca/gvv6v
In my personal case I'd like to see (2) though, but I'll take what you have :)
cheers, Jaime
On Wed, Mar 19, 2014 at 5:41 PM, Jeff Sheltren <jeff@tag1consulting.com mailto:jeff@tag1consulting.com> wrote:
Karanbir Singh wrote: > > the aim being to setup a base image, that is under 150mb to download and > deploy. > > I think there are (at least) two different types of "minimal" that could (and should) be provided. 1) "working server minimal" which would have at least yum and sshd -- this could be similar to what we do for minimal now, though I'm not totally opposed to shrinking it down a bit more. 2) "really really minimal -- and we mean minimal!" -- where the goal is to strip out as much as possible, no docs, no yum, no ssshd, etc. I don't have a use for (2) personally, but use (1) -- or at least one of my own making -- quite frequently. I'd be happy if we could keep both. -Jeff
On Wed, Mar 19, 2014 at 04:32:06PM +0000, Karanbir Singh wrote:
Something that keeps coming up is how far can we minimalise an Instance / Image / Installer before we cant call it CentOS anymore. In the past, what we have generally stuck with is:
Related questions we struggle with in Fedora: what about i18n and docs? If no docs, docs at all, not even man pages?
similarly, should nobase and nocore be acceptable ? the aim being to setup a base image, that is under 150mb to download and deploy.
Why 150? Next round number down from 200? :)
Matthew Miller wrote:
Related questions we struggle with in Fedora: what about i18n and docs? If no docs, docs at all, not even man pages?
"No docs at all" makes a lot of sense to me if we're going for truly minimal. The main issue I see with that is making end-users aware that they better know what they're doing if they're installing this version.
-Jeff
On Wed, Mar 19, 2014 at 12:14 PM, Jeff Sheltren jeff@tag1consulting.com wrote:
Related questions we struggle with in Fedora: what about i18n and docs? If no docs, docs at all, not even man pages?
"No docs at all" makes a lot of sense to me if we're going for truly minimal. The main issue I see with that is making end-users aware that they better know what they're doing if they're installing this version.
Normally when you install a minimal version you already have a plan for what you will do next. In my case I want the least possible user intervention (or network infrastructure support) to get a system to the point where I can ssh in and complete the setup because people in remote locations that are more familiar with other OS's may have to do it. I'd prefer for sshd and yum to work and to have openssh-clients and rsync installed, but it wouldn't be a showstopper if it took an extra scripted step to get yum going. I'd gladly trade that for an easier way to do the initial network setup when you have multiple NICs and no DHCP (like showing you the one(s) with link up).
On 03/19/2014 07:27 PM, Les Mikesell wrote:
On Wed, Mar 19, 2014 at 12:14 PM, Jeff Sheltren jeff@tag1consulting.com wrote:
Related questions we struggle with in Fedora: what about i18n and docs? If no docs, docs at all, not even man pages?
"No docs at all" makes a lot of sense to me if we're going for truly minimal. The main issue I see with that is making end-users aware that they better know what they're doing if they're installing this version.
Normally when you install a minimal version you already have a plan for what you will do next. In my case I want the least possible user intervention (or network infrastructure support) to get a system to the point where I can ssh in and complete the setup because people in remote locations that are more familiar with other OS's may have to do it. I'd prefer for sshd and yum to work and to have openssh-clients and rsync installed, but it wouldn't be a showstopper if it took an extra scripted step to get yum going.
hence my suggestion from the previous mail...
I'd gladly trade that for aneasier way to do the initial network setup when you have multiple NICs and no DHCP (like showing you the one(s) with link up).
well put desire. however ( PLEASE prove me wrong if I am mistaken ) anaconda only knows something along
network --bootproto=static --ip=a.b.c.n --netmask=255.255.255.0 --gateway=a.b.c.1 --nameserver=a.b.c.2 --device=$DEVICENAME
So ( wild guess here... ) you'd need a bit of intelligence in the %pre/%post sections of a kickstart to detect which interface is up and feed that info to anaconda
On Wed, Mar 19, 2014 at 12:39 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
I'd gladly trade that for aneasier way to do the initial network setup when you have multiple NICs and no DHCP (like showing you the one(s) with link up).
well put desire. however ( PLEASE prove me wrong if I am mistaken ) anaconda only knows something along
network --bootproto=static --ip=a.b.c.n --netmask=255.255.255.0 --gateway=a.b.c.1 --nameserver=a.b.c.2 --device=$DEVICENAMESo ( wild guess here... ) you'd need a bit of intelligence in the %pre/%post sections of a kickstart to detect which interface is up and feed that info to anaconda
Actually that is the part that is normally interactively. That is, the people who handle the hardware and networking are doing the 'hands-on' part. They can fill in a form with the right values but they don't work with linux much and don't have much to go on as to which NIC gets which name. It is painful to figure that out for multiple connected NICs even if you know what you are doing. I usually end up doing something like 'ip link ls' to get the interface names, iterate over them with 'ifconfig up' so that iterating over them with 'ethtool' will show whether link is detected. And then maybe tcpdump to see what subnet addresses are going by... But the 'hands on' guy has to get at least one interface configured correctly without help.
I think we need to take into account that there are multiple different purposes for a minimal image. If I'm using the minimal image in Docker, I don't want or need sshd. In other (non-container) places, I probably do. So maybe we need more than one minimal (or micro) -- 'micro' (outrageously small image for outrageously small machines) and 'micro-lxc' (even smaller image for even smaller containers).
I definitely think yum should be included, though. I should be able to 'RUN yum -y install ...' in my Dockerfile without first invoking some ugly 'RUN rpm -hvU http://...' mess.
One of the many cool things about containers is that we can really almost eliminate all of the userspace except for the application itself. With that in mind, including yum is probably a violation of Twelve Factor (specifically, http://12factor.net/build-release-run), but the Docker build process doesn't really permit truly strict separation of build and run toolsets, just of the stages. As LXC tools continue to evolve, though, there may be a use case for a micro image without even yum, with the assumption that the build stage will be accomplished by an external toolset. That'll be an opportunity to really experiment with how much userspace we can pull out of CentOS.
On Wed, Mar 19, 2014 at 1:27 PM, Les Mikesell lesmikesell@gmail.com wrote:
On Wed, Mar 19, 2014 at 12:14 PM, Jeff Sheltren jeff@tag1consulting.com wrote:
Related questions we struggle with in Fedora: what about i18n and docs?
If
no docs, docs at all, not even man pages?
"No docs at all" makes a lot of sense to me if we're going for truly minimal. The main issue I see with that is making end-users aware that
they
better know what they're doing if they're installing this version.
Normally when you install a minimal version you already have a plan for what you will do next. In my case I want the least possible user intervention (or network infrastructure support) to get a system to the point where I can ssh in and complete the setup because people in remote locations that are more familiar with other OS's may have to do it. I'd prefer for sshd and yum to work and to have openssh-clients and rsync installed, but it wouldn't be a showstopper if it took an extra scripted step to get yum going. I'd gladly trade that for an easier way to do the initial network setup when you have multiple NICs and no DHCP (like showing you the one(s) with link up).
-- Les Mikesell lesmikesell@gmail.com _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Wed, Mar 19, 2014 at 12:44 PM, Chris St. Pierre chris.a.st.pierre@gmail.com wrote:
I think we need to take into account that there are multiple different purposes for a minimal image. If I'm using the minimal image in Docker, I don't want or need sshd. In other (non-container) places, I probably do. So maybe we need more than one minimal (or micro) -- 'micro' (outrageously small image for outrageously small machines) and 'micro-lxc' (even smaller image for even smaller containers).
I definitely think yum should be included, though. I should be able to 'RUN yum -y install ...' in my Dockerfile without first invoking some ugly 'RUN rpm -hvU http://...' mess.
For some purposes, you might want to look at what the 'rear' package (from EPEL) does in terms of building a bootable image containing a script to reconstruct the partitions/filesystems and restore a backup to it. With a little configuration you might be able to tune it to restore exactly what you want, especially if you intend to effectively clone a base install.
On 03/19/2014 05:10 PM, Matthew Miller wrote:
Related questions we struggle with in Fedora: what about i18n and docs? If no docs, docs at all, not even man pages?
no docs at all, our default minimal install does not put in 'man' either. and no lang support other than EN
similarly, should nobase and nocore be acceptable ? the aim being to setup a base image, that is under 150mb to download and deploy.
Why 150? Next round number down from 200? :)
the problem with tuning stuff is knowing when to stop for long enough to release something, 150 is 50% of the present minimal installable, bootable image, so a good target ( imho ) to hit. Anecdotal evidence suggests that its possible to get a centos-6 kernel booting and sshd running in a bit less than that ( with 'excess stuff' like syslog removed.. ) Not sure if we want to go there.
On 19 March 2014 10:32, Karanbir Singh mail-lists@karan.org wrote:
Hi
Something that keeps coming up is how far can we minimalise an Instance / Image / Installer before we cant call it CentOS anymore. In the past, what we have generally stuck with is:
- CentOS Shipped kernel
- Initscripts
- functional yum
- functional openssh-server
- atleast all of @base
however, in some cases, openssh-server might not be needed, and initscripts has a fairly long dep tree, similarly making yum work needs a few things. Can we get away with losing yum as an example and replacing it with a script that says 'need yum? I can download and install it for you' and have it hit mirror.centos.org for static yum and yum dep urls ?
similarly, should nobase and nocore be acceptable ?
the aim being to setup a base image, that is under 150mb to download and deploy.
The bare minimum I have had to help groups get down to is basically a kernel+busybox with scripts that they could install whatever they wanted from there. As I see busybox isn't installed by default anymore on Fedora I can see this was a lot longer in the past than I realized. If there is a 'newer' shinier replacement to busybox I don't know what that is but it may be more of the 'way' to go these days.
I would call that a nano install. It should give you just enough to get other stuff onto a box to make it usable if you have the time and love to write the scripts to do the stuff that would need to get yum and other stuff working.
On Wed, Mar 19, 2014 at 2:43 PM, Stephen John Smoogen smooge@gmail.com wrote:
the aim being to setup a base image, that is under 150mb to download and deploy.
The bare minimum I have had to help groups get down to is basically a kernel+busybox with scripts that they could install whatever they wanted from there.
And for a slightly different variation on the concept of mimimal - it would be fun to have a 'thin-client' variation that would boot 'live' from USB/iso/pxe with just enough to run native X, x2go, vnc client, or freerdp -preferably with a way to pre-configure the targets and an optional full-screen startup of one of those apps. Maybe spice could work that way too.
19.3.2014 18.32, Karanbir Singh kirjoitti:
the aim being to setup a base image, that is under 150mb to download and deploy.
I think there's a bit of confusion between what is included in the minimal.iso, and what gets installed as a result of installing from the said minimal.iso. Currently the set of packages that gets installed from minimal.iso is fixed, but it doesn't necessarily need to be that way.
How about a single minimal.iso that lets you decide how minimal you want it to be? The default would contain the usually required tools like yum, openssh-server, dhclient, dhcpv6-client, but if someone doesn't want them, they could be deselected from the installer. Likewise, if someone needs openssh-clients, it could be selected to be installed from the installer.
Yes, that may mean some more downloading for those folks who need to use only the 'micro' package set, but the benefit of having a slightly more general purpose .iso outweights that, imho.
I'm looking at this from the support perspective. "I installed the micro variant, but there's no yum to install more packages?" -- "Correct, the micro.iso does not contain yum, you will need to download and burn and install the minimal.iso if you need that [or jump through other hoops]" -- "Well that sucks, I'm switching to $some_other_distro."
On 19 March 2014 15:11, Anssi Johansson centos@miuku.net wrote:
19.3.2014 18.32, Karanbir Singh kirjoitti:
the aim being to setup a base image, that is under 150mb to download and deploy.
I think there's a bit of confusion between what is included in the minimal.iso, and what gets installed as a result of installing from the said minimal.iso. Currently the set of packages that gets installed from minimal.iso is fixed, but it doesn't necessarily need to be that way.
How about a single minimal.iso that lets you decide how minimal you want it to be? The default would contain the usually required tools like yum, openssh-server, dhclient, dhcpv6-client, but if someone doesn't want them, they could be deselected from the installer. Likewise, if someone needs openssh-clients, it could be selected to be installed from the installer.
Yes, that may mean some more downloading for those folks who need to use only the 'micro' package set, but the benefit of having a slightly more general purpose .iso outweights that, imho.
I'm looking at this from the support perspective. "I installed the micro variant, but there's no yum to install more packages?" -- "Correct, the micro.iso does not contain yum, you will need to download and burn and install the minimal.iso if you need that [or jump through other hoops]" -- "Well that sucks, I'm switching to $some_other_distro."
Having dealt with that kind of support question for 15+ years... they are usually going to say that no matter what. It is a game of whatif you can't get past because this type of person is mostly looking for an excuse not to use you versus seeing it as something they should have known.
You can call it micro-noyum.image or put it behind a "Do you really want to do this" download page and you will end up with people still asking the same question and the same reply when told. In the end, the best you can do is say "That's great, you may find <X> more to your flavour" and go on supporting the people who want to be using CentOS. [Only took me 12 of my 15+ years to figure that out.]
On Wed, Mar 19, 2014 at 4:24 PM, Stephen John Smoogen smooge@gmail.com wrote:
I'm looking at this from the support perspective. "I installed the micro variant, but there's no yum to install more packages?" -- "Correct, the micro.iso does not contain yum, you will need to download and burn and install the minimal.iso if you need that [or jump through other hoops]" -- "Well that sucks, I'm switching to $some_other_distro."
Having dealt with that kind of support question for 15+ years... they are usually going to say that no matter what. It is a game of whatif you can't get past because this type of person is mostly looking for an excuse not to use you versus seeing it as something they should have known.
Sure, but support questions aren't really a problem if you have an answer like 'run this one-line, easily typed command" and the issue is resolved'. For pretty much anything but yum, that command is 'yum install some_list_of_stuff'. If you leave out yum, you need some functional equivalent to get it - which might be considerably smaller than yum but still non-trivial since it needs to find the current version and all its dependencies. Maybe that list of packages could be maintained externally in a way that rpm could get them directly, though.
On 19 March 2014 15:37, Les Mikesell lesmikesell@gmail.com wrote:
On Wed, Mar 19, 2014 at 4:24 PM, Stephen John Smoogen smooge@gmail.com wrote:
I'm looking at this from the support perspective. "I installed the micro variant, but there's no yum to install more packages?" -- "Correct, the micro.iso does not contain yum, you will need to download and burn and install the minimal.iso if you need that [or jump through other hoops]" -- "Well that sucks, I'm switching to $some_other_distro."
Having dealt with that kind of support question for 15+ years... they are usually going to say that no matter what. It is a game of whatif you
can't
get past because this type of person is mostly looking for an excuse not
to
use you versus seeing it as something they should have known.
Sure, but support questions aren't really a problem if you have an answer like 'run this one-line, easily typed command" and the issue is resolved'. For pretty much anything but yum, that command is 'yum install some_list_of_stuff'. If you leave out yum, you need some functional equivalent to get it - which might be considerably smaller than yum but still non-trivial since it needs to find the current version and all its dependencies. Maybe that list of packages could be maintained externally in a way that rpm could get them directly, though,.
Support questions are always a problem. I have had many many many requests where telling someone that if they ran this script it would download and fix their problem and then be told it is too much work and they would rather use X instead.
Look this image isn't for general consumption. It is to solve a particular problem for a set of people who want to be able to have a box with 128 MB of RAM and 200 MB or less of disk space. That number of people who have this problem are large enough that Karanbir and others would like to solve it with a CentOS image. The people who use this sort of image just want an OS, some basic libraries and the ability to drop their tar ball of whatever on it and make it work. These balls will generally come with their own apache server, python or ruby etc etc in it. Everything outside of that is just wasted disk space to them.
On Wed, Mar 19, 2014 at 5:01 PM, Stephen John Smoogen smooge@gmail.com wrote:
Support questions are always a problem. I have had many many many requests where telling someone that if they ran this script it would download and fix their problem and then be told it is too much work and they would rather use X instead.
People should be suspicious of having to get some external script to fix a problem since that means it wasn't designed well in the first place. But running an included command already designed for the situation should be reasonable for anyone who has taken the 'build it from tiny pieces' approach in the first place.
Look this image isn't for general consumption. It is to solve a particular problem for a set of people who want to be able to have a box with 128 MB of RAM and 200 MB or less of disk space. That number of people who have this problem are large enough that Karanbir and others would like to solve it with a CentOS image. The people who use this sort of image just want an OS, some basic libraries and the ability to drop their tar ball of whatever on it and make it work. These balls will generally come with their own apache server, python or ruby etc etc in it. Everything outside of that is just wasted disk space to them.
But, there's no way to know what libs those things they want to add will need. And, in my opinion it should be criminal to distribute code without a mechanism to obtain security updates. Unless, of course, that code doesn't have any flaws. So I'd consider yum essential except in the odd case of VMs that you'd re-create rather than update, or where you have some other means of updating.
-
Anssi Johansson -
Bryan Seitz -
Chris St. Pierre -
Dan Porter -
Jaime Melis -
Jeff Sheltren -
Karanbir Singh -
Les Mikesell -
Manuel Wolfshant -
Matthew Miller -
Pat Riehecky -
Stephen John Smoogen -
Trevor Hemsley