Interesant wäre ein Info Bereich in dem tote Blocklisten stehen die bei einem Listen Update nicht geladen wurden.
3 Likes
This is shown in the output of pihole -g and in the log record of your weekly gravity update:
/var/log/pihole_updateGravity.log
Wenn ein Update Gravity gemacht wird kann man die sehen entweder ein grüner Hacken oder ein toten Link.
Wenn man das Update manuell macht weiss ich das man es sieht.
In der Regel passiert das Listen Update ja einmal die Woche automatisch und da bekommt man es ja nicht mit.
Mit dem log File ist klar aber da muss man halt immer in die Komando Zeile.
Schön wäre es das über die Oberfläche sehen zu können.
@DL6ER Wäre das nicht etwas für das "Diagnostik System" von FTL? Wenn ein entsprechender Eintrag in /var/log/pihole_updateGravity.log auftaucht, dann auch eine Meldung in die Datenbank übernehmen?
Dann wiederrum müste man aber die gesamte liste Stück für Stück durchgehen. Man hätte nicht sofort die Gesamt Übersicht über die nicht geladenen Listen.
Ja, prinzipiell keine schlechte Idee, wir müssten den letzten Status dafür nur in einer extra Spalte in der adlist Tabelle speichern.
Es gibt mehrere Möglichkeiten, die aus den jetzt vorhandenen Daten nicht abgeleitet werden können, die sich hier lohnen zu unterscheiden:
- Download ok, Liste ist somit aktuell - GRÜN
-> Gut - Download nicht nötig, da sich die Liste nicht geändert hat - BLASSGRÜN
-> Gut - Download fehlgeschlagen, es ist aber noch eine lokale Kopie vorhanden - GELB
-> Okay, aber vielleicht stimmt hier auch etwas nicht - Download fehlgeschlagen, die lokale Kopie ist älter als 2 Wochen - ORANGE
-> Immer noch okay, aber man könnte sich nach einer Alternative umsehen - Download fehlgeschlagen, es ist keine lokale Kopie vorhanden oder die lokale Kopie ist älter als 4 Wochen - ROT
-> Diese Liste kann nun endgültig in den Müll
Also ich sag mal wie ich mir das vorgestellt habe, ob es realisierbar ist weiss ich nicht und was ihr macht liegt natürlich an euch.
Ich dachte es gibt z.b. unter dem Menüpunkt Adlist einen neuen Menüpunkt z.b. Nicht ladbare Listen.
Bei jedem Update der Listen, egal wie geupdatet wird, werden hier die listen in einer Tabelle eingetragen die nicht ladbar sind.
Diese Liste wird auch immer aktualisiert, das heist entweder neue kommen hinzu oder welche die drinstehen aber doch wieder ladbar sind werden gelöscht.
Das ist meine Idee, mal sehen was enstehen wird.
Ich denke auch, dass ein einfacher zusätzliche Klecks Farbe irgendwo in der existierenden Seite einfacher und für die Nutzer auch einfacher zu verstehen ist. Umso mehr einzelne Unterseiten es gibt, umso mehr Details können auch verloren gehen. "Alles auf einen Blick" und dabei gleichzeitig nicht überladen sein, ist was ich derzeit anstrebe. Mal schauen, was am Ende heraus kommt 
So, bitte testen und ich freue mich über Rückmeldungen:
pihole checkout core new/gravity_adlist_infos
pihole checkout web new/gravity_adlist_infos
Dieser Versuch sollte möglichst Touchscreen-kompatibel sein. Weitere Infos zu den jeweiligen Listen gibt es wenn man auf das farbige Icon klickt:
Ich habe die Listen nun auch zu klickbaren Links umgewandelt, damit man schneller nachschauen kann, wieso eine Liste nicht funktioniert, z.B. in diesem Fall:
[i] Requested branch "new/gravity_adlist_infos" is not available
Hmm, bitte erneut versuchen, ich habe den Branch noch einmal auf den Server hoch geschoben.
Supi - Funktioniert jetzt einwandfrei. Vielen Dank
Screenshot des aktuellen Entwicklungsstands, den Ihr mit obigen Befehlen abholen könnt:
Bei Vorliegen von ungültigen Domains auf einer Liste, gibt es ein Warndreieck und ein bisschen Farbe dazu:
(diesmal mit hellem Hintergrund)
2 Likes
Ich kann nur sagen großartige Idee und großartige Umsetzung! Vielen Dank!
Gruß
MothersCoffee
Sehr schöne Umsetzung, vielen Dank.
Ein paar Gedanken:
-
Number of invalid domains on this list: 0
wird im Dashboard rot angezeigt. Bei0wäre grün schöner. -
Es wäre toll, wenn man die Tabelle nach dem "Status" sortieren könnte
-
Die Links sollten sich in einem neuen Fenster/Tab öffnen
Etwas weiter ausgeholt:
Du verwendest die Formulierung "The list contents were last updated". Das weiß Pihole jedoch streng genommen nur für Listen, die einen entsprechenden http header mitliefern (was z.B. https://raw.githubusercontent.com nicht macht). Ich hatte vor einige Zeit entsprechende Feature Requests geschrieben (z.B. hier und hier) , dass Pihole zusätzlich noch die (falls vorhanden) lokale Kopie der Liste nutzen und vergleichen könnte, um festzustellen, ob sich der Inhalt wirklich geändert hat.
Evt. ist das etwas, dass du aufnehmen möchtest/könntest im Zuge der aktuellen Änderungen.
Das ist natürlich ein Fehler. 
Das kann ich dem Browser ja nur vorschlagen, was er dann macht obliegt seiner Philosophie.
Ja, hmm, ja. Eigentlich könnten wir das schon machen. Heruntergeladen (= Datenvolumen verbraucht) werden sie ja eh. Stellt sich die Frage, was hat eine höhere Performance? sha1sum, ein bloßes diff oder reicht uns ein Dateigrößenvergleich aus Byteebene (das wäre natürlich instantan und ohne irgendwelche Arbeit auch auf einem RPi). md5sum hat nachweisbare Kollisionen und es wird seit Jahren von MD5-Dateihashing abgeraten.
edit: Ich denke sha1sum ist das Mittel der Wahl in diesem Fall.
Huh?
nanopi@nanopi:~$ sqlite3 /etc/pihole/gravity.db -header -column "Select * from adlist where id=13"
id address enabled date_added date_modified comment date_updated number invalid_domains status
---------- -------------------------------------------------------------------------- ---------- ---------- ------------- ---------- ------------ ---------- --------------- ----------
13 https://raw.githubusercontent.com/r-a-y/mobile-hosts/master/AdguardDNS.txt 1 1579547647 1606251436 1609183647 38989 -1
[i] Target: https://raw.githubusercontent.com/r-a-y/mobile-hosts/master/AdguardDNS.txt
[✓] Status: Retrieval successful
[i] Analyzed 38989 domains, -1 domains invalid!
Betrifft nur diese eine Liste.
Das Optimum wäre sicher, einen wirklichen "Inhaltsvergleich" zu machen, d.h. haben sich die (gültigen) Domains auf der Liste geändert? Aber das ist sicher overkill.
Prinzipiell wäre wahrscheinlich ein diff gut, weil es einem Inhaltsvergleich nahe kommt. Bei sha1sum kenne ich mich nicht aus, inwiefern das schon auf ein einzelnes geändertes Byte reagiert. Das wäre im Zweifelsfall zu sensitiv.
Ja, sha1sum ist byte-orientiert. Ich denke das sollte ausreichen, bei einem einfachen diff wäre es auch nicht anders (eine Änderung ist am Ende eine Änderung). Ich habe das heute morgen schon implementiert und comitted (ich antworte gleich auch in der anderen Diskussion).
Ja, bei mir:
[i] Target: https://raw.githubusercontent.com/r-a-y/mobile-hosts/master/AdguardDNS.txt
[✓] Status: Retrieval successful
[i] Analyzed 38989 domains
$ sqlite3 /etc/pihole/gravity.db -header -column "Select * from adlist where id=13"
id address enabled date_added date_modified comment date_updated number invalid_domains status
---------- --------------------------------------------------------- ---------- ---------- ------------- ---------- ------------ ---------- --------------- ----------
13 https://zerodot1.gitlab.io/CoinBlockerLists/hosts_browser 1 1609225139 1609225139 1609225150 166749 0 2
Da ist bei Dir aber auch das status Feld leer, das sollte auch nicht passieren können.
