Info über tote Listen

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:

  1. Download ok, Liste ist somit aktuell - GRÜN
    -> Gut
  2. Download nicht nötig, da sich die Liste nicht geändert hat - BLASSGRÜN
    -> Gut
  3. Download fehlgeschlagen, es ist aber noch eine lokale Kopie vorhanden - GELB
    -> Okay, aber vielleicht stimmt hier auch etwas nicht
  4. Download fehlgeschlagen, die lokale Kopie ist älter als 2 Wochen - ORANGE
    -> Immer noch okay, aber man könnte sich nach einer Alternative umsehen
  5. 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 :slight_smile:

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:
Screenshot from 2020-12-27 20-50-41

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:
Screenshot from 2020-12-27 20-55-11

  [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:

Screenshot from 2020-12-28 10-58-28

(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:

  1. Number of invalid domains on this list: 0
    wird im Dashboard rot angezeigt. Bei 0 wäre grün schöner.

  2. Es wäre toll, wenn man die Tabelle nach dem "Status" sortieren könnte

  3. 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. :white_check_mark:

:white_check_mark:

Das kann ich dem Browser ja nur vorschlagen, was er dann macht obliegt seiner Philosophie. :white_check_mark:

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?

Bildschirmfoto zu 2020-12-29 09-53-28

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.

Screenshot from 2020-12-29 20-32-43

Super!

-1 ist behoben und der Diff funktioniert auch. Alle Listen bekommen beim zweimaligen Abrufen jetzt den Status "List unchanged".

Eine kleine kosmetische Sache: Ich würde das "This list is new" ersetzen durch "No checksum available for this list, creating one"

Ja, genau das stand da zwischendurch schon, dem Nutzer kann es aber eigentlich egal sein und ich frage mich, ob das mehr Fragen aufwirft. So würde ich diesen Kommentar am liebsten auch einfach weg nehmen. Dennoch ist er wahr. Nur für "neue" (im Sinne von "wurde vorher noch nicht herunter geladen") Listen kommt der Kommentar. Und auch dann nur einmal.

Danke für dieses Addon. Tolle Idee.

Kann ich in Zukunft einfach so Pi-hole updaten oder muss ich vorher dieses Update deinstallieren? Wenn ja, wie mache ich das?

(Error-Problem gelöst. Danke an msatter)

Letzteres. Pi-hole bleibt nach einem Checkout-Befehl auf diesem Entwicklungszweig stehen. Das ist so beabsichtigt. Man kann jederzeit zur "Hauptversion" zurückkehren, indem man

pihole checkout master

ausführt.

1 Like

Wird diese Darstellung und Check der Adlists in den Master übernommen?