When performing bookworm update, 99-dietpi-pihole-block_public_admin.conf is not removed

[murraythegoz]

Creating a bug report/issue

Required Information

• DietPi version | cat /boot/dietpi/.version G_DIETPI_VERSION_CORE=8 G_DIETPI_VERSION_SUB=22 G_DIETPI_VERSION_RC=3 G_GITBRANCH='master' G_GITOWNER='MichaIng'

• Distro version | echo $G_DISTRO_NAME $G_RASPBIAN bookworm

• Kernel version | uname -a Linux orangepi0-306.priv.bth 6.1.53-current-sunxi #3 SMP Wed Sep 13 07:43:05 UTC 2023 armv7l GNU/Linux

• SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3) OrangePi Zero (1st gen)

• Power supply used | (EG: 5V 1A RAVpower) Poe Splitter

• SD card used | (EG: SanDisk ultra) SanDisk Extreme

Additional Information (if applicable)

• Software title | (EG: Nextcloud) PiHole
• Was the software title installed freshly or updated/migrated? Updated
• Can this issue be replicated on a fresh installation of DietPi? I guess so

• Bug report ID | echo $G_HW_UUID

Steps to reproduce

1. have a working bullseye installation
2. have the Dietpi "block non private networks enabled"
3. proceed with the upgrade to bookworm using the command sudo bash -c "$(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/master/.meta/dietpi-bookworm-upgrade')"
4. upon Pihole reinstallation answer "no" to the query about having only the private network enabled
5. at the end the configuration to block from private networks is still enabled.

ls -l /etc/lighttpd/conf-enabled | grep block lrwxrwxrwx 1 root root 58 Nov 27 2020 99-dietpi-pihole-block_public_admin.conf -> ../conf-available/99-dietpi-pihole-block_public_admin.conf

Expected behaviour

the above symlink should be deleted

Actual behaviour

the above symlink is not deleted

Extra details

• ...

[MichaIng]

Right, this choice was meant as a "do you want to enable it or do you not want to enable it" choice, instead of "or do you want to disable it".

We could change that to have a previously enabled public access block removed when selecting "NO", but then the wording needs to be changed to reflect that. What I am a little concerned about is that non-interactive reinstalls would then always remove the block. So actually it would require a little more rework:

• If there is no block currently in place, offer to enable it, do nothing in case of "NO". So this is the current behaviour.
• If a block is currently in place, i.e. on a reinstall, offer to keep or remove it. Hence a switched around prompt, so that it is clear what it does in both cases, and offers the only two relevant things in each situation.

However, the prompt tells you the oneliner commands to enable/disable the block by yourself. A reinstall was never meant for only this job, and would be complete overkill 😉.