Bug 249204 - (SCServicesUI) the UI sucks
the UI sucks
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: system-config-services (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Nils Philippsen
Fedora Extras Quality Assurance
bzcl34nup
:
Depends On:
Blocks: 249201
  Show dependency treegraph
 
Reported: 2007-07-22 12:01 EDT by Nils Philippsen
Modified: 2009-09-21 17:46 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-04 11:06:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nils Philippsen 2007-07-22 12:01:58 EDT
the UI is too complicated (daemons vs. xinetd services) and needs to be simplified
Comment 1 Linus Walleij 2007-12-30 16:30:42 EST
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.
Comment 2 Nils Philippsen 2007-12-31 07:38:17 EST
(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.
Comment 3 Bug Zapper 2008-04-04 09:25:42 EDT
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.
Comment 4 Nils Philippsen 2008-04-04 11:06:32 EDT
The UI should be mostly uncluttered in F-9, i.e. system-config-services-0.99.x
and later.

Note You need to log in before you can comment on or make changes to this bug.