Red Hat Bugzilla – Bug 1002016
Combined zones does not show up as permanent
Last modified: 2014-03-08 23:43:17 EST
Description of problem:
When creating a combined zone, they don't show as --permanent
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. mkdir /etc/firewalld/zones/test/
2. cp /usr/lib/firewalld/zones/work.xml /etc/firewalld/zones/test/test.xml
3. firewall-cmd --reload
4. firewall-cmd --permanent --list-all --zone test
Error: INVALID_ZONE: test
services: ipp-client mdns dhcpv6-client ssh
Combined zones are also hidden in the firewall-config GUI
I would suggest combined zones to show up as a number 'zone/subname' in both firewalld-config and firewalld-cmd, which would make it possible to edit the individual combined zones from the GUI.
Just adding "self.config.add_zone(copy.deepcopy(combined_zone))" makes it show up permanent, but editing will be totally bogus (only /etc/firewalld/zones/test/test.xml in my example will be affected).
Created attachment 791395 [details]
Hackish first try at adding editing capability of combined zones
Created attachment 791875 [details]
Editable combined zones
Adding, removing and editing of combined zones implemented.
Combined zones now includes both top level .xml files as well as file from subdirectory (i.e. /etc/firewalld/zones/zone.xml and /etc/firewalld/zones/zone/*.xml)
Minor problem: name of combined zone name files can easily exceed the 17 character limit in max_zone_name_len, but netfilter rule will only? contain the part before the '/', perhaps max_zone_name_len should be made a function that checks constraints and returns a properly truncated zone_name. E.g
returning a suitable tuple, would make it possible to only enable the OK button for well-formed entries as well (firewall-config).
Created attachment 791924 [details]
Allow longer names for combined zones, create combine directory
1. Check and create /etc/firewalld/zones/<combined>/ before creating .xml (sloppy testing on my part, testing with reused name :-()
2. Allow longer names for combined zones (hopefully only the combined name will occur in netfilter rules).
I've just applied your patch.
Sorry it took so long and thank you very much for it !
firewalld-0.3.9-1.fc20 has been submitted as an update for Fedora 20.
firewalld-0.3.9-1.fc19 has been submitted as an update for Fedora 19.
tested firewalld-0.3.9-1.fc20 ,the output is still :
Error: INVALID_ZONE: test
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing firewalld-0.3.9-1.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Actually it works, but you have to specify the zone name as "zone/subname".
For example if I have test/1.xml and test/2.xml
# firewall-cmd --permanent --list-all-zones
#firewall-cmd --permanent --list-all --zone test/1
#firewall-cmd --permanent --list-all --zone test/2
I'll take a look if it can be changed to be able to use the zone name without the subname.
It actually makes perfect sense as it is now.
Permanent changes mean changes in configuration files.
When I take the above example, i.e. test/1 and test/2, from the following command
#firewall-cmd --permanent --add-service=dns --zone=test
it's not clear whether the service should be added to 1.xml or 2.xml, therefore it's necessary to use the name as "zone/subname".
firewalld-0.3.9.1-1.fc19 has been submitted as an update for Fedora 19.
(In reply to Jiri Popelka from comment #12)
> It actually makes perfect sense as it is now.
> Permanent changes mean changes in configuration files.
> When I take the above example, i.e. test/1 and test/2, from the following
> #firewall-cmd --permanent --add-service=dns --zone=test
> it's not clear whether the service should be added to 1.xml or 2.xml,
> therefore it's necessary to use the name as "zone/subname".
My intention in this case was to add it to test.xml (hance the changed logic for combined zones).
firewalld-0.3.9.3-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.