Nach updaten auf Pihole v5, zeigt das Dashboard nichts an

[Schultze]

@Bucking_Horn

In der Tat haben wir in Deinem Debug Log ein paar Ungereimtheiten in Deiner Netzwerkonfiguration:

Gateway und Pi-hole befinden sich nicht im gleichen Subnetz (*192.168.**41***.1 vs. *192.168.**42***.3)

Der Rechner hat zwei NICs, er ist in beiden Netzen. Das eine (42) ist mein internes Netzwerk, das andere (41) geht nur zum Kabelrouter.

Zudem taucht eine link-lokale IPV4-Adresse (aus 169.254.0.0/16) auf eth0 auf, und eine solche Adresse wird eigentlich nur automatisch vom Gerät selbst vergeben, wenn anderweitig keine gültige IP beschafft werden konnte.

Wo die herkommt, weiß ich nicht. Beide Interfaces bekommen eine statische Adresse zugewiesen.

Das legt nahe, dass Du vielleicht eine fehlerhafte statische Adresse verwenden könntest.
Was gibt folgendes Kommando auf Deiner Pi-hole-Maschine zurück:

grep -v '^#\|^$' /etc/dhcpcd.conf

root@dalmore:~# grep -v '^#|^$' /etc/dhcpcd.conf
hostname
duid
persistent
option rapid_commit
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
option interface_mtu
require dhcp_server_identifier
slaac private

Schultze

[yubiuser]

@Schultze

Sieht alles gut aus, bringt aber nichts:

Irgendwie scheint er die gravity.db nicht angelegt zu haben..

[Schultze]

@Bucking_Horn

In der Tat haben wir in Deinem Debug Log ein paar Ungereimtheiten in Deiner Netzwerkonfiguration:
...
Zudem taucht eine link-lokale IPV4-Adresse (aus 169.254.0.0/16) auf eth0 auf, und eine solche Adresse wird eigentlich nur automatisch vom Gerät selbst vergeben, wenn anderweitig keine gültige IP beschafft werden konnte.

Ich habe die APIPA-Adresse nun gelöscht und pihole-FTL neu gestartet. Macht keinen Unterschied, aber wieso eth0 diese Adresse bekommt ist mir nicht klar.

Schultze

[Bucking_Horn]

@Schultze

Macht keinen Unterschied, aber wieso eth0 diese Adresse bekommt ist mir nicht klar.

@Bucking_Horn

eine solche Adresse wird (..) vom Gerät selbst vergeben, wenn anderweitig keine gültige IP beschafft werden konnte.

Das kann man leicht nachvollziehen, wenn man z.B. einem Rechner das Netzwerkkabel abzieht. Vielleicht ist das irgendwann mal passiert.

Auf welcher Hardware läuft Dein Pi-hole?
Nicht zufällig ein Pogoplug?

[Schultze]

Die Adresse scheint jedenfalls nicht gestört zu haben.

Die Hardware ist armbasiert ein armv5tel, genauer ein OpenRD von Globalscale.

pihole-FTL habe ich selbst kompiliert, damit es auf dem System läuft. Vor dem Upgrade lief es ja auch.

[Bucking_Horn]

@Schultze

pihole-FTL habe ich selbst kompiliert, damit es auf dem System läuft.
Vor dem Upgrade lief es ja auch.

Wenn Du pihole-FTL selbst kompiliert hast, dann wirst Du für die Installation von 5.0 wohl auch wieder aus den Sourcen kompilieren müssen.

(Daher auch die Frage nach dem Pogoplug, für den das in Is gravity.db missing in v5.0? - #36 by bluzfanmr1 ebenfalls die Lösung war.)

[Conan179]

Ich hatte es NACH der veröffentichung von v5 kompiliert.

[Schultze]

@Bucking_Horn

Wenn Du pihole-FTL selbst kompiliert hast, dann wirst Du für die Installation von 5.0 wohl auch wieder aus den Sourcen kompilieren müssen.

Ja. Eben. Habe ich ja auch gemacht. Sonst würde es gar nicht laufen. Und so wie das sehe, läuft es ja. DNS und DHCP funktionieren.

(Daher auch die Frage nach dem Pogoplug, für den das in Is gravity.db missing in v5.0? - #36 by bluzfanmr1 ebenfalls die Lösung war.)

Hm, die Beschreibung sieht aber ganz anders aus.

Good, but now I can't change anything. Permission denied.

In den Settings kann ich Werte verändern.

[Conan179]

Also bei mir sieht es so aus:

Wen ich jetzt per root
touch /etc/pihole/gravity.db mache, sieht die seite so aus:

Jetzt habe ich von meinem reserve innstallation von meinem pi, die gravity.db auf die nas kopiert und er blockt fleisig vor sich hin.
ABER wen ich die Gravitiy akt. wird sie NICHT geändert sondern die /etc/pihole/gravity.list

Jetzt müste man herausfinden, warm die selbst kompilierte version
(root@Qnap-NAS:~# pihole-FTL -v
v5.0
root@Qnap-NAS:~#)
sich anders verhält als eine fertige version.

[Bucking_Horn]

@Schultze

( Daher auch die Frage nach dem Pogoplug, für den das in Is gravity.db missing in v5.0? ebenfalls die Lösung war. )

Hm, die Beschreibung sieht aber ganz anders aus.

@Schultze

Die Datei /etc/pihole/gravity.db existiert nicht!

In beiden Fällen geht es um eine fehlende gravity.db auf armv5tel; um die außerdem in Deinem Fall abweichende Netzwerkonfiguration haben wir uns ja bereits gekümmert.

Da pihole-FTL bereits von euch kompiliert wurde, funktioniert nun vielleicht auch folgendes, um die DB neu aufzusetzen:

pihole -g -r

[Conan179]

@Bucking_Horn

Da pihole-FTL bereits von euch kompiliert wurde, funktioniert nun vielleicht auch folgendes, um die DB neu aufzusetzen:

pihole -g -r

@Conan179

ABER wen ich die Gravitiy akt. wird sie NICHT geändert sondern die /etc/pihole/gravity.list

da hab ich schon was herausgefunden.

[Schultze]

@Conan179

da hab ich schon was herausgefunden.

Was hast Du denn herausgefunden?

[Schultze]

@Bucking_Horn

Da pihole-FTL bereits von euch kompiliert wurde, funktioniert nun vielleicht auch folgendes, um die DB neu aufzusetzen:

pihole -g -r

Das FTL hatte ich bereits vor dem Upgrade mit 'pihole -up' kompiliert und nach dem Upgrade nach /usr/bin/ kopiert.
Alle hier beschriebenen Probleme bestehen also nach der Kompilation. Wie von Conan179 beschrieben, habe ich nun auch eine gravity.db erzeugt und bekomme nun wenigstens eine Anzeige. Ein 'pihole -g -r' bringt keine Änderung.

Den Owner der /etc/pihole/gravity habe ich auf 'pihole' geändert, bringt aber auch nix. Wie bekomme ich nun irgend etwas in die Blocklist?

[jfb]

Please upload a new debug log and post the new token.

[Conan179]

Bitte schön:
https://tricorder.pi-hole.net/8dnl1vtwng

[Schultze]

Und hier meines: https://tricorder.pi-hole.net/vdggg0zp5d

[Schultze]

Habe eben etwas seltsames gefunden. Unter /var/log/ fand ich folgende Dateien:

-rw-r--r-- 1 pihole pihole 706M May 15 20:18 /var/log/pihole.log
-rw-r--r-- 1 pihole pihole 71M May 15 00:00 /var/log/pihole.log.1
-rw-r--r-- 1 pihole pihole 2.7M May 14 15:17 /var/log/pihole.log.2.gz
-rw-r--r-- 1 pihole pihole 12M May 14 14:29 /var/log/pihole.log.3.gz
-rw-r--r-- 1 pihole pihole 16M May 14 00:00 /var/log/pihole.log.4.gz
-rw-r--r-- 1 pihole pihole 218K May 13 00:00 /var/log/pihole.log.5.gz

Interessant finde ich die Größe der Files. Das vom 13. Mai, vor dem Upgrade ist ziemlich klein, nach dem Upgrade werden die Files ziemlich groß.

[Conan179]

Schultze
https://wiki.ubuntuusers.de/Logdateien/#Logrotate
Normales verhalten von logrotate.

[Schultze]

Das scheint mir Unfug zu sein. Warum ist das eine Logfile 200k groß und das nächste 16m?

[Conan179]

Dann öffne die logsfile und schau nach was drin steht, allein die grösse sagt null aus, der inhalt ist das wichtige und da kannst nur du rein schauen.