V6 Beta QoL improvements

General Beta 6.0
1

Thanks for all the hard work in the v6 rebuild!

I had three simple suggestions:

  • Please provide a way to permanently suppress/ignore warnings in pihole diagnosis - e.g. RE: TLS error due to self-signed certs.
  • During beta when we're opting-in, and asked to update daily, why not automate that via cronjob by updating the current pihole cronjob to run 'pihole -up' 5 mins after the daily update check?
  • Please can Fedora 39 just be added to the 'supported' OS list? It works flawlessly, and has consistently on the latest Fedora releases for many years now. Is there a good reason pihole OS version support lags so far behind? It is needlessly grating having to pass a var to skip the OS check for every Pihole command...

Ta

2

Will be addressed by Drop Fedora 36 and add Fedora 39 to the test suite by yubiuser · Pull Request #5482 · pi-hole/pi-hole · GitHub

1 Like
3

Here's a chron job you can add. Buyer beware on automatically asking for an unattended crash, per the thread.

4

Thanks for the link. I did write a quick and dirty cronjob already which just redirects output to /dev/null, but figured it might be of use suggesting it more broadly during beta. The redirect to the logger from your example is probably a better idea. :slight_smile:

5

I wonder how such a setting should look like... normally all the warnings should be fixable by proper configuration changes (which is quite obviously preferable over simply muting the warning!). Maybe let's first address the particular example you have. Could you provide a screenshot? I'm asking because Pi-hole should not complain about self-signed certificates. It should only war if your used certificate does not contain the Pi-hole domain you configured. Both possible are easily fixes: Either adjust your webserver.domain to a domain in your certificate or ensure that this domain is in the certificate.

Because beta means "stable but not rock-solid". We really always try our best, but there may be hidden issues we see too late. Manual updates have the advantage of being applied (a) asynchronously (spread over at least time zones) and (b) should normally only be done when you have the time to apply possible fixes. Nothing is more frustrating that being in a time-critical situation (say, an online exam of any kind) and your DNS breaks just because the cronjob thought it is a good idea to update just now.

6

RE: cert warnings - Fair point regarding config changes being a reasonable solution. However, there will be many people that:

  • Do want to enable and use HTTPS via using the self-signed cert
  • Do want to change the default pihole FQDN from pi.hole
  • Don't care if the self-generated cert matches the new FQDN or not, as enabling HTTPS is the sole objective.

In this respect, people would then have the same 'accept SSL/TLS exception' web browser workflow to access pihole as with other locally hosted web-services with similar self-signed certs e.g. Cockpit etc. Sure, they could setup a reverse proxy, or use ACME certbot and a legit domain they actually own, but most probably won't bother. That should still be ok for pihole, and not generate a "CERTIFICATE_DOMAIN_MISMATCH" error on every single restart of piholedns. If you want a practical means to enable an exception - surely a toggle option to "ignore certificate domain mismatch errors" under Settings -> Web interface/API that is exposed only in 'expert' mode would provide an easy way to do this. Those that want it, can find it. Those that ask for it can be readily directed to it e.g. in an FAQ or other docs. An option to re-generate the self-signed cert for the user-defined FQDN would also be a valid solution.

RE: Cronjobs having the potential to silently break things - agreed and understood. I get that. It shouldn't be required, but there is also no harm in giving beta testers, who are signing up for things potentially breaking, a pre-defined cronjob and the option (if only during beta - perhaps via the 'reconfiguration' workflow, or via another web-settings tick-box) to enable it without creating a cronjob manually. If you recommend daily updates, make it easy to do.

This could help keep a majority of people on a smaller and more consistent range of dev builds. That would both reduce the bug-report overhead for any breaking issues that are quickly fixed, and also help ensure the bugs reports you do get are less likely to be for stale builds.

The point about silently breaking things via cronjob is entirely valid, but this is beta, and shouldn't be in prod as breaking changes are to be expected. The v6 beta disclaimer on shifting branch already makes people sign-up to that.

As many people will run more than one instance of pihole either physically or via docker, even if run in prod, so long as there is a non v6-instance as secondary DNS people still shouldn't care if the beta build breaks. As again, they quite literally signed up for that :stuck_out_tongue:

If you're concerned about visibility or tracability of cronjob issues, either flagging when the job will run when the option is enabled, and/or redirecting the job command output to logs would be easy wins. You could equally set a flag that is user-discoverable via 'pihole status' should the update cronjob command return a non-zero exit etc.

7

How about a new status? green if last gravity run is max. 1 week old, then yellow for 1.5 weeks and red after 2 weeks? Then it is obvious when a cronjob fails.

8

Pi-hole runs gravity every Sunday night automatically.

9

The first two will not cause any warnings in Pi-hole's diagnosis systems. Well, there may be warnings in your browser but we cannot do anything about that.

Self-signed is perfectly accepted. Pi-hole even uses the domain (whatever you have configured!) to generate its own self-signed certificate. So you can easily resolve the third point even by simply removing the generated file and Pi-hole will regenerate a new, matching (!) one for you.

I will come back to you other points later.

10

RE: Browser errors - understood, that much is very much expected.

RE: The means to auto re-generate a new tls cert - Great, good to know, thanks! Removing the previous tls.pem from /etc/pihole/ works as described and the pihole diagnosis error on restart is gone. Rather than relying on documentation, is there any merit in automating that process rather than requiring user intervention? I suppose to avoid issue with certs that aren't self-signed there might need to be some logic check, but for self-signed certs there's presumably no harm in regenerating them automatically as/when settings like webserver FQDN changes?

11

Sorry for another delay, it's busy times...

Users may have added their self-signed certificates to their OS/browser trust stores so they don't have to add exceptions for this certificate but instead have the browser trust the underlying CA. Similarly, your scripts have to use --insecure when interacting with the API unless you have the public part of the certificate at hand (which is obviously the better solution).

Changing the domain shouldn't happen too often. And regenerating the certificate by manually deleting the old one makes you very aware of that the certificate is changing.

Nothing is carved in stone in this beta, we can always discuss anything. You may not be able to convince us for everything but we will try to reason why some decisions are how they they are at the very least.

1 Like
12

Fair enough. In which case, perhaps instead it's worth noting in documentation somewhere user-accessible that a new self-signed cert will be generated for your new domain, simply by deleting the old one. That addressed my issue, but I had no reason to believe deleting the old cert would regenerate a new one that was any more useful that the one I deleted. I may just be stupid, but I'd suspect others may similarly not realise the same unless it's documentated somewhere as the useful feature it is. :slight_smile:

Thank you for your time, and the considered replies.