I just did an update to my installed PiHole set-up (to v5.2.4) and now it seems to be inaccessible. The web interface doesn’t load, and there’s no access available via Home Assistant either.
The update was via “pihole -up” from the command line (the normal update route). From the command line PiHole still seems to be running fine (at least “pihole status” still works and shows it listening on UDP and TCP for both IPv4 and IPv6 and is enabled).
Is this latest version not compatible with the general DietPi set-up? Is there something I can adjust to get the web interface access back again? I tried already an uninstall and reinstall via dietpi-software (leaving the dependencies in place) and that didn’t help.
Hi,
many thanks for your message. For me PiHole is working fine on latest version.
Basically PiHole application consist out of 2 different stacks.
- DNS server stack, responsible for actual DNS resolution. This is the status you see running pihole status
- Web server stack, providing a user frontend - Gui
The main component is the DNS server, which is able to work even if the web server is not running. The web server themselves is a standard web server. DietPi is offering to use nginx, apache and lighttpd. If you don’t change anything on the setting, lighttpd is the default one.
probably web server is not working correctly as you are not able to access the Gui. Pls can you check the status of the web server? In case of lighttpd it would be systemctl status lighttpd.service
Thanks - looks like lighttpd.service is indeed the root cause:
root@VPNPi:~# systemctl status lighttpd.service
● lighttpd.service - Lighttpd Daemon
Loaded: loaded (/lib/systemd/system/lighttpd.service; disabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2021-01-23 21:46:08 GMT; 11h ago
Process: 850 ExecStartPre=/usr/sbin/lighttpd -tt -f /etc/lighttpd/lighttpd.conf (code=exited, status=255/EXCEPTION)
Jan 23 21:46:07 VPNPi systemd[1]: lighttpd.service: Control process exited, code=exited, status=255/EXCEPTION
Jan 23 21:46:07 VPNPi systemd[1]: lighttpd.service: Failed with result 'exit-code'.
Jan 23 21:46:07 VPNPi systemd[1]: Failed to start Lighttpd Daemon.
Jan 23 21:46:08 VPNPi systemd[1]: lighttpd.service: Service RestartSec=100ms expired, scheduling restart.
Jan 23 21:46:08 VPNPi systemd[1]: lighttpd.service: Scheduled restart job, restart counter is at 5.
Jan 23 21:46:08 VPNPi systemd[1]: Stopped Lighttpd Daemon.
Jan 23 21:46:08 VPNPi systemd[1]: lighttpd.service: Start request repeated too quickly.
Jan 23 21:46:08 VPNPi systemd[1]: lighttpd.service: Failed with result 'exit-code'.
Jan 23 21:46:08 VPNPi systemd[1]: Failed to start Lighttpd Daemon.
What would be the way to fix that? The only other thing I’ve done on this system recently is to remove certbot as I no longer needed it (removed via dietpi-software). Would that have broken things?
Looks like pre check is failing already. Can you do
/usr/sbin/lighttpd -tt -f /etc/lighttpd/lighttpd.conf
Looks like the certbot removal did break it:
root@VPNPi:~# /usr/sbin/lighttpd -tt -f /etc/lighttpd/lighttpd.conf
2021-01-24 09:42:35: (mod_openssl.c.445) SSL: BIO_read_filename('/etc/letsencrypt/live/****.****.****/combined.pem') failed
2021-01-24 09:42:35: (server.c.1183) Initialization of plugins failed. Going down.
I’ve removed my DDNS url (the *'s). How can I recover this? Do I need to reinstall from back-up?
I have certbot on another system (it’s running NextCloud in Docker and has certbot installed as part of it), so I don’t want/need it on the DietPi system any longer as everything’s been consolidated to the other install.
No need to re-install, it’s somewhere inside the configured files. Currently I’m out, so can’t really check it atm. Need to have a look later the day.
However can you post ls -la /etc/lighttpd/conf-enabled/
Thanks - it’s not an urgent rush. More than happy to wait a little (and I appreciate the support!).
root@VPNPi:~# ls -la /etc/lighttpd/conf-enabled/
total 8
drwxr-xr-x 2 root root 4096 Jan 14 13:27 .
drwxr-xr-x 4 root root 4096 Oct 28 13:50 ..
lrwxrwxrwx 1 root root 33 Oct 28 13:49 10-fastcgi.conf -> ../conf-available/10-fastcgi.conf
lrwxrwxrwx 1 root root 37 Oct 28 13:50 15-fastcgi-php.conf -> ../conf-available/15-fastcgi-php.conf
lrwxrwxrwx 1 root root 38 Jan 14 13:27 50-dietpi-https.conf -> ../conf-available/50-dietpi-https.conf
lrwxrwxrwx 1 root root 58 Oct 28 13:50 99-dietpi-pihole-block_public_admin.conf -> ../conf-available/99-dietpi-pihole-block_public_admin.conf
lrwxrwxrwx 1 root root 39 Oct 28 13:50 99-dietpi-pihole.conf -> ../conf-available/99-dietpi-pihole.conf
lrwxrwxrwx 1 root root 38 Oct 28 13:31 99-unconfigured.conf -> ../conf-available/99-unconfigured.conf
Editted to add - it’s in 50-dietpi-https.conf (slightly redacted copy below)
server.modules += ( "mod_openssl" )
# Based on: https://ssl-config.mozilla.org/#server=lighttpd&version=1.4.45&config=intermediate&openssl=1.1.0l&guideline=5.6
$SERVER["socket"] == ":443" {
protocol = "https://"
ssl.engine = "enable"
ssl.disable-client-renegotiation = "enable"
# pemfile is cert+privkey, ca-file is the intermediate chain in one file
ssl.pemfile = "/etc/letsencrypt/live/****.****.****/combined.pem"
ssl.ca-file = "/etc/letsencrypt/live/****.****.****/fullchain.pem"
# For DH/DHE ciphers, dhparam should be >= 2048-bit
#ssl.dh-file = "/path/to/dhparam.pem"
# ECDH/ECDHE ciphers curve strength, see "openssl ecparam -list_curves"
ssl.ec-curve = "secp384r1"
# Environment flag for HTTPS enabled
setenv.add-environment = ( "HTTPS" => "on" )
# Intermediate configuration, tweak to your needs
ssl.use-sslv2 = "disable"
ssl.use-sslv3 = "disable"
ssl.cipher-list = ****
ssl.honor-cipher-order = "disable"
}
Not sure what I need to change here to get it working again though?
Not sure if it is enough but remove https config and re-run the test
rm /etc/lighttpd/conf-enabled/50-dietpi-https.conf
Looks like you can fix things even when you’re out 
Renamed the file to .bak and rebooted, now the dashboard comes up.
Will give it a further test and restore my backup of the PiHole configuration (as of course it’s come up vanilla due to the removal/reinstall) but we’re looking good to go so far.
I’ll finish setting it up again and if all is OK will post back here to close things off.
@Joulinar - ok, all seems to be working properly again. Both web interface and HA connection are back up again.
Thanks once again for the excellent support. You can close this one off as solved, enjoy your time out!
Is this something that should be considered with regard to uninstalling certbot? Looks like it’s currently leaving an orphaned config behind which might break other people’s installs in the future?
well it’s not that black and white I would say. Probably someone would like to continue using HTTPS even if he remove certbot. Maybe if he get certificate on another way. Maybe we should implement a dialog asking for the clean-up?
MichaIng
your thoughts pls 
I thought it probably wouldn’t be so easy
In my case I removed certbot as I have it elsewhere (built into NextCloud, running under Docker on another Pi) and didn’t need the duplication or extra port openings. So the certificate is still valid, it’s just not renewed/downloaded under the DietPi install, so doesn’t exist in the location where the config file was expecting it to be.
What you say is correct, but at the moment removing certbot breaks PiHole web access, which obviously isn’t an ideal situation for end users.
There is already an open request about disabling HTTPS via dietpi-letsencrypt: https://github.com/MichaIng/DietPi/issues/1910
But it requires some rework when it should be possible as well after Certbot has been uninstalled. And indeed removing Certbot should probably not disable HTTPS directly, as key and cert are still present and valid and the user might simply switch to a different ACME client. But we should at least print a warning that renewal should be taken care of another way, in case key and cert paths adjusted or lighty-disable-mod dietpi-https used to disable HTTPS on the webserver. If HSTS was used, disabling HTTPS breaks access via public domain for all clients that accessed it once.