{{Header}} __FORCETOC__ {{#seo: |description=How to refactor the firewall script while being sure there are no nftables changes. }} {{intro| How to refactor the firewall script while being sure there are no nftables changes. }} = nftables = '''1.''' Store current nftables rules to file nftables-old. {{CodeSelect|code= sudo nft --stateless list ruleset > nftables-old }} '''2.''' Refactor the {{project_name_long}} firewall code. '''3.''' {{Reload_Firewall}} '''4.''' Store current nftables rules to file nftables-new. {{CodeSelect|code= sudo nft --stateless list ruleset > nftables-new }} '''5.''' Compare files nftables-old and nftables-new. Use console diff viewer or...
diff nftables-old nftables-newUse a graphical diff viewer.
meld nftables-old nftables-new= systemcheck nftables test = Does not exist yet. * "''systemcheck (which is somewhat a replacement for the lack of test suite) could indeed be useful to check if the loaded nftables rules match a hardcoded nftables dump. Yes, with additional firewalll add-ons that would be hard. Then these firewall add-ons could ship a dump that also gets verified. (nftables-dumps.d folder checked by systemcheck or so.) But then multiple firewall add-ons gets hard. Mutliple firewall add-ons and dumping, that kind of flexibility might be stretching what the {{project_name_short}} project may be able to implement.''" (From [https://forums.whonix.org/t/bolt-on-for-whonix-firewall-best-place-to-put-files/2222 (Forum) Bolt on for whonix_firewall - best place to put files?] ) ** systemcheck could use this nftables diff facility to warn the user of non-standard / unexpected rules present. And, just like unwanted packages, could ask the user to run ''e.g. nftables-save-whonix'' to establish a new baseline. systemcheck would then pass, unless something else had changed things user unexpectedly, at which point systemcheck would again warn. = Split {{project_name_short}} Firewall Script for better readability = ''From Patrick:''
function ScriptFuncPreloadElement1() { script lines, e.g. $nftables_cmd ''blah''}** Optionally followed, for inline / immediate execution rather than hooking in later within firewall script, with:
ScriptFuncPreloadElement1 # (Within the same file == calling main().)** This separates code definition from code execution. * "''The other question with firewall code injection, pre/post hooks is when to dispatch them? When you want to dispatch them depends on what you actually want to implement.''" * e.g.
if [ "$(type -t firewall_input_hook_end)" = "function" ]; then firewall_input_hook_end fi** However, such would only allow a single call per hook. (User would have to chain all calls within whonix_firewall.d) Perhaps array variables instead. Code would then be something like ScriptFuncPreloadElement1() as above, then
firewall_input_hook_end[${#firewall_input_hook_end[@]}]=ScriptFuncPreloadElement1*** ''It would be up to the user to appropriately manage the array ordering.'' ** Hooks within the firewall would then walk the appropriate array at the appropriate time.