12:56 p.m.
Greetings.
FESCo is looking at the question of what services can start by default
(ie, you install something and it's set to start automatically next
time you boot up).
We have a draft at:
https://fedoraproject.org/wiki/User:Kevin/DefaultServices
With a policy and list of exceptions.
We would like to gather feedback on this over the next week, and
revisit at our next meeting.
Some questions:
* Do you know of/maintain another service that should start by default?
Why?
* Do you think there is some other hurestic we could use to determine
when services should start by default? are there other categories
than one-shot, network facing?
Constructive feedback welcome.
kevin
3:29 a.m.
On Wed, 2011-02-23 at 11:56 -0700, Kevin Fenzi wrote:
Some questions:
* Do you know of/maintain another service that should start by default?
Why?
CUPS currently starts by default. The reason is that, even when
printing over the network as a client, this service is required to be
running (it spools the job, handles status feedback etc).
In the default configuration (i.e. client only, no local print queues
defined) it only listens to UDP port 631, which is used by CUPS
Browsing.
Tim.
*/
7:27 a.m.
On Thu, 24.02.11 09:29, Tim Waugh (twaugh(a)redhat.com) wrote:
On Wed, 2011-02-23 at 11:56 -0700, Kevin Fenzi wrote:
> Some questions:
>
> * Do you know of/maintain another service that should start by default?
> Why?
CUPS currently starts by default. The reason is that, even when
printing over the network as a client, this service is required to be
running (it spools the job, handles status feedback etc).
In the default configuration (i.e. client only, no local print queues
defined) it only listens to UDP port 631, which is used by CUPS
Browsing.
I still have unupstreamed patches here which would allow us to start
CUPS automatically when a local client needs it or when a printer is
plugged in.
Lennart
--
Lennart Poettering - Red Hat, Inc.
8:21 a.m.
On Thu, 2011-02-24 at 14:27 +0100, Lennart Poettering wrote:
I still have unupstreamed patches here which would allow us to start
CUPS automatically when a local client needs it or when a printer is
plugged in.
I think that's separate from the issue of whether the service is allowed
to start automatically, isn't it?
In other words, delaying start-up until it is needed is separate from
whether the service is available by default at all.
Tim.
*/
6:23 a.m.
On 02/23/2011 06:56 PM, Kevin Fenzi wrote:
Greetings.
FESCo is looking at the question of what services can start by default
(ie, you install something and it's set to start automatically next
time you boot up).
We have a draft at:
https://fedoraproject.org/wiki/User:Kevin/DefaultServices
With a policy and list of exceptions.
We would like to gather feedback on this over the next week, and
revisit at our next meeting.
Some questions:
* Do you know of/maintain another service that should start by default?
Why?
* Do you think there is some other hurestic we could use to determine
when services should start by default? are there other categories
than one-shot, network facing?
Constructive feedback welcome.
kevin
Is it possible to get the rationality behind why those services which
are permitted to be enabled by default as specific exceptions are
granted that exception.
JBG
1:33 p.m.
On Thu, 24 Feb 2011 12:23:59 +0000
"Jóhann B. Guðmundsson" <johannbg(a)gmail.com> wrote:
Is it possible to get the rationality behind why those services which
are permitted to be enabled by default as specific exceptions are
granted that exception.
Well, I think the rationale was "these are basic services that are
required to bring the machine up into a gui and allow a user to login
and be able to apply updates, etc"
At least that was my thought.
I wonder now if we couldn't use the critical path setup to define
these.
Ie, "If your package is not critical path, it should not start by
default. If it is, it _may_ start by default"
Just a thought.
kevin
4:33 p.m.
On 02/27/2011 01:33 PM, Kevin Fenzi wrote:
Ie, "If your package is not critical path, it should not start
by
default. If it is, it _may_ start by default"
+1
--
========================================================================
Ian Pilcher arequipeno(a)gmail.com
========================================================================
10:53 a.m.
Kevin Fenzi (kevin(a)scrye.com) said:
Well, I think the rationale was "these are basic services that
are
required to bring the machine up into a gui and allow a user to login
and be able to apply updates, etc"
At least that was my thought.
I wonder now if we couldn't use the critical path setup to define
these.
Ie, "If your package is not critical path, it should not start by
default. If it is, it _may_ start by default"
It's not bad, although it makes comps the arbiter, which seems a
little weird.
Bill
11:03 a.m.
On Mon, 2011-02-28 at 11:53 -0500, Bill Nottingham wrote:
Kevin Fenzi (kevin(a)scrye.com) said:
> Well, I think the rationale was "these are basic services that are
> required to bring the machine up into a gui and allow a user to login
> and be able to apply updates, etc"
>
> At least that was my thought.
>
> I wonder now if we couldn't use the critical path setup to define
> these.
>
> Ie, "If your package is not critical path, it should not start by
> default. If it is, it _may_ start by default"
It's not bad, although it makes comps the arbiter, which seems a
little weird.
well, the arbiter of what's critpath is supposed to be the critpath
policy, not comps. Comps is just how the policy is implemented.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:46 p.m.
On 02/27/2011 07:33 PM, Kevin Fenzi wrote:
On Thu, 24 Feb 2011 12:23:59 +0000
"Jóhann B. Guðmundsson"<johannbg(a)gmail.com> wrote:
> Is it possible to get the rationality behind why those services which
> are permitted to be enabled by default as specific exceptions are
> granted that exception.
Well, I think the rationale was "these are basic services that are
required to bring the machine up into a gui and allow a user to login
and be able to apply updates, etc"
We should not standardize our policy around "Desktop Installs" our
community is broader then any ( single ) *DE
At least that was my thought.
I wonder now if we couldn't use the critical path setup to define
these.
Ie, "If your package is not critical path, it should not start by
default. If it is, it _may_ start by default"
Interesting approach but I agree whole heartedly with Colin Walters take
on this..
"Honestly I think it'd be conceptually a lot simpler if all services
didn't start on RPM installation, period. Specific ones that we want
enabled by default in a desktop install could simply be turned on in
the kickstart file."
JBG
8:44 a.m.
On Wed, Feb 23, 2011 at 1:56 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
Greetings.
FESCo is looking at the question of what services can start by default
(ie, you install something and it's set to start automatically next
time you boot up).
Honestly I think it'd be conceptually a lot simpler if all services
didn't start on RPM installation, period. Specific ones that we want
enabled by default in a desktop install could simply be turned on in
the kickstart file.
Something like the attached patch (obviously incomplete, and not tested):
9:04 a.m.
On Thu, Feb 24, 2011 at 09:44:19AM -0500, Colin Walters wrote:
On Wed, Feb 23, 2011 at 1:56 PM, Kevin Fenzi <kevin(a)scrye.com>
wrote:
> Greetings.
>
> FESCo is looking at the question of what services can start by default
> (ie, you install something and it's set to start automatically next
> time you boot up).
Honestly I think it'd be conceptually a lot simpler if all services
didn't start on RPM installation, period. Specific ones that we want
enabled by default in a desktop install could simply be turned on in
the kickstart file.
We considered that option, but it's not just about the desktop install -
you need a default set for a default install, or the entire world is
going to set fire to you because cron isn't there by default any more.
And once you've got a default set for the default install, why not just
do it at the package level and ensure some level of consistency?
--
Matthew Garrett | mjg59(a)srcf.ucam.org
9:25 a.m.
On Thu, Feb 24, 2011 at 10:04 AM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Thu, Feb 24, 2011 at 09:44:19AM -0500, Colin Walters wrote:
> On Wed, Feb 23, 2011 at 1:56 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
> > Greetings.
> >
> > FESCo is looking at the question of what services can start by default
> > (ie, you install something and it's set to start automatically next
> > time you boot up).
>
> Honestly I think it'd be conceptually a lot simpler if all services
> didn't start on RPM installation, period. Specific ones that we want
> enabled by default in a desktop install could simply be turned on in
> the kickstart file.
We considered that option, but it's not just about the desktop install -
you need a default set for a default install,
"Default install"? This is @base from anaconda or something?
or the entire world is
going to set fire to you because cron isn't there by default any more.
True, in this design just running through the RPM path isn't
going to give you what it did before.
And once you've got a default set for the default install, why
not just
do it at the package level and ensure some level of consistency?
Well...until one product wants a "service" enabled and another
doesn't. I guess in the "whitelist" design the latter just has to
"chkconfig foo off" in a kickstart. I think this is already the case
with openssh-server.
Anyways if we end up with just a documented list that's probably OK.
But it has tradeoffs - for example, it just says these services *may*
be enabled, not that they will. So for someone writing a kickstart
file, you pretty much have to "chkconfig foo on" *anyways*, since you
have no guarantee that they actually *are* enabled in a specific
Fedora release.
9:32 a.m.
On Thu, Feb 24, 2011 at 10:25:25AM -0500, Colin Walters wrote:
On Thu, Feb 24, 2011 at 10:04 AM, Matthew Garrett
<mjg59(a)srcf.ucam.org> wrote:
> We considered that option, but it's not just about the desktop install -
> you need a default set for a default install,
"Default install"? This is @base from anaconda or something?
Whatever you get if you do an install from something other than the
desktop spin.
> And once you've got a default set for the default install,
why not just
> do it at the package level and ensure some level of consistency?
Well...until one product wants a "service" enabled and another
doesn't. I guess in the "whitelist" design the latter just has to
"chkconfig foo off" in a kickstart. I think this is already the case
with openssh-server.
Right. I think the reasonable expectation here is that if you (as a
user) don't want the service, don't install the package. If you (as a
SIG) don't want the service but do want the package, blacklist it
somehow.
Anyways if we end up with just a documented list that's probably
OK.
But it has tradeoffs - for example, it just says these services *may*
be enabled, not that they will. So for someone writing a kickstart
file, you pretty much have to "chkconfig foo on" *anyways*, since you
have no guarantee that they actually *are* enabled in a specific
Fedora release.
"May" as in "Are allowed to". It's always going to be the package
maintainers call in the end - we're not going to mandate it.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
9:42 a.m.
On Thu, Feb 24, 2011 at 10:32 AM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
"May" as in "Are allowed to". It's always
going to be the package
maintainers call in the end - we're not going to mandate it.
Okay; it's not worth going through the details if you guys already
discussed and rejected it, we've lived for years with the status quo
and this is basically just documenting it.
One other random thing - NetworkManager seems to be a big missing item
from the list?
11:47 a.m.
On Thu, Feb 24, 2011 at 10:42:54AM -0500, Colin Walters wrote:
On Thu, Feb 24, 2011 at 10:32 AM, Matthew Garrett
<mjg59(a)srcf.ucam.org> wrote:
> "May" as in "Are allowed to". It's always going to be the
package
> maintainers call in the end - we're not going to mandate it.
Okay; it's not worth going through the details if you guys already
discussed and rejected it, we've lived for years with the status quo
and this is basically just documenting it.
Actually, this policy is a large departure to the status quo. The standard
has pretty much been "off by default unless you're an old package from RHL
that was on or you slip it by your reviewer."
I think that the intention of the old policy (I believe there was an
explicit policy about this in Fedora.us but mschwendt or someone who has
a better memory than I could correct me there) was that only essential
services were on by default to minimize security risk (not just remote
exploits, but local exploits as well), to minimize resource usage, and to
put the system administrator in charge of their environment (as Till Maas
has pointed out, he has a lot of server software installed but not running
unless he needs it for a particular task.)
The draft policy that FESCo has up is much broader than that. For instance,
"If a service does not require configuration to be functional and is not
network enabled, it may be enabled by default (but is not required to do
so)." Includes things such as apache and mysql if we ship them with
a configuration that only listens on localhost.
This isn't necessarily a bad thing (although speakingfor myself, I lean
towards your view of everything off in packaging and then turn things on at
the installer/spin creator/kickstart/etc level) but it is a large policy
shift, not just a statement of the status quo.
-Toshio
9:58 a.m.
On 02/24/2011 03:32 PM, Matthew Garrett wrote:
"May" as in "Are allowed to". It's always
going to be the package
maintainers call in the end - we're not going to mandate it.
Hum not following you..
If ultimately packagers can override this then is this [1] being worked on?
I thought the whole purpose was to allow "exceptions" that should be
turned on by default but everything else should be off at install time?
But I think Colin is right everything should default to off then each
SIG document on their wiki page what service they have turned "on" in
their kickstart file and why.
JBG
1.https://fedoraproject.org/wiki/User:Kevin/DefaultServices
10:27 a.m.
On Thu, Feb 24, 2011 at 03:58:25PM +0000, "Jóhann B. Guðmundsson" wrote:
On 02/24/2011 03:32 PM, Matthew Garrett wrote:
> "May" as in "Are allowed to". It's always going to be the
package
> maintainers call in the end - we're not going to mandate it.
>
Hum not following you..
If ultimately packagers can override this then is this [1] being worked on?
I thought the whole purpose was to allow "exceptions" that should be
turned on by default but everything else should be off at install time?
Yes. A package's presence on the exception list does not preclude a
maintainer from defaulting it to off.
But I think Colin is right everything should default to off then each
SIG document on their wiki page what service they have turned "on" in
their kickstart file and why.
Fedora is intended to be a functional distribution, not merely a toolbox
for SIGs to build functional distributions.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
10:44 a.m.
On 02/24/2011 04:27 PM, Matthew Garrett wrote:
Fedora is intended to be a functional distribution, not merely a
toolbox
for SIGs to build functional distributions.
The project has already outgrown that purpose...
It's just taking several people some time to let go and realize that a
"Default" no longer applies and it's no longer a question of if but when
we stop shipping a "Default". ( from my perspective ).
JBG
10:52 a.m.
On Thu, Feb 24, 2011 at 03:32:43PM +0000, Matthew Garrett wrote:
Right. I think the reasonable expectation here is that if you (as a
user) don't want the service, don't install the package. If you (as a
The package is more than just the service. It will also include the
documentation and the possibility to start the service whenever I need
it. I have lots of server software installed like apache httpd or a
tftpd, ftpd, etc. on a client system and I only enable them whenever
they are needed. Even when I install some of the software, how is it
supposed to know which files to serve?
Regards
Till
10:14 a.m.
On Thu, 24.02.11 15:04, Matthew Garrett (mjg59(a)srcf.ucam.org) wrote:
On Thu, Feb 24, 2011 at 09:44:19AM -0500, Colin Walters wrote:
> On Wed, Feb 23, 2011 at 1:56 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
> > Greetings.
> >
> > FESCo is looking at the question of what services can start by default
> > (ie, you install something and it's set to start automatically next
> > time you boot up).
>
> Honestly I think it'd be conceptually a lot simpler if all services
> didn't start on RPM installation, period. Specific ones that we want
> enabled by default in a desktop install could simply be turned on in
> the kickstart file.
We considered that option, but it's not just about the desktop install -
you need a default set for a default install, or the entire world is
going to set fire to you because cron isn't there by default any more.
And once you've got a default set for the default install, why not just
do it at the package level and ensure some level of consistency?
Related to this:
Some people have been asking us to extend the systemd unit file header
to include information about whether a service should be on or off by
default (Michal!), like chkconfig had it. But after thinking about this
we came to the conclusion that this information is not specific to
services at all, but to the distro image you install, and hence has no
place in the unit files. Ideally unit files are shipped along the
upstream sources, and whether a service is enabled by default is not an
upstream decision, but genuinely one not only of the distro but by the
particular distro "profile" installed. Hence the place to encode this
information is not the upstream shipped unit files and not packaging
spec files, but other distro specific list.
Lennart
--
Lennart Poettering - Red Hat, Inc.
11:06 a.m.
On 2/24/2011 8:14, Lennart Poettering wrote:
Some people have been asking us to extend the systemd unit file
header
to include information about whether a service should be on or off by
default (Michal!), like chkconfig had it. But after thinking about this
we came to the conclusion that this information is not specific to
services at all, but to the distro image you install, and hence has no
place in the unit files. Ideally unit files are shipped along the
upstream sources, and whether a service is enabled by default is not an
upstream decision, but genuinely one not only of the distro but by the
particular distro "profile" installed. Hence the place to encode this
information is not the upstream shipped unit files and not packaging
spec files, but other distro specific list.
So whether or not a given package will be enabled by default after I
tell yum to install it depends on which spin, if any, that I initially
installed my system with? Why should the initial package set that my
system came up with have any effect at all on what happens when I
install something new?
11:12 a.m.
On Thu, Feb 24, 2011 at 12:06 PM, Garrett Holmstrom
<gholms(a)fedoraproject.org> wrote:
So whether or not a given package will be enabled by default after I
tell yum to install it depends on which spin, if any, that I initially
installed my system with? Why should the initial package set that my
system came up with have any effect at all on what happens when I
install something new?
No. In my proposal above (which I'm not really going to spend more
effort debating since we have bigger issues and the current FESCo
consensus of basically documenting is better than nothing) the
services are enabled in the kickstart - *no* service is enabled by
default after installing via yum later with 100% consistency. If you
want it on you use chkconfig.
11:26 a.m.
On Thu, 24.02.11 09:06, Garrett Holmstrom (gholms(a)fedoraproject.org) wrote:
On 2/24/2011 8:14, Lennart Poettering wrote:
> Some people have been asking us to extend the systemd unit file header
> to include information about whether a service should be on or off by
> default (Michal!), like chkconfig had it. But after thinking about this
> we came to the conclusion that this information is not specific to
> services at all, but to the distro image you install, and hence has no
> place in the unit files. Ideally unit files are shipped along the
> upstream sources, and whether a service is enabled by default is not an
> upstream decision, but genuinely one not only of the distro but by the
> particular distro "profile" installed. Hence the place to encode this
> information is not the upstream shipped unit files and not packaging
> spec files, but other distro specific list.
So whether or not a given package will be enabled by default after I
tell yum to install it depends on which spin, if any, that I initially
installed my system with? Why should the initial package set that my
system came up with have any effect at all on what happens when I
install something new?
No. this information would be used most only at installation time of the
system itself.
that said, I do think it would make sense to offer some command to
enable all modules that were originally enabled, to get a working system
back if you broke it. Something in the sense of #630174.
Lennart
--
Lennart Poettering - Red Hat, Inc.
noon
On 02/24/2011 05:26 PM, Lennart Poettering wrote:
that said, I do think it would make sense to offer some command to
enable all modules that were originally enabled, to get a working system
back if you broke it. Something in the sense of #630174.
Hum
You probably would need to implement something more similar to iptables
save/restore.
Like systemd --save state which would scan for relevant changes and
would "save" the current state into /etc/sysconfig/systemd.save
and you would have simply create a systemd service that is run ones at
first time the machine is run which would run systemd --save state
/etc/sysconfig/systemd.initial
Then the admin would just run "systemd --restore-state /path/to/file"..
That would allow the admin to save the current systemd state before
making any changes..
I do think that's an better approach to the problem than what's being
mentioned in that report..
JBG
10:59 a.m.
On Thu, Feb 24, 2011 at 03:04:26PM +0000, Matthew Garrett wrote:
And once you've got a default set for the default install, why
not just
do it at the package level and ensure some level of consistency?
Because by enabling lots of potential vulnerable services you make it a
PITA to use Fedora securely. A proper way would be to have some system
setting to specify whether or not non-essential services require
explicit enabling, e.g. a file in /etc/sysconfig/initscripts file with a
variable that one can set to true, which ensures that all not explicitly
enabled services won't be enabled.
It is pretty easy to notice that a wanted service does not run compared
to notice that an unwanted/unused service suddenly runs, because an
innocent looking package has been installed. This is a trap that is
usually set on Debian systems which everyone I know who uses Debian
dislikes.
Regards
Till
12:32 p.m.
On Thu, Feb 24, 2011 at 05:59:33PM +0100, Till Maas wrote:
On Thu, Feb 24, 2011 at 03:04:26PM +0000, Matthew Garrett wrote:
> And once you've got a default set for the default install, why not just
> do it at the package level and ensure some level of consistency?
Because by enabling lots of potential vulnerable services you make it a
PITA to use Fedora securely. A proper way would be to have some system
setting to specify whether or not non-essential services require
explicit enabling, e.g. a file in /etc/sysconfig/initscripts file with a
variable that one can set to true, which ensures that all not explicitly
enabled services won't be enabled.
There are no essential services, which means any proposal that contains
the phrase "non-essential services" is already unimplementable.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
2:59 p.m.
On Thu, Feb 24, 2011 at 03:51:37PM -0500, Genes MailLists wrote:
On 02/24/2011 01:32 PM, Matthew Garrett wrote:
> There are no essential services, which means any proposal that contains
> the phrase "non-essential services" is already unimplementable.
>
HID services (keyboard/mouse) might be nice ... :-) :-)
Not if you have a headless server. Also I don't think its absolutely
necessary to have a service running to use the keyboard.
There's no real usecases that want _no_ services running, and there's
probably very few within Fedora proper that don't want things like udev
(and then they're probably doing so much to the base install anyway that
a bit of service reconfiguration is nothing), but technically Matthew is
correct.
--CJD
3:24 p.m.
On Thu, Feb 24, 2011 at 03:51:37PM -0500, Genes MailLists wrote:
On 02/24/2011 01:32 PM, Matthew Garrett wrote:
> There are no essential services, which means any proposal that contains
> the phrase "non-essential services" is already unimplementable.
>
HID services (keyboard/mouse) might be nice ... :-) :-)
Handled by the kernel.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
3:25 p.m.
On Thu, Feb 24, 2011 at 06:32:44PM +0000, Matthew Garrett wrote:
On Thu, Feb 24, 2011 at 05:59:33PM +0100, Till Maas wrote:
> On Thu, Feb 24, 2011 at 03:04:26PM +0000, Matthew Garrett wrote:
>
> > And once you've got a default set for the default install, why not just
> > do it at the package level and ensure some level of consistency?
>
> Because by enabling lots of potential vulnerable services you make it a
> PITA to use Fedora securely. A proper way would be to have some system
> setting to specify whether or not non-essential services require
> explicit enabling, e.g. a file in /etc/sysconfig/initscripts file with a
> variable that one can set to true, which ensures that all not explicitly
> enabled services won't be enabled.
There are no essential services, which means any proposal that contains
the phrase "non-essential services" is already unimplementable.
For me essential services are the services that are required to start
other services. If there are no services required to boot Fedora, login
as root and start other services, then I do not see any point of
requiring services to be enabled by default.
Regards
Till
3:46 p.m.
On Thu, Feb 24, 2011 at 10:25:44PM +0100, Till Maas wrote:
For me essential services are the services that are required to
start
other services. If there are no services required to boot Fedora, login
as root and start other services, then I do not see any point of
requiring services to be enabled by default.
So we should default to init=/bin/sh and take it from there?
--
Matthew Garrett | mjg59(a)srcf.ucam.org
10:18 a.m.
On Thu, Feb 24, 2011 at 09:46:06PM +0000, Matthew Garrett wrote:
On Thu, Feb 24, 2011 at 10:25:44PM +0100, Till Maas wrote:
> For me essential services are the services that are required to start
> other services. If there are no services required to boot Fedora, login
> as root and start other services, then I do not see any point of
> requiring services to be enabled by default.
So we should default to init=/bin/sh and take it from there?
Is it possible to start there and to get to a gdm login by only using
the command "service <foo> start"[0] and making this persistent by using
"chkconfig <foo> on"[0]? I doubt it, as editing /boot/grub/grub.conf does
not happen using this interface, which is where init=/bin/sh is set.
Using the command "service <foo> start" is what I meant by starting
other services as this is the usual interface for this on Fedora.
Regards
Till
[0] Or the respective systemd command
10:45 a.m.
On Fri, Feb 25, 2011 at 05:18:34PM +0100, Till Maas wrote:
On Thu, Feb 24, 2011 at 09:46:06PM +0000, Matthew Garrett wrote:
> So we should default to init=/bin/sh and take it from there?
Is it possible to start there and to get to a gdm login by only using
the command "service <foo> start"[0] and making this persistent by using
"chkconfig <foo> on"[0]? I doubt it, as editing /boot/grub/grub.conf
does
not happen using this interface, which is where init=/bin/sh is set.
Using the command "service <foo> start" is what I meant by starting
other services as this is the usual interface for this on Fedora.
No, but if that's your definition of "essential" then all we need is to
launch init and have it give you a getty. chkconfigging gdm on would
give you a graphical login, and you could probably even get a session. A
bunch of stuff wouldn't work because you'd be missing dbus and udev,
you'd be wasting extra power and losing performance becase there'd be no
irq balancing, you'd have no networking, you wouldn't be able to mount
anything via nfs, bluetooth would obviously be right out the window and
system logs wouldn't be updated.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
11:11 a.m.
On Fri, Feb 25, 2011 at 04:45:35PM +0000, Matthew Garrett wrote:
No, but if that's your definition of "essential" then
all we need is to
launch init and have it give you a getty. chkconfigging gdm on would
give you a graphical login, and you could probably even get a session. A
bunch of stuff wouldn't work because you'd be missing dbus and udev,
As long it is possible to start dbus and udev afterwards once I need
something that is not working otherwise, I do not see a problem.
you'd be wasting extra power and losing performance becase
there'd be no
irq balancing, you'd have no networking, you wouldn't be able to mount
anything via nfs, bluetooth would obviously be right out the window and
system logs wouldn't be updated.
I do not need to mount anything via nfs and if I have to, I have no
problem by starting some service first or making it persistent if I need
it always. The same holds true for bluetooth. Also it is a lot easier to
once start all the necessary services or enabling them than finding all
services that need to be disabled. It is a lot easier to identify
missing services and unwanted extra services. There could even be a
command that suggest to start all the services that are more or less
always useful like udev, cpufreq, irqbalance or rsyslog.
Regards
Till
11:46 a.m.
On Thu, Feb 24, 2011 at 06:32:44PM +0000, Matthew Garrett wrote:
On Thu, Feb 24, 2011 at 05:59:33PM +0100, Till Maas wrote:
> On Thu, Feb 24, 2011 at 03:04:26PM +0000, Matthew Garrett wrote:
>
> > And once you've got a default set for the default install, why not just
> > do it at the package level and ensure some level of consistency?
>
> Because by enabling lots of potential vulnerable services you make it a
> PITA to use Fedora securely. A proper way would be to have some system
> setting to specify whether or not non-essential services require
> explicit enabling, e.g. a file in /etc/sysconfig/initscripts file with a
> variable that one can set to true, which ensures that all not explicitly
> enabled services won't be enabled.
There are no essential services, which means any proposal that contains
the phrase "non-essential services" is already unimplementable.
You've said this many times and it seems that you do it to be
obstructionist. The constructive way to deal with this is to start making
a list of what people really mean by "essential" and then propose alternate
words to use.
I think, by essential, some people mean:
start the bare minimum so I don't have to start any additional services to:
... I don't want anything but init and a shell [*]
... log into a getty
... log in over the network
... log into a desktop
... do any client-side operations
[*] This one (but not limited to this one) also specifies that additional
services would be started, just not by packaging. ie: the installer or
something else will start additional services independent of packaging.
I'll note that with both traditional SysV runlevels and the set of systemd
targets that we'll give to people in F15, we can have multiple defintions of
what services to start as well. The rescue target (formerly runlevel 1)
would be different from the multi-user target would be different from the
graphical target.
-Toshio
11:53 a.m.
On 2/25/11 9:46 AM, Toshio Kuratomi wrote:
You've said this many times and it seems that you do it to be
obstructionist. The constructive way to deal with this is to start making
a list of what people really mean by "essential" and then propose alternate
words to use.
I think, by essential, some people mean:
start the bare minimum so I don't have to start any additional services to:
... I don't want anything but init and a shell [*]
... log into a getty
... log in over the network
... log into a desktop
... do any client-side operations
I think his point is that we could argue endlessly about what is
"essential", because what's essential to you is different from what is
essential to Bob, or Jim, or Susie. This was the same realization that
led to the removal of the labeled "minimal" install, too many people
just wanted to argue over the meaning of the term "minimal".
To be constructive here, I think we as a builder of a distribution need
to decide what it means to have /Fedora/ boot. What is running when
something called Fedora is installed and booted. In the past it has
been enough stuff to do basically what you've written above, provided
the right sets of packages were installed. Some of that was dictated by
anaconda, not necessarily by the contents of the rpms themselves.
I understand that Fedora is in one hand a big pile of packages that
users can massage and manipulate into any number of smaller end products
with various configurations, but Fedora is also supposed to be a useable
distribution itself, and thus we should define what it means to have
Fedora boot, and perhaps avoid loaded terms such as "essential".
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
2:26 p.m.
New subject: Minimal install option (was Re: Services that can start by default policy feedback)
On Fri, 2011-02-25 at 09:53 -0800, Jesse Keating wrote:
This was the same realization that
led to the removal of the labeled "minimal" install, too many people
just wanted to argue over the meaning of the term "minimal".
? There's still a 'minimal' radio button in the installer at the package
set selection stage. I know, I just clicked on it not half an hour ago
in the F15 Alpha RC1 installer. :) Is it meant to be gone?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:41 p.m.
New subject: Minimal install option (was Re: Services that can start by default policy feedback)
2011/2/25 Adam Williamson <awilliam(a)redhat.com>:
On Fri, 2011-02-25 at 09:53 -0800, Jesse Keating wrote:
> This was the same realization that
> led to the removal of the labeled "minimal" install, too many people
> just wanted to argue over the meaning of the term "minimal".
? There's still a 'minimal' radio button in the installer at the package
set selection stage. I know, I just clicked on it not half an hour ago
in the F15 Alpha RC1 installer. :) Is it meant to be gone?
I hope not. This is an option that I use most often.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Best regards,
Michal
http://eventhorizon.pl/
2:51 p.m.
New subject: Minimal install option (was Re: Services that can start by default policy feedback)
> This was the same realization that
> led to the removal of the labeled "minimal" install, too many people
> just wanted to argue over the meaning of the term "minimal".
? There's still a 'minimal' radio button in the installer at the package
set selection stage. I know, I just clicked on it not half an hour ago
in the F15 Alpha RC1 installer. :) Is it meant to be gone?
It was there a long, long time ago. It was taken away a medium long
time ago. It came back a short long time ago. It's still there.
- Chris
3:07 p.m.
New subject: Minimal install option (was Re: Services that can start by default policy feedback)
On 2/25/11 12:51 PM, Chris Lumens wrote:
>> This was the same realization that
>> led to the removal of the labeled "minimal" install, too many people
>> just wanted to argue over the meaning of the term "minimal".
>
> ? There's still a 'minimal' radio button in the installer at the package
> set selection stage. I know, I just clicked on it not half an hour ago
> in the F15 Alpha RC1 installer. :) Is it meant to be gone?
It was there a long, long time ago. It was taken away a medium long
time ago. It came back a short long time ago. It's still there.
Heh, have we started getting bug reports about it not being minimal
enough or it being too minimal yet?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
7 p.m.
New subject: Minimal install option (was Re: Services that can start by default policy feedback)
On Fri, Feb 25, 2011 at 9:07 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
On 2/25/11 12:51 PM, Chris Lumens wrote:
>>> This was the same realization that
>>> led to the removal of the labeled "minimal" install, too many
people
>>> just wanted to argue over the meaning of the term "minimal".
>>
>> ? There's still a 'minimal' radio button in the installer at the
package
>> set selection stage. I know, I just clicked on it not half an hour ago
>> in the F15 Alpha RC1 installer. :) Is it meant to be gone?
>
> It was there a long, long time ago. It was taken away a medium long
> time ago. It came back a short long time ago. It's still there.
Heh, have we started getting bug reports about it not being minimal
enough or it being too minimal yet?
If it includes sendmail its not minimal enough ;-)
Peter
10:57 p.m.
New subject: Minimal install option (was Re: Services that can start by default policy feedback)
On Sun, Feb 27, 2011 at 7:00 PM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
If it includes sendmail its not minimal enough ;-)
From a recent default install of F14:
ps auxw | wc -l
124
Several of the BSDish distros achieve 30-50 as a minimal install.
e.g., on RHEL.
IMHO some thought should be given to the security of a new user who
may not be aware that it is best to harden a box behind a firewall
before presenting it to the Internet.
On some other packages, enough may be known by the install process to
know that they are not applicable.
regards/vaden(a)texoma.net
3:21 a.m.
New subject: Minimal install option (was Re: Services that can start by default policy feedback)
Larry Vaden <vaden(a)texoma.net> writes:
>From a recent default install of F14:
ps auxw | wc -l
124
How many of those are kernel threads?
Andreas.
--
Andreas Schwab, schwab(a)redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
8:20 a.m.
New subject: Minimal install option (was Re: Services that can start by default policy feedback)
On Mon, Feb 28, 2011 at 3:21 AM, Andreas Schwab <schwab(a)redhat.com> wrote:
Larry Vaden <vaden(a)texoma.net> writes:
>>From a recent default install of F14:
>
> ps auxw | wc -l
> 124
How many of those are kernel threads?
I dunno but if you will suggest a mod to the CLI command I'll run it
and report back.
regards/vaden(a)texoma.net
11:06 p.m.
New subject: Minimal install option (was Re: Services that can start by default policy feedback)
On 02/25/2011 03:07 PM, Jesse Keating wrote:
Heh, have we started getting bug reports about it not being minimal
enough or it being too minimal yet?
Do you want them? ;-)
--
========================================================================
Ian Pilcher arequipeno(a)gmail.com
========================================================================
12:22 p.m.
On Fri, Feb 25, 2011 at 09:46:08AM -0800, Toshio Kuratomi wrote:
On Thu, Feb 24, 2011 at 06:32:44PM +0000, Matthew Garrett wrote:
> There are no essential services, which means any proposal that contains
> the phrase "non-essential services" is already unimplementable.
>
You've said this many times and it seems that you do it to be
obstructionist. The constructive way to deal with this is to start making
a list of what people really mean by "essential" and then propose alternate
words to use.
Like Jesse said, my objection here is that using the word "essential"
just results in us being doomed to argue over what "essential" means.
A literal interpretation of "essential" means "start init and have it
launch a getty". I don't think anyone's advocating that that be the
outcome of a vanilla Fedora install. An alternative would be "Essential
for a traditional UNIX experience", which would seem to preclude dbus. I
don't think that's a rational outcome either. So we end up with
"Essential for providing an experience consistent with what we feel a
vanilla Fedora install should provide", which means you haven't actually
defined "essential" at all. So don't say "essential". Say what you
mean.
I think, by essential, some people mean:
start the bare minimum so I don't have to start any additional services to:
... I don't want anything but init and a shell [*]
... log into a getty
... log in over the network
... log into a desktop
... do any client-side operations
That's my point. If people have different interpretations of "essential"
then any policy using the word "essential" is meaningless. You need to
define "essential" - and if you're doing that then you don't need to use
the word in the first place.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
12:30 p.m.
On Fri, Feb 25, 2011 at 06:22:25PM +0000, Matthew Garrett wrote:
Like Jesse said, my objection here is that using the word
"essential"
just results in us being doomed to argue over what "essential" means.
A literal interpretation of "essential" means "start init and have it
launch a getty". I don't think anyone's advocating that that be the
outcome of a vanilla Fedora install. An alternative would be "Essential
The services that are started when the respective package is installed
and the services that are enabled by default by the Fedora installer do
not need to be the same and are afaik currently not the same. There is
imho a huge difference, whether services are enabled during
installation, because afterwards one can usually expect that there are
unwanted services and whether services are enabled after the respective
package is installed long after the system has been installed.
Regards
Till
1 p.m.
On Fri, Feb 25, 2011 at 07:30:34PM +0100, Till Maas wrote:
The services that are started when the respective package is
installed
and the services that are enabled by default by the Fedora installer do
not need to be the same and are afaik currently not the same. There is
imho a huge difference, whether services are enabled during
installation, because afterwards one can usually expect that there are
unwanted services and whether services are enabled after the respective
package is installed long after the system has been installed.
I think multipath is the only service enabled by Anaconda. Everything
else depends on the package doing so.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
9:33 a.m.
On Fri, Feb 25, 2011 at 07:00:20PM +0000, Matthew Garrett wrote:
On Fri, Feb 25, 2011 at 07:30:34PM +0100, Till Maas wrote:
> The services that are started when the respective package is installed
> and the services that are enabled by default by the Fedora installer do
> not need to be the same and are afaik currently not the same. There is
> imho a huge difference, whether services are enabled during
> installation, because afterwards one can usually expect that there are
> unwanted services and whether services are enabled after the respective
> package is installed long after the system has been installed.
I think multipath is the only service enabled by Anaconda. Everything
else depends on the package doing so.
This does not mean that this is a good way or the only way to do this.
Regards
Till
1:21 p.m.
On Sun, Feb 27, 2011 at 04:33:56PM +0100, Till Maas wrote:
On Fri, Feb 25, 2011 at 07:00:20PM +0000, Matthew Garrett wrote:
> On Fri, Feb 25, 2011 at 07:30:34PM +0100, Till Maas wrote:
>
> > The services that are started when the respective package is installed
> > and the services that are enabled by default by the Fedora installer do
> > not need to be the same and are afaik currently not the same. There is
> > imho a huge difference, whether services are enabled during
> > installation, because afterwards one can usually expect that there are
> > unwanted services and whether services are enabled after the respective
> > package is installed long after the system has been installed.
>
> I think multipath is the only service enabled by Anaconda. Everything
> else depends on the package doing so.
This does not mean that this is a good way or the only way to do this.
No, but it does mean that what you're proposing would involve adding
functionality to Anaconda. The current situation is that the services
that are started when the respective package is installed and the
services that are enabled by default by the Fedora installer *are* the
same.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
4:13 p.m.
On Sun, Feb 27, 2011 at 07:21:30PM +0000, Matthew Garrett wrote:
On Sun, Feb 27, 2011 at 04:33:56PM +0100, Till Maas wrote:
> On Fri, Feb 25, 2011 at 07:00:20PM +0000, Matthew Garrett wrote:
> > On Fri, Feb 25, 2011 at 07:30:34PM +0100, Till Maas wrote:
> >
> > > The services that are started when the respective package is installed
> > > and the services that are enabled by default by the Fedora installer do
> > > not need to be the same and are afaik currently not the same. There is
> > > imho a huge difference, whether services are enabled during
> > > installation, because afterwards one can usually expect that there are
> > > unwanted services and whether services are enabled after the respective
> > > package is installed long after the system has been installed.
> >
> > I think multipath is the only service enabled by Anaconda. Everything
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > else depends on the package doing so.
>
> This does not mean that this is a good way or the only way to do this.
No, but it does mean that what you're proposing would involve adding
functionality to Anaconda. The current situation is that the services
that are started when the respective package is installed and the
services that are enabled by default by the Fedora installer *are* the
same.
You wrote that Anaconda already has the code to active services, so
there is no additional functionality needed. Only the list of services
to be enabled needs to be extended. Nevertheless, this is a lot cleaner
solution that having to recommend to users of Fedora to not install
packages on systems on a network or with non-admin users logged in to
avoid potential security risks because services might activate
themselves.
Btw. it is also possible to move the initial activation of services into
a single package that actives the respective services once after
installation, so no changes to the Anaconda code is even required.
People who want a secure system can then just deselect it. It could work
like the firstboot package.
Btw. in case someone with yum plugin writing skills reads this: Is it
possible with a yum plugin that manipulates rpm scriptlets, e.g. one
that makes sure that no rpm can enable a service using "service foo on"?
Regards
Till
8:03 a.m.
On Sun, Feb 27, 2011 at 11:13:44PM +0100, Till Maas wrote:
On Sun, Feb 27, 2011 at 07:21:30PM +0000, Matthew Garrett wrote:
> No, but it does mean that what you're proposing would involve adding
> functionality to Anaconda. The current situation is that the services
> that are started when the respective package is installed and the
> services that are enabled by default by the Fedora installer *are* the
> same.
You wrote that Anaconda already has the code to active services, so
there is no additional functionality needed. Only the list of services
to be enabled needs to be extended.
Anaconda obviously has the code to activate services, given that you can
do so with Kickstart. But there's no mechanism for a set of packages to
be provided in order to allow a per-spin set of defaults. You'd need to
write code for parsing a configuration file of some description and
you'd need to provide a way to get those files into each spin's Anaconda
image. The multipathd case is one that's explicitly special-cased in the
storage code.
Nevertheless, this is a lot cleaner solution that having to recommend
to users of Fedora to not install packages on systems on a network or
with non-admin users logged in to avoid potential security risks
because services might activate themselves.
What's the policy you actually want here? If it's "Services shouldn't
start by default" then your solution obviously satisfies that, but if
it's "Packages should not install anything that runs with elevated
privileges unless the user explicitly enables them" then it doesn't.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
11:41 a.m.
On Mon, Feb 28, 2011 at 02:03:26PM +0000, Matthew Garrett wrote:
On Sun, Feb 27, 2011 at 11:13:44PM +0100, Till Maas wrote:
> On Sun, Feb 27, 2011 at 07:21:30PM +0000, Matthew Garrett wrote:
> > No, but it does mean that what you're proposing would involve adding
> > functionality to Anaconda. The current situation is that the services
> > that are started when the respective package is installed and the
> > services that are enabled by default by the Fedora installer *are* the
> > same.
>
> You wrote that Anaconda already has the code to active services, so
> there is no additional functionality needed. Only the list of services
> to be enabled needs to be extended.
Anaconda obviously has the code to activate services, given that you can
do so with Kickstart. But there's no mechanism for a set of packages to
be provided in order to allow a per-spin set of defaults. You'd need to
write code for parsing a configuration file of some description and
you'd need to provide a way to get those files into each spin's Anaconda
image. The multipathd case is one that's explicitly special-cased in the
storage code.
Afaik the spins are usually live images and use a kickstart file to
enable services. The services that are enabled after the installation
from a live images are afaik the same that are started when the live
image is booted. Therefore the configuration can take place in the
kickstart file that is used to create the live image. I am not sure
whether there are different spins that are not based on live images.
> Nevertheless, this is a lot cleaner solution that having to
recommend
> to users of Fedora to not install packages on systems on a network or
> with non-admin users logged in to avoid potential security risks
> because services might activate themselves.
What's the policy you actually want here? If it's "Services shouldn't
start by default" then your solution obviously satisfies that, but if
it's "Packages should not install anything that runs with elevated
privileges unless the user explicitly enables them" then it doesn't.
Since we are discussing about services here, my proposal regards only
services. Nevertheless I would also like for cron jobs not to be
installed automatically with a package etc. Or what is the other
behaviour you are referring to? I guess in an optimal case yum would ask
users after a service or cron job has been installed, whether it should
be activated. And there were default settings for systems. Then a
unexperienced Desktop user can use the defaults the Desktop SIG
considers to be good, but advanced users can use their own or answer the
questions to yum manually.
Regards
Till
2:46 p.m.
On Fri, Feb 25, 2011 at 06:22:25PM +0000, Matthew Garrett wrote:
On Fri, Feb 25, 2011 at 09:46:08AM -0800, Toshio Kuratomi wrote:
> On Thu, Feb 24, 2011 at 06:32:44PM +0000, Matthew Garrett wrote:
> > There are no essential services, which means any proposal that contains
> > the phrase "non-essential services" is already unimplementable.
> >
> You've said this many times and it seems that you do it to be
> obstructionist. The constructive way to deal with this is to start making
> a list of what people really mean by "essential" and then propose
alternate
> words to use.
Like Jesse said, my objection here is that using the word "essential"
just results in us being doomed to argue over what "essential" means.
A literal interpretation of "essential" means "start init and have it
launch a getty". I don't think anyone's advocating that that be the
outcome of a vanilla Fedora install. An alternative would be "Essential
for a traditional UNIX experience", which would seem to preclude dbus. I
don't think that's a rational outcome either. So we end up with
"Essential for providing an experience consistent with what we feel a
vanilla Fedora install should provide", which means you haven't actually
defined "essential" at all. So don't say "essential". Say what
you mean.
> I think, by essential, some people mean:
>
> start the bare minimum so I don't have to start any additional services to:
>
> ... I don't want anything but init and a shell [*]
> ... log into a getty
> ... log in over the network
> ... log into a desktop
> ... do any client-side operations
That's my point. If people have different interpretations of "essential"
then any policy using the word "essential" is meaningless. You need to
define "essential" - and if you're doing that then you don't need to
use
the word in the first place.
And my point is that instead of telling people "there are no essential
survices" and therefore jsut leading people to argue about the meaning of
a word, it's much more helpful to try to figure out these definitions that
they are using the word to mean and then, if the word still bothers you,
assign a different word then essential to it.
-Toshio
9:59 a.m.
On Thu, 24.02.11 09:44, Colin Walters (walters(a)verbum.org) wrote:
On Wed, Feb 23, 2011 at 1:56 PM, Kevin Fenzi <kevin(a)scrye.com>
wrote:
> Greetings.
>
> FESCo is looking at the question of what services can start by default
> (ie, you install something and it's set to start automatically next
> time you boot up).
Honestly I think it'd be conceptually a lot simpler if all services
didn't start on RPM installation, period. Specific ones that we want
enabled by default in a desktop install could simply be turned on in
the kickstart file.
Something like the attached patch (obviously incomplete, and not tested):
I think I agree with this. Information about enabling a service is not a
distro-global decision. It depends on the profile you install.
However, this does leave the question about bus services open. Would
this mean we turn all bus activatable services off by default, too?
udisks? upower and friends?
Lennart
--
Lennart Poettering - Red Hat, Inc.
4:11 p.m.
On 24/02/11 15:44, Colin Walters wrote:
On Wed, Feb 23, 2011 at 1:56 PM, Kevin Fenzi<kevin(a)scrye.com>
wrote:
> Greetings.
>
> FESCo is looking at the question of what services can start by default
> (ie, you install something and it's set to start automatically next
> time you boot up).
Honestly I think it'd be conceptually a lot simpler if all services
didn't start on RPM installation, period. Specific ones that we want
enabled by default in a desktop install could simply be turned on in
the kickstart file.
Please start systemd automatically.
Something like the attached patch (obviously incomplete, and not tested):
4804
days inactive
4809
days old
56 comments
21 participants
participants (21)
-
Adam Williamson -
Andreas Schwab -
Bill Nottingham -
Casey Dahlin -
Chris Lumens -
Colin Walters -
Garrett Holmstrom -
Genes MailLists -
Ian Pilcher -
Jesse Keating -
Jóhann B. Guðmundsson -
Kevin Fenzi -
Larry Vaden -
Lennart Poettering -
Matthew Garrett -
Michał Piotrowski -
nodata -
Peter Robinson -
Till Maas -
Tim Waugh -
Toshio Kuratomi