Info über tote Listen

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

Zuerst wird der Zweig von den anderen Entwicklern geprüft und für die Aufnahme in den "allgemeinen" Entwicklungszweig freigegeben. Darin sammeln sich alle Änderungen, die für die nächste Pihole Version vorgesehen sind. Irgendwann wird dann ein Abbild des aktuellen, allgemeinen Entwicklungszweig in den Master übernommen.
Dann wären da auch diese Änderungen dabei.

1 Like

Good catch! This should work when you yousing a browser locally on your Pi-hole. From other computers, this will not work. I will look at disabling a link in this case.

They are checksums on the files they refer to (filename without the extra .sha1). This is expected and useful IMO. This is also the natural way to use sha1sum as we can just use sha1sum --check $filename. When storing in the database, we'd need extra parsing of the output of the sha1sum command to extract the relevant part only and verify there was no error. And then the save from the database back into the command. I'd say the way we have right now is better. But I'm always open for suggestions/discussions. :slight_smile:

Diese Funktion wird nun von

und

implementiert. Ihr könnt Euch dort über den jeweils aktuellen Stand informieren.

1 Like

Eine Idee habe ich noch:
Ein Maus-Overlay (Tooltip), der mir die "Erklärung" des Symbols anzeigt, wenn man länger über dem Symbol schwebt, also z.B.

Health status of this list: List unchanged upstream, Pi-hole used a local copy (OK)

Vielleicht noch verbunden mit "Click for more info"

Danke für den Vorschlag, aber wir wollte ja eigentlich weg von Tooltips um die Diskriminierung von Touchscreen-Nutzern zu reduzieren :wink: Ich habe dennoch einen (generischen) hinzugefügt.
Screenshot from 2021-01-06 13-26-51

Eine Tabelle am Ende der Seite erschiene mir für diesen Zweck dienlicher, am Ende ist es aber vermutlich nur vergeudeter Platz, da jeder die Bedeutung der Icons schnell erkennen können wird.
(außerdem wäre es ein Ort, den man bei Änderung/Hinzufügen neuer Status-Icons vergessen könnte, da dies in einer anderen Quellcodedatei passieren müsste)

Ach ja, die hab ich vergessen :smiley:
Generisch ist auch gut.

Tabelle am Ende würde ich aus den von dir genannten Gründe nicht machen.