promofaux

v5.0 image was released minutes after the main v5.0 release. I've personally not tried :latest, but I am told that works. I prefer to use named tags

One of the Pi-hole dev's here. The comment you are replying to is talking about the blog post about this CVE, not Pi-hole's aesthetics. (Which haven't changed, btw)

Say hi to J from me.

Keep an eye on this PR for future functionality...

https://github.com/pi-hole/pi-hole/pull/2935

And of course, now we have more control over/hooks into the resolver, we can look at things like per-client configs:

https://github.com/pi-hole/pi-hole/pull/2935

Hi there, one of the Pi-hole Devs here. This is something we are very much looking into. Take a look at this PR[1] for more details!

No ETAs as yet, of course, but it's something that has been asked about time and time again, and we think we may just have solved it...

[1] https://github.com/pi-hole/pi-hole/pull/2935

That post is 2 years old, and the op understood and was ok with the outcome...

Oobe is either 1)leave suggested defaults as is 2)don't use those lists.

Option 2 is available in the installer before you're even up and running. There is only so much hand holding we can do, to be fair. We have an extensive support community, and plenty of documentation, and yes, whilst I agree some users may fall between the cracks, the majority are able to find a solution to their problems.

Hmmm, not sure I recall. Mind linking back to the conversation? Point is, we don't choose what domains are blocked or not, so there is nothing we can do except ship with a default whitelist. But we're not going to do that either, if we were to start doing that... what's to say we wouldn't whitelist something more nefarious.

It's safest for us, and our reputation, to stay out of the finer points of the actual blocked/not domains and instead defer to individual list maintainers who make that their business.

As commented below, we don't actually maintain any of the lists, so that wasn't us you spoke to!

You can configure the lists that you use to suit your needs. You can also whitelist any domains that you need. It's up to you what you ultimately block!

When you say unbearably slow, do you mean the actual DNS resolution, or the Admin interface?

An Rpi3, even a Rpi B or zero is plenty good enough for DNS queries! The Admin interface has been a bit of a bugbear for a while, but we are working on some massive improvements for the 3.0 release (coming soon™)

There is a disable button on the web interface[1] which allows you to either disable it permanently, or for a specific amount of time. Of course, client devices need to clear their DNS cache, too, in order for this to work properly, but at the moment there is no way of automating that.

There are also other tools to help with blacklisted domains that cause issues/site breakages, such as a query log to identify them, and the ability to whitelist with ease!

[1] http://imgur.com/a/DlIeq

Of course it can! If it has a domain name, it can be blocked. What you may see is the browser grumbling about it.

Essentially all that is happening is a client asks for a domain (e.g ssl.google.com) and if it is on the blacklist, then it returns it's own local IP address for that domain instead of the real one. Which is where you will find the browser complaining. All we return is a blank page/blocking information page, but not via https.

Of course, we could probably get around that by generating self-signed certificates on install, but the user would then need to install that certificate on all of their client machines (I think, I'm not massively proficient in this area!) which makes it an extra, and not vital, step that may scare off the more novice users.

Ah! I did wonder what was going on.. :) I've heard of HN before, but never actively participated, hence only signing up today!

Thanks for vouching for me :)

Exactly that!

The name has just kind of stuck, even though you can in fact run it on most linux distros (We officially support Ubuntu/Debian based distros, but there is limited support for Centos, and even forks for Arch, and Docker!), on a whole host of different hardware.

You can always review the code for yourself over on our github repo (https://github.com/pi-hole/pi-hole)! As well as the devs, there are so many pairs of eyes on the code that if anything fishy were to happen, everyone would know about it (not to mention it would completely undermine the hard work we've put into it over the past couple of years!)

Updates are manual, too, so unless you intervene, there is no reason that a working system would suddenly become compromised, except if somebody had access to your network. But then you have a different issue...

We have a web interface with a whole host of tools to easily identify and whitelist the domains that may or may not be causing issues with sites you browse.

Everyone's mileage varies, but I have only had to whitelist 5 or 6 sites using the default blocklists.

Pi-hole Dev here. The only domains added to the whitelist are the domains on which the source lists are themselves hosted. It's probably complete over-kill, but the reasoning behind it is just in case one list tried to blacklist another.

Compare the "automagical" whitelist entries (http://imgur.com/a/rxgsC) to the Default whitelist here: https://github.com/pi-hole/pi-hole/blob/master/adlists.defau...

Edit: The code that does it: https://github.com/pi-hole/pi-hole/blob/master/gravity.sh#L2...