Tumbleweed update

What about this?

Problem: SuSEfirewall2-3.6.378-2.1.noarch conflicts with firewalld provided by firewalld-0.5.1-1.1.noarch
 Solution 1: Following actions will be done:
  deinstallation of firewalld-0.5.1-1.1.noarch
  deinstallation of firewalld-lang-0.5.1-1.1.noarch
 Solution 2: deinstallation of SuSEfirewall2-3.6.378-1.1.noarch
 Solution 3: keep obsolete SuSEfirewall2-3.6.378-1.1.noarch

The following product is going to be upgraded:
openSUSE Tumbleweed 20180311-0 -> 20180312-0

firewalld has replaced SuSEfirewall2 so select 2, or 3 if you are not sure.

If you don’t use the default configuration you should use yast to set up firewalld, or at least review the settings.

Use the yast services manager to make sure SuSEfirewall2 services are stopped and disabled, and that firewalld is enabled and started.

When everything looks good you can use yast to find all SuSEfirewall2 installed packages and remove them.

SuSEfirewall2 has become obsolete and replaced with firewalld. Choose option 2.

I went with option 2 when I saw that. But I know there was a move toward replacing SuSEFirewall2 with firewalld, so it seemed the sensible option.

Thanks all, i did not now that…:\

GJ

It’s a bug! See this Factory ML thread refers and the last post from the maintainer of the packages.

PS. AFAIK they were to be run in parallel.

It seems to be more an argument than a bug. And the argument is not yet settled.

There are some strnage things going on with the firewall in TW. I don’t believe this is all clear in the open what’s going on here. You can’t have both firewalls running.

For example firewalld can’t be configured from CLI-YaST. Take care to allow all necessary services in firewalld. Otherwise you might end up locked-out (if machine managed headless, had that yesterday…)

Argument about what exactly? I’ll let you worry about that on the ML. :wink:

IMO such conflicts shouldn’t present to the user at “zypper dup” time, that is the bug. Whatever results hopefully will be resolved before Leap 15’s final release. At least there is a bug report now to focus any arguments or discussions.

Well “run in parallel” may not be achievable, but parallel availability - yes, at least as mutually exclusive services.

My understanding is that both could be installed, but only one of them could be allowed to run.

Apparently someone decided that this conflict could be avoided by creating a package conflict (so that only one could be installed). And there seems to be a disagreement as to whether that was an appropriate way to solve the problem.

This is what I gather from reading the bug report and the mailing list messages.

Personally, I’m not too much concerned. Since “firewalld” seems to be the proposed future, I just go with that when there’s a conflict.

Hi
Moving forward it’s firewalld, so just switch and move forward.

Mine also.

In the ML thread I referenced, there is this: “The conversion utility requires both installed… Sounds like a catch22?” (from end of Peter Suetterlin post). A good reason for a bug report, I thought on reading it and what followed. I see no disagreement in that thread. On seeing only a couple of early posts there, I decided to postpone the update. Otherwise I would have chosen to keep the old firewall going, pending a clearer understanding of the replacement in my case. Whether Solution 2 or 3 goes to personal choice, available info, and circumstances.

Apparently someone decided that this conflict could be avoided by creating a package conflict (so that only one could be installed). And there seems to be a disagreement as to whether that was an appropriate way to solve the problem.

The maintainer decided to create the package conflict, but did apologize later in that ML thread. I guess he was motivated by damage limitation, and I suspect issues lie with the conversion utility.

just a note.

firewalld is a very nice piece of software, much better than susefirewall2. For basic users i would not recommend using the conversion script. it appears to simply copy over the port settings, which for a service like kde connect can be dozens. If you set up firewalld from scratch you can allocate, monitor and control as a named service. A good tutorial to get up to speed is the following.

https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-firewalld-on-centos-7