Ja, lief komplett glatt durch, wie auf der homepage von pihole beschrieben.
Unbound test: die Befehle
dig kuketz-blog.de @127.0.0.1 -p 5335 +short
dig sigfail.verteiltesysteme.net @127.0.0.1 -p 5335
dig sigok.verteiltesysteme.net @127.0.0.1 -p 5335
liefern die gleichen Antworten wie bei pihole v5.
RaspberryPi3 mit debian bookworm.
Hallo.
Auch ich kann keinen Web-Admin-Zugriff herstellen.
Ich befürchte, dass der RPi schon zu alt ist? ( Raspberry Pi Model B Rev 2 )
Jedenfalls scheint das update nicht vollständig durchgelaufen zu sein.
Ich erhalte die Fehlermeldung:
This processor architecture is not supported by Pi-hole (v5TE) [i] Downloading and Installing FTL...curl: (3) bad range in URL position 70:
Ich kenne mich nicht so gut damit und mit Linux aus, aber wenn man
pihole -d
eingibt steht irgendwo:
✓ armv6l
Etwas weiter später:
X-Header does not match or could not be retrieved
Das pihole blocking funktioniert aber gut. Nur der Web-Server lässt sich nicht aufrufen.
Ein curl -IL http://localhost/admin/ gibt mir u.a. „Forbidden“.
Ich habe dann, wie ich bei @bummelstein gelesen habe, eingegeben:
# systemctl disable --now lighttpd
Danach gibt ein
curl -IL http://localhost/admin/
curl: (7) Failed to connect to localhost port 80 after 5 ms: Couldn't connect to server
uname -a
Debian 6.1.128-1
Weiss jemand was ich jetzt tun kann?
Vielen Dank !
An der Raspberry Pi Hardware liegt es nicht. Auch ich betreibe Pi-Hole auf einem Raspberry Pi Model B Rev 2 und bei mir hat das Update problemlos funktioniert.
Allerdings bin ich auch auf dem aktuellen Raspbian OS (Debian Bookworm).
Kernel 6.1 bei dir sieht mir noch nach Bullseye aus. Vielleicht probierst du mal ein Upgrade des OS.
Via ssh…
lighttpd deaktivieren
/etc/pihole/pihole.toml aufrufen und die IP Adressen anpassen
mit pihole -a -p ein neues Passwort für die Weboberfläche setzen. Das alte funzt nicht mehr.
Die Weboberfläche am besten mittels IP aufrufen.
Dort muss dann in den Settings auch die unbound Adresse wieder eingetragen werden.
Hallo,
bei mir läuft eine DietPi Version, die ich vor dem Pihole Upgrade auf 9.10.0 geupgradet habe. Hier wurde u.a. der Kernel geupdatet (Bookworm). Danach lief das Pihole-Update ohne Probleme durch. Die Weboberfläche ist danach nur noch über https aufrufbar. lighthttp habe ich im Anschluß via Dietpi-Software deinstalliert.
Das Passwort wird mit seit V6 mit
pihole setpassword
geändert. pihole -a -p geht nicht mehr.
Hallo Leute, zunächst mal vielen Dank für eure Antworten!
Entschuldigt bitte meine verspätete Rückmeldung, musste einiges erledigen, wenn ich Zeit hatte dann nur sehr spät abends oder gar nicht.
Ich habe mich entschieden V6 direkt auf einen etwas neueren Pi zu installieren.
Raspberry Pi 3 Model B Plus Rev 1.3
Aber auch da gibt es einige Schwierigkeiten!
Retrieval of supported OS list failed. dig failed with return code 10.
Unable to determine if the detected OS (Debian 12) is supported
Als Lösung für dieses Problem wird vom Installations-Skript selbst folgendes vorgeschlagen:
curl -sSL https://install.pi-hole.net | sudo PIHOLE_SKIP_OS_CHECK=true bash
Hab ich gemacht, funktionierte auch - aber heißt das nicht letztenendes, dass es irgendwie Netzwerk-Probleme gibt ?
Dieses Problem habe ich jetzt auch beim Updaten des Piholes.
Wie werde ich das wieder los?
Was ich auch blöd finde, ist: die Teleporter-Datei lässt sich nicht vom alten Pi (V5) auf den neuen übertragen, es heißt beim Importieren:
The uploaded file does not appear to be a valid Pi-hole Teleporter archive
Dabei hatte ich sie vorher mittels:
pihole -a -t
erzeugt
Weiß jemand, was ich nun tuen könnte?
Vielen Dank !
Hallo Mike,
ich habe eine frische Debian 12 Installation (in einer VM) und pihole6 mit Deiner Anleitung (Teil 1) gerade erfolgreich installiert.
Im Anleitung Teil 2 läuft unbound bei mir erst wenn ich
service unbound start
eingebe. Nach einem reboot muss ich es leider wieder eingeben. Was muss ich ändern, damit unbound gleich mit pihole mitstartet?
VG, vsa
Könnte sein. Es könnte aber auch an der Gegenseite liegen, dass diese gerade nicht verfügbar war/ist.
Kann es sein, dass deine DNS-Namensauflösung gerade nicht richtig funktioniert? Klappt es, wenn du temporär einen externen Nameserver verwendest (z. B. in /etc/resolv.conf die Zeile nameserver 9.9.9.9 eintragen)?
Nicht mit Pi-hole, aber mit dem System:
systemctl enable --now unbound
enable lässt Unbound beim Booten starten, mit --now wird es zusätzlich auch in dem Moment gestartet.
gestern das pihole update angestoßen. Lief ohne Probleme durch. Auch Unbound läuft weiterhin ohne Probleme.
Das ganze auf einem Raspi 3b+ mit Dietpi v9.11.2
Bei mir ist das Update auch problemlos durchgelaufen auf Raspi 3B+ mit Bullseye
4 Beiträge wurden in ein neues Thema verschoben: DNSSEC-Problem von Adguard Home + Unbound unter OpenWRT
Hallo,
ich habe eine Frage zu diesem Abschnitt:
[…] Debian Bullseye-Releases installieren automatisch ein Paket namens openresolv mit einer Konfiguration, die zu unerwartetem Verhalten in Kombination mit dem Pi-hole und unbound führt. Der unbound-resolvconf-Service weist resolvconf an, unbound als Nameserver in die Datei /etc/resolv.conf einzutragen – allerdings nur mit 127.0.0.1 ohne Angabe des benötigten Ports 5335. Lokale Dienste und Prozesse verwenden die Konfigurationsdatei, um den DNS-Server zu ermitteln. Der fehlende Port führt dazu, dass die DNS-Anfragen unbeantwortet bleiben.
[…]
Ist es richtig, dass in /etc/resolv.conf der Port 5335 angegeben werden muss?
Ich habe bisher keine andere Quelle gefunden, die das bestätigt.
Meine /etc/resolv.conf sieht entsprechend so aus (gemäß Arch Linux Wiki):
$ cat /etc/resolv.conf
# Generated by resolvconf
nameserver ::1
nameserver 127.0.0.1
options edns0 trust-ad
Eine weitere Frage bezieht sich auf diesen Abschnitt:
[…] Diese Unabhängigkeit geht derzeit leider noch mit unverschlüsselten DNS-Anfragen (via UDP/TCP) einher, da die Root-Nameserver selbst Protokolle wie DNS over TLS (DoT) und auch DNS over HTTPS (noch) nicht unterstützen.<
Ist diese Aussage aktuell gültig?
Oder kann man inzwischen DoT nutzen?
Nein, denn dann würden DNS-Anfragen, die vom Pi selbst kommen, an Unbound gehen und Pi-hole übergangen. Und Pi-hole nimmt seine Upstream Nameserver nicht aus /etc/resolv.conf.
Ja.
Unbound kann so konfiguriert werden, dass DoT gemacht wird.
Ist diese Konfiguration empfehlenswert? Oder sollte man davon Abstand nehmen?
Das ist (auch) mein Verständnis.
Damit wäre allerdings der zitierte Abschnitt inhaltlich nicht korrekt.
Kommt drauf an, was du erreichen willst. Jedenfalls gehen all deine Anfragen so wieder nur an einen Nameserver.
Stimmt.
Aber ein den einen Nameserver, den ich definiere und mit DoT.
Moin zusammen,
habe auch noch das „alte“ Setup nach tschaegger in Betrieb aber muss nun updaten.
Damals gab es im Setup noch die Einstellung, dass der gesamte Speicherplatz der SD Karte genutzt werden soll - gibt es diese weiterhin oder ist das mittlerweile entfallen und nicht mehr notwendig?
Habe dazu in Mikes Tutorial jedenfalls nichts zu gelesen.
Danke + Gruß
Das passiert mittlerweile ganz automatisch, zumindest bei Debian – dann wird es bei Rasperry Pi OS wohl auch so sein.