You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Change the /doc/*.xml content to eliminate the "options" parameter by parameter reference material and link to the man pages where that information already exists in much better detail. Augment the top level content for each object with more information regarding "what" and "how" the various configuration objects affect the accessibility of the system. I don't think each section needs to be terribly long. For instance the "service" should describe how applying a service to a zone permits incoming connection requests from that zone to the host (i.e. input/output) and applying it to a policy permits connections from the source zone(s) to access the service in the target zone(s).
Why is this needed
Clearly a lot of work has been put into the documentation of firewalld. I actually find there to be a lot of duplicate documentation (e.g. man pages, doc "option" pages, and the github wiki) which is nearly but not quite all identical so it must be maintained separately. Yet, I can't really find an explanation of how the various config objects effect the access rules. I'm sure the "how" or "what" part of the config is really simple/obvious and so experts don't think it needs to be said. I have many years of experience designing firewall rule sets on cisco, aws, iptables, etc. When reading the docs here I can't definitively understand what various config objects are doing to the rule sets. Sure I can guess and might be 95% but I'm not going to do that with a firewall. I've resorted to trial and error; make a change, dump the nftables, vimdiff to an earlier dump, repeat. For instance enabling a service on a zone... does that permit others to access that service in the zone? or does it permit that zone to access the service? Trial and error says the latter, but nothing in the documentation clearly says that. I think the project would get a lot more use if it was easier and faster to grasp the concepts; otherwise people like me just keep making our own nftables rulesets by hand.
The text was updated successfully, but these errors were encountered:
What would you like to be added
Change the /doc/*.xml content to eliminate the "options" parameter by parameter reference material and link to the man pages where that information already exists in much better detail. Augment the top level content for each object with more information regarding "what" and "how" the various configuration objects affect the accessibility of the system. I don't think each section needs to be terribly long. For instance the "service" should describe how applying a service to a zone permits incoming connection requests from that zone to the host (i.e. input/output) and applying it to a policy permits connections from the source zone(s) to access the service in the target zone(s).
Why is this needed
Clearly a lot of work has been put into the documentation of firewalld. I actually find there to be a lot of duplicate documentation (e.g. man pages, doc "option" pages, and the github wiki) which is nearly but not quite all identical so it must be maintained separately. Yet, I can't really find an explanation of how the various config objects effect the access rules. I'm sure the "how" or "what" part of the config is really simple/obvious and so experts don't think it needs to be said. I have many years of experience designing firewall rule sets on cisco, aws, iptables, etc. When reading the docs here I can't definitively understand what various config objects are doing to the rule sets. Sure I can guess and might be 95% but I'm not going to do that with a firewall. I've resorted to trial and error; make a change, dump the nftables, vimdiff to an earlier dump, repeat. For instance enabling a service on a zone... does that permit others to access that service in the zone? or does it permit that zone to access the service? Trial and error says the latter, but nothing in the documentation clearly says that. I think the project would get a lot more use if it was easier and faster to grasp the concepts; otherwise people like me just keep making our own nftables rulesets by hand.
The text was updated successfully, but these errors were encountered: