Hi
I have a quick question about the group
"Unassociated". It is described that:
All domains, clients, and adlists without a specific group assignment are automatically managed through this group. Disabling this group will disable Pi-hole blocking for all unmanaged devices.
I should now know whether this really applies to all domains and adlists, or only to active ones.
My goal is to run v5.0 like v.4.4, with the exception that there is still a group of Unfiltered. Only the clients belonging to the Unfiltered group should be integrated and configured.
I'm not sure if I understand your question in total but if an adlist is disabled (a.k.a not active) it is not included in gravity.db at all - so it is independent of which groups it is in.
So it is not in the standard group. ok, that's the solution thank you. How about a regex, domain or adlist assigned to a group. as I understand it belongs to the standard group too, or not?
Wir können das auch auf Deutsch klären, wenn das einfacher sein sollte.
Jeder neu hinzugefügte Eintrag (sei es eine Domain, eine Blockliste oder ein Regex Filter) wird automatisch der Gruppe "Unassociated" zugewiesen. Das kann dann beliebig verändert werden.
Clients blocken nur solche Domains, die ihnen ĂĽber eine Gruppe zugewiesen sind.
Wenn ich eine Gruppe bilde, in der TeamViewer deaktiviert sein soll, dann gilt dies auch fĂĽr "Unassociated".
Wenn ich eine Blockliste deaktiviere, gehört diese auch nicht mehr zu "Unassociated".
Wenn ich eine Domain zur whitliste aber keiner Gruppe zuordne, gehört sie automatisch zu "Unassociated".
"Known Clients" die keiner Gruppe zugewiesen wurden gehören automatisch "Unassociated"
Soweit alles korreckt?
Ok, ist geregelt. Wegen der Clients ging ich davon aus dass eine Domain, eine Blockliste oder ein Regex auch dann noch "Unassociated" zugewiesen ist, wen die Domain, Blockliste oder Regex deaktiviert, oder die automatische zuweisung zu "Unassociated" entfernt wurde. Scheint aber nicht so zu sein. Vielen dank und sorry fĂĽr den wirbel.
Es freut mich, dass wir klären konnten, dass beides nicht der Fall ist. Deaktiviert ist wirklich deaktiviert (wie entfernt). Wenn die Zuweisung zu Unassociated entfernt wurde, dann ist sie weg.
Ich spiele mit dem Gedanken diese Gruppe noch vor Veröffentlichung von 5.0 zu Default umzubenennen. Ich denke das wird einfacher sein.
Ich finde den Namen eigentlich ganz treffend. Ok default gibts auch bei v4.x. Aber was mich iritiert hat ist das nicht zugeortnete clients dieser Gruppe zugehören (1), der leicht irreführende Text der beschriebeung (2), und dem fakt das ich keine Gruppen, Domains oder RegEx in dieser Gruppe hatte (3).
Ist so ein klassischer fall von: "Wer denk schon so dumm, dass man das begreiffen könnte?"
Was noch cool wäre: Eine searchbox für "known client".
Mal schauen, es gibt eh Pläne die "Network" Tabelle zu einer Client-Management Overfläche umzubauen und die jetzt existierende Seite zu entfernen. Das ermöglicht dann eine Orientierung mehr anhand von Geräten (zugehörige IP Adressen werden automatisch erkannt insofern technisch möglich) anstelle von bislang Adressen.
Ja finde ich super. Ubiquiti macht das ja auch so, und so weit ich weiss haben sie auch eine Suche integriert. Was sinnvoll ist. Mann sollte sich das vielleicht mal so vorstellen dass Pi-Hole auch auf leistungsfähiger Hardware, und einem grösseren Netzwerk installiert werden kann. Sagen wir mal 300 Arbeitsplätze die man einschränken möchte. Auf dem Pi-Hole ist ein Client aber eine NIC, und viele Arbeitsplätze werden mehr als einen NIC haben. Dazu kommt die Peripherie wie Drucker, Netzwerkkomponenten usw, Industrielle Maschinen z.B. in der Verpackungsabteilung, und das IoT das immer mehr wächst, wo ebenfalls pro Gerät 1-2 NIC's hinzukommen. Je nach dem wie modern das Gebäude ist, landet man da schnell bei <1k NIC's.
Wen die Seite schön übersichtlich ist, und sich auf das Praktische fokussiert, ist man spätestens ab 300 NIC's am scrollen, und froh um eine Suche.
Jemand der Privat mit 10 clients (Notebook, PlayStation und TV sind schon 6) hinter seiner Fritzbox sitzt, kümmert das womöglich wenig. Aber da wo Change Control zum Einsatz kommt, ist auch das Management von toten Clients ein Thema. Soweit ich bisher gesehen habe, gibt es diesbezüglich für den Pi-Hole ebenfalls noch Potential. z.b mit einer suche für "Static DHCP leases configuration". Alternatiev bestünde ja auch die Möglichkeit dass diese Client-Management Overfläche auch wirklich wiedergibt was der Name verspricht?
Das würde für die verschlankung von pi.hole/admin/settings.php Chancen bieten. «blocklists» kann eh komplett weg, und «DHCP» bräuchte zumindest kein lease Management mehr.
M.m.n abspecken kann man aber auch im NavigationsmenĂĽ. Whitelist und Blacklist werden dev nicht mehr gebraucht. Deren Funktion Ersatz findet man unter http://pi.hole/admin/groups-domains.php
Let's continue the discussion in English as this is a more general thing. More people will be able to follow without needing to rely on the outcomes of a translator.
Ubiquiti is doing the same...
Well, there are two main differences here: 1. Ubiquiti has a large(r) number of employees and, for sure, a design team. While our userbase is really great (and this is a lot of value!) Pi-hole's codebase is mostly maintained by maybe two to three people actively writing code. And even this strongly depends on their availability as we are not earning our money through Pi-hole.
Especially as the design team is missing, we try to come up with good solutions, however, again, none of the main code contributors is employed in the IT/network management sector so we don't know the tools many users are talking about. I, for instance, have never seen a Ubiquiti device in real life and, likewise, I have no idea how the interface may look like from your description.
I can very well understand your enthusiasm for a "all-in-one" network management solution Pi-hole could offer, however, things are on the very edge of really escalating here.
Firstly, Pi-hole is not (and should not become) a network management tool. Something like this needs a lot more manpower PLUS should run on a router. The more we offer network tools, the more support we will be providing on network management, host names, MAC IDs, IPv6, etc. Almost all of this is unrelated to the core function of adblocking. What started as a simple tool to show users a quick overview of their network so they can identify clients not using Pi-hole is escalating in your request to become a "one-for-all" thing to also manage DHCP static leases.
As I said above, I can see the network overview becoming a replacement of the currently existing groups-clients management page as it makes it easier for users as they are thinking more in terms of devices rather than single addresses. I can see this and we're trying to find the best approach in the background.
However, we're certainly at a point where the core team is severely loaded with support requests already know and you see what this leads to: More and more feature requests, we try to address most of this, at least we always take our time to reply with more than simple "No, will not happen." and, in the end, there is no time left to do actual coding in the hour we can take away from our family time after work. This is no meant as a complaint, more to put things into perspective.
Users with only a few devices may not care too much, however, places using change control need to care about "dead" devices as well.
This is about deploying Pi-hole on a large scale with potentially hundreds of clients, maybe even separated in VLANs. We try to make Pi-hole as good as possible for every possible environment, however, and especially because we are not getting paid for our "product" (which would allow to hire people for coding stuff), I have the feeling that we're coming to a point where we have to say: So far and no further.
We know from reports that Pi-hole has been used on large-scales in businesses with hundreds of clients and everything works really well. However, please keep in mind that Pi-hole was never intended to work on these scales. The main idea was is and will be to have a system running for small-scale networks on low-end hardware in typical at-home kind of networks. The fact that we realize Pi-hole in such a way that it uses minimal resources allows you to go to large scales given you use suitable hardware. That's possible but - by no means - an intended feature.
We simply cannot process the incoming support workload. If more people with good networking knowledge were to participate, okay, however, the current team of people contributing on a daily basis for a sufficiently long time to say that they'll stay for longer is less then ten people. This is not enough.
Blocklists can be removed altogether, if the network table is redesigned, DHCP lease management isn't needed, either.
Lease Management is simple and proven to work. My explanation why I don't want to see it in the network table is partially above, already above. As said, Pi-hole is still intended for the home network. It is furthermore intended as a starting project. Many (most?) users new to Pi-hole use it as their first Raspberry Pi project. Many even as their first Linux and networking project. The interface has to be as clear and easy as possible. I know that there's some room for improvement on the current interface, however, I wanted to add the per-client feature as it was requests for such a long time. And I think we're on a good way to get there.
The DHCP server was never meant to be used on any large networks. I implemented it some years ago for those routers where you cannot change the DNS server announced to the routers (I had the Deutsche Telekom Speedport at home at this time). That's the reason for its existence. Even adding static leases is something we probably shouldn't have done: why would you care for IP addresses to stay constant? You should really use host names to contact devices also to ensure more simple migration if ever needed. But this was requested by a lot of users and, in the end, we implemented it for them because it was not much work.
The navigation menu can be trimmed down, like removing Whitelist and Blacklist.
When comparing these with the Groups-domain management page, you'll see a subtle difference: The groups-domain page can change domains between white- and blacklist types and add to both types of list + mange the groups. This is a more difficult thing for users and the decision was to keep two more simpler pages so users can use the Pi-hole as before when they do not want to wrap their heads around per-client blocking. I, for instance, don't care myself. All my devices block the same stuff, I see no need for per-client differences, but tastes differ and that's okay.
TL;DR
Pi-hole is dangerously close to a "one-for-all" network management tool. We have to stop this or we will completely swamped by support questions by users doing networking for the first time and asking us how to realize complex setups with guest networks, split-horizon, IPv6 tunneling and whatnot. This will bring its development to a halt.
The network overview page already got very complex now. If you are working in IT or if this is your hobby, you may see this differently. I don't find it complex, too, but I wrote the code for it.
We will likely (<- not promised!) replace the current groups-client interface by the network overview + group assignment selection. Everything beyond this will be too much.
Pihole should not go down this way if there is not enough man-power and time to deal with all the support requests that it will generate. I can see already a lot of requests that turn out to be related to network design in general rather pihole specific. If you want to keep this awesome forum you should wisely think about which doors you want to open. I'm always amazed how many hours all of the devs and moderators spend answering the questions. I think this is really unique for pihole - I've never seen this dedication in any other software product. I've nudged a lot of feature requests in different directions myself but I would not be sad if features would not be implemented because developers dedicate their time to help others on the forum. I think it's better that everyone have a running pihole system instead of a few users get all the features they want and others left behind.
Of course you could stop dev support and sole focus on development and have the users answer their questions only by other users.
I can already see that developers can't catch up with issues and pull requests - some date back >2 years. My non-dev view on how to proceed: release v5.0, take care of open issues and PRs (that also shows people and contributors that you care), and then continue to implement new features. Just my 2 cents.
wtf? I was never talking about that or anything like that. I'll get back to you later, but for the first time I'm going to eat something. I am starving!
Back
@DL6ER So I have put a lot of effort into understanding what you have written so extensively. But honestly, I have no idea what you're talking about. I never discussed 80% of what you're talking about. I hate all-in-one, I can't stand Fritz boxes. It is one of the worst things possible, and I really hope that you will not go this way.
By the way, if you think v5 is close to an all-in-one network management tool, you're completely wrong. Fortunately, it is still very, very faaaaaaaaaaaar from it.
The comparison with Ubiquity
Ubiquity does some things differently than they usually do. A large collection of these can be found in the "UniFi Network Controller". There are in for Windows, Mac and Linux. I ask you to download the controller, install it on your desktop, and study. UniFi - Rethinking IT - Ubiquiti
My request applies in particular to the UNC client manager (/ manage / site / default / clients / 1/50). I had to think about it immediately when you wrote about a possible client manager for the Pi-Hole. You should really take a look at it and steal it for your pi-hole. This is exactly what you are looking for and makes the current DHCP lease solution for the Pi-Hole completely useless.
Regarding IT skills: Sorry I didn't know that. I agree with you that the voice of a network admin would be worth something for you -> if it were heard.
The only thing left for me to do is to take off my hat and pay my respects.
Really great work! Stay focused and keep going.
Remember: it is always better to remove something half-baked than to circulate something bad.
In the newly opened window, the first and the last folder are particularly interesting. The first folder shows that the client is recorded as a whole. In the last folder, the alias, the network membership and the static DHCP address can be set. The reason why I think that the current DHCP solution from the Pi-Hole could also be organized differently.
Network affiliation: In your case, this could be the domain. But could also offer a multi-network (multiple IP ranges) DHCP. Without routing NAT and all that, all just DHCP.
I cannot click on a client as such, but rather on different columns of a row that represents a client, resulting in different UI reactions when clicking on e.g. name, ap/port or uptime.
None of them brings up the folders you mention, the closest resemblance to your description being a click on name.
Specifically, I do see some client data, but not any of the alias, network membership or static DHCP address you mention, and I cannot edit anything:
So maybe the UniFi Network Controller you mention is different from UniFi Controller?
Also, UC is able to accumulate its data through actively communicating with equipment that allows to query that kind of data, i.e. Unifi products.
The same level of detail is not available if you were to use APs, switches or routers of different brands, which is a lot more like the situation Pi-hole has to cope with.
No, we do not think that.
DL6ER just made clear that we don't want to add any more features that will move Pi-hole towards that end, focussing development on its core features instead.
By the way, since you understood that Pi-hole's core feature is DNS filtering, not DHCP (as DL6ER has gone at great lengths to explain), why do you continue to advocate DHCP features?
No! They do some things differently - unlike HP, Cisco, etc
No. Just keep going you're already on the right track.
Do you want to make the Pi-Hole better or keep it as is? If you want to make it better then there are two ways: make it fatter and more powerful, or make it leaner and faster. Whichever path you choose, stay focused and always consider pi-hole as a whole.
If you don't want a DHCP, why is it there? Why do you replace lists with a performance-eating database? Why do you integrate a DNS forwarder instead of a DNS resolver? Why don't you sign DNSSEC yourself using Let's encrypt? Why do you recommend third-party Free and Public DNS servers from somewhere if you can use hyperlocal to move the internet root zone directly to your Pi? - If you use a Pi.
And why the f** do you concentrate on the small private, instead of on companies that could support you?
To all team members: You don't have to answer, I realy don't care. I don't want anything from you either. Answer yourself and decide what you want. Pi-Hole is your project.
