Bug 249204 (SCServicesUI)

I have suggestions:

A) Make it possible to turn services on/off by GROUP, so for example
group:
* Networked file systems = netfs, nfs, nfslock, rpcgssd, rpcidmapd, rpcsvcgssd,
(rpcbind??), winbind, 
* Directory services = nscd, ypbind
* Printing = cups (hint, if you're not printing from this machine, turn
  this OFF.
* SELinux = mctrans, restorecond, setroubleshoot, 
* SW RAID = mdmonitor (hint turn off if you're not using SW RAID, why
  the hell is it default on again??)
* Bittorrent = btseed, bttrack
* Bluetooth = bluetooth, pand
* Sendmail = sendmail (hint, not many users need this, perhaps they need
  a chance to be reminded to turn it off)
* Necessary services = messahebus, haldaemon etc, you're gonna get trouble 
  if you try to shut these off. HIDE THEM until requested visible.
  BIG FAT WARNING if user try to disable these.

B) Make it possible to turn on/off such a group across ALL runlevels,
they are simply identical most of the time anyway.

C) At "firstboot" or even in anaconda (wherever such things as SELinux and
directory services are set) offer to disable the SELinux daemons if the users
chooses to deactivate SELinux, because currently it's not! Same thing for: 
*Are you going to mount networked filesystems on this machine? (Hint, it's a
laptop, perhaps you don't want this.)
*Directory services
*Is the user really using software RAID?
*Do you really need bluetooth services on this machine etc.
Little helpful things like that needed to cut off a number of unneccessary
daemons taking up memory and bootspeed for no good reason.

D) Power users that need all the stuff configurable and working in corporate
environments could perhaps be offered an "advanced view" of the services. But to
my best knowledge they prefer to hack the text files. (Perhaps they use
kickstart for setting up clients in the end, that things I don't know.)

This hides a fair part of complexity.

(In reply to comment #1)
> I have suggestions:

These would fit better in their own RFEs, but I'll answer some things here:

> A) Make it possible to turn services on/off by GROUP, so for example
> group:
> * Networked file systems = netfs, nfs, nfslock, rpcgssd, rpcidmapd, rpcsvcgssd,
> (rpcbind??), winbind,

Usually these services shouldn't be treated alike. Think NFS client vs. server,
think using Kerberos vs. not using it. Rpcbind (ex. portmap) is used for more
things than NFS.
 
> * Directory services = nscd, ypbind

Same here. Usually you don't use LDAP and NIS on the same machine.

> * Printing = cups (hint, if you're not printing from this machine, turn
>   this OFF.

That's just using a different name. It would surely help to have "screen names"
for the services, e.g. "NFS server" instead of plain "nfs", or comments. Well,
there are comments, but these could contain such hints and they (as well as
screen names) would have to translated. There'd need to be infrastructure for this.

> * SELinux = mctrans, restorecond, setroubleshoot, 

These also have different objectives and it can't be assumed that they'd be
turned on/off together (then they could be one service ;-).

> * SW RAID = mdmonitor (hint turn off if you're not using SW RAID, why
>   the hell is it default on again??)

"Screen name" vs. plain name again. The defaults aren't the fault of
system-config-services but of the respective packages ;-).

> * Bittorrent = btseed, bttrack
> * Bluetooth = bluetooth, pand

Ditto for different objectives.

> * Sendmail = sendmail (hint, not many users need this, perhaps they need
>   a chance to be reminded to turn it off)

Name change, hint: as above.

> * Necessary services = messahebus, haldaemon etc, you're gonna get trouble 
>   if you try to shut these off. HIDE THEM until requested visible.
>   BIG FAT WARNING if user try to disable these.

These need "# hide: true" to be added to the chkconfig section of their init files.

> B) Make it possible to turn on/off such a group across ALL runlevels,
> they are simply identical most of the time anyway.

They simply aren't to be treated the same within these groups ;-). I intend to
do something about the runlevel clutter though, so that a user would normally
only enable/disable a service and it would get enabled/disabled for the levels
specified in its init file. I.e. it would do what "chkconfig <service> [on|off]"
would do unless you'd delve into "details" of the service to specify it
individually for the runlevels.

> C) At "firstboot" or even in anaconda (wherever such things as SELinux and
> directory services are set) offer to disable the SELinux daemons if the users
> chooses to deactivate SELinux, because currently it's not! Same thing for: 
> *Are you going to mount networked filesystems on this machine? (Hint, it's a
> laptop, perhaps you don't want this.)
> *Directory services
> *Is the user really using software RAID?
> *Do you really need bluetooth services on this machine etc.
> Little helpful things like that needed to cut off a number of unneccessary
> daemons taking up memory and bootspeed for no good reason.

This doesn't concern system-config-services.

> D) Power users that need all the stuff configurable and working in corporate
> environments could perhaps be offered an "advanced view" of the services. But to
> my best knowledge they prefer to hack the text files. (Perhaps they use
> kickstart for setting up clients in the end, that things I don't know.)

De-cluttering the UI for the normal non-Unix-admin type of user is on my agenda
for system-config-services but I don't think introducing arbitrary groups like
you suggested removes clutter. Currently I only see that this would introduce
one more level of unnecessary indirection, one more click for the user to do
before he gets where he wants to get.

Based on the date this bug was created, it appears to have been reported
during the development of Fedora 8. In order to refocus our efforts as
a project we are changing the version of this bug to '8'.

If this bug still exists in rawhide, please change the version back to
rawhide.
(If you're unable to change the bug's version, add a comment to the bug
and someone will change it for you.)

Thanks for your help and we apologize for the interruption.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

The UI should be mostly uncluttered in F-9, i.e. system-config-services-0.99.x
and later.