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 )....
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 ).
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
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 )
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...
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*.
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..
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.
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.
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, ...
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.
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.
Thanks,
Martin
<-- snip --->
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
