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@xxxxxxxxxx
"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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
