Speicherort der `dnsmasq` log Datei dauerhaft frei wählbar einstellen

Feature Requests
1

Ich habe gestern ein neues Update eingespielt (das letzte davor war im November 2021). Was ansonsten immer anstandslos durchlief, endete gestern mit der Meldung

Unable to complete update, please contact Pi-hole Support

Pi-hole status zeigte dann auch, dass es keinen DNS Service gab und dem entsprechend auch kein Blocking.

Die Fehler-Meldung läßt leider offen, ob das Update komplett eingespielt worden ist oder noch Teile fehlen. Hier könnte man noch etwas verbessern.

Der Fehler war schnell gefunden. Dnsmasq mag es nicht, wenn eine Option, die nur einmal angegeben werden darf, ein zweites Mal erscheint. In dem Fall startet dnsmasq einfach nicht.

Das war auch hier der Fall. Wenn man bei Pi-hole dnsmasq-logging aktiviert, dann erzeugt Pi-hole in der Datei /etc/dnsmasq.d/01-pihole.conf die Einträge

log-queries
log-facility=/var/log/pihole.log

Um die Schreib-Operation auf die SD-Card meines RPI3B zu reduzieren, habe ich den Eintrag log-facility auskommentiert und in einer eigenen Datei /etc/dnsmasq.d/50-logging.conf die Log-Datei neu definiert:

log-facility=/tmp/pihole/pihole.log

Durch den Update-Prozess erschien aber in der /etc/dnsmasq.d/01-pihole.conf wieder der Eintrag

log-facility=/var/log/pihole.log

Damit gab es zwei Einträge log-facility und prompt weigerte sich dnsmasq zu starten. Folglicherweise auch kein DNS-Service und Blocking.

Ich schlage daher vor, dass man die dnsmasq-Log-Datei als Parameter angeben kann (entweder in der Datei /etc/pihole/pihole-FTL.conf oder /etc/pihole/setupVars.conf), z.B. wie bei LOGFILE=/tmp/pihole/pihole-FTL.log. Pi-hole könnte dann einen entsprechenden Eintrag in der /etc/dnsmasq.d/01-pihole.conf erzeugen. Ein Re-Start von dnsmasq würde dann aus den oben angeführten Gründen nicht mehr scheitern und der Update-Prozess keine kaputte Konfiguration hinterlassen.

Generell gesprochen halte ich das Update-Verhalten von Pi-hole für alles andere als smart und benutzer-freundlich: bestehende Konfigurationsdateien werden ohne Nachfrage einfach überschrieben. Damit werden alle vom Benutzer gemachte Anpassungen zunichte gemacht.

Dabei zeigt das Programm apt (inkl. seiner Verwandten apt-get oder aptitude) wie man es besser machen kann: findet apt eine modifizierte Konfiguarationsdatei, dann fragt es nach und bietet mehrere Optionen an, wie weiter zu verfahren ist. Ich schlage daher vor, bei einem Pihole Update ähnlich zu verfahren.

2

Ich habe deinen Beitrag in einen Feature Request umgewandelt, da es im Kern darum geht, folgende Funktion zu implementieren:

Das stimmt, dafür gibt es jedoch einen entsprechenden Hinweis am Anfang der Datei

3

This large warning appears in the file you edited:

###############################################################################
#      FILE AUTOMATICALLY POPULATED BY PI-HOLE INSTALL/UPDATE PROCEDURE.      #
# ANY CHANGES MADE TO THIS FILE AFTER INSTALL WILL BE LOST ON THE NEXT UPDATE #
#                                                                             #
#        IF YOU WISH TO CHANGE THE UPSTREAM SERVERS, CHANGE THEM IN:          #
#                      /etc/pihole/setupVars.conf                             #
#                                                                             #
#        ANY OTHER CHANGES SHOULD BE MADE IN A SEPARATE CONFIG FILE           #
#                    WITHIN /etc/dnsmasq.d/yourname.conf                      #
###############################################################################
7

Schön.

Was meinst Du: wird der Request einen größeren Aufwand nach sich ziehen? Wann kann man mit der Umsetzung/Fertigstellung rechnen?

Stimmt, und den Hinweis habe ich auch gelesen. Doch die Aufnahme der Option log-facility in eine eigene Datei hat nicht verhindert, dass Pi-hole nach dem Update nicht mehr gestartet ist. Hier kann man sicherlich noch einigen Gehirn-Schmalz investieren, damit Pi-hole hinsichtlich Benutzer-Anpassungen etwas smarter wird (siehe dazu auch mein Hinweis auf apt & friends)

8

Siehe meine Antwort an @yubiuser

12

Zumindest einen mittelgroßen. Ich denke es wird recht lange dauer, bis das umgesetzt wird. Bisher bist du der erste Nutzer der dieses Problem berichtet. Es muss ein Entwickler das Problem für so wichtig erachten, dass er es ändern will und dann noch dafür Zeit/Lust aufbringen. Da die Entwicklung von Pi-hole als Hobby in der Freizeit stattfindet ist mit einer langen Entwicklungszeit zu rechnen.
Du kannst natürlich gerne selbst einen Pull requests mit den entsprechenden Änderungen am Code einreichen, das geht dann entsprechend schneller.

14

Wer den Speicher-Ort der dnsmasq-log-Datei nicht ändert, hat das Problem natürlich nicht.

Abgesehen davon, ob das Problem nun von 1 oder von 100 Nutzern berichtet wird, es ändert nichts an der Tatsache, dass der Fehler existiert und rekonstruierbar ist.

Dann will ich mal hoffen, dass ein Entwickler eine kaputte Konfiguration für so wichtig erachtet, dass er es für nötig hält, diesen Fehler zu beseitigen.

16

Wie wäre es mit einem Symlink von /var/log/pihole.log zum gewünschten Zielort?

17

Darüber hatte ich auch schon nachgedacht und dann bei weiteren Recherchen Deinen Hinweis in einer FAQ von 2017 (wenn ich mich richtig erinnere) gefunden.

Das würde den gegenwärtigen Zustand der Hard-Codierung zementieren und allein dem Benutzer die "Last" der Umlenkung mit all ihren Konsequenzen (siehe Deine FAQ) auferlegen. Der klare Vorteil für die Entwickler: sie brauchen nichts zu ändern.

Ich halte diese Variante aber für benutzer-unfreundlich und bevorzuge daher eine, die dem Benutzer den Komfort anbietet, nur einmal den Speicher-Ort anzugeben.

Also ich habe es dann einfach ausprobiert und jeweils einen Symlink

/var/log/pihole-FTL.log -> /tmp/pihole/pihole-FTL.log
/var/log/pihole.log -> /tmp/pihole/pihole.log

angelegt.

Doch unter Tools->Tail pihole.log und Tools->Tail pihole-FTL.log wird weiterhin nichts angezeigt, obwohl in beide Dateien fleißig und munter geschrieben wird. Daran ändert auch ein Restart von Pihole nichts.

Da ich mich heute noch um andere Dinge kümmern mußte, hatte ich noch keine Gelegenheit, die Sache weiter zu verfolgen. Werde ich aber bei nächster Gelegenheit nachholen.

19

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.