10:28 a.m.
Okay, cool -- there's a lot of enthusiasm for a SIG for the core package
set.
So, first up on the SIG goals: clarifying our target.
It's been suggested before that there's so many possibilities that this is
useless, but the point here is to *pick* a reasonable choice as a group and
to work with that (even if we can't get complete consensus). Then, later,
when someone says "but minimal could mean so many differen things!" we
simply say "sure, but *this* is what we mean".
I see three basic options for the target:
A) kernel + init system and we're done
B) "boot to yum (with network)": a text-mode bootstrap environment on which
other things can be added by hand (or by kickstart)
C) a traditional Unix command line environment with the expected basic
tools available
To me, 'C' is too wide for two reasons. First, it's too open for continual
debate, because different people might expect different tools. Second, it's
not necessarily the right base for the rest of the distribution, because
many use cases might not really need that traditional Unix environment.
I think 'A' is interesting and useful, but I don't think it should be our
target, because it's not *useful enough*. We may want to eventually define a
sub-group which covers just this tiny base (maybe with busybox?), but I
think that's a different project.
So that leaves me at *mostly B*, although I have some sympathy to the idea
that we should include a few other things like a man page reader, since
we're installing man pages, and a way to deliver e-mail to root, since we're
installing things that send such mail. And I think the core environment
should include ssh, but I'm open to the idea that even that should be an
add-on.
What do you think?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
10:29 a.m.
On Mon, 12 Nov 2012, Matthew Miller wrote:
Okay, cool -- there's a lot of enthusiasm for a SIG for the core
package
set.
So, first up on the SIG goals: clarifying our target.
It's been suggested before that there's so many possibilities that this is
useless, but the point here is to *pick* a reasonable choice as a group and
to work with that (even if we can't get complete consensus). Then, later,
when someone says "but minimal could mean so many differen things!" we
simply say "sure, but *this* is what we mean".
I see three basic options for the target:
A) kernel + init system and we're done
B) "boot to yum (with network)": a text-mode bootstrap environment on which
other things can be added by hand (or by kickstart)
C) a traditional Unix command line environment with the expected basic
tools available
To me, 'C' is too wide for two reasons. First, it's too open for continual
debate, because different people might expect different tools. Second, it's
not necessarily the right base for the rest of the distribution, because
many use cases might not really need that traditional Unix environment.
I think 'A' is interesting and useful, but I don't think it should be our
target, because it's not *useful enough*. We may want to eventually define a
sub-group which covers just this tiny base (maybe with busybox?), but I
think that's a different project.
So that leaves me at *mostly B*, although I have some sympathy to the idea
that we should include a few other things like a man page reader, since
we're installing man pages, and a way to deliver e-mail to root, since we're
installing things that send such mail. And I think the core environment
should include ssh, but I'm open to the idea that even that should be an
add-on.
What do you think?
I think ssh has to be in the mix. Of ths systems I use/maintain/etc very
few of them are ones I actually have a reliable console to.
If ssh isn't there, I have to add it just to get the system set up.
-sv
10:38 a.m.
On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote:
I think ssh has to be in the mix. Of ths systems I use/maintain/etc
very few of them are ones I actually have a reliable console to.
If ssh isn't there, I have to add it just to get the system set up.
Yeah: if we get to the point where every real install has to add the same
subset of packages to core, I don't think we've succeeded in doing anything
except make more work for the whole world.
A cron daemon and (at least basic) MTA fall in the same area, I think.
But what about ssh-clients?
Is there a reasonable yardstick rule we can make, or is it pragmatically
best to just make per-package decisions?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
10:37 a.m.
On Mon, 12 Nov 2012, Matthew Miller wrote:
On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote:
> I think ssh has to be in the mix. Of ths systems I use/maintain/etc
> very few of them are ones I actually have a reliable console to.
> If ssh isn't there, I have to add it just to get the system set up.
Yeah: if we get to the point where every real install has to add the same
subset of packages to core, I don't think we've succeeded in doing anything
except make more work for the whole world.
A cron daemon and (at least basic) MTA fall in the same area, I think.
But what about ssh-clients?
Is there a reasonable yardstick rule we can make, or is it pragmatically
best to just make per-package decisions?
so - imo
openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/
ditto w/rsync.
-sv
11:02 a.m.
On Mon, 2012-11-12 at 11:37 -0500, Seth Vidal wrote:
On Mon, 12 Nov 2012, Matthew Miller wrote:
> On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote:
>> I think ssh has to be in the mix. Of ths systems I use/maintain/etc
>> very few of them are ones I actually have a reliable console to.
>> If ssh isn't there, I have to add it just to get the system set up.
>
> Yeah: if we get to the point where every real install has to add the same
> subset of packages to core, I don't think we've succeeded in doing anything
> except make more work for the whole world.
>
> A cron daemon and (at least basic) MTA fall in the same area, I think.
> But what about ssh-clients?
>
> Is there a reasonable yardstick rule we can make, or is it pragmatically
> best to just make per-package decisions?
>
so - imo
openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/
Perhaps scp could be moved to the base openssh package then.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
11:03 a.m.
On Mon, 12 Nov 2012, Tomas Mraz wrote:
On Mon, 2012-11-12 at 11:37 -0500, Seth Vidal wrote:
>
>
> On Mon, 12 Nov 2012, Matthew Miller wrote:
>
>> On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote:
>>> I think ssh has to be in the mix. Of ths systems I use/maintain/etc
>>> very few of them are ones I actually have a reliable console to.
>>> If ssh isn't there, I have to add it just to get the system set up.
>>
>> Yeah: if we get to the point where every real install has to add the same
>> subset of packages to core, I don't think we've succeeded in doing
anything
>> except make more work for the whole world.
>>
>> A cron daemon and (at least basic) MTA fall in the same area, I think.
>> But what about ssh-clients?
>>
>> Is there a reasonable yardstick rule we can make, or is it pragmatically
>> best to just make per-package decisions?
>>
>
> so - imo
>
> openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/
Perhaps scp could be moved to the base openssh package then.
Sounds reasonable to me.
-sv
11:09 a.m.
On 11/12/2012 06:03 PM, Seth Vidal wrote:
On Mon, 12 Nov 2012, Tomas Mraz wrote:
> On Mon, 2012-11-12 at 11:37 -0500, Seth Vidal wrote:
>>
>>
>> On Mon, 12 Nov 2012, Matthew Miller wrote:
>>
>>> On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote:
>>>> I think ssh has to be in the mix. Of ths systems I use/maintain/etc
>>>> very few of them are ones I actually have a reliable console to.
>>>> If ssh isn't there, I have to add it just to get the system set up.
>>>
>>> Yeah: if we get to the point where every real install has to add the same
>>> subset of packages to core, I don't think we've succeeded in doing
>>> anything
>>> except make more work for the whole world.
>>>
>>> A cron daemon and (at least basic) MTA fall in the same area, I think.
>>> But what about ssh-clients?
>>>
>>> Is there a reasonable yardstick rule we can make, or is it pragmatically
>>> best to just make per-package decisions?
>>>
>>
>> so - imo
>>
>> openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/
>
> Perhaps scp could be moved to the base openssh package then.
>
Sounds reasonable to me.
Not sure that's a good idea. "ssh" itself is also part of the clients
package and should probably moved as well then. "sftp" is probably popular
too. I think its better to bite the bullet and just include the clients
package as a whole.
Regards,
Dennis
11:10 a.m.
On Mon, 12 Nov 2012, Dennis Jacobfeuerborn wrote:
On 11/12/2012 06:03 PM, Seth Vidal wrote:
>
>
>
> On Mon, 12 Nov 2012, Tomas Mraz wrote:
>
>> On Mon, 2012-11-12 at 11:37 -0500, Seth Vidal wrote:
>>>
>>>
>>> On Mon, 12 Nov 2012, Matthew Miller wrote:
>>>
>>>> On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote:
>>>>> I think ssh has to be in the mix. Of ths systems I use/maintain/etc
>>>>> very few of them are ones I actually have a reliable console to.
>>>>> If ssh isn't there, I have to add it just to get the system set
up.
>>>>
>>>> Yeah: if we get to the point where every real install has to add the
same
>>>> subset of packages to core, I don't think we've succeeded in
doing
>>>> anything
>>>> except make more work for the whole world.
>>>>
>>>> A cron daemon and (at least basic) MTA fall in the same area, I think.
>>>> But what about ssh-clients?
>>>>
>>>> Is there a reasonable yardstick rule we can make, or is it pragmatically
>>>> best to just make per-package decisions?
>>>>
>>>
>>> so - imo
>>>
>>> openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/
>>
>> Perhaps scp could be moved to the base openssh package then.
>>
>
> Sounds reasonable to me.
Not sure that's a good idea. "ssh" itself is also part of the clients
package and should probably moved as well then. "sftp" is probably popular
too. I think its better to bite the bullet and just include the clients
package as a whole.
i think you misunderstand.
if I am attempting to connect to a server running sshd:
I can run
ssh servername
and that works
I can run
sftp servername
and THAT works
I cannot run
scp servername
I have to have a local scp client installed on the server for scp to work
as a service.
-sv
11:43 a.m.
On 11/12/2012 06:10 PM, Seth Vidal wrote:
On Mon, 12 Nov 2012, Dennis Jacobfeuerborn wrote:
> On 11/12/2012 06:03 PM, Seth Vidal wrote:
>>
>>
>>
>> On Mon, 12 Nov 2012, Tomas Mraz wrote:
>>
>>> On Mon, 2012-11-12 at 11:37 -0500, Seth Vidal wrote:
>>>>
>>>>
>>>> On Mon, 12 Nov 2012, Matthew Miller wrote:
>>>>
>>>>> On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote:
>>>>>> I think ssh has to be in the mix. Of ths systems I
use/maintain/etc
>>>>>> very few of them are ones I actually have a reliable console to.
>>>>>> If ssh isn't there, I have to add it just to get the system
set up.
>>>>>
>>>>> Yeah: if we get to the point where every real install has to add the
same
>>>>> subset of packages to core, I don't think we've succeeded in
doing
>>>>> anything
>>>>> except make more work for the whole world.
>>>>>
>>>>> A cron daemon and (at least basic) MTA fall in the same area, I
think.
>>>>> But what about ssh-clients?
>>>>>
>>>>> Is there a reasonable yardstick rule we can make, or is it
pragmatically
>>>>> best to just make per-package decisions?
>>>>>
>>>>
>>>> so - imo
>>>>
>>>> openssh-clients is required, yes - b/c w/o them scp doesn't work.
:-/
>>>
>>> Perhaps scp could be moved to the base openssh package then.
>>>
>>
>> Sounds reasonable to me.
>
> Not sure that's a good idea. "ssh" itself is also part of the clients
> package and should probably moved as well then. "sftp" is probably popular
> too. I think its better to bite the bullet and just include the clients
> package as a whole.
>
i think you misunderstand.
if I am attempting to connect to a server running sshd:
I can run
ssh servername
and that works
I can run
sftp servername
and THAT works
I cannot run
scp servername
I have to have a local scp client installed on the server for scp to work as a service.
scp is a ssh client. It connects to other host using a ssh connection and runs 'scp
-t' or 'scp -f'
commands on the remote side. From my point of view, it's same as any other program you
can use via
ssh and I believe that openssh-clients is the right place for it.
sftp subsystem is configured by default so you can use it if you need transfer files to
minimal system.
Petr
--
Petr Lautrbach, Red Hat, Inc.
http://cz.redhat.com
11:44 a.m.
On Mon, 12 Nov 2012, Petr Lautrbach wrote:
scp is a ssh client. It connects to other host using a ssh connection
and
runs 'scp -t' or 'scp -f'
commands on the remote side. From my point of view, it's same as any other
program you can use via
ssh and I believe that openssh-clients is the right place for it.
sftp subsystem is configured by default so you can use it if you need
transfer files to minimal system.
which was, in fact, what I said.
scp is something people expect to be able to use on servers to send files
over. that it is not there makes the server install feel a touch awkward.
that's all.
-sv
12:10 p.m.
On 11/12/2012 06:44 PM, Seth Vidal wrote:
On Mon, 12 Nov 2012, Petr Lautrbach wrote:
> scp is a ssh client. It connects to other host using a ssh connection and runs
'scp -t' or 'scp -f'
> commands on the remote side. From my point of view, it's same as any other
program you can use via
> ssh and I believe that openssh-clients is the right place for it.
>
> sftp subsystem is configured by default so you can use it if you need transfer files
to minimal system.
>
which was, in fact, what I said.
scp is something people expect to be able to use on servers to send files over. that it
is not there makes the server install feel a touch awkward.
that's all.
A thin client would probably not want to install openssh-server.
Petr
12:42 p.m.
On Mon, Nov 12, 2012 at 07:10:21PM +0100, Petr Lautrbach wrote:
A thin client would probably not want to install openssh-server.
Bringing us back around to the point of this thread. :)
Thin client is one use case.
Server base is another.
JEOS cloud image is another.
We don't necessarily have to define @core such that it means only the bare
minimum (although I think that's on the table, at least). It's useful to
consider packages which might fit a broad reading of the use cases within
the scope of this SIG. For example, if SSH suddenly grew a dependency on
(picking on something at random) Django, I think we'd want to talk about it.
That's one of the reasons I think it's useful to have a broader target.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
4:07 p.m.
On Mon, Nov 12, 2012 at 01:42:02PM -0500, Matthew Miller wrote:
On Mon, Nov 12, 2012 at 07:10:21PM +0100, Petr Lautrbach wrote:
> A thin client would probably not want to install openssh-server.
Bringing us back around to the point of this thread. :)
Thin client is one use case.
Server base is another.
JEOS cloud image is another.
oVirt Node is another ... It's not really like any of the things
discussed before:
(a) It's "sealed". You can't use yum to install packages, by design.
(b) It's minimized. In order to fit it on very tiny flash disks,
large parts such as docs and locales are 'rm -rf'd.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
1:57 p.m.
On Mon, 12 Nov 2012, Petr Lautrbach wrote:
> which was, in fact, what I said.
>
> scp is something people expect to be able to use on servers to send files
> over. that it is not there makes the server install feel a touch awkward.
>
> that's all.
A thin client would probably not want to install openssh-server.
fantastic. show me a deployment somewhere of a 'thin client' that doesn't
use their own custom kickstart/pxe for instantiating the clients and that
will be relevant to this discussion.
-sv
2:08 p.m.
On 11/12/2012 11:57 AM, Seth Vidal wrote:
On Mon, 12 Nov 2012, Petr Lautrbach wrote:
>> which was, in fact, what I said.
>>
>> scp is something people expect to be able to use on servers to send
>> files over. that it is not there makes the server install feel a
>> touch awkward.
>>
>> that's all.
>
> A thin client would probably not want to install openssh-server.
>
fantastic. show me a deployment somewhere of a 'thin client' that
doesn't use their own custom kickstart/pxe for instantiating the clients
and that will be relevant to this discussion.
-sv
To be fair if we're talking about redefining what goes into @core (which
cannot be deselected, and mandatory items cannot be deselected) then
even those doing kickstart/pxe are relevant to the discussion.
--
Help me fight child abuse: http://tinyurl.com/jlkcourage
- jlk
2:17 p.m.
On Mon, Nov 12, 2012 at 12:08:38PM -0800, Jesse Keating wrote:
To be fair if we're talking about redefining what goes into
@core
(which cannot be deselected, and mandatory items cannot be
deselected) then even those doing kickstart/pxe are relevant to the
discussion.
Is it now the case that they can't be deselected with "-" in kickstart?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
2:21 p.m.
On 11/12/2012 12:17 PM, Matthew Miller wrote:
On Mon, Nov 12, 2012 at 12:08:38PM -0800, Jesse Keating wrote:
> To be fair if we're talking about redefining what goes into @core
> (which cannot be deselected, and mandatory items cannot be
> deselected) then even those doing kickstart/pxe are relevant to the
> discussion.
Is it now the case that they can't be deselected with "-" in kickstart?
Historically the @core group did not have anything other than mandatory
packages as there was no UI to deselect them (because core was not a
visible group). Core is still not a visible group, but there appears to
be a few "default" packages in there now, NetworkManager, ppc64-utils,
and sendmail. I'm not sure of the backstory on this, but now you can -
those packages (provided nothing else requires them). More of @core
could be made this way, if that was desired for the kickstarters.
--
Help me fight child abuse: http://tinyurl.com/jlkcourage
- jlk
2:25 p.m.
On Mon, 12 Nov 2012, Jesse Keating wrote:
On 11/12/2012 12:17 PM, Matthew Miller wrote:
> On Mon, Nov 12, 2012 at 12:08:38PM -0800, Jesse Keating wrote:
>> To be fair if we're talking about redefining what goes into @core
>> (which cannot be deselected, and mandatory items cannot be
>> deselected) then even those doing kickstart/pxe are relevant to the
>> discussion.
>
> Is it now the case that they can't be deselected with "-" in
kickstart?
>
>
Historically the @core group did not have anything other than mandatory
packages as there was no UI to deselect them (because core was not a visible
group). Core is still not a visible group, but there appears to be a few
"default" packages in there now, NetworkManager, ppc64-utils, and sendmail.
I'm not sure of the backstory on this, but now you can - those packages
(provided nothing else requires them). More of @core could be made this way,
if that was desired for the kickstarters.
sendmail is in there so we didn't need a special case to make sendmail
'win' for the options for MTA.
ppc64-utils is b/c I do not think we had another way to get it in for the
ppc boxes.
-sv
2:25 p.m.
On Mon, Nov 12, 2012 at 12:21:43PM -0800, Jesse Keating wrote:
>>To be fair if we're talking about redefining what goes
into @core
>>(which cannot be deselected, and mandatory items cannot be
>>deselected) then even those doing kickstart/pxe are relevant to the
>>discussion.
>Is it now the case that they can't be deselected with "-" in
kickstart?
Historically the @core group did not have anything other than
mandatory packages as there was no UI to deselect them (because core
was not a visible group). Core is still not a visible group, but
there appears to be a few "default" packages in there now,
But there was a non-UI way. Does that no longer work?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
2:27 p.m.
On 11/12/2012 12:25 PM, Matthew Miller wrote:
On Mon, Nov 12, 2012 at 12:21:43PM -0800, Jesse Keating wrote:
>>> To be fair if we're talking about redefining what goes into @core
>>> (which cannot be deselected, and mandatory items cannot be
>>> deselected) then even those doing kickstart/pxe are relevant to the
>>> discussion.
>> Is it now the case that they can't be deselected with "-" in
kickstart?
> Historically the @core group did not have anything other than
> mandatory packages as there was no UI to deselect them (because core
> was not a visible group). Core is still not a visible group, but
> there appears to be a few "default" packages in there now,
But there was a non-UI way. Does that no longer work?
The non-UI way was kickstart. But you can't deselect (-) mandatory
packages in a group. @core is primarily made up of mandatory packages.
--
Help me fight child abuse: http://tinyurl.com/jlkcourage
- jlk
7:25 p.m.
On Mon, Nov 12, 2012 at 12:27:34PM -0800, Jesse Keating wrote:
>But there was a non-UI way. Does that no longer work?
The non-UI way was kickstart. But you can't deselect (-) mandatory
packages in a group. @core is primarily made up of mandatory
packages.
Huh. I could swear I've done that before and it worked. In any case, it is
_certainly_ working with appliance-creator right now. :)
This actually opens up another axis, here, so we could have one standard for
mandatory packages (kernel+init, or up-to-yum+net) and a second level for
default (up-to-yum+net, +ssh,cron,etc). Even without a UI exposed, the
distinction between mandatory and deselectable is huge for kickstart, which
I think is common for _most_ of our use cases.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
8:41 p.m.
I don't know Fedora minimal looks like...FOR SERVER USE the Minimal
includes:
Network support;
BASH;
Maybe some development tools also.
Nothing else.
BUT FOR DESKTOP USE,I think it should also have a desktop based on server
version...That's what is troubling me...If it has a built-in desktop,I
don't know if we can still treat it as minimal..
8:33 a.m.
2012/11/13 Christopher Meng <cickumqt(a)gmail.com>
I don't know Fedora minimal looks like...FOR SERVER USE the
Minimal
includes:
[...]
BUT FOR DESKTOP USE,I think it should also have a desktop based on server
version...That's what is troubling me...If it [...]
This is something we shouldn't mix. When we are talking about core I would
assume it is the core for everything, regardless if it is a server or a
desktop. So if we talk about server minimal or desktop minimal, we talk
about core + X for server minimal and core + Y for desktop minimal.
So from my point of view, core is not minimal, it is the base for every
later taste, regardless if server, desktop, mobile or whatever.
Regards, Thomas
--
Linux ... enjoy the ride!
10:07 p.m.
On 11/12/2012 05:25 PM, Matthew Miller wrote:
appliance-creator may not force @core. The force of @core is an
anaconda thing.
On Mon, Nov 12, 2012 at 12:27:34PM -0800, Jesse Keating wrote:
>> But there was a non-UI way. Does that no longer work?
> The non-UI way was kickstart. But you can't deselect (-) mandatory
> packages in a group. @core is primarily made up of mandatory
> packages.
Huh. I could swear I've done that before and it worked. In any case, it is
_certainly_ working with appliance-creator right now. :)
This actually opens up another axis, here, so we could have one standard for
mandatory packages (kernel+init, or up-to-yum+net) and a second level for
default (up-to-yum+net, +ssh,cron,etc). Even without a UI exposed, the
distinction between mandatory and deselectable is huge for kickstart, which
I think is common for _most_ of our use cases.
Yeah, that's a thing that probably could be done. Bug again I'd like
some input from people who have made the switch to these packages being
mandatory.
--
Help me fight child abuse: http://tinyurl.com/jlkcourage
- jlk
10:24 p.m.
On Mon, Nov 12, 2012 at 08:07:39PM -0800, Jesse Keating wrote:
Yeah, that's a thing that probably could be done. Bug again
I'd
like some input from people who have made the switch to these
packages being mandatory.
Well, I think it's just that the policy for a long time that since core
isn't visible, default or optional are pointless. Specifically:
http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_g...
says (right now, but maybe not for long):
Core is not visible, so adding 'default' or 'optional' packages to it
isn't
needed. Boot loaders are listed as 'default' in the group so that they're
pulled in by compose tools.
That last part isn't even right. There's not too many packages in core, so I
don't think it'll be that difficult of an excercise to find the reasoning
for each.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
3:41 p.m.
Matthew Miller (mattdm(a)fedoraproject.org) said:
On Mon, Nov 12, 2012 at 08:07:39PM -0800, Jesse Keating wrote:
> Yeah, that's a thing that probably could be done. Bug again I'd
> like some input from people who have made the switch to these
> packages being mandatory.
Well, I think it's just that the policy for a long time that since core
isn't visible, default or optional are pointless. Specifically:
http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_g...
says (right now, but maybe not for long):
Core is not visible, so adding 'default' or 'optional' packages to it
isn't
needed. Boot loaders are listed as 'default' in the group so that they're
pulled in by compose tools.
That last part isn't even right. There's not too many packages in core, so I
don't think it'll be that difficult of an excercise to find the reasoning
for each.
So, what it is bascially designed for now is:
- Boot to a normal prompt
basesystem
bash
coreutils
filesystem
glibc
initscripts
plymouth (was for boot logs & encrypted partitions; could be dropped)
rootfiles
setup
systemd
util-linux
(plus implicit kernel)
- Support basic networking
biosdevname (consistent naming policy)
initscripts
dhclient
hostname
iproute
iputils
NetworkManager
- Connect to remote systems
curl
openssh-clients
- Allow remote systems to connect to us
openssh-server
- Store & forward logs
audit
rsyslog
- Install other software
rpm
yum
- SELinux
policycoreutils
selinux-policy-targeted
- Add/remove/configure local users, and allow them to admin if necessary
passwd
shadow-utils
sudo
- Minimal tools for admins
less
man-db
procps-ng
vim-minimal
- Scheduled tasks
cronie
- Get mail off the box (and define a default for doing so)
sendmail
- Support a local console
kbd
ncurses
- Configure additional partitions for the simple case
e2fsprogs
parted
- Probably legacy and can be dropped from explicit listing
iprutils
ppc64-utils
Bill
3:59 p.m.
On Tuesday, November 13, 2012 04:41:12 PM Bill Nottingham wrote:
Matthew Miller (mattdm(a)fedoraproject.org) said:
> On Mon, Nov 12, 2012 at 08:07:39PM -0800, Jesse Keating wrote:
> > Yeah, that's a thing that probably could be done. Bug again I'd
> > like some input from people who have made the switch to these
> > packages being mandatory.
>
> Well, I think it's just that the policy for a long time that since core
> isn't visible, default or optional are pointless. Specifically:
>
> http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_gr
> oups#Core>
> says (right now, but maybe not for long):
> Core is not visible, so adding 'default' or 'optional' packages to
it
> isn't
> needed. Boot loaders are listed as 'default' in the group so that
> they're
> pulled in by compose tools.
>
> That last part isn't even right. There's not too many packages in core, so
> I don't think it'll be that difficult of an excercise to find the
> reasoning for each.
So, what it is bascially designed for now is:
- Boot to a normal prompt
basesystem
bash
coreutils
filesystem
glibc
initscripts
plymouth (was for boot logs & encrypted partitions; could be dropped)
rootfiles
setup
systemd
util-linux
(plus implicit kernel)
- Support basic networking
biosdevname (consistent naming policy)
initscripts
dhclient
hostname
iproute
iputils
NetworkManager
Shouldn't iptables be here too?
- Connect to remote systems
curl
openssh-clients
- Allow remote systems to connect to us
openssh-server
- Store & forward logs
audit
rsyslog
As soon as you have logs, you need to be able to rotate them. So, I'd add
logrotate and cronie at this point. Failure to rotate logs can fill the /var
partition and then bad things happen.
Thanks,
-Steve
- Install other software
rpm
yum
- SELinux
policycoreutils
selinux-policy-targeted
- Add/remove/configure local users, and allow them to admin if necessary
passwd
shadow-utils
sudo
- Minimal tools for admins
less
man-db
procps-ng
vim-minimal
- Scheduled tasks
cronie
- Get mail off the box (and define a default for doing so)
sendmail
- Support a local console
kbd
ncurses
- Configure additional partitions for the simple case
e2fsprogs
parted
- Probably legacy and can be dropped from explicit listing
iprutils
ppc64-utils
Bill
4:07 p.m.
Once upon a time, Bill Nottingham <notting(a)redhat.com> said:
So, what it is bascially designed for now is:
- Boot to a normal prompt
basesystem
bash
coreutils
filesystem
glibc
initscripts
plymouth (was for boot logs & encrypted partitions; could be dropped)
rootfiles
setup
systemd
util-linux
(plus implicit kernel)
Plus a bootloader, which may be implicit (and I guess isn't absolutely
required for at least some virtualization setups).
What makes rootfiles essential? That's just overriding the defaults
from /etc/skel with annoying aliases.
- Support basic networking
biosdevname (consistent naming policy)
initscripts
dhclient
hostname
iproute
iputils
NetworkManager
Is NM really required for "basic" networking? If so, you probably don't
need to specify some of the rest (such as dhclient) manually. NM brings
a bunch of deps I believe.
Also, I'd include ethtool, since you need it to configure NICs (although
it may be pulled in as a dep). IIRC it got dropped from a default
install for one release (and that was annoying for me anyway).
- Configure additional partitions for the simple case
e2fsprogs
parted
LVM? I know it is a can of worms, but it has been the default for a
long time now.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
4:15 p.m.
On Tue, Nov 13, 2012 at 04:07:16PM -0600, Chris Adams wrote:
What makes rootfiles essential? That's just overriding the
defaults
from /etc/skel with annoying aliases.
I think it should be at least "default" instead of mandatory.
Is NM really required for "basic" networking? If so, you
probably don't
need to specify some of the rest (such as dhclient) manually. NM brings
a bunch of deps I believe.
So far everything works without, and I think we should endevor to keep that
true.
Also, I'd include ethtool, since you need it to configure NICs
(although
it may be pulled in as a dep). IIRC it got dropped from a default
install for one release (and that was annoying for me anyway).
Seems like a possible candidate to have default but not mandatory in core.
Nothing pulls it in.
> - Configure additional partitions for the simple case
> e2fsprogs
> parted
LVM? I know it is a can of worms, but it has been the default for a
long time now.
Automatically added by anaconda when the system has LVM.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
4:20 p.m.
Matthew Miller (mattdm(a)fedoraproject.org) said:
On Tue, Nov 13, 2012 at 04:07:16PM -0600, Chris Adams wrote:
> What makes rootfiles essential? That's just overriding the defaults
> from /etc/skel with annoying aliases.
I think it should be at least "default" instead of mandatory.
Consistency of environment. Root's environment should always be
the same no matter how you install.
> Also, I'd include ethtool, since you need it to configure
NICs (although
> it may be pulled in as a dep). IIRC it got dropped from a default
> install for one release (and that was annoying for me anyway).
Seems like a possible candidate to have default but not mandatory in core.
Nothing pulls it in.
It's in standard, not core.
> > - Configure additional partitions for the simple case
> > e2fsprogs
> > parted
> LVM? I know it is a can of worms, but it has been the default for a
> long time now.
Automatically added by anaconda when the system has LVM.
If we want to rely on anaconda to add the filesystem tools for whatever
FS you install, we could drop e2fsprogs. But we'd still want parted.
(And I think leaving e2fsprogs in the minimal install likely makes sense
anyway.)
Bill
4:22 p.m.
On Tue, Nov 13, 2012 at 05:20:43PM -0500, Bill Nottingham wrote:
> On Tue, Nov 13, 2012 at 04:07:16PM -0600, Chris Adams wrote:
> > What makes rootfiles essential? That's just overriding the defaults
> > from /etc/skel with annoying aliases.
> I think it should be at least "default" instead of mandatory.
Consistency of environment. Root's environment should always be
the same no matter how you install.
I hear that, but if you're in a big environment and you want root's dotfiles
to be different, maybe you should be able to deselect the package?
> Automatically added by anaconda when the system has LVM.
If we want to rely on anaconda to add the filesystem tools for whatever
FS you install, we could drop e2fsprogs. But we'd still want parted.
(And I think leaving e2fsprogs in the minimal install likely makes sense
anyway.)
I think it needs to be there for fsck.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
4:40 p.m.
On 13 November 2012 15:22, Matthew Miller <mattdm(a)fedoraproject.org> wrote:
On Tue, Nov 13, 2012 at 05:20:43PM -0500, Bill Nottingham wrote:
> > On Tue, Nov 13, 2012 at 04:07:16PM -0600, Chris Adams wrote:
> > > What makes rootfiles essential? That's just overriding the defaults
> > > from /etc/skel with annoying aliases.
> > I think it should be at least "default" instead of mandatory.
> Consistency of environment. Root's environment should always be
> the same no matter how you install.
I hear that, but if you're in a big environment and you want root's dotfiles
to be different, maybe you should be able to deselect the package?
I think this seems to be a bike shed issue. If I want different stuff
I am going to be overlaying other stuff myself but if I don't have
some sort of defaults starting out.. I end up in various pain.
--
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
6:06 p.m.
On Tue, Nov 13, 2012 at 03:40:26PM -0700, Stephen John Smoogen wrote:
>> > > from /etc/skel with annoying aliases.
>> > I think it should be at least "default" instead of mandatory.
>> Consistency of environment. Root's environment should always be
>> the same no matter how you install.
> I hear that, but if you're in a big environment and you want root's
dotfiles
> to be different, maybe you should be able to deselect the package?
I think this seems to be a bike shed issue. If I want different stuff
I am going to be overlaying other stuff myself but if I don't have
some sort of defaults starting out.. I end up in various pain.
This package is _so_ tiny there's really no point in arguing about it either
way. It's basically the size of a rounding error.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
6:55 p.m.
On Tue, 2012-11-13 at 17:15 -0500, Matthew Miller wrote:
> Is NM really required for "basic" networking? If so,
you probably don't
> need to specify some of the rest (such as dhclient) manually. NM brings
> a bunch of deps I believe.
So far everything works without, and I think we should endevor to keep that
true.
I think this is similar to the firewalld issue in that the basic theory
here is that, look, NetworkManager is the way, the truth and the light:
it's supposed to be the One True Networking System, and we're just
keeping the network service around because there's some stuff it does
that NM doesn't do yet.
This logic is getting a tad stretched because we've been rolling with it
for several years at this point, but AIUI this is still the party line
and the reason NetworkManager is in core. In theory the idea is not that
we provide, actively maintain and support both NM and the network
service, but that we want to only provide, maintain and support NM, and
we're keeping the legacy 'network service' stuff around only until NM is
done.
It might be worth re-evaluating whether that's realistic any more,
though, and whether we're _really_ committed to finally replacing
network with NM in some kind of reasonable timeframe.
(It's also a possibility of course that I'm misunderstanding and that we
do intend to provide and support 'network' for the foreseeable future,
in which case I'd agree it should be in @core and NM should be only in
@standard).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
9:57 p.m.
Once upon a time, Adam Williamson <awilliam(a)redhat.com> said:
It might be worth re-evaluating whether that's realistic any
more,
though, and whether we're _really_ committed to finally replacing
network with NM in some kind of reasonable timeframe.
Until NM supports 802.1q, bridging, and tunnels, to name a few things
which AFAIK it does not yet, it isn't a suitable replacement. If/when
it gets to the point it can handle all the things the basic network
service/scripts can do, then having it in @core could be revisited.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
11:59 p.m.
On 11/13/2012 06:55 PM, Adam Williamson wrote:
It might be worth re-evaluating whether that's realistic any
more,
though, and whether we're _really_ committed to finally replacing
network with NM in some kind of reasonable timeframe.
To this point, NetworkManager has failed to gain basic bridge support.
In the meantime, Open vSwitch, which has a ton more configuration
options has been recently added to the distro.
I'd argue that NM actually continues to fall farther behind.
--
========================================================================
Ian Pilcher arequipeno(a)gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
========================================================================
6:27 p.m.
On Tue, Nov 13, 2012 at 9:59 PM, Ian Pilcher <arequipeno(a)gmail.com> wrote:
On 11/13/2012 06:55 PM, Adam Williamson wrote:
> It might be worth re-evaluating whether that's realistic any more,
> though, and whether we're _really_ committed to finally replacing
> network with NM in some kind of reasonable timeframe.
To this point, NetworkManager has failed to gain basic bridge support.
In the meantime, Open vSwitch, which has a ton more configuration
options has been recently added to the distro.
I'd argue that NM actually continues to fall farther behind.
Yeah, I love NetworkManager until it bites me - I've lost count of how
many times I've been in a coffee shop and had to use 'sudo nmcli con
del id' to get back online. ;-)
--
Twitter: http://twitter.com/znmeb; Computational Journalism Publishers
Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/
How the Hell can the lion sleep with all those people singing "A weem
oh way!" at the top of their lungs?
8:02 p.m.
On Wed, 2012-11-14 at 16:27 -0800, M. Edward (Ed) Borasky wrote:
On Tue, Nov 13, 2012 at 9:59 PM, Ian Pilcher
<arequipeno(a)gmail.com> wrote:
> On 11/13/2012 06:55 PM, Adam Williamson wrote:
>> It might be worth re-evaluating whether that's realistic any more,
>> though, and whether we're _really_ committed to finally replacing
>> network with NM in some kind of reasonable timeframe.
>
> To this point, NetworkManager has failed to gain basic bridge support.
> In the meantime, Open vSwitch, which has a ton more configuration
> options has been recently added to the distro.
>
> I'd argue that NM actually continues to fall farther behind.
Yeah, I love NetworkManager until it bites me - I've lost count of how
many times I've been in a coffee shop and had to use 'sudo nmcli con
del id' to get back online. ;-)
SCOPE CREEP ALARM! AWOOGA! AWOOGA!
Unless you actually think the network scripts are a better way of
managing casual wireless connections, I think this is a bit out of
scope, as we can already chalk up 'casual wireless connections' in the
'win' column for NetworkManager - it's already better than
network.service at that. it may not be *perfect*, but it's *better*.
The context here is not 'let's all get our NM pet peeves out of our
systems', but 'what does network.service still do better than NM, and
how long is it going to take to fix that?'
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
8:49 p.m.
On Wed, Nov 14, 2012 at 6:02 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Wed, 2012-11-14 at 16:27 -0800, M. Edward (Ed) Borasky wrote:
> On Tue, Nov 13, 2012 at 9:59 PM, Ian Pilcher <arequipeno(a)gmail.com> wrote:
> > On 11/13/2012 06:55 PM, Adam Williamson wrote:
> >> It might be worth re-evaluating whether that's realistic any more,
> >> though, and whether we're _really_ committed to finally replacing
> >> network with NM in some kind of reasonable timeframe.
> >
> > To this point, NetworkManager has failed to gain basic bridge support.
> > In the meantime, Open vSwitch, which has a ton more configuration
> > options has been recently added to the distro.
> >
> > I'd argue that NM actually continues to fall farther behind.
>
> Yeah, I love NetworkManager until it bites me - I've lost count of how
> many times I've been in a coffee shop and had to use 'sudo nmcli con
> del id' to get back online. ;-)
SCOPE CREEP ALARM! AWOOGA! AWOOGA!
Unless you actually think the network scripts are a better way of
managing casual wireless connections, I think this is a bit out of
scope, as we can already chalk up 'casual wireless connections' in the
'win' column for NetworkManager - it's already better than
network.service at that. it may not be *perfect*, but it's *better*.
The context here is not 'let's all get our NM pet peeves out of our
systems', but 'what does network.service still do better than NM, and
how long is it going to take to fix that?'
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
In the current context, a minimal Fedora, I'd argue that
NetworkManager is overkill too. An openSUSE / SUSE Studio JEOS or
server appliance defaults to some kind of DHCP client built on top of
whatever the base networking tools are in openSUSE. You have to
specifically *ask* for NetworkManager if you want it. I don't even
think the bridge tools are included at that minimalist level. You get
a firewall, yes, and DHCP too but ssh is optional - you probably have
to go in with 'vi' from the console and edit configuration files to
make networking happen beyond that.
While we're on the subject of minimalism, does yum default to
installing "suggested" packages on top of required ones?
--
Twitter: http://twitter.com/znmeb; Computational Journalism Publishers
Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/
How the Hell can the lion sleep with all those people singing "A weem
oh way!" at the top of their lungs?
12:02 a.m.
On Wed, 2012-11-14 at 18:49 -0800, M. Edward (Ed) Borasky wrote:
On Wed, Nov 14, 2012 at 6:02 PM, Adam Williamson
<awilliam(a)redhat.com> wrote:
> On Wed, 2012-11-14 at 16:27 -0800, M. Edward (Ed) Borasky wrote:
>> On Tue, Nov 13, 2012 at 9:59 PM, Ian Pilcher <arequipeno(a)gmail.com>
wrote:
>> > On 11/13/2012 06:55 PM, Adam Williamson wrote:
>> >> It might be worth re-evaluating whether that's realistic any more,
>> >> though, and whether we're _really_ committed to finally replacing
>> >> network with NM in some kind of reasonable timeframe.
In the current context, a minimal Fedora, I'd argue that
NetworkManager is overkill too.
We're going round in circles, here. The post of mine quoted above - five
levels of quotation deep, 11/13/2012 - was a reply to someone saying the
same thing. Please just read back to there, and break us out of this
eternal loop. :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
9:54 a.m.
On Tuesday, November 13, 2012 04:55:50 PM Adam Williamson wrote:
> So far everything works without, and I think we should endevor
to keep
> that true.
I think this is similar to the firewalld issue in that the basic theory
here is that, look, NetworkManager is the way, the truth and the light:
it's supposed to be the One True Networking System, and we're just
keeping the network service around because there's some stuff it does
that NM doesn't do yet.
This logic is getting a tad stretched because we've been rolling with it
for several years at this point, but AIUI this is still the party line
and the reason NetworkManager is in core. In theory the idea is not that
we provide, actively maintain and support both NM and the network
service, but that we want to only provide, maintain and support NM, and
we're keeping the legacy 'network service' stuff around only until NM is
done.
It might be worth re-evaluating whether that's realistic any more,
though, and whether we're really committed to finally replacing
network with NM in some kind of reasonable timeframe.
For Common Criteria purposes, everything running as root goes under the
microscope and its painful and costly. We have to avoid that. If NM did not
run as root and just retained whatever capability it needed, then we have an
easier time. Same thing with firewalld.
-Steve
7:38 p.m.
On Tue, Nov 13, 2012 at 08:00:23PM -0500, Ben Cotton wrote:
On Tue, Nov 13, 2012 at 4:41 PM, Bill Nottingham
<notting(a)redhat.com> wrote:
> [list of packages]
ntpdate
chrony
On EC2 (as in many virt environments) the hardware clock source is actually
synced and running an ntpd service on the client is redundant.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
7:55 p.m.
On Tue, Nov 13, 2012 at 8:38 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On EC2 (as in many virt environments) the hardware clock source is
actually
synced and running an ntpd service on the client is redundant.
(Neat, I learned something today!) Sure, but there are a lot of Fedora
instances not running on such environments. We could come up with
plenty of use cases to exclude packages already mentioned in this
thread, but that doesn't mean they shouldn't be included.
--
Ben Cotton
Fedora Docs Leader
8:02 p.m.
On Tue, Nov 13, 2012 at 08:55:46PM -0500, Ben Cotton wrote:
> On EC2 (as in many virt environments) the hardware clock source
is
> actually synced and running an ntpd service on the client is redundant.
(Neat, I learned something today!) Sure, but there are a lot of Fedora
instances not running on such environments. We could come up with
plenty of use cases to exclude packages already mentioned in this
thread, but that doesn't mean they shouldn't be included.
Yep, but cloud/virt is a major use case for the minimal install, so we
certainly shouldn't make them mandatory there. I think time sync should be
in @standard, though, and it is.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
8:57 p.m.
On 13 November 2012 18:38, Matthew Miller <mattdm(a)fedoraproject.org> wrote:
On Tue, Nov 13, 2012 at 08:00:23PM -0500, Ben Cotton wrote:
> On Tue, Nov 13, 2012 at 4:41 PM, Bill Nottingham <notting(a)redhat.com> wrote:
> > [list of packages]
> ntpdate
> chrony
On EC2 (as in many virt environments) the hardware clock source is actually
synced and running an ntpd service on the client is redundant.
<bikeshed=blue>
They say it is .... but it is not always. I have had multiple cases
in KVM and some in Xen where supposedly the clock is kept up but what
you end up is actually watching time go backwards if you hit heavy
load in IO or CPU or Mem. Of course if you run into hardware like
that.. you can install it after your DB has gone poopsies.
</bikeshed>
--
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
9:22 a.m.
From: Stephen John Smoogen <smooge(a)gmail.com>
> On Tue, Nov 13, 2012 at 08:00:23PM -0500, Ben Cotton wrote:
> On EC2 (as in many virt environments) the hardware clock source is
actually
> synced and running an ntpd service on the client is redundant.
>
<bikeshed=blue>
They say it is .... but it is not always. I have had multiple cases
in KVM and some in Xen where supposedly the clock is kept up but what
you end up is actually watching time go backwards if you hit heavy
load in IO or CPU or Mem. Of course if you run into hardware like
that.. you can install it after your DB has gone poopsies.
</bikeshed>
I've seen that happen as well. I found this by hitting the pause button
on the guest IIRC. I just always use NTP to avoid the worry, but I agree
NTP (whether ntpd or chronyd) belongs in @standard not @core.
--
John Florian
6:33 p.m.
Time synchronization inside virtual machines is
a. Hypervisor-dependent. See the docs for VirtualBox, VMware, Xen and
kvm and read the fine print. I don't even know if there *is*
documentation for EC2.
b. Poorly documented and difficult to test. If you don't *need*
anything better than NTP / one second synchronization, don't waste
your time.
c. A mine field if you *do* need something better.
Stay safe out there. ;-)
On Wed, Nov 14, 2012 at 7:22 AM, <John.Florian(a)dart.biz> wrote:
> From: Stephen John Smoogen <smooge(a)gmail.com>
> > On Tue, Nov 13, 2012 at 08:00:23PM -0500, Ben Cotton wrote:
> > On EC2 (as in many virt environments) the hardware clock source is
> > actually
> > synced and running an ntpd service on the client is redundant.
> >
>
> <bikeshed=blue>
> They say it is .... but it is not always. I have had multiple cases
> in KVM and some in Xen where supposedly the clock is kept up but what
> you end up is actually watching time go backwards if you hit heavy
> load in IO or CPU or Mem. Of course if you run into hardware like
> that.. you can install it after your DB has gone poopsies.
> </bikeshed>
I've seen that happen as well. I found this by hitting the pause button on
the guest IIRC. I just always use NTP to avoid the worry, but I agree NTP
(whether ntpd or chronyd) belongs in @standard not @core.
--
John Florian
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Twitter: http://twitter.com/znmeb; Computational Journalism Publishers
Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/
How the Hell can the lion sleep with all those people singing "A weem
oh way!" at the top of their lungs?
11:37 p.m.
On Tue, 13 Nov 2012, Matthew Miller wrote:
On Tue, Nov 13, 2012 at 08:00:23PM -0500, Ben Cotton wrote:
> On Tue, Nov 13, 2012 at 4:41 PM, Bill Nottingham <notting(a)redhat.com> wrote:
>> [list of packages]
> ntpdate
> chrony
On EC2 (as in many virt environments) the hardware clock source is actually
synced and running an ntpd service on the client is redundant.
I would say this is not accurate.
My experience with the instances running under xen is that that is true.
My experience with the instances running in euca under kvm is that that is
not true.
-sv
6:45 a.m.
On Wed, Nov 14, 2012 at 12:37:38AM -0500, Seth Vidal wrote:
>On EC2 (as in many virt environments) the hardware clock source
is actually
>synced and running an ntpd service on the client is redundant.
I would say this is not accurate.
My experience with the instances running under xen is that that is true.
My experience with the instances running in euca under kvm is that
that is not true.
I didn't mean to imply that it's true everywhere. It's just true enough
places that we shouldn't make it mandatory.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
10:01 p.m.
Once upon a time, Ben Cotton <bcotton(a)fedoraproject.org> said:
ntpdate
chrony
Daemons should only be added to @core if they are critical for basic
system function; NTP is recommended for most setups, but certainly not
critical.
It would be nice to have ntpdate and/or rdate though, so that the system
clock can be initialized from the network. Trying to set it accurately
by hand can be annoying, and an accurate clock is required for some
network authentication methods like Kerberos.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
11:29 p.m.
I can tell you what openSUSE / SUSE Studio does. The smallest
appliance you can build is JEOS (Just Enough Operating System). That
has kernel, grub, openssh, bash, small vim and zypper, which is the
openSUSE equivalent of yum. It does not have man pages; they're
stripped out.
Next up is something called 'server'. The main thing you get beyond
JEOS is a bigger system administration tool called YaST, which has a
curses interface for things like the firewall. I think the man pages
show up in 'server'.
Neither JEOS nor server have 'ntp' or 'sudo' - you have to add those.
You also have to add command-line conveniences like command-not-found,
findutils-locate and bash-completion.
Next up is "Minimal X". This is a stripped IceWM desktop that's
actually quite nice if you want X Windows.
Personally I don't think anything smaller than JEOS is useful and I
don't think it's necessary. It's only about 174 MB as an ISO
On Tue, Nov 13, 2012 at 8:01 PM, Chris Adams <cmadams(a)hiwaay.net> wrote:
Once upon a time, Ben Cotton <bcotton(a)fedoraproject.org> said:
> ntpdate
> chrony
Daemons should only be added to @core if they are critical for basic
system function; NTP is recommended for most setups, but certainly not
critical.
It would be nice to have ntpdate and/or rdate though, so that the system
clock can be initialized from the network. Trying to set it accurately
by hand can be annoying, and an accurate clock is required for some
network authentication methods like Kerberos.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Twitter: http://twitter.com/znmeb; Computational Journalism Publishers
Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/
How the Hell can the lion sleep with all those people singing "A weem
oh way!" at the top of their lungs?
6:27 a.m.
2012/11/13 Bill Nottingham <notting(a)redhat.com>
[...]
- Minimal tools for admins
less
man-db
procps-ng
vim-minimal
Is man-db really necessary? In the man pages included in the man-db package
are not really helpful for a core system ... from my point of view.
[...]
- Get mail off the box (and define a default for doing so)
sendmail
Does an MTA really make sense in the core definition? The configuration of
MTA is nowadays much more complex compared to the "old" days. Normaly you
need a FQDN, you need a SMTP relay and lot other stuff more. So you will
only get the mails off the system after a lot of configuration work which
can, from my point of view, also include the installation of an MTA.
Regards, Thomas
--
Linux ... enjoy the ride!
6:49 a.m.
On Wed, Nov 14, 2012 at 01:27:21PM +0100, Thomas Bendler wrote:
- Minimal tools for admins
> less
> man-db
> procps-ng
> vim-minimal
Is man-db really necessary? In the man pages included in the man-db package
are not really helpful for a core system ... from my point of view.
I'd like to go back a step here to the question starting the thread. There's
plenty of time to go over each package, but the basic question is intent.
Clearly man pages aren't necessary for a super-minimal JEOS image, but
that's not *historically* been the intent of @core, and based on the
discussion so far I think it will continue to not be.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
8:24 a.m.
2012/11/14 Matthew Miller <mattdm(a)fedoraproject.org>
[...]
I'd like to go back a step here to the question starting the thread.
There's
plenty of time to go over each package, but the basic question is intent.
Clearly man pages aren't necessary for a super-minimal JEOS image, but
that's not *historically* been the intent of @core, and based on the
discussion so far I think it will continue to not be.
[...]
Ok, but what is the intent? The first mail was a questioning what should be
the scope of core and I didn't see a discussion answering this question. I
think we should first define the mission statement and then discuss the
technical details. Or is it only unclear to me what the intent is?
Regards, Thomas
--
Linux ... enjoy the ride!
8:36 a.m.
On Wed, Nov 14, 2012 at 03:24:04PM +0100, Thomas Bendler wrote:
Ok, but what is the intent? The first mail was a questioning what
should be
the scope of core and I didn't see a discussion answering this question. I
That's *this* discussion. :)
think we should first define the mission statement and then discuss
the
technical details. Or is it only unclear to me what the intent is?
I kind of skipped past the mission statement because no one commented on the
draft one I made, which is:
The Fedora Minimal Core SIG ensures that the Fedora minimal package set is
an intentionally curated selection rather than an ad hoc accretion of
packages.
to the first of the stated goals, which is: "Choose a working definition for
"minimal" (kernel + systemd only vs enough to get to yum install over the
net vs basic traditional unix system)".
Based on the conversation so far, I think the target is:
- mandatory install of everything up to yum install from the network
- default install of a small set of packages necessary for a consistent
Fedora experience including minimal admin tools
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
8:55 a.m.
2012/11/14 Matthew Miller <mattdm(a)fedoraproject.org>
default install of a small set of packages necessary for a
consistent
Fedora experience including minimal admin tools
I was just surprised that there was no discussion about your proposal,
instead, there was immediately a discussion about the packages that should
be in core. So should this definition be the one that we are working on?
From my point of view, core should only contain kernel, network,
ssh-server
plus yum to be ready for installation (locally and remotely). But if the
rest of the group say, no, we need more (i.e. minimal admin tools), fine
with me. But then we have something that we agreed on and that can be
documented as the core base.
Regards, Thomas
--
Linux ... enjoy the ride!
9:23 p.m.
On Wed, Nov 14, 2012 at 09:36:17AM -0500, Matthew Miller wrote:
Based on the conversation so far, I think the target is:
- mandatory install of everything up to yum install from the network
- default install of a small set of packages necessary for a consistent
Fedora experience including minimal admin tools
Is there any reason those two can't be split up? Maybe @really-hard-core
for the first, and @core for the second. ;-)
Alternatively, I could see where the first is marked "required", but
the second is marked "default" so it can be deselected in a kickstart
config without needing to rpm -e it in %post.
--
Scott Schmit
12:03 a.m.
On Wed, 2012-11-14 at 22:23 -0500, Scott Schmit wrote:
On Wed, Nov 14, 2012 at 09:36:17AM -0500, Matthew Miller wrote:
> Based on the conversation so far, I think the target is:
>
> - mandatory install of everything up to yum install from the network
> - default install of a small set of packages necessary for a consistent
> Fedora experience including minimal admin tools
Is there any reason those two can't be split up? Maybe @really-hard-core
for the first, and @core for the second. ;-)
That's basically what Kevin proposed several mails back, and I agree it
seems like we have two broadly definable cases here rather than one.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
9:28 a.m.
On Wed, Nov 14, 2012 at 10:03:36PM -0800, Adam Williamson wrote:
> Is there any reason those two can't be split up? Maybe
@really-hard-core
> for the first, and @core for the second. ;-)
That's basically what Kevin proposed several mails back, and I agree it
seems like we have two broadly definable cases here rather than one.
I think Bill Nottingham mentioned something similar too, although I don't
want to put words into his mouth.
I'm open to the possibility, but I think using "default" instead of
mandatory for many packages in @core covers this distinction relatively
well. Then we have @standard for the next level.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
3:10 p.m.
Matthew Miller (mattdm(a)fedoraproject.org) said:
On Wed, Nov 14, 2012 at 10:03:36PM -0800, Adam Williamson wrote:
> > Is there any reason those two can't be split up? Maybe @really-hard-core
> > for the first, and @core for the second. ;-)
> That's basically what Kevin proposed several mails back, and I agree it
> seems like we have two broadly definable cases here rather than one.
I think Bill Nottingham mentioned something similar too, although I don't
want to put words into his mouth.
What I had suggested at one point was we have an 'image-base' group that
is *really* tiny, that is intended to be used as a basis for creating
images, chroot, and other things where you're not necessarily doing package
management *on the running system*.
So it would be:
kernel
systemd
initscripts
util-linux
bash
and their dependencies.
Bill
8:18 a.m.
Once upon a time, Thomas Bendler <ml(a)bendler-net.de> said:
Does an MTA really make sense in the core definition? The
configuration of
MTA is nowadays much more complex compared to the "old" days. Normaly you
need a FQDN, you need a SMTP relay and lot other stuff more. So you will
only get the mails off the system after a lot of configuration work which
can, from my point of view, also include the installation of an MTA.
Well, as soon as you have cron, you'll have things wanting to send
email, and even sendmail mail to "root" on the local system requires
some type of MTA in most cases.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:32 a.m.
2012/11/14 Chris Adams <cmadams(a)hiwaay.net>
[...]
Well, as soon as you have cron, you'll have things wanting to send
email, and even sendmail mail to "root" on the local system
requires
some type of MTA in most cases.
True, but then you need a mail client as well otherwise you won't see the
local mails. So the question is, what is the definition of core? What
should be the goal of core?
Regards, Thomas
--
Linux ... enjoy the ride!
9:13 a.m.
Once upon a time, Thomas Bendler <ml(a)bendler-net.de> said:
True, but then you need a mail client as well otherwise you won't
see the
local mails. So the question is, what is the definition of core? What
should be the goal of core?
Ehh, for local "root" mails from failing cron jobs, "less
/var/mail/root" works just fine. :)
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
9:35 a.m.
2012/11/14 Chris Adams <cmadams(a)hiwaay.net>
[...]
Ehh, for local "root" mails from failing cron jobs, "less
/var/mail/root" works just fine. :)
Sending mails with telnet also works fine but I don't think that this is
the question ;). We work on the definition of core and what will be inside.
If we say, mail must be inside we should also install a client to access
the mail. That's why I wrote, we should define what core is first (and
document it) and then talk about the packages which should be in core.
Regards, Thomas
--
Linux ... enjoy the ride!
9:34 a.m.
From: Chris Adams <cmadams(a)hiwaay.net>
Well, as soon as you have cron, you'll have things wanting to send
email, and even sendmail mail to "root" on the local system requires
some type of MTA in most cases.
From my experience, an MTA is still not required. Any stdout/err from
the
cron jobs just go to the syslog, but this may be systemd's journal magic
that I've been seeing.
--
John Florian
6:10 p.m.
On Wed, 14.11.12 10:34, John.Florian(a)dart.biz (John.Florian(a)dart.biz) wrote:
> From: Chris Adams <cmadams(a)hiwaay.net>
>
> Well, as soon as you have cron, you'll have things wanting to send
> email, and even sendmail mail to "root" on the local system requires
> some type of MTA in most cases.
>From my experience, an MTA is still not required. Any stdout/err from the
cron jobs just go to the syslog, but this may be systemd's journal magic
that I've been seeing.
cronie is actually able to log the cron output to syslog since a long
time. I haven't been running MTAs on any of my machines for a many years
now.
If you deinstall the MTA then cronie will log a error message that
sendmail wasn't around, and then go on and log job output to
syslog. This error message is really pointless and should go away.
Honestly, we really should drop sendmail from the default install of
*all* systems, not just the minimal installations. It is simply not
useful without configuration, and nothing else we install requires it,
not even cronie.
Lennart
--
Lennart Poettering - Red Hat, Inc.
6:05 p.m.
On Wed, 14.11.12 08:18, Chris Adams (cmadams(a)hiwaay.net) wrote:
Once upon a time, Thomas Bendler <ml(a)bendler-net.de> said:
> Does an MTA really make sense in the core definition? The configuration of
> MTA is nowadays much more complex compared to the "old" days. Normaly you
> need a FQDN, you need a SMTP relay and lot other stuff more. So you will
> only get the mails off the system after a lot of configuration work which
> can, from my point of view, also include the installation of an MTA.
Well, as soon as you have cron, you'll have things wanting to send
email, and even sendmail mail to "root" on the local system requires
some type of MTA in most cases.
I am pretty sure the default should be to push everything to the
logs.
But note that in the container case you are likely to encounter a setup
where you install the host host, and then add one container for mail,
another one for web, a third one for database, and so on. If you do that
it would be really bogus to include sendmail in the minimal set...
Lennart
--
Lennart Poettering - Red Hat, Inc.
2:33 p.m.
Seth Vidal <skvidal(a)fedoraproject.org> writes:
fantastic. show me a deployment somewhere of a 'thin client'
that
doesn't use their own custom kickstart/pxe for instantiating the
clients and that will be relevant to this discussion.
Is kickstart installs generally out of scope for minimal package set?
The problem used to be that even with kickstart, you ended up with a
too-large package set which you then had to rpm -e at the end. Awkward.
This has gotten much better, of course.
Personally I was hoping that the minimal project would end up making it
possible, using kickstart, to install enough to get yum running. Ideally
the size of that minimal install would be rather small. The users can
always add more... If people want an actual functional system out of the
box, it seems that they would be better off with one of the other
installation choices.
But anyway, if it is possible to prevent the installation of openssh-*
in the kickstart file, that is ok with me. rpm -e afterwards, not so
much.
/Benny
2:39 p.m.
On Mon, 12 Nov 2012, Benny Amorsen wrote:
Seth Vidal <skvidal(a)fedoraproject.org> writes:
> fantastic. show me a deployment somewhere of a 'thin client' that
> doesn't use their own custom kickstart/pxe for instantiating the
> clients and that will be relevant to this discussion.
Is kickstart installs generally out of scope for minimal package set?
The problem used to be that even with kickstart, you ended up with a
too-large package set which you then had to rpm -e at the end. Awkward.
This has gotten much better, of course.
Personally I was hoping that the minimal project would end up making it
possible, using kickstart, to install enough to get yum running. Ideally
the size of that minimal install would be rather small. The users can
always add more... If people want an actual functional system out of the
box, it seems that they would be better off with one of the other
installation choices.
But anyway, if it is possible to prevent the installation of openssh-*
in the kickstart file, that is ok with me. rpm -e afterwards, not so
much.
why is rpm -e in %post in the kickstart not okay?
the system isn't 'up'. what harm is it in cleaning up crap? If you're
doing enough installs that the bandwidth is an issue in installing these
additional packages then you should make a local mirror, I'd think.
-sv
8:18 a.m.
2012/11/12 Matthew Miller <mattdm(a)fedoraproject.org>
[...]
Yeah: if we get to the point where every real install has to add the same
subset of packages to core, I don't think we've succeeded in doing anything
except make more work for the whole world.
A cron daemon and (at least basic) MTA fall in the same area, I think.
But what about ssh-clients?
Is there a reasonable yardstick rule we can make, or is it pragmatically
best to just make per-package decisions?
Depends on the scope. I think that the B definition plus ssh-server goes
into the right direction. The minimal system should have networking in
place and ssh ready to interact with the fresh installation. More stuff is
not necessary. If you need more, invoke yum and install whatever you need
(so yum should also be in the core definition). Things like cron, MTA and
other stuff should from my point of view not be in the core installation,
this is more something like core plus lsb.
Regards Thomas
--
Linux ... enjoy the ride!
10:09 a.m.
New subject: A minimal subset of python (was Re: [@core] working definition for the minimal package set)
On Mon, 2012-11-12 at 11:28 -0500, Matthew Miller wrote:
Okay, cool -- there's a lot of enthusiasm for a SIG for the core
package
set.
So, first up on the SIG goals: clarifying our target.
It's been suggested before that there's so many possibilities that this is
useless, but the point here is to *pick* a reasonable choice as a group and
to work with that (even if we can't get complete consensus). Then, later,
when someone says "but minimal could mean so many differen things!" we
simply say "sure, but *this* is what we mean".
I see three basic options for the target:
A) kernel + init system and we're done
B) "boot to yum (with network)": a text-mode bootstrap environment on which
other things can be added by hand (or by kickstart)
C) a traditional Unix command line environment with the expected basic
tools available
To me, 'C' is too wide for two reasons. First, it's too open for continual
debate, because different people might expect different tools. Second, it's
not necessarily the right base for the rest of the distribution, because
many use cases might not really need that traditional Unix environment.
I think 'A' is interesting and useful, but I don't think it should be our
target, because it's not *useful enough*. We may want to eventually define a
sub-group which covers just this tiny base (maybe with busybox?), but I
think that's a different project.
So that leaves me at *mostly B*, although I have some sympathy to the idea
that we should include a few other things like a man page reader, since
we're installing man pages, and a way to deliver e-mail to root, since we're
installing things that send such mail. And I think the core environment
should include ssh, but I'm open to the idea that even that should be an
add-on.
If we're targeting "yum" as core functionality, that implies a subset of
Python: enough to run yum at least, but probably not much more.
This ties into https://bugzilla.redhat.com/show_bug.cgi?id=867962 which
I'd prefer to solve by introducing a "python-core" package. I've heard
complaints from upstream that no-one can know what the "python" package
means on any given distribution (everyone splits it out in slightly
different ways). Fixing that suggests that the "python" package should
become a metapackage that brings in everything built from the python
tarball.
If we go down this route, say in Fedora 19, then let's introduce a
"python-core" or somesuch, and define it loosely to be "whatever yum
needs in the minimal environment".
Does this sound sane? (especially from the POV of yum developers) What
does yum need?
Dave
11:26 a.m.
New subject: A minimal subset of python (was Re: [@core] working definition for the minimal package set)
Did a quick scan and removed internals
random : ['import random : (cli.py)']
subprocess : ['from subprocess import Popen, PIPE :
(yum/packages.py)']
gettext : ['import gettext : (output.py)']
fnmatch : ['import fnmatch : (completion-helper.py)']
tempfile : ['import tempfile : (yum/misc.py)']
base64 : ['import base64 : (yum/misc.py)']
imp : ['import imp : (yum/plugins.py)']
logging.config : ['import logging.config : (yum/__init__.py)']
string : ['import string : (yum/__init__.py)']
textwrap : ['from textwrap import fill : (yum/plugins.py)']
urlgrabber.grabber : ['from urlgrabber.grabber import URLGrabError :
(output.py)']
iniparse.compat : ['from iniparse.compat import NoSectionError,
NoOptionError, ParsingError : (yum/config.py)']
ConfigParser : ['from ConfigParser import ConfigParser,
ParsingError : (yum-updatesd.py)']
cmd : ['import cmd : (shell.py)']
uuid : ['from uuid import uuid4 : (yum/misc.py)']
logging.handlers : ['import logging.handlers : (yum/logginglevels.py)']
threading : ['import threading : (yum-updatesd.py)']
shlex : ['import shlex : (completion-helper.py)']
signal : ['import signal : (cli.py)']
cStringIO : ['from cStringIO import StringIO :
(yum/mdparser.py)']
locale : ['import locale : (output.py)']
xml.sax.saxutils : ['import xml.sax.saxutils : (yum/misc.py)']
lzma : ['import lzma : (yum/misc.py)']
sha : ['import sha : (yum/misc.py)']
urllib : ['import urllib : (yum/misc.py)']
re : ['import re # For YumTerm : (output.py)']
gpgme : ['import gpgme : (yum/misc.py)']
fcntl : ['import fcntl : (yum/rpmtrans.py)']
optparse : ['from optparse import OptionParser :
(yum-updatesd.py)']
xml.etree : ['from xml.etree import cElementTree :
(yum/mdparser.py)']
struct : ['import struct : (yum/packages.py)']
logging : ['import logging : (output.py)']
socket : ['import socket : (yum/logginglevels.py)']
weakref : ['from weakref import proxy as weakref :
(output.py)']
sqlitecachec : ['import sqlitecachec : (yum/yumRepo.py)']
os : ['import os : (yum-updatesd.py)']
pdb : ['import pdb : (yummain.py)']
struct, time, cStringIO, base64, types
curses : ['import curses : (output.py)']
__builtin__ : ['import __builtin__ : (shell.py)']
operator : ['import operator : (yumcommands.py)']
rpm : ['import rpm : (output.py)']
errno : ['import errno : (yummain.py)']
binascii : ['import binascii : (yum/misc.py)']
types : ['import types : (output.py)']
md5 : ['import md5 : (yum/misc.py)']
pwd : ['import pwd : (output.py)']
gpgme.editutil : ['import gpgme.editutil : (yum/misc.py)']
copy : ['import copy : (yum/config.py)']
hashlib : ['import hashlib : (yum/misc.py)']
atexit : ['import atexit : (yum/plugins.py)']
StringIO : ['import StringIO : (yum/__init__.py)']
exceptions : ['import exceptions : (utils.py)']
sqlutils : ['from sqlutils import sqlite, executeSQL, sql_esc :
(yum/pkgtag_db.py)']
urlgrabber : ['import urlgrabber : (yum/__init__.py)']
sqlite : ['import sqlite : (yum/sqlutils.py)']
urlgrabber.progress : ['from urlgrabber.progress import TextMeter,
TextMultiFileMeter : (output.py)']
shutil : ['import shutil : (yum/misc.py)']
xattr : ['import xattr : (yum/packages.py)']
bz2 : ['import bz2 : (yum/misc.py)']
grp : ['import grp : (yum/packages.py)']
sqlite3 : ['import sqlite3 as sqlite : (yum/sqlutils.py)']
stat : ['import stat : (yum/packages.py)']
warnings : ['import warnings : (yum/config.py)']
glob
urlgrabber.mirror : ['import urlgrabber.mirror : (yum/yumRepo.py)']
iniparse : ['from iniparse import INIConfig : (yum/config.py)']
sys : ['import sys : (yum-updatesd.py)']
cElementTree : ['import cElementTree : (yum/mdparser.py)']
os.path : ['import os.path : (yummain.py)']
urlparse : ['import urlparse : (yum/config.py)']
Tim
On Tue, Nov 13, 2012 at 5:09 PM, David Malcolm <dmalcolm(a)redhat.com> wrote:
On Mon, 2012-11-12 at 11:28 -0500, Matthew Miller wrote:
> Okay, cool -- there's a lot of enthusiasm for a SIG for the core package
> set.
>
> So, first up on the SIG goals: clarifying our target.
>
> It's been suggested before that there's so many possibilities that this
is
> useless, but the point here is to *pick* a reasonable choice as a group
and
> to work with that (even if we can't get complete consensus). Then, later,
> when someone says "but minimal could mean so many differen things!" we
> simply say "sure, but *this* is what we mean".
>
> I see three basic options for the target:
>
> A) kernel + init system and we're done
> B) "boot to yum (with network)": a text-mode bootstrap environment on
which
> other things can be added by hand (or by kickstart)
> C) a traditional Unix command line environment with the expected basic
> tools available
>
> To me, 'C' is too wide for two reasons. First, it's too open for
continual
> debate, because different people might expect different tools. Second,
it's
> not necessarily the right base for the rest of the distribution, because
> many use cases might not really need that traditional Unix environment.
>
> I think 'A' is interesting and useful, but I don't think it should be
our
> target, because it's not *useful enough*. We may want to eventually
define a
> sub-group which covers just this tiny base (maybe with busybox?), but I
> think that's a different project.
>
> So that leaves me at *mostly B*, although I have some sympathy to the
idea
> that we should include a few other things like a man page reader, since
> we're installing man pages, and a way to deliver e-mail to root, since
we're
> installing things that send such mail. And I think the core environment
> should include ssh, but I'm open to the idea that even that should be an
> add-on.
If we're targeting "yum" as core functionality, that implies a subset of
Python: enough to run yum at least, but probably not much more.
This ties into https://bugzilla.redhat.com/show_bug.cgi?id=867962 which
I'd prefer to solve by introducing a "python-core" package. I've
heard
complaints from upstream that no-one can know what the "python" package
means on any given distribution (everyone splits it out in slightly
different ways). Fixing that suggests that the "python" package should
become a metapackage that brings in everything built from the python
tarball.
If we go down this route, say in Fedora 19, then let's introduce a
"python-core" or somesuch, and define it loosely to be "whatever yum
needs in the minimal environment".
Does this sound sane? (especially from the POV of yum developers) What
does yum need?
Dave
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
5:56 p.m.
On Mon, 12.11.12 11:28, Matthew Miller (mattdm(a)fedoraproject.org) wrote:
Okay, cool -- there's a lot of enthusiasm for a SIG for the core
package
set.
So, first up on the SIG goals: clarifying our target.
It's been suggested before that there's so many possibilities that this is
useless, but the point here is to *pick* a reasonable choice as a group and
to work with that (even if we can't get complete consensus). Then, later,
when someone says "but minimal could mean so many differen things!" we
simply say "sure, but *this* is what we mean".
I see three basic options for the target:
A) kernel + init system and we're done
B) "boot to yum (with network)": a text-mode bootstrap environment on which
other things can be added by hand (or by kickstart)
C) a traditional Unix command line environment with the expected basic
tools available
To me, 'C' is too wide for two reasons. First, it's too open for continual
debate, because different people might expect different tools. Second, it's
not necessarily the right base for the rest of the distribution, because
many use cases might not really need that traditional Unix environment.
I think 'A' is interesting and useful, but I don't think it should be our
target, because it's not *useful enough*. We may want to eventually define a
sub-group which covers just this tiny base (maybe with busybox?), but I
think that's a different project.
So that leaves me at *mostly B*, although I have some sympathy to the idea
that we should include a few other things like a man page reader, since
we're installing man pages, and a way to deliver e-mail to root, since we're
installing things that send such mail. And I think the core environment
should include ssh, but I'm open to the idea that even that should be an
add-on.
What do you think?
I think a good way to approach this is by looking for the interesting
usecases for a minimal installation:
A) Containers
B) VMs
C) Bare-Metal Servers
D) Paranoid people (not relevant)
E) Embedded (out of focus for Fedora)
... anything else?
I list A and B as separate items, since they have different needs. For
A you don't want SSH or bootloader (the bootloader is not necessary, as
the container manager will directly invoke init, and you can login via
local console). For B you you need a bootloader and probably SSH.
I think it would make sense to focus on the intersection of installation
set for these usecases. And hence:
No SSH. No Boot loader. And definitely not Sendmail.
Lennart
--
Lennart Poettering - Red Hat, Inc.
6:03 p.m.
On Thu, 15.11.12 00:56, Lennart Poettering (mzerqung(a)0pointer.de) wrote:
I think a good way to approach this is by looking for the
interesting
usecases for a minimal installation:
A) Containers
B) VMs
C) Bare-Metal Servers
D) Paranoid people (not relevant)
E) Embedded (out of focus for Fedora)
... anything else?
I list A and B as separate items, since they have different needs. For
A you don't want SSH or bootloader (the bootloader is not necessary, as
the container manager will directly invoke init, and you can login via
local console). For B you you need a bootloader and probably SSH.
I think it would make sense to focus on the intersection of installation
set for these usecases. And hence:
No SSH. No Boot loader. And definitely not Sendmail.
Also, no kernel and no kmod for A, as that is provided by the container
host.
Lennart
--
Lennart Poettering - Red Hat, Inc.
6:05 p.m.
On Thu, 15 Nov 2012 01:03:03 +0100
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
...snip...
>
> I think it would make sense to focus on the intersection of
> installation set for these usecases. And hence:
>
> No SSH. No Boot loader. And definitely not Sendmail.
Also, no kernel and no kmod for A, as that is provided by the
container host.
That doesn't look like an intersection to me. ;)
How about a separate group for containers, since the packages and use
case are very different than 'core' provides?
@core-container ? or @container ?
kevin
6:13 p.m.
On Wed, 14.11.12 17:05, Kevin Fenzi (kevin(a)scrye.com) wrote:
On Thu, 15 Nov 2012 01:03:03 +0100
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
...snip...
> >
> > I think it would make sense to focus on the intersection of
> > installation set for these usecases. And hence:
> >
> > No SSH. No Boot loader. And definitely not Sendmail.
>
> Also, no kernel and no kmod for A, as that is provided by the
> container host.
That doesn't look like an intersection to me. ;)
Well, if you look at all the usecases it happens that the container
usecase ends up being the most minimal, and hence the intersection of
all of them.
How about a separate group for containers, since the packages and
use
case are very different than 'core' provides?
@core-container ? or @container ?
Well, it would be weird that the "minimal" installation is actually not
"minimal" at all, but the "container" installation is.
Lennart
--
Lennart Poettering - Red Hat, Inc.
6:15 p.m.
On 14 November 2012 17:13, Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Wed, 14.11.12 17:05, Kevin Fenzi (kevin(a)scrye.com) wrote:
> On Thu, 15 Nov 2012 01:03:03 +0100
> Lennart Poettering <mzerqung(a)0pointer.de> wrote:
>
> ...snip...
>
> > >
> > > I think it would make sense to focus on the intersection of
> > > installation set for these usecases. And hence:
> > >
> > > No SSH. No Boot loader. And definitely not Sendmail.
> >
> > Also, no kernel and no kmod for A, as that is provided by the
> > container host.
>
> That doesn't look like an intersection to me. ;)
Well, if you look at all the usecases it happens that the container
usecase ends up being the most minimal, and hence the intersection of
all of them.
> How about a separate group for containers, since the packages and use
> case are very different than 'core' provides?
>
> @core-container ? or @container ?
Well, it would be weird that the "minimal" installation is actually not
"minimal" at all, but the "container" installation is.
I didn't think one installed an OS inside a container.. but basically
copied what one wanted into it... eg running anaconda to build a
container means you already went too far :).
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
6:19 p.m.
On Wed, 14.11.12 17:15, Stephen John Smoogen (smooge(a)gmail.com) wrote:
>> How about a separate group for containers, since the
packages and use
>> case are very different than 'core' provides?
>>
>> @core-container ? or @container ?
>
> Well, it would be weird that the "minimal" installation is actually not
> "minimal" at all, but the "container" installation is.
I didn't think one installed an OS inside a container.. but basically
copied what one wanted into it... eg running anaconda to build a
container means you already went too far :).
Oh, I wasn't aware that this is solely about anaconda-based installs,
sorry.
For containers a yum group for usage with --installroot= is the only
thing that matters.
Lennart
--
Lennart Poettering - Red Hat, Inc.
6:23 p.m.
On 14 November 2012 17:19, Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Wed, 14.11.12 17:15, Stephen John Smoogen (smooge(a)gmail.com)
wrote:
> >> How about a separate group for containers, since the packages and use
> >> case are very different than 'core' provides?
> >>
> >> @core-container ? or @container ?
> >
> > Well, it would be weird that the "minimal" installation is actually
not
> > "minimal" at all, but the "container" installation is.
>
> I didn't think one installed an OS inside a container.. but basically
> copied what one wanted into it... eg running anaconda to build a
> container means you already went too far :).
Oh, I wasn't aware that this is solely about anaconda-based installs,
sorry.
Well actually I think the correct question here is.. is this about
anaconda based installs which was my guess when reading through this.
However it is an assumption.. which means I am probably as much an ass
as an umption in it.
For containers a yum group for usage with --installroot= is the only
thing that matters.
Where I think the core-container would go to define that. But again..
my assumptions may be as wrong as anything.
--
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
7:39 a.m.
From: Stephen John Smoogen <smooge(a)gmail.com>
On 14 November 2012 17:19, Lennart Poettering <mzerqung(a)0pointer.de>
wrote:
>
> Oh, I wasn't aware that this is solely about anaconda-based installs,
> sorry.
Well actually I think the correct question here is.. is this about
anaconda based installs which was my guess when reading through this.
However it is an assumption.. which means I am probably as much an ass
as an umption in it.
How about images created with things such as livecd-tools? I don't know
to what extent, if any, that anaconda is involved in those builds. Last
time I checked, it did not appear to be so maybe this whole @core thing
really is irrelevant to me.
--
John Florian
8:27 p.m.
On 15.11.2012 02:19, Lennart Poettering wrote:
For containers a yum group for usage with --installroot= is the only
thing that matters.
FWIW, For me Anaconda is overkill for the KVM guest images too. I am
used to do that with small xquery script (easy for the libvirt domain
definition) containing:
yum (conf, root) install setup kernel acpid chrony acl attr audit
rsyslog dhclient openssh-server openssh-clients rootfiles yum
(yum dep-solves the above to 152 packages for F17, x86_64)
9:31 a.m.
On Thu, Nov 15, 2012 at 01:19:59AM +0100, Lennart Poettering wrote:
For containers a yum group for usage with --installroot= is the only
thing that matters.
For this, is a group even necessary or useful?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
9:32 a.m.
On Thu, Nov 15, 2012 at 01:13:09AM +0100, Lennart Poettering wrote:
Well, it would be weird that the "minimal" installation is
actually not
"minimal" at all, but the "container" installation is.
That would be weird. But fortunately, it's @core, not @minimal. So we could
easily have @minimal, @core, and @standard, each with different targets.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
3:12 p.m.
Matthew Miller (mattdm(a)fedoraproject.org) said:
> Well, it would be weird that the "minimal"
installation is actually not
> "minimal" at all, but the "container" installation is.
That would be weird. But fortunately, it's @core, not @minimal. So we could
easily have @minimal, @core, and @standard, each with different targets.
@core is what's shown as the minimal install in anacona. We could do some
renaming, but having @minimal, and having it *not* be the minimal install
in anaconda, sounds like a really bad idea.
Bill
4 p.m.
On Thu, Nov 15, 2012 at 10:12 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Matthew Miller (mattdm(a)fedoraproject.org) said:
> > Well, it would be weird that the "minimal" installation is actually
not
> > "minimal" at all, but the "container" installation is.
>
> That would be weird. But fortunately, it's @core, not @minimal. So we could
> easily have @minimal, @core, and @standard, each with different targets.
@core is what's shown as the minimal install in anacona. We could do some
renaming, but having @minimal, and having it *not* be the minimal install
in anaconda, sounds like a really bad idea.
We could have @core, @container and @cloud ... trying to fit multiple
cases in one group just wont work.
7:43 a.m.
On Thu, Nov 15, 2012 at 4:32 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Thu, Nov 15, 2012 at 01:13:09AM +0100, Lennart Poettering wrote:
> Well, it would be weird that the "minimal" installation is actually not
> "minimal" at all, but the "container" installation is.
That would be weird. But fortunately, it's @core, not @minimal. So we could
easily have @minimal, @core, and @standard, each with different targets.
Hm, the scope expansion happened rather quickly.
Can we, for now, restrict ourselves to things that an "ordinary
sysadmin" would encounter? That would, right now, mean anaconda-based
or image-based installations of full systems.
Anyone running custom scripts to create container chroots, or building
hypervisor images where post-install files are removed from the
system, is more of a programmer and therefore less reliant on us
choosing a good default for the @core/@standard comps groups.
Mirek
10:17 a.m.
On Fri, Nov 16, 2012 at 02:43:24PM +0100, Miloslav Trmač wrote:
> That would be weird. But fortunately, it's @core, not
@minimal. So we
> could easily have @minimal, @core, and @standard, each with different
> targets.
Hm, the scope expansion happened rather quickly.
Can we, for now, restrict ourselves to things that an "ordinary
sysadmin" would encounter? That would, right now, mean anaconda-based
or image-based installations of full systems.
+1. Specifically, regardless of the above distinction, we should really
focus on @core.
Anyone running custom scripts to create container chroots, or
building
hypervisor images where post-install files are removed from the
system, is more of a programmer and therefore less reliant on us
choosing a good default for the @core/@standard comps groups.
I don't think "more of a programmer" is necessarily the right
categorization, but I think "not in need of specific comps group defaults"
is probably true.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
11:26 a.m.
On 11/16/2012 08:17 AM, Matthew Miller wrote:
> Anyone running custom scripts to create container chroots, or
building
> >hypervisor images where post-install files are removed from the
> >system, is more of a programmer and therefore less reliant on us
> >choosing a good default for the @core/@standard comps groups.
I don't think "more of a programmer" is necessarily the right
categorization, but I think "not in need of specific comps group defaults"
is probably true.
Tools outside of anaconda don't have to force @core, which opens those
tools up to far more creative payloads.
--
Help me fight child abuse: http://tinyurl.com/jlkcourage
- jlk
12:17 p.m.
On Fri, Nov 16, 2012 at 09:26:30AM -0800, Jesse Keating wrote:
>>>hypervisor images where post-install files are removed
from the
>>>system, is more of a programmer and therefore less reliant on us
>>>choosing a good default for the @core/@standard comps groups.
>I don't think "more of a programmer" is necessarily the right
>categorization, but I think "not in need of specific comps group defaults"
>is probably true.
Tools outside of anaconda don't have to force @core, which opens
those tools up to far more creative payloads.
That was agreement, right? :)
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
12:20 p.m.
On 11/16/2012 10:17 AM, Matthew Miller wrote:
On Fri, Nov 16, 2012 at 09:26:30AM -0800, Jesse Keating wrote:
>>>> hypervisor images where post-install files are removed from the
>>>> system, is more of a programmer and therefore less reliant on us
>>>> choosing a good default for the @core/@standard comps groups.
>> I don't think "more of a programmer" is necessarily the right
>> categorization, but I think "not in need of specific comps group
defaults"
>> is probably true.
> Tools outside of anaconda don't have to force @core, which opens
> those tools up to far more creative payloads.
That was agreement, right? :)
Yeah, sorry I didn't make that clear. I was agreeing that the focus on
@core has to do with Anaconda based installs.
--
Help me fight child abuse: http://tinyurl.com/jlkcourage
- jlk
8:06 p.m.
On Fri, Nov 16, 2012 at 09:26:30AM -0800, Jesse Keating wrote:
Tools outside of anaconda don't have to force @core, which opens
those tools up to far more creative payloads.
So where's that put kickstart?
Or is the assumption that anyone who wants a more-minimal target won't
be going that route?
--
Scott Schmit
8:35 p.m.
On Fri, Nov 16, 2012 at 09:06:03PM -0500, Scott Schmit wrote:> On Fri, Nov 16, 2012 at
09:26:30AM -0800, Jesse Keating wrote:
> Tools outside of anaconda don't have to force @core, which
opens
> those tools up to far more creative payloads.
So where's that put kickstart?
Or is the assumption that anyone who wants a more-minimal target won't
be going that route?
Many of the outside-of-anaconda tools use kickstart too; they just don't
necessarily have the same rules for pulling in core automatically.
I don't know if that's necessarily a great situation, since it means the
same kickstart will do different things in different situations.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
10:29 a.m.
Matthew Miller (mattdm(a)fedoraproject.org) said:
> So where's that put kickstart?
> Or is the assumption that anyone who wants a more-minimal target won't
> be going that route?
Many of the outside-of-anaconda tools use kickstart too; they just don't
necessarily have the same rules for pulling in core automatically.
I don't know if that's necessarily a great situation, since it means the
same kickstart will do different things in different situations.
Well, anaconda could change such that the interactive person explicitly
specifies @core in kickstart, and we could then change anaconda's default
to not always include it.
Would require very large release notes, though.
Bill
10:37 a.m.
On Mon, Nov 19, 2012 at 11:29:51AM -0500, Bill Nottingham wrote:
> Many of the outside-of-anaconda tools use kickstart too; they
just don't
> necessarily have the same rules for pulling in core automatically.
> I don't know if that's necessarily a great situation, since it means the
> same kickstart will do different things in different situations.
Well, anaconda could change such that the interactive person explicitly
specifies @core in kickstart, and we could then change anaconda's default
to not always include it.
Would require very large release notes, though.
I'm in favor, and now seems like the time to do it, as we're changing @base
anyway.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
11:02 a.m.
On 11/16/2012 06:35 PM, Matthew Miller wrote:
On Fri, Nov 16, 2012 at 09:06:03PM -0500, Scott Schmit wrote:> On
Fri, Nov 16, 2012 at 09:26:30AM -0800, Jesse Keating wrote:
>> Tools outside of anaconda don't have to force @core, which opens
>> those tools up to far more creative payloads.
> So where's that put kickstart?
> Or is the assumption that anyone who wants a more-minimal target won't
> be going that route?
Many of the outside-of-anaconda tools use kickstart too; they just don't
necessarily have the same rules for pulling in core automatically.
I don't know if that's necessarily a great situation, since it means the
same kickstart will do different things in different situations.
This is kinda the point of breaking out pykickstart, so that other tools
can make use of the kickstart file format and parsing utilities without
having to drag in the rest of anaconda and anaconda's rules.
In fact, pykickstart is all about the format and parsing. It's up to
other tools to actually /act/ upon the data.
--
Jesse Keating
Fedora -- Freedom² is a feature!
6:41 p.m.
On Wed, Nov 14, 2012 at 4:03 PM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
On Thu, 15.11.12 00:56, Lennart Poettering (mzerqung(a)0pointer.de)
wrote:
> I think a good way to approach this is by looking for the interesting
> usecases for a minimal installation:
>
> A) Containers
> B) VMs
> C) Bare-Metal Servers
> D) Paranoid people (not relevant)
> E) Embedded (out of focus for Fedora)
> ... anything else?
>
> I list A and B as separate items, since they have different needs. For
> A you don't want SSH or bootloader (the bootloader is not necessary, as
> the container manager will directly invoke init, and you can login via
> local console). For B you you need a bootloader and probably SSH.
>
> I think it would make sense to focus on the intersection of installation
> set for these usecases. And hence:
>
> No SSH. No Boot loader. And definitely not Sendmail.
Also, no kernel and no kmod for A, as that is provided by the container
host.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
It's been a while since I did anything with containers (LXC) but as I
recall they're pretty much unmanageable without being able to ssh into
them. But yes, I do think the bare-assed minimum viable Fedora is an
LXC guest that one can get a console of some kind on and install
packages into via yum. I'd even be willing to give up vim for nano. I
don't need bash-completion or locate or man pages. ;-)
--
Twitter: http://twitter.com/znmeb; Computational Journalism Publishers
Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/
How the Hell can the lion sleep with all those people singing "A weem
oh way!" at the top of their lungs?
7:15 a.m.
From: Lennart Poettering <mzerqung(a)0pointer.de>
I think a good way to approach this is by looking for the interesting
usecases for a minimal installation:
A) Containers
B) VMs
C) Bare-Metal Servers
D) Paranoid people (not relevant)
E) Embedded (out of focus for Fedora)
I don't believe embedded is out of focus for Fedora, I already have
several hundred such systems, soon likely to scale into the thousands. It
works quite well for this and I don't see any reason @core can't work to
their benefit as well.
--
John Florian
9:59 a.m.
On 11/12/2012 11:28 AM, Matthew Miller wrote:
I see three basic options for the target:
A) kernel + init system and we're done
B) "boot to yum (with network)": a text-mode bootstrap environment on which
other things can be added by hand (or by kickstart)
C) a traditional Unix command line environment with the expected basic
tools available
To me, 'C' is too wide for two reasons. First, it's too open for continual
debate, because different people might expect different tools. Second, it's
I was just working on a VMWare ESXI hypervisor which basically is a
minimal Linux install, including a kernel running their virtualization
hosting environment, and a busybox session.
I found that there is a shockingly large amount of functionality in that
busybox: we needed some network diagnostic tools, and discovered that it
includes nc/netcat and ssh, as well as the usual
ping/traceroute/nslookup/etc.
I don't know if that is what you're after, because busybox duplicates
the functionality of individual packages (and may have some limitations
in how well it duplicates, I'm sure). All the same, I would definitely
consider including it---it's of course available as a Fedora package.
10:18 a.m.
On Thu, Nov 15, 2012 at 10:59:26AM -0500, Przemek Klosowski wrote:
I don't know if that is what you're after, because busybox
duplicates the functionality of individual packages (and may have
some limitations in how well it duplicates, I'm sure). All the same,
I would definitely consider including it---it's of course available
as a Fedora package.
Well, this is part of what I mean by "Fedora is not a tiny-linux
distribution." It might be interesting to have a busybox-based spin, but I
think that's a different thing.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
10:31 a.m.
On 11/15/2012 11:18 AM, Matthew Miller wrote:
On Thu, Nov 15, 2012 at 10:59:26AM -0500, Przemek Klosowski wrote:
> I don't know if that is what you're after, because busybox
> duplicates the functionality of individual packages (and may have
> some limitations in how well it duplicates, I'm sure). All the same,
> I would definitely consider including it---it's of course available
> as a Fedora package.
Well, this is part of what I mean by "Fedora is not a tiny-linux
distribution." It might be interesting to have a busybox-based spin, but I
think that's a different thing.
Since busybox package already exists, I think it makes sense to use
it--not because we're doing some tiny-linux, but because why not, it's
just 651 kB. Most packages we discussed here (openssh-clients, sendmail)
are individually much larger than that.
10:38 a.m.
Once upon a time, Przemek Klosowski <przemek.klosowski(a)nist.gov> said:
Since busybox package already exists, I think it makes sense to use
it--not because we're doing some tiny-linux, but because why not, it's
just 651 kB. Most packages we discussed here (openssh-clients, sendmail)
are individually much larger than that.
That's not a good reason to use busybox in a general install. It
doesn't exactly duplicate the commands it offers, only a subset.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
10:39 a.m.
On Thu, Nov 15, 2012 at 11:31:52AM -0500, Przemek Klosowski wrote:
>Well, this is part of what I mean by "Fedora is not a
tiny-linux
>distribution." It might be interesting to have a busybox-based spin, but I
>think that's a different thing.
Since busybox package already exists, I think it makes sense to use
it--not because we're doing some tiny-linux, but because why not,
it's just 651 kB. Most packages we discussed here (openssh-clients,
sendmail) are individually much larger than that.
We could just add the busybox binary, but doing that alone doesn't really
get much. In order to be useful, you want links to the commands you want
busybox to implement. And then, I suppose we'd want some way for those
commands to automatically get out of the way when full-featured versions are
installed (I guess install in an alternate dir with less priority in $PATH
than /usr/bin/). But since not every command is a literal drop-in
replacement for the full-featured Fedora versions, that could be confusing
(and for scripts, buggy).
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
4207
days inactive
4214
days old
104 comments
29 participants
participants (29)
-
Adam Williamson -
Alek Paunov -
Ben Cotton -
Benny Amorsen -
Bill Nottingham -
Chris Adams -
Christopher Meng -
David Malcolm -
Dennis Jacobfeuerborn -
drago01 -
Ian Pilcher -
Jesse Keating -
Jesse Keating -
John.Florian＠dart.biz -
Kevin Fenzi -
Lennart Poettering -
M. Edward (Ed) Borasky -
Matthew Miller -
Miloslav Trmač -
Petr Lautrbach -
Przemek Klosowski -
Richard W.M. Jones -
Scott Schmit -
Seth Vidal -
Stephen John Smoogen -
Steve Grubb -
Thomas Bendler -
Tim Lauridsen -
Tomas Mraz