Sofern DNS verfügbar ist, läuft pihole -r auch sauber durch. Sonst ja besagte Meldungen ...
Vielleicht hat sich bei Raspian etwas zerschossen? dnsmasq hab ich mal reinstalliert - brachte aber nichts. Mehr viel mir da aber nicht ein
Hatte vor dem pihole -up gestern noch ein apt-get update/upgrade gemacht... Laut History:
Log started: 2018-08-05 23:13:37
(Lese Datenbank ... 60%
(Lese Datenbank ... 39142 Dateien und Verzeichnisse sind derzeit installiert.)
Entfernen von openresolv (3.8.0-1) ...
Vormals nicht ausgewähltes Paket dns-root-data wird gewählt.
(Lese Datenbank ... 60%
(Lese Datenbank ... 39128 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../dns-root-data_2017072601~deb9u1_all.deb ...
Entpacken von dns-root-data (2017072601~deb9u1) ...
Vormals nicht ausgewähltes Paket resolvconf wird gewählt.
Vorbereitung zum Entpacken von .../resolvconf_1.79_all.deb ...
Entpacken von resolvconf (1.79) ...
dns-root-data (2017072601~deb9u1) wird eingerichtet ...
Trigger für systemd (232-25+deb9u4) werden verarbeitet ...
Trigger für man-db (2.7.6.1-2) werden verarbeitet ...
resolvconf (1.79) wird eingerichtet ...
Neue Version der Konfigurationsdatei /etc/dhcp/dhclient-enter-hooks.d/resolvconf
wird installiert ...
Neue Version der Konfigurationsdatei /etc/network/if-down.d/resolvconf wird inst
alliert ...
Neue Version der Konfigurationsdatei /etc/network/if-up.d/000resolvconf wird ins
talliert ...
Neue Version der Konfigurationsdatei /etc/ppp/ip-down.d/000resolvconf wird installiert ...
Neue Version der Konfigurationsdatei /etc/ppp/ip-up.d/000resolvconf wird installiert ...
Created symlink /etc/systemd/system/sysinit.target.wants/resolvconf.service → /lib/systemd/system/resolvconf.service.
Trigger für systemd (232-25+deb9u4) werden verarbeitet ...
Trigger für resolvconf (1.79) werden verarbeitet ...
Log ended: 2018-08-05 23:13:44
dnsmasq wird in Pi-hole v4.0 ja durch FTL ersetzt, das sollte also keinen Unterschied machen. Irgendwie ist es sonderbar dass FTL bei Dir entweder abstürzt oder schnell beendet wird falls mit Nutzer pihole aufgerufen. Mit sudo geht es aber...
Ich habe den Thread hier seit heute Mittag verfolgt und konnte bei mir die exakt gleiche Problematik bestätigen.
Ich habe zwischenzeitlich die SD-Karte meines RPis komplettt formatiert und Raspbian Lite plus Pihole neu aufgesetzt, was aber keine Verbesserung brachte.
Ein runuser -u pihole pihole-FTL debug ging auch bei mir zunächst nicht.
Die nachfolgende Meldung tritt auch bei mir auf:
dnsmasq: cannot open or create lease file /var/lib/misc/dnsmasq.leases: Permission denied
Ich hab einfach mal testweise 'chmod 757 /var/lib/misc/' als root ausgeführt und dann nochmals 'runuser -u pihole pihole-FTL debug'.
Das Ganze scheint nun laufen, aber ich bin noch nicht zum ausführlichen Testen gekommen.
Nach einem Neustart ist die Admin-Weboberfläche zumindest da, DNS Namensauflösung funktioniert und ADs werden geblockt.
ich glaub aber die Fehlermeldung sagt hier nichts aus. In der .leases stehen die aktuellen DHCP-Lease .. und die stimmen bei mir auch (wenn dhcp sauber läuft -> also im debug).
Klappt es den bei dir auch nach einem reboot? Ich würde fast behaupten: nein.
Was genau meinst du denn nun ? Wie bereits gesagt, soweit ich das überblicken kann funktioniert alles oder habe ich was wichtiges vergessen?
Das Ganze funktioniert auch nach dem mittlerweile dritten Neustart wie gewohnt.
touch: '/var/log/pihole-FTL.log' kann nicht berührt werden: Keine Berechtigung
touch: '/run/pihole-FTL.pid' kann nicht berührt werden: Keine Berechtigung
touch: '/run/pihole-FTL.port' kann nicht berührt werden: Keine Berechtigung
touch: '/var/log/pihole.log' kann nicht berührt werden: Keine Berechtigung
chown: der Eigentümer von '/var/run/pihole' wird geändert: Die Operation ist nicht erlaubt
chown: der Eigentümer von '/var/log/pihole' wird geändert: Die Operation ist nicht erlaubt
chown: der Eigentümer von '/var/log/pihole-FTL.log' wird geändert: Die Operation ist nicht erlaubt
chown: der Eigentümer von '/run/pihole-FTL.pid' wird geändert: Die Operation ist nicht erlaubt
chown: der Eigentümer von '/run/pihole-FTL.port' wird geändert: Die Operation ist nicht erlaubt
chown: der Eigentümer von '/etc/pihole' wird geändert: Die Operation ist nicht erlaubt
chown: Zugriff auf '/etc/pihole/dhcp.leases' nicht möglich: Datei oder Verzeichnis nicht gefunden
chown: der Eigentümer von '/var/log/pihole.log' wird geändert: Die Operation ist nicht erlaubt
chmod: Beim Setzen der Zugriffsrechte für '/var/log/pihole-FTL.log': Die Operation ist nicht erlaubt
chmod: Beim Setzen der Zugriffsrechte für '/run/pihole-FTL.pid': Die Operation ist nicht erlaubt
chmod: Beim Setzen der Zugriffsrechte für '/run/pihole-FTL.port': Die Operation ist nicht erlaubt
chmod: Beim Setzen der Zugriffsrechte für '/var/log/pihole.log': Die Operation ist nicht erlaubt
unable to set CAP_SETFCAP effective capability: Operation not permitted
Passwort:
su: Fehler bei Authentifizierung
klar - es fehlt das sudo ... aber ich werde am Ende nach einen PW gefragt - ich trage da das root PW ein => Fehler ...
sudo /etc/init.d/pihole-FTL start
Not running
chown: Zugriff auf '/etc/pihole/dhcp.leases' nicht möglich: Datei oder Verzeichnis nicht gefunden
dnsmasq: cannot open or create lease file /var/lib/misc/dnsmasq.leases: Permission denied
ich hab das gleiche Problem. Hab von 3.2.1 (glaub ich) heute auf 4.0 geupdated (Raspianlite auf aktuellem Stand). Danach geht bei mir die Namensauflösung nicht mehr.
Die sudo-Befehle habe ich auch alle durch, bewirken bei mir aber gar nichts. Einmal kam sogar die Fehlermeldung, dass dnsmasq nicht gestartet werden konnte, weil der Port 53 schon verwendet wird. Stoppe ich pihole-FLT und starte dafür dnsmasq klappt die Namensauflösung wieder.
Nach einem Reboot wieder das gleiche Spiel. Laut Debug-Log wäre aber alles in Ordnung und pihole -r bewirkt bei mir auch nichts...
Web-Interface geht wieder und zeigt auch an, dass FTL läuft. Wenn ich dann beispielsweise web.de aufrufen will, kommt nur ein Fehler, dass der Name nicht aufgelöst werden konnte. Im Query Log steht dann jetzt auch bei Reply NODATA bei Type AAAA und Reply IP bei Type A. Folglich funktioniert das DNS auflösen nicht oder?
Edit:
Wenn ich mit FTL aktiviert ein pihole -up aufrufe, dann steht da, dass für FTL ein Update vorhanden ist, kann es aber nicht herunterladen, weil er den DNS nicht auflösen kann.
Mache ich ein
sudo systemctl stop pihole-FTL
sudo systemctl start dnsmasq
und rufe dann wieder pihole -up auf, dann steht da, dass alles up to date ist...
Ich habe DNSSEC deaktiviert in den Settings, dnsmasq gestoppt und pihole-FLT restarted. Jetzt scheint es zu laufen. Das Webinterface hat wieder eine Verbindung und zeigt auch etwas an. Hab jetzt ein paar Webseiten ausprobiert und alle konnten geöffnet werden.
Your debug token is: fzdl2syxpo
Laut dem Debug Log funktioniert es wohl aber nicht^^
Habe dnsmasq deinstalliert. Mit der deaktivierten DNSSEC Option scheint es bei mir jetzt auch zu laufen. Domains werden auch geblockt, auch wenn es im Debug Log nicht so wirklich funktioniert.
Als ob du Gedanken lesen könntest
Reboot ging ohne Probleme und danach können DNS Anfragen weiterhin aufgelöst werden. Im Debug Log passt dann auch alles, soweit ich es gesehen habe. Zumindest war jetzt der Abschnitt okay, der vorher eine Fehler ausgespuckt hat.
Ihr hattet wohl ein anderes Problem als ich
dnsmasq hab ich wie oben angegeben deinstalliert
dnssec hab ich deaktiviert
reboot
=>
ping heise.de
ping: heise.de: Temporärer Fehler bei der Namensauflösung
sudo /etc/init.d/pihole-FTL start
Not running
chown: Zugriff auf '/etc/pihole/dhcp.leases' nicht möglich: Datei oder Verzeichnis nicht gefunden
dnsmasq: cannot open or create lease file /var/lib/misc/dnsmasq.leases: Permission denied
pi@piserv:~ $ ping heise.de
ping: heise.de: Temporärer Fehler bei der Namensauflösung
Was ich die ganze Zeit NICHT Probiert habe:
sudo pihole-FTL
... also OHNE debug ... das klappt!. Muss aber nach JEDEM reboot neu durchgeführt werden. Kann es sein das einfach der START von pihole-FTL (wo immer der erfolgt - ich kenne mich mit linux leider nicht aus ... unter Windows würde ich jetzt die Autostart-Varianten durchprüfen) mit falscher berechtigung erfolgt? @DL6ER was sagst du dazu?
Der User laut WebIF ist jetzt ein anderer!
User / Group: nobody / dip vorher war es root / root
Mhhh?!
Wenn ich DNSSEC wieder aktiviere, geht DNS sofort flöten ... ich muss mit sudo pihole-FTL das ganze wieder starten - aber dann geht es auch mit DNSSEC
pihole-FTL sollte als Nutzer pihole gestartet werden. Wenn ein Start mit sudo ... funktioniert, dann ist etwas mit den Berechtigungen im Argem. dnsmasq wird als root gestartet, wir wollen das aber mit pihole-FTLunbedingt umgehen weil man Bugs niemals komplett ausschließen kann und wir nicht wollen dass Schäden am System angerichtet werden könnten. Da dnsmasq als root startet, ist alles hier einfacher, aber wie gesagt, wir wollen mit einem besseren Sicherheitskonzept an die Angelegenheit herangehen.
Die Fehlermeldung /var/lib/misc/dnsmasq.leases sollte niemals auftauchen, denn in /etc/dnsmasq.d/02-pihole-dhcp.conf sollte stehen:
dhcp-leasefile=/etc/pihole/dhcp.leases
Diese Unterhaltung ist mittlerweile auf > 50 Nachrichten angewachsen und hat einiges an Eigendynamik entwickelt. Ich konnte gestern leider nicht mehr allen Nachrichten folgen.
Wer hat jetzt noch Probleme und sind diese noch immer vorhanden wenn sichergestellt ist, dass die Zeile dhcp-leasefile=... korrekt ist? Die Berechtigungen sollten ansonsten durch ein sudo service pihole-FTL retart korrigiert werden. Bitter hier aus überprüfen ob die Datei /etc/init.d/pihole-FTL mit dieser hier identisch ist.
bei mir klappt das nicht ...