Run the following: sudo firewall-cmd --permanent --zone=public --add-port=80/tcp --list-all shows: public interfaces: p2p1 services: mdns dhcpv6-client ssh ports: forward-ports: icmp-blocks: iptables -L -n | grep 80 also shows that the port wasn't setup.
Yes, the --permanent option is still not documented (will be fixed soon) so you can't possibly know that it only changes what we call 'Persistent configuration' in firewalld(1): 'The persistent configuration is stored in the config files and will be restored with every machine boot or service reload or restart.' So it only changes the config files, it does not affect the actual configuration. If you want the change to affect actual configuration you either need to use the same command without the --permanent switch, i.e. firewall-cmd --zone=public --add-port=80/tcp or reload/restart firewalld after you change the config files so the config files get loaded. examples: (allow 80/tcp right now, this runtime change disappears with restart) # firewall-cmd --zone=public --add-port=80/tcp (allow 80/tcp permanently, runtime configuration is not touched) # firewall-cmd --permanent --zone=public --add-port=80/tcp (allow 80/tcp permanently and also in runtime configuration) # firewall-cmd --permanent --zone=public --add-port=80/tcp # firewall-cmd --zone=public --add-port=80/tcp does it make sense ?
I must say the current behavior is quite unintuitive. I expected that adding --permanent to a commandline will do the same as the non-permanent variant only ... um, ... not permanently = the resulting iptables rules will be identical. Can this behavior be changed? If not, can you at least warn the user? E.g. if resulting iptables ruleset with and without --permanent differ then "Warning! you have to reload firewalld service for the changes to take effect!" Or maybe rename the parameter?
So you suggest that with --permanent switch it should alter both permanent as well as runtime configuration ? I've been actually thinking about the same, i.e. that most users want to do both with one command. What's the use case for changing - *only* runtime configuration, i.e. change disappears with restart - *only* permanent configuration, i.e. one needs to reload firewalld after ?
Hi, I ran into the same problem, but I think it's more a problem of firewalld rather than firewall-cmd. Even after a reload the ports are not listed when doing a firewalld-cm --list-all-zones. The corresponding line in the zone's xml file is present, but it has no effect. It seems firewalld loads only the <service name ...> tags but not the <port protocol...> tags. Regards, Tom.
(In reply to comment #4) > Even after a reload the ports are not listed when doing a firewalld-cm > --list-all-zones. Then you see a different problem. Please create new bug report and add your own steps to reproduce. thanks!
*** Bug 964462 has been marked as a duplicate of this bug. ***
Sorry, I filed the above duplicate before I found this bug. :-( As I said in that bug, I'd prefer it if it worked like this: firewall-cmd -> affects runtime and persistent configuration firewall-cmd --runtime -> affects runtime configuration only firewall-cmd --permanent -> affects persistent configuration only That way the argumentless call does what IMHO 99% of users usually want when configuring their firewall, but the other two possibilities are left as options for those who want that sort of thing. The use case for `--runtime` in the above setup would be trying out some new service that I'm not sure about and don't want to add to the permanent config yet. I'm not sure of a use case for --permanent.
*** Bug 961974 has been marked as a duplicate of this bug. ***
We discussed this with Thomas some time ago and agreed that it'd be good to have an option to change both runtime/permanent setting at the same time. (In reply to T.C. Hollingsworth from comment #7) > firewall-cmd -> affects runtime and persistent configuration > firewall-cmd --runtime -> affects runtime configuration only > firewall-cmd --permanent -> affects persistent configuration only This exactly I suggested then as ideal solution, but I'm not so sure now, because: - it changes current behaviour - what if it can not be enabled for one of them? enable the other one also in error case? - for example systemctl has also only 'start' and 'enable' but no command for starting the service now *and* after reboot, even in most cases you do 'systemctl start x.service; systemctl enable x.service'.
We can add "--permanent-also" as an option to chnage runtime and permanent at the same time. But we need an other error handling in this case. A nice additional idea from a colleague was to have an option that makes the active runtime configuration permanent with a call like "firewall-cmd --make-permanent". The configuration could be adapted till it matches the needs and then it could be made permanent.
(In reply to Thomas Woerner from comment #10) > A nice additional idea from a colleague ... also in bug #910491
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Changing the behavior of --permanent is not an option at this point. It would be too surprising to users. Current versions of firewalld allow a compromise by using the "--runtime-to-permanent" option. You make all your runtime changes, then finish up by using this flag. e.g. # firewall-cmd --add-service=samba # firewall-cmd --add-port=1234/tcp # firewall-cmd --runtime-to-permanent