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 --->
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 *****
- 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.
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).
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?
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... :)
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 -->
- 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)
- 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 ;-).
- 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.
- 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++.
- 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