I'd appreciate the reboot button back in settings and a pihole button somewhere. At least for the beta.
Reason: No opportunity to start update from mobile or PC wo. shell client (Putty)
system: Bookworm and PH beta 6 on Pi2b
I don't be think we're going to add them back. They were removed by
which allowed to reduce capabilities of pihole-FTL
Pi-hole is not meant to be a system management tool.
Regarding the update: Why do you need to update your Pi-hole from your mobile? As a DNS server, it's a critical part of your network infrastructure, you sound have access to the machine during the update in case something goes wrong.
Don't worry. I'm always at home for the updates but:
If the indicator in the footnote shows a new release it would be very handy to pull it directly on the fly.
Also valid for the reboot. It sometimes needed. Specifically on beta status.
If you somewhen want to enhance the current nerdy community with pihole and think more of a bigger approach you will need more convince for a regular user. It's not a wrong path to think about useability and ease of use.
I don't expect you to bring the buttons back but it's worth asking you and submitting user feedback.
Definitely. Please don't get us wrong, we are factoring in user feedback as actually the most valued input we have for continued development. At this point, we have a fight between convenience and security. I know I'll have to write more text to explain our stance, but I'll do this now so it hopefully gets clear.
Bad analogy: It would be more convenient if you leave your front door open because you won't have to lock and unlock it every time for which you need to search your key in your pockets.
Back to being serious: Pi-hole is used at a critical point in your network. If an attacker manages to compromise it, they can rewrite DNS replies to your clients and - potentially - steal data using an MITM attack. Granted, HTTPS makes this hard but many users install self-signed certificate authorities (CAs) into their browsers for their own (internal) services so MITM may actually be real for them without certificate pinning which is still not common practice in browsers today.
No software is secure. We can only seek to minimize security issues. However, if there are critical security issues in software developed by massively large companies with entire IT security team, how can we pretend to not be affected by some stuff. I'm not saying we are infallible but errors may also come in from external factors such as libraries we depend on and not manage ourselves.
To strengthen your security as user using Pi-hole, we intentionally run our DNS server as the unprivileged user pihole on your system. This means that even when there is a bug somewhere that could, e.g., lead to remote code execution (RCE), this can only affect the tiny bit of your system that is Pi-hole and not the other services you are running thereon. Say you have a CA on your system - Pi-hole will not be able to read it. Furthermore, the attacker will not be able to launch a proxy server on your system or modify your SSH settings to allow login from outside.
All this (and much more!) would be possible when Pi-hole would be running using admin rights on your system (root user) and there would be a bug. I know - this is all very hypothetical - but, as said above, it is not a good security measure to say "this will never happen". I know that the vast majority of services is running as root under Linux and we all think this is an issue in itself. Operating systems curators are aware of this and try to fix the aforementioned hypothetical security issues using SELinux, AppArmor, ... but this really is band-aid fixing and not caring about the underlying wound itself - because rewriting every daemon out there to not needing root permissions is some massive effort and - in general - developers don't seem to care about it enough.
Long introduction, now to the main point: This intentionally chosen security considerations are precisely what cause an online update to not work: Pi-hole simply doesn't have the permissions to update files on your system. While minor patch updates (not changing system-wide files) could possibly be done, it would be a massive effort to implement support for this. And once 6.1 comes (instead of 6.0.4), you may have to login anyway. I know, I know. Others offer support for automated updates but - believe me - they do so by scrutinizing aforementioned extra security Pi-hole adds for you.
One final word: Pi-hole is also officially provided in a docker container. For containers, there are several web interfaces allowing you to control them, e.g., portainer. These web GUIs will allow you to recreate (including pulling the latest version) via a web frontend:
There are also other options like automatic updates using, e.g., watchtower, but be warned that automatic updates while you are not at home can cause severe family ... "friction" ... when done whitout you being near to fix possible hiccups. This warning about automated updates is surely not isolated to Pi-hole but all applications you are running in a container. That's the reason why I have set up watchtower to notify me about stale container images but never update them on its own.
Hey DL6ER,
thanks for very much for this explanation and the problem description. I didn't consider this view and admit you are fully right.
This gives me more insights and understanding instead of Just no, we don't do it and we don't think it's needed.
Thanks again & cheers