Services that can start by default policy feedback
walters at verbum.org
Thu Feb 24 15:25:25 UTC 2011
On Thu, Feb 24, 2011 at 10:04 AM, Matthew Garrett <mjg59 at 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 at 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
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
More information about the devel