Bugzilla – Bug 804894
Disabling firewall in yast does not survive reboot
Last modified: 2013-07-04 07:16:38 UTC
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0 If I both disable and stop the firewall in Yast, it still starts again after the system reboots. Bug 779455 addressed something related to this for 12.2, but there is something going on in 12.3 RC1 Reproducible: Always Steps to Reproduce: 1. Stop and Disable the firewall in Yast 2. Reboot 3. Actual Results: The firewall is started Expected Results: The firewall, having been disabled, should not be started. Stopping the firewall in Yast works. It just does not survive a reboot. Before the reboot, but after I have disabled the firewall, looking in yast again shows the correct/expected settings. They just don't happen after the reboot.
more a job for yast2-maintainers i think
YaST or systemd?
yast or the way yast is enabling / disabling systemd services. I think there was a bug somewhere in checking the location of the services (/lib/systemd/system => /usr/lib/systemd/system) but I might be wrong.
Enabling the firewall in yast does work, disabling doesn't. To disable the firewall I had to use: systemctl disable SuSEfirewall2_init.service
When using YaST (curses or normal), disabling firewall, finishing, and then going back into firewall setup, enable at startup is still displayed.
might be related to bug 807507
I also noticed that SuSEfirewall2 ist not listed in chkconfig anymore, which is also not wanted, I assume.
I installed the patched yast2 provided in bug 807507 and I am able to enable and disable the firewall now. However, it would be nice to have SuSEfirewall2 back in chkconfig, as I don't like the systemctl interface.
ok so closing as duplicate of bug 807507 you can still run chkconfig SuSEfirewall2 on etc. SuSEfirewall2 even has a shortcut, SuSEfirewall2 off will unload all rules and disable the script. SuSEfirewall2 on will enable the scripts and apply rules. *** This bug has been marked as a duplicate of bug 807507 ***
*** Bug 811188 has been marked as a duplicate of this bug. ***