User enhancement feature's request for Fedora Core 9'ish

[Nils Philippsen]

On Sat, 2007-09-15 at 00:11 +0000, Jóhann B. Guðmundsson wrote:
> While we cant agree on what should be and should not be loaded and during
> install adding an new advanced user feature to Anaconda/kickstart where
> advanced user can choose IPv4 or IPv6 and which services will start after
> installation should address these issues until concrete solution is
> formed..
> 
> ***** System-Config-Services-Gui *****
> 
> 1. Allow user to bind the service to certain interface or IP
>    # New / not discussed.. ( Advanced user feature maybe )....

That's something for configuration tool of the specific service, not
system-config-services.

> 2. Check if firewall has been opened for service ( when enabled or started )
>     if not notify the user ( and possible fail to start ) which port to open
>     and open System-Config-Security, Ask the user to re-enable the service.
>     ( check again until he gets it right or just one time if we don't want
>     to *spam* the user with messages )
> 
>    For this to work more user predefined port options need to be added to
>    System-Config-Security  # already have filed an RFE for that
>    Advanced user need to be able to disable this both in
>    System-Config-Services ( Advanced user maybe want to be just notified
>    or disable this feature )and  System-Config-Security
>    ( not to mess with custom firewall rules ).

Please let's not get this overboard. The system-config-services tool is
to start/stop services and to specify under which circumstances they
should be started/stopped automatically. System-config-securitylevel (or
in the future system-config-firewall) is the tool to change firewall
rules. System-config-<something> is for configuring <something>, among
that which IPs/ports it should bind (if that's configurable anyway).

> 3.   Notify the user about SElinux issues maybe to? # New / Not discussed..
> 
>    There is also the question if other apps should notify  user the same
>    way.. ( Bittorrent, NetworkManager ( vpn ) etc.. ) # New / Not discussed

setroubleshoot anyone?

> 4.  Notify the user of possible  chain reaction if  he disabled a service,
>     let's say user decides to disable service A and service b and c strictly
>     depended on # Somewhat  discussed
>     ( IPv6, ipv6iptables would fit in here  )
> 
>      service A, the user receives warning and those services ( b and c )
>      are turned off, or user just notified, or even yet those services just
>      are turned off as well. ( User receives no message )

That's pretty much dependent on that services define on which other
services they depend on, possibly in the course of a revamped init
scheme.

> Warning the following suggestion may cause sun burn so put on your
> sunblock to protect you from the heat... :)
> 
> 5.  Renaming some services to more *user friendly* names.
>    ( cups to printer service for example ).  # Somewhat discussed
> 
>       I personally stay neutral on this issue, ( I see both sites on this
> one... )
> 
>      * All together rename a service .   (  suggest  a  new name  for
>       service  --> name  sent upstream --> upstream approves ( unlikely )
>        --> package(s) renamed --> service renamed )
>      * Alias in System-Config-Services.  ( Could cause some confusion if
>        user ever had to deal with it outside X )..
>      * Info given to user when the mouse pointer is over the service.
>      * Put this one under the rug...

If services use a uniform way to announce their generic name, I'm game
for adding tooltips for that.

> To achieve the user notifier we need to use something that we already have
> ( ideas any one ) or create a new *x-to-system-to-x-to-user msg*.

If the services file in e.g. /etc/init.d contains the generic name, we
could do with something less complicated ;-).

> I think regarding S-C-S point 2 we can all agree that that's the best
> way to do it security/user friendly wise..

No :-P. Firewalls -- like SELinux -- are mandatory access control
systems and tools like system-config-services are NOT the place to
second-guess them. I'll point back to my description of s-c-services'
purpose above.

> Best regards.
>           Johann B.
> 
> Ps. Good summarization from  Martin Sourada regarding some of those
> issues
> in previously threads..
> 
> <-- snip -->
> 
> 1. redefine the default set of services. Should be runlevel dependent
> and it should include only the services that are crucial to
> non-problematic run on every machine and that provide good user
> experience as well (like automounting CD's)
> 
> 2. add support for automatically turning on services dependant on
> hardware. If you plug in bluetooth, HAL detects it and turn on the
> bluetooth services. Should be however handled in a way where user can
> have control over the service if (s)he want. That would mean that we
> would need three states for such a service: turned off by default,
> turned on by default, automatic.

Services activated by DBUS events. I've already heard that
somewhere ;-).

> 3. Improve the system-config-services. Its great tool and has great
> potential but its confusing at first look. We need to provide to each
> service such a description *AND* name that everyone (well, I exaggerate
> here a little...) will understand it.

The most confusing thing at the moment is the tabbed distinction between
long-running daemons and xinetd-started services. That's on my list of
things to change.

> 4. Some services that require a change of firewall rules to run
> correctly should offer such a change (but not do the change
> automatically, sometimes you want to have specific rules for the
> firewall, like opening ports only to specific IPs). These are mostly
> server services like sendmail, postfix, vsftpd, ...

This could be put in the config tool of the respective service,
s-c-firewall could offer widgets/modules that other config tools could
use for that. Just as well as s-c-services should offer widgets/modules
to enable/disable/start/stop a service from its own config tool. Plan++.

> 5. Would be good if we provide gui utilities for easy (and only basic)
> configuration of services that has configuration capabilities. Should be
> accessible from system-config-services.

If there's an easy way to map service -> config tool, I could let
s-c-services offer a "Configure ..." button rather easily.

> I hope this list makes sense, I think I learned a lot in this particular
> thread... We could maybe, if the changes are desirable and sane, add
> this on the F9 feature list.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011