Bug 259304

Summary: yast doesn't start firewall when set for manual start
Product: [openSUSE] openSUSE 10.3 Reporter: Chuck Morrison <chuck.morrison>
Component: YaST2Assignee: Lukas Ocilka <locilka>
Status: RESOLVED FIXED QA Contact: Jiri Srain <jsrain>
Severity: Enhancement    
Priority: P5 - None CC: asadeghpour, gp, jeanne.colon-bonet, michael.raskey, scott
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: Other   
Whiteboard:
Found By: Corporate Interoperability Test Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Chuck Morrison 2007-03-30 14:32:44 UTC
This test was performed on an HP Integrity (ia64) system.

Conditions:
1) in a console session (not X)
2) yast started and in "Security and Users"->Firewall->Start-Up section
3) firewall set for Service start -> manual (not "When booting")
4) select [Start Firewall Now] and hit <Enter>, It appears to have started and gives the only option as [Stop Firewall Now].
5) select <Next>, <Accept>, and <quit>

6) type "iptables -L" at the CLI, the results show no firewall rules in place.

7) re-enter yast, ->"Security and Users"->Firewall->Start-Up section
8) yast shows the firewall NOT running (which is true, it's not)
9) select Service start -> "When booting"
10) select [Start Firewall Now] and hit <Enter>, It appears to have started and gives the only option as [Stop Firewall Now].
11) select <Next>, <Accept>, and <quit>

12) type "iptables -L" at the CLI, the results show MANY firewall rules in place.

Stop the firewall and Repeat steps 1-6 above to verify
Comment 1 Lukas Ocilka 2007-03-30 17:29:32 UTC
3) You have selected to start firewall manually

4) Firewall is started at that point

5) Summary says that firewall will be stopped after configuration is written

9) You have selected to start firewall on boot

10) Firewall is started at that point

11) Summary says that firewall will be started after configuration gets written

For most of users, it only makes sense to have the firewall stopped / started according the start manually / when booting. Actually, I'm thinking about removing start/stop buttons completely from that dialog... they are there just for tuning the configuration.
Comment 2 Lukas Ocilka 2007-03-30 21:06:59 UTC
Anyway, if you had any better idea - a simple one, working for all possible cases - I'd definitely appreciate it. YaST should be constantly moving forward to be more understandable by it's users and I have to admit that the current solution is sometimes a bit confusing.

Please, fell free to reopen the bug in such case.
Comment 3 Chuck Morrison 2007-04-02 14:08:25 UTC
I guess my take on this is quite different. Yast is the preferred administration tool for SLES and it seems like the functionality for starting the firewall is rather basic. Yes, it's primarily for tuning the config, but it's while configuring the firewall that a user would logically select "manual" instead of "when booting" and then proceed to start and stop the firewall repeatedly (via yast). Otherwise it's CLI and mastering IPTables syntax.

I don't think removing the ability to start and stop the firewall via yast (reducing yast's functionality) is a great idea.

As far as a simple solution, starting the firewall works if "When booting" is selected, so it's obvious the functionality exists in yast. At worst, a simple cut and paste should add this functionality to the "manually" selection as well.
Comment 4 Lukas Ocilka 2007-04-03 13:29:02 UTC
As I can see, the current behavior cannot be understood well despite having the summary about enabling/starting the service.

The current solution: Enable / Start firewall vs. Disable / Stop firewall. If user enables the firewall (when booting) it's also started after writing the configuration. Disabling (manually) also stops the firewall after the configuration is written. The behavior is better than was because of undefined states (explained later). Moreover, the current behavior cannot be changed for SP1 as we are in RC phase. Manual starting/stopping expects calling `rcSuSEfirewall2 stop/start`.

Moving to the openSUSE 10.3 (+ SLE 11).

The firewall service has (at least) two aspects that need to be considered. That's why we have (at least) four possible initial states.

Firewall is enabled: yes/no (when booting/manually)
Firewall is started: yes/no (running/not running)

Additionally, the firewall state can be changed by user when configuring:
Firewall is enabled: changed from yes to no and vice versa
Firewall is started: can be started or stopped manually

Almost everything is simply solvable but one issue: disabling the firewall (changing from 'when booting' to 'manually'). According to some users, in this case, firewall should be stopped after writing the configuration. On the other hand a quite big group of users thinks that if such change is made, manually means: do not touch it, I'll start/stop it by myself manually (as it was selected).

The current solution simplifies getting rid of such problems by writing that summary line about starting or stopping the firewall. Simplicity is more important than the fact that some expert users might have problems with it however they just need to read.

I'll explain more about a new solution (and current problems) in the very next comment.
Comment 5 Lukas Ocilka 2007-04-04 08:27:11 UTC
I have here a table of possible states in which a firewall can operate. Some of them could be merged into one by using variables. Anyway, just to present the pieces of information with which the YaST firewall needs to work:
- There is the initial state of a firewall: enabled/disabled*
- And another initial state: running/not running
- User can enable/disable the firewall in UI*
- User can start/stop the firewall in UI
- Firewall can be enabled/disabled at the end*
- Firewall can be running/stopped at the end

* enabled/disabled means that it starts automatically at the boot process, disabled means "Manually" in UI.

Without user's help (question), we sometimes just can't know what to do. User might want to disable the firewall (or leave it disabled) while he/she wants to leave it running. To be honest, this has been discussed many times before and despite the fact that firewall isn't the only one service that has exactly the current behavior, it is the only reported case in bugzilla.

Never mind, ... so how to solve that?

Radio buttons:
  (*) When booting
  ( ) Manually
don't fit to a situation when a common user wants to simply disable the firewall. 

However, if I only change them to:
  (*) Enable firewall
  ( ) Disable firewall
it wouldn't work for experts with their manual setup.

Let's forget now, that manual setup (manual start) doesn't make much sense in a desktop or even server environment. Maybe if experts call `rcSuSEfirewall2 start` from some (another) starting script but what's the point?

That's why I've decided to rename these radio buttons to:
  (*) Enable firewall automatic starting
  ( ) Disable firewall automatic starting
(or something similar using a proper English ;))

Additionally, a new functionality has been added:
1.) Unless the enable/disable is changed by user in that dialog, no status change is proposed for the currently running/stopped service.
2.) If user selects to "Enable firewall...", it's also proposed to be started after the configuration is written.
3.) If user selects to "Disable firewall...", user is asked whether he/she wants to stop the firewall after the configuration is written (default "yes, stop it").
4.) Text about stopping or starting the firewall service uses a bold text in a summary.

This new solution cannot be added into SLES10 SP1. The right product is openSUSE 10.3 where it should prove its correctness or escalate into discussion about another, better, solution that would appear in SLES11 (after oS 10.3).

This is a part of the yast2-firewall changes file:
--- cut ---
- A brand new and better revolutionary solution has been worked out
  for a firewall service starting/stopping and enabling/disabling
  in order to maximize user understanding and minimize errors
  (#259304).
- yast2-firewall-2.15.5
--- cut ---

Closing as FIXED
Comment 6 Lukas Ocilka 2007-04-19 14:28:40 UTC
*** Bug 265439 has been marked as a duplicate of this bug. ***