[Bug 1114673] New: New UI for firewalld: interface not assigned to the right zone when changed to public in first run
http://bugzilla.suse.com/show_bug.cgi?id=1114673
Bug ID: 1114673 Summary: New UI for firewalld: interface not assigned to the right zone when changed to public in first run Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers@suse.de Reporter: jeriveramoya@suse.com QA Contact: jsrain@suse.com Found By: --- Blocker: ---
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)
http://bugzilla.suse.com/show_bug.cgi?id=1114673
Joaquín Rivera jeriveramoya@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |oorlov@suse.com
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c1
Stefan Schubert schubi@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeriveramoya@suse.com, | |schubi@suse.com Flags| |needinfo?(jeriveramoya@suse | |.com)
--- Comment #1 from Stefan Schubert schubi@suse.com --- Could you please add y2logs ? https://en.opensuse.org/openSUSE:Report_a_YaST_bug#I_reported_a_YaST2_bug.2C...
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c2
--- Comment #2 from Joaquín Rivera jeriveramoya@suse.com --- 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.
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c3
Joaquín Rivera jeriveramoya@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jeriveramoya@suse | |.com) |
--- Comment #3 from Joaquín Rivera jeriveramoya@suse.com --- 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.
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c4
Arvin Schnell aschnell@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P2 - High URL| |https://trello.com/c/cGpBu4 | |GG/2660-tw-1114673-p2-new-u | |i-for-firewalld-interface-n | |ot-assigned-to-the-right-zo | |ne-when-changed-to-public-i | |n-first-run Assignee|yast2-maintainers@suse.de |yast-internal@suse.de
--- Comment #4 from Arvin Schnell aschnell@suse.com --- Added a card to the YaST trello task board so that the issue is prioritised with all other tasks.
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c5
Stefan Schubert schubi@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|yast-internal@suse.de |schubi@suse.com
--- Comment #5 from Stefan Schubert schubi@suse.com --- 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.
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c6
--- Comment #6 from Lukas Ocilka locilka@suse.com --- Schubi, I guess sle12-sp1 was expected to be sle15-sp1, right? sle-12 still uses SuSEfirewall2, sle 15 uses firewalld.
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c7
--- Comment #7 from Stefan Schubert schubi@suse.com --- 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.
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c8
--- Comment #8 from Stefan Schubert schubi@suse.com --- (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" :-)
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c9
--- Comment #9 from Stefan Schubert schubi@suse.com --- (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.
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c10
Stefan Schubert schubi@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #10 from Stefan Schubert schubi@suse.com --- Fixed: https://github.com/yast/yast-firewall/pull/113
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c11
Knut Alejandro Anderssen González knut.anderssen@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |knut.anderssen@suse.com
--- Comment #11 from Knut Alejandro Anderssen González knut.anderssen@suse.com --- (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.
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c12
--- Comment #12 from Joaquín Rivera jeriveramoya@suse.com --- 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
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c13
--- Comment #13 from Knut Alejandro Anderssen González knut.anderssen@suse.com --- (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.
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c15
Joaquín Rivera jeriveramoya@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |---
--- Comment #15 from Joaquín Rivera jeriveramoya@suse.com --- 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&dist... (ens4 should be in public zone)
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c16
Stefan Schubert schubi@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED
--- Comment #16 from Stefan Schubert schubi@suse.com --- (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.
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c17
Joaquín Rivera jeriveramoya@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(knut.anderssen@su | |se.com)
--- Comment #17 from Joaquín Rivera jeriveramoya@suse.com --- 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.
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c18
--- Comment #18 from Joaquín Rivera jeriveramoya@suse.com --- 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.
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c19
Martin Loviska mloviska@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mloviska@suse.com
--- Comment #19 from Martin Loviska mloviska@suse.com --- 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
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c20
Rodion Iafarov riafarov@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |riafarov@suse.com Resolution|FIXED |---
--- Comment #20 from Rodion Iafarov riafarov@suse.com --- We still have this issue in TW with version which should contain the patch. Could you please suggest how to proceed?
http://bugzilla.suse.com/show_bug.cgi?id=1114673
Lukas Ocilka locilka@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |CONFIRMED URL|https://trello.com/c/cGpBu4 |https://trello.com/c/WuqGm1 |GG/2660-tw-1114673-p2-new-u |ET |i-for-firewalld-interface-n | |ot-assigned-to-the-right-zo | |ne-when-changed-to-public-i | |n-first-run | Assignee|schubi@suse.com |yast-internal@suse.de Whiteboard| |https://trello.com/c/cGpBu4 | |GG
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c21
--- Comment #21 from Knut Alejandro Anderssen González knut.anderssen@suse.com --- 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).
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c22
Knut Alejandro Anderssen González knut.anderssen@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrostecki@suse.com Flags| |needinfo?(mrostecki@suse.co | |m)
--- Comment #22 from Knut Alejandro Anderssen González knut.anderssen@suse.com --- Created attachment 800788 --> http://bugzilla.suse.com/attachment.cgi?id=800788&action=edit 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?
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c23
--- Comment #23 from Knut Alejandro Anderssen González knut.anderssen@suse.com --- Created attachment 800791 --> http://bugzilla.suse.com/attachment.cgi?id=800791&action=edit 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.
http://bugzilla.suse.com/show_bug.cgi?id=1114673
Knut Alejandro Anderssen González knut.anderssen@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|yast-internal@suse.de |mrostecki@suse.com
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c30
Oliver Kurz okurz@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocker|--- |Yes CC| |okurz@suse.com
--- Comment #30 from Oliver Kurz okurz@suse.com --- @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?
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c31
--- Comment #31 from Joaquín Rivera jeriveramoya@suse.com --- 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.
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c32
--- Comment #32 from Oliver Kurz okurz@suse.com --- (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.
http://bugzilla.suse.com/show_bug.cgi?id=1114673 http://bugzilla.suse.com/show_bug.cgi?id=1114673#c33
Joaquín Rivera jeriveramoya@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(knut.anderssen@su | |se.com) |
--- Comment #33 from Joaquín Rivera jeriveramoya@suse.com --- Suggested workaround didn't work for me: http://rivera-workstation.suse.cz/tests/3025#step/yast2_firewall/10
https://bugzilla.suse.com/show_bug.cgi?id=1114673
Pavel Dost�l pdostal@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pdostal@suse.com
https://bugzilla.suse.com/show_bug.cgi?id=1114673 https://bugzilla.suse.com/show_bug.cgi?id=1114673#c46
Knut Alejandro Anderssen Gonz�lez kanderssen@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(jeriveramoya@suse | |.com)
--- Comment #46 from Knut Alejandro Anderssen Gonz�lez kanderssen@suse.com --- Joaqu�n is this issue still present? It is a very old one so I expect it to be already solved in TW
https://bugzilla.suse.com/show_bug.cgi?id=1114673 https://bugzilla.suse.com/show_bug.cgi?id=1114673#c47
Joaqu�n Rivera jeriveramoya@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jeriveramoya@suse | |.com) |
--- Comment #47 from Joaqu�n Rivera jeriveramoya@suse.com --- Just checked with SLE and TW and all good now. Thanks!
https://bugzilla.suse.com/show_bug.cgi?id=1114673 https://bugzilla.suse.com/show_bug.cgi?id=1114673#c48
Stefan Hundhammer shundhammer@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED Resolution|--- |FIXED Flags|needinfo?(mrostecki@suse.co | |m) |
--- Comment #48 from Stefan Hundhammer shundhammer@suse.com --- Closing.
-
bugzilla_noreply＠novell.com -
bugzilla_noreply＠suse.com