Selecting enabled for the ipblocklist page and/or selecting a blocklist, eg DShield, then pressing save results in a blank page which stays there. Re-selecting the IPFire WUI and going to the ipblocklist page shows that it is not enabled and no blocklists selected. This problem only happens with the update from CU169 to CU170 Testing master/ef7d41ef When I downloaded master/ef7d41ef as an iso and did a fresh install then enabling the ipblocklist page and selecting an ipblocklist and pressing save resulted in a page that had the message to go and update the Firewall Rules. I did that and then went back to the ipblocklist page and it is enabled with the previously selected blocklist enabled. It looks like the problem only occurs when doing an update and not a fresh install. I have kept the fresh install and the updated versions of the vm's so can do any checking etc that might be required.
Should have mentioned in the initial bug submission that this was identified by other people and flagged up in the forum. https://community.ipfire.org/t/core-170-test-ip-address-blocklists-error/8400
change the owner and group to nobody on /var/ipfire/ipblocklist folder so it can write the settings file. chown nobody:nobody /var/ipfire/ipblocklist verified as working afterwards by others
Moved back to assigned as it is only marked as modified once a patch has been accepted and merged/committed into the git repository.
(In reply to Adolf Belka from comment #3) > Moved back to assigned as it is only marked as modified once a patch has > been accepted and merged/committed into the git repository. got it, sorry!
I gather from the discussion that something like the following needs to be done as part of the Core 170 upgrade process: . "chown nobody:nobody /var/ipfire/ipblocklist/" . However, this bug is showing as "assigned" but it is currently assigned only to "nobody"
https://patchwork.ipfire.org/project/ipfire/patch/59c78fd9-46a7-6290-ad8e-cae28cfc2bfc@ipfire.org/
https://lists.ipfire.org/pipermail/development/2022-August/014289.html Second attempt of patching this: https://patchwork.ipfire.org/project/ipfire/patch/06825b38-ec53-38c5-c8ce-12d70c1acb5b@ipfire.org/
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=763efaf672a27297e274fbe526a3c49ea96904ee
https://blog.ipfire.org/post/ipfire-2-27-core-update-170-is-available-for-testing
Tested on my vm testbed - cloned a CU169 system, upgraded to CU170 and rebooted and the ipblocklists entry is fully accessible as expected. Confirm that the fix has fixed the bug.
https://blog.ipfire.org/post/ipfire-2-27-core-update-170-released