Bugzilla – Bug 1114673
New UI for firewalld: interface not assigned to the right zone when changed to public in first run
Last modified: 2023-03-07 17:31:04 UTC
Interface is not assigned to the right zone after following steps: - Open new UI for firewalld: yast2 firewall - Assign interface to different zone (for example public) - In Zones, set different zone (for example trusted) as default. - Accept - Check with firewall-cmd interface assignation: firewall-cmd --list-interfaces --zone=public | grep ens4 (is not there) but firewall-cmd --list-interfaces --zone=trusted | grep ens4 (it succeeds and it is pointing to the default zone not the one that was assigned) (same result also after trying a firewall-cmd --reload) Assignation works in general, but in this combination and just when the user enters first to this screen and set previous steps, does not work (perhaps some wrong initialization). Expected result: Point to the interface that is assigned in the UI (in the example, to public)
Could you please add y2logs ? https://en.opensuse.org/openSUSE:Report_a_YaST_bug#I_reported_a_YaST2_bug.2C_and_now_I_am_asked_to_.22attach_y2logs.22._What_does_that_mean.2C_and_how_do_I_do_that.3F
You can see the whole sequence of action in this job now in prod: https://openqa.opensuse.org/tests/789887#step/yast2_firewall/66 In the meantime I will recover the logs manually.
This logs should contains info requested: https://openqa.suse.de/tests/2262677/file/yast2_lang-y2logs_clone.tar.bz2. You can ignore the modules failing in this job. Before failing in yast2_lang is running yast2_firewall and yast2_hostname.
Added a card to the YaST trello task board so that the issue is prioritised with all other tasks.
Hm, I have tested it with sles12-sp1 too and there it is working. The only difference here is that we have interface eth0. I can reproduce that bug with TW AND the latest packages of master. It seems that ens? is every time assigned to the defined default zone and not by the manual selected zone in the UI.
Schubi, I guess sle12-sp1 was expected to be sle15-sp1, right? sle-12 still uses SuSEfirewall2, sle 15 uses firewalld.
The setting will be written correctly in permanent mode. E.g.: firewall-cmd --permanent --list-interfaces --zone=public returns the correct value. But the have not been done in the running mode. Either we also call the write command without the --permanent mode or we have to restart the firewalld service (reload does not help here). While writing the settings I can only see: "systemctl show firewalld.service" but no restart.
(In reply to Lukas Ocilka from comment #6) > Schubi, I guess sle12-sp1 was expected to be sle15-sp1, right? > sle-12 still uses SuSEfirewall2, sle 15 uses firewalld. Yes, you are right. You know, sometimes I am "old fashioned" :-)
(In reply to Joaquín Rivera from comment #0) > and it is pointing to the default zone not the one that was assigned) (same > result also after trying a firewall-cmd --reload) From the man page: Note: Runtime changes applied via the direct interface are not affected and will therefore stay in place until firewalld daemon is restarted completely.
Fixed: https://github.com/yast/yast-firewall/pull/113
(In reply to Stefan Schubert from comment #7) > The setting will be written correctly in permanent mode. > E.g.: firewall-cmd --permanent --list-interfaces --zone=public > returns the correct value. But the have not been done in the running mode. > Either we also call the write command without the --permanent mode or we > have to > restart the firewalld service (reload does not help here). Well, the reload should work although there was a bug in firewalld which was not reflecting the changes: https://bugzilla.opensuse.org/show_bug.cgi?id=1112008 > While writing the settings I can only see: > "systemctl show firewalld.service" but no restart.
For SLE15SP1 is fixed: https://openqa.suse.de/tests/2397917#step/yast2_firewall/90 But for Leap we can still see the problem: https://openqa.opensuse.org/tests/836155#step/yast2_firewall/86
(In reply to Joaquín Rivera from comment #12) > For SLE15SP1 is fixed: > https://openqa.suse.de/tests/2397917#step/yast2_firewall/90 > But for Leap we can still see the problem: > https://openqa.opensuse.org/tests/836155#step/yast2_firewall/86 That test still uses yast2-firewall-4.1.8 So basically once the build ships with this request https://build.opensuse.org/request/show/667764 it will also pass the test.
I checked leap and sle15sp1 and it is fixed. Thanks! I'm going to reopen the bug only for TW: https://openqa.opensuse.org/tests/latest?arch=x86_64&flavor=DVD&distri=opensuse&version=Tumbleweed&test=yast2_gui&machine=64bit#step/yast2_firewall/85 (ens4 should be in public zone)
(In reply to Joaquín Rivera from comment #15) > I checked leap and sle15sp1 and it is fixed. Thanks! > I'm going to reopen the bug only for TW: > https://openqa.opensuse.org/tests/ > latest?arch=x86_64&flavor=DVD&distri=opensuse&version=Tumbleweed&test=yast2_g > ui&machine=64bit#step/yast2_firewall/85 (ens4 should be in public zone) Makes it really sense to reopen the bug ? The fix should go automatically to opensuse. I think a bug should be closed if it has been fixed. Otherwise the YAST team looses the overview about bugs which still has to be fixed.
Probably not, you're right, it might be fix and for some reason it didn't arrive to TW. I should just state that the verification failed. Thanks for the reminder of the process. @Knut, any idea why TW didn't get yet? thanks.
In y2logs in rpm-qa I can see the version yast2-firewall-4.1.10-1.1, so it should have hit TW as well.
yast2-firewall-4.1.10-1.2 (openSUSE) openSUSE Tumbleweed Despite that NIC ens4 has been assigned to zone public in the interfaces option, it is not present in the list of interfaces assigned to zone public. https://openqa.opensuse.org/tests/881879#step/yast2_firewall/79 Zone configuration: https://openqa.opensuse.org/tests/881879#step/yast2_firewall/58 Interfaces: https://openqa.opensuse.org/tests/881879#step/yast2_firewall/51 There is an issue with missing "allowed:trusted" widget, also. 2019-03-16 19:42:22 <2> susetest(4790) [ui] YWidget.cc(findWidget):635 THROW: No widget with ID "allowed:trusted" 2019-03-16 19:42:22 <2> susetest(4790) [ui] YCP_UI.cc(ChangeWidget):728 CAUGHT: No widget with ID "allowed:trusted" 2019-03-16 19:42:22 <3> susetest(4790) [libycp] cwm/table.rb:48 UI::ChangeWidget failed: UI::ChangeWidget( `id ("allowed:trusted"), `Items, [] ) 2019-03-16 19:42:22 <2> susetest(4790) [ui] YWidget.cc(findWidget):635 THROW: No widget with ID "allowed:trusted" 2019-03-16 19:42:22 <2> susetest(4790) [ui] YCP_UI.cc(ChangeWidget):728 CAUGHT: No widget with ID "allowed:trusted" 2019-03-16 19:42:22 <3> susetest(4790) [libycp] cwm/table.rb:62 UI::ChangeWidget failed: UI::ChangeWidget( `id ("allowed:trusted"), `SelectedItems, [] ) 2019-03-16 19:43:27 <1> susetest(4790) [Ruby] firewalld/api.rb:198 Executing firewall-cmd with ["--permanent", "--zone=public", "--list-interfaces"] 2019-03-16 19:43:27 <1> susetest(4790) [Ruby] lib/cheetah.rb:158 Executing "firewall-cmd --permanent --zone\=public --list-interfaces". 2019-03-16 19:43:28 <1> susetest(4790) [Ruby] lib/cheetah.rb:206 Standard output: 2019-03-16 19:43:28 <1> susetest(4790) [Ruby] lib/cheetah.rb:178 Status: 0 2019-03-16 19:43:28 <1> susetest(4790) [Ruby] firewalld/api.rb:198 Executing firewall-cmd with ["--permanent", "--zone=public", "--list-interfaces"] 2019-03-16 19:43:28 <1> susetest(4790) [Ruby] lib/cheetah.rb:158 Executing "firewall-cmd --permanent --zone\=public --list-interfaces". 2019-03-16 19:43:28 <1> susetest(4790) [Ruby] lib/cheetah.rb:206 Standard output: 2019-03-16 19:43:28 <1> susetest(4790) [Ruby] lib/cheetah.rb:178 Status: 0 2019-03-16 19:43:28 <1> susetest(4790) [Ruby] firewalld/api.rb:198 Executing firewall-cmd with ["--permanent", "--zone=public", "--change-interface=ens4"] 2019-03-16 19:43:28 <1> susetest(4790) [Ruby] lib/cheetah.rb:158 Executing "firewall-cmd --permanent --zone\=public --change-interface\=ens4". 2019-03-16 19:43:29 <1> susetest(4790) [Ruby] lib/cheetah.rb:206 Standard output: The interface is under control of NetworkManager, setting zone to 'public'. 2019-03-16 19:43:29 <1> susetest(4790) [Ruby] lib/cheetah.rb:206 Standard output: success 2019-03-16 19:43:29 <1> susetest(4790) [Ruby] lib/cheetah.rb:178 Status: 0 2019-03-16 19:43:29 <1> susetest(4790) [Ruby] firewalld/api.rb:198 Executing firewall-cmd with ["--permanent", "--zone=trusted", "--list-services"] 2019-03-16 19:43:29 <1> susetest(4790) [Ruby] lib/cheetah.rb:158 Executing "firewall-cmd --permanent --zone\=trusted --list-services". 2019-03-16 19:43:29 <1> susetest(4790) [Ruby] lib/cheetah.rb:206 Standard output: 2019-03-16 19:43:29 <1> susetest(4790) [Ruby] lib/cheetah.rb:178 Status: 0 2019-03-16 19:43:29 <1> susetest(4790) [Ruby] firewalld/api.rb:198 Executing firewall-cmd with ["--permanent", "--zone=trusted", "--list-services"] 2019-03-16 19:43:29 <1> susetest(4790) [Ruby] lib/cheetah.rb:158 Executing "firewall-cmd --permanent --zone\=trusted --list-services". 2019-03-16 19:43:29 <1> susetest(4790) [Ruby] lib/cheetah.rb:206 Standard output: 2019-03-16 19:43:29 <1> susetest(4790) [Ruby] lib/cheetah.rb:178 Status: 0 2019-03-16 19:43:29 <1> susetest(4790) [Ruby] firewalld/api.rb:198 Executing firewall-cmd with ["--permanent", "--zone=trusted", "--add-service=bitcoin"] 2019-03-16 19:43:29 <1> susetest(4790) [Ruby] lib/cheetah.rb:158 Executing "firewall-cmd --permanent --zone\=trusted --add-service\=bitcoin". 2019-03-16 19:43:30 <1> susetest(4790) [Ruby] lib/cheetah.rb:206 Standard output: success 2019-03-16 19:43:30 <1> susetest(4790) [Ruby] lib/cheetah.rb:178 Status: 0 2019-03-16 19:43:30 <1> susetest(4790) [Ruby] firewalld/api.rb:198 Executing firewall-cmd with ["--permanent", "--zone=trusted", "--list-ports"] 2019-03-16 19:43:30 <1> susetest(4790) [Ruby] lib/cheetah.rb:158 Executing "firewall-cmd --permanent --zone\=trusted --list-ports". 2019-03-16 19:43:30 <1> susetest(4790) [Ruby] lib/cheetah.rb:206 Standard output: 2019-03-16 19:43:30 <1> susetest(4790) [Ruby] lib/cheetah.rb:178 Status: 0 2019-03-16 19:43:30 <1> susetest(4790) [Ruby] firewalld/api.rb:198 Executing firewall-cmd with ["--permanent", "--zone=trusted", "--list-ports"] 2019-03-16 19:43:30 <1> susetest(4790) [Ruby] lib/cheetah.rb:158 Executing "firewall-cmd --permanent --zone\=trusted --list-ports". 2019-03-16 19:43:31 <1> susetest(4790) [Ruby] lib/cheetah.rb:206 Standard output: 2019-03-16 19:43:31 <1> susetest(4790) [Ruby] lib/cheetah.rb:178 Status: 0 2019-03-16 19:43:31 <1> susetest(4790) [Ruby] firewalld/api.rb:198 Executing firewall-cmd with ["--permanent", "--zone=trusted", "--add-port=7777/tcp"] 2019-03-16 19:43:31 <1> susetest(4790) [Ruby] lib/cheetah.rb:158 Executing "firewall-cmd --permanent --zone\=trusted --add-port\=7777/tcp". 2019-03-16 19:43:31 <1> susetest(4790) [Ruby] lib/cheetah.rb:206 Standard output: success 2019-03-16 19:43:31 <1> susetest(4790) [Ruby] lib/cheetah.rb:178 Status: 0 2019-03-16 19:43:31 <1> susetest(4790) [Ruby] firewalld/api.rb:198 Executing firewall-cmd with ["--set-default-zone=trusted"] 2019-03-16 19:43:31 <1> susetest(4790) [Ruby] lib/cheetah.rb:158 Executing "firewall-cmd --set-default-zone\=trusted". 2019-03-16 19:43:31 <1> susetest(4790) [Ruby] lib/cheetah.rb:206 Standard output: success 2019-03-16 19:43:31 <1> susetest(4790) [Ruby] lib/cheetah.rb:178 Status: 0 2019-03-16 19:43:31 <1> susetest(4790) [Ruby] yast2/systemctl.rb:34 systemctl reload firewalld.service 2019-03-16 19:43:31 <1> susetest(4790) [Ruby] yast2/systemctl.rb:34 systemctl show firewalld.service --property=Id --property=MainPID --property=Description --property=LoadState --property=ActiveState --property=SubState --property=UnitFileState --property=FragmentPath --property=CanReload 2019-03-16 19:43:31 <1> susetest(4790) [Ruby] yast2/systemctl.rb:34 systemctl show firewalld.service --property=Id --property=MainPID --property=Description --property=LoadState --property=ActiveState --property=SubState --property=UnitFileState --property=FragmentPath --property=CanReload 2019-03-16 19:43:31 <1> susetest(4790) [Ruby] clients/firewall.rb:73 ret=next 2019-03-16 19:43:31 <1> susetest(4790) [Ruby] clients/firewall.rb:75 Firewall client finished
We still have this issue in TW with version which should contain the patch. Could you please suggest how to proceed?
I have to check if it is a combination of changes that are not done correctly (maybe just some order should be applied) by the API or if it is NM who prevent from doing the changes. Thus, I will check if it is NM specific or also happens with wicked. The scenario seems to be: Before do the zone changes: Network backend: NetworkManager Firewalld state: running Default zone: public Interface: ens4 (no explicit zone) Changes applied through the UI: Default zone: trusted Interface: ens4 (public zone) As a first impression before a deep analysis and debugging it, seems that NM does not apply the change in running because the interface was already in public zone (not explicitly but because it was the default zone).
Created attachment 800788 [details] Change interface zone and default permanently and reload with NM backend (manual changes) I have tested the changes done through the interface and the bug seems to be in firewalld reload. I remember the bug about not updating the ifcfg files, but not sure if this was already reported or duplicate. Michal, could you take a look?
Created attachment 800791 [details] Reload without flush all with NM With FlushAllOnReload=no in (/etc/firewalld/firewalld.conf) it works fine but that was added because of not working in wicked, so seems to be some inconsistency.
@jeriveramoya please take care to always set the "Blocker" flag on bugs that cause openQA tests to fail. Do you think it is possible by now to implement a workaround in the test?
Sure, I will verify if that setting works for tw, I'm creating a few needles that were not created to really see the error with current build. Not sure what it is blocked by this bug because there are no other tests depending on this scenario and the gui tests continue even if one fails.
(In reply to Joaquín Rivera from comment #31) > […] Not sure what it is blocked by this bug because there are no other tests depending on this scenario and the gui tests continue even if one fails. Of course the *scenario* is not blocked but the single test module. A side-effect is that the carry-over is more tedious and less robust than the error condition detection within the test code or a workaround needle.
Suggested workaround didn't work for me: http://rivera-workstation.suse.cz/tests/3025#step/yast2_firewall/10
Joaquín is this issue still present? It is a very old one so I expect it to be already solved in TW
Just checked with SLE and TW and all good now. Thanks!
Closing.