Read configuration from /etc/firewalld/firewalld.conf.d/*.conf
What would you like to be added
Currently, firewalld reads its configuration from a single file /etc/firewalld/firewalld.conf. Ideally the configuration must be read from multiple sources:
- /etc/firewalld/firewalld.conf.d/*.conf (modified by system administrator and administrator tools for drop-in of configuration snippets)
- /etc/firewalld/firewalld.conf (modified by system administrator)
- /usr/lib/firewalld/firewalld.conf.d/*.conf (this directory is used for drop-in of configuration snippets by tools/distributions that ship modified configuration for firewalld)
- /usr/lib/firewalld/firewalld.conf (this file is shipped by firewalld package)
The configuration is merged in specific order and prioritization (the first listed paths above have highest priority). Systemd has elegantly solved all the problems listed below using this approach. For more details, see how systemd implements this.
Why is this needed
The current approach creates problems:
- For users who wish to edit the configuration file when they wish to deploy software updates automatically. When firewalld ships a newer configuration file with new options and values, this file must be 3-way merged manually with the older configuration file and the user modified file.
- This is also a problem for automated tools such as FreedomBox which want to deploy firewalld and maintain custom configuration. In our case we change the DefaultZone= (and earlier FirewalldBackend=nftables). When updates have to be deployed, merging the configuration using an automated tool is unnecessarily hard.
- For distributions aiming to implement Factory Reset and Stateless machines, this is a problem.
Sorry, I prematurely submitted the feature request. I have now edited the description to complete the request.
Hey @erig0 , I was thinking of taking the time and picking up this issue, I do see there's this stale PR that could collide (https://github.com/firewalld/firewalld/pull/1290)
Would it be ok with current work to pick up this issue? And if that's the case is it better to start from the #1290 base or from main?
Hey @erig0 , I was thinking of taking the time and picking up this issue, I do see there's this stale PR that could collide (#1290)
I do not intend to merge that PR. I will close it.
Would it be ok with current work to pick up this issue? And if that's the case is it better to start from the #1290 base or from main?
Start from main.