Default services enabled

[Simo Sorce]

On Tue, 2011-08-23 at 16:57 +0200, Lennart Poettering wrote:
> On Tue, 23.08.11 07:29, Toshio Kuratomi (a.badger at gmail.com) wrote:
> 
> > > > I think FESCo needs to decide what its policies are wrt on-demand
> > > > loading, then we can adjust the Packaging Guidelines appropriately.
> > > 
> > > This is broken IMO ... there is nothing inherently wrong with on
> > > demand loading ... actually it is the opposite. (i.e should be done
> > > whenever possible).
> > >
> > On demand loading is great.  But the system administrator needs to have
> > control to be able to turn things on and off.  So we need Lennart to give us
> > information on how to do that.  
> 
> The same way as for services basically. [Install] sections are used for
> all kinds of unit files, not just services.
> 
> > Lennart also needs to give us information on how to write .socket
> > files.
> 
> This is probably more of an upstream issue. Writing unit files
> downstream is probably not really needed, since socket activation needs
> some kind of upstream support.
> 
> > With those in hand, guidelines would and fesco
> > would be able to ship with on-demand-loading that was off by default (does
> > nt load at all) but the system administrator would be able to enable the
> > service so that it would start to load on-demand rather than at boot.
> 
> Hmm? Not sure I can parse your paragraph, but I think we really should
> be loading seldom used services by default via socket/device activation,
> not on boot. Examples for these services are SSH and CUPS.
> 
> I am pretty sure that 95% of everybody who has ssd or CUPS installed
> will not use it more often than than 1/h, which is really seldom. Hence
> I'd make these services socket activated by default (like MacOS does it
> too), and for the 5% of machines which use it more often we make it easy
> to spawn the daemons on boot. The default should be to make it nice for
> 95% of people. The 5% who want to run it unconditionally are probably
> knowleadgable admins anyway.

Any chance systemd upstream or Fedora at least will provide a
chkconfig-like tool that can give you a very simple intuitive way to
completely disable/enable/enable(forced on at boot)/etc... each service
in the system ?

Systemd unit files are cool and all, but they are also much more
difficult to keep track of for admins. With the previous system
chkconfig --list gave you an immediate *concise* clear view of the
system configuration wrt initialization. Something like that would
really be welcome for systemd. Esp when a service has multiple files
that need to be changed/unliked/linked at the same time. A tool like
that would also show/point out if an action breaks dependencies with a
verbose mode view or something.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York