dietpi-update to beta v6.25.3 fails because of pihole

[AaronDavidSchneider]

• Date | Tue 8 Oct 09:08:33 CEST 2019
• Bug report | 88fce573-0741-4ff9-be69-536e85399b0c
• DietPi version | v6.25.3 (MichaIng/beta)
• Image creator | DietPi Core Team
• Pre-image | Raspbian Lite
• SBC device | RPi 4 Model B (armv7l) (index=4)
• Kernel version | Linux DietPi 4.19.66-v7l+ DietPi-Config | CPU performance benchmark #1253 SMP Thu Aug 15 12:02:08 BST 2019 armv7l GNU/Linux
• Distro | buster (index=5)
• Command | wget https://raw.githubusercontent.com/MichaIng/DietPi/beta/.conf/dps_93/apache.block_public_admin.conf -O /etc/apache/sites-available/dietpi-pihole-block_public_admin.conf
• Exit code | 1
• Software title | DietPi-Patchfile

Steps to reproduce:

1. dietpi installation with pihole installed (via dietpi-software)
2. follow the steps at https://github.com/MichaIng/DietPi/blob/master/BRANCH_SYSTEM.md

Expected behaviour:

• update proceeds

Actual behaviour:

• update fails

Extra details:

Additional logs:

/etc/apache/sites-available/dietpi-pihole-block_public_admin.conf: No such file or directory

related: #3131

[MichaIng]

@AaronDavidSchneider
Many thanks for reporting. Indeed a typo in patch file. Just fixed it: 94c4af3

Fix will be merged with v6.26.2 into Beta. Since the update finishes regardless (right?), please do the following to reapply/fix it:

mkdir -p /etc/apache/sites-available
dietpi-update -1
mv /etc/apache/sites-available/dietpi-pihole-block_public_admin.conf /etc/apache2/sites-available/dietpi-pihole-block_public_admin.conf
rm -R /etc/apache

---

Side note: This config allows to block Pi-hole admin panel access for requests from outside your local network, if you even opened webserver access to www . On fresh Pi-hole installs it is interactively asked if this is wanted or not, on update we just place the file. If wanted you can run:

a2ensite dietpi-pihole-block_public_admin
systemctl reload apache2

[AaronDavidSchneider]

thanks for the fix!
I really like this feature by the way

[MichaIng]

@AaronDavidSchneider
Thanks for feedback. Jep it simply makes sense. Most likely we gonna implement similar things for other web applications as well, e.g. a separate script to toggle public/LAN-only/host-only access for each application. Reasonable control when one has different websites/applications where usually not all of them shall be accessible for same remote-hosts.