Das finde ich sehr löblich, genau so wie yubiusers Frage auch.
Wenn sich hier User untereinander helfen, muss natürlich nicht jeder Vorschlag auch passen, Keiner kennt ja die Situation vor Ort besser als der Betroffene, in dem Fall also Du.
Bezüglich der Unterstützung von arm5vtel:
Bislang sind mir genau vier Benutzer bekannt, die ein solches System für Pi-hole verwenden (weil sie beim Update Probleme hatten).
Du könntest einen Feature Request zur Unterstützung durch ein eigenes Binary stellen.
Oder vielleicht hast Du sogar Lust, das selbst für Pi-hole bereitzustellen und zu warten?
Pi-hole lebt ja von der Untersützung durch die Community.
Das stimmt natürlich und es wäre toll, wenn aus dieser Diskussion eine Lösung für das Problem hervorgeht. Sollte diese aber nicht in Sicht sein, würde ich mir überlegen, ob es mir jedes Mal den Aufwand wert wäre. Du kannst natürlich zu einer anderen Entscheidung kommen als ich.
Wen der aufwand, nur das kompilieren des FTL dienst wäre, wie bei den updates zuvor war, Ja, das wäre es mir wert.
In der nas sind 4 hdds verbaut, 3extern hdds hängen per usb dran, Openpn client läuft drauf, hab sie sogar auf debian umgeflasht um ein richtigen pc raus zu machen, ausederm überwache ich, per Cacti, meine 6591, die Modemwerte.
Aber, wenn ich das jetzt richtig verstehe, müsste man zusätzlich zum Kompilieren des FTL nur noch das Skript gravity.sh händisch ausführen.
Dann läuft es doch, oder habe ich noch etwas übersehen?
@ Bucking_Horn
Das pihole nicht alle cpu arten, mit allen variationen abdecken kann ist mir bewust, hab ich auch nie angekreidet, ich hab mich hingesetzt, als pihole nicht gelaufen ist, hab per google heruasgefunden, das mein armv5l nicht direkt unterstützt wird.
Dann bin ich darauf gestosen https://docs.pi-hole.net/ftldns/compile/
Hab es kompliert und lief und das war für mich das wichtigste.
Bei den letzten 2 Update muste ich "nur" pihole -up eintippen und dann den ftl neu komplieren und dann lief wieder alles.
Nemen wir mal an, ich würde die pihole-ftl für alle zuverfügung stellen, wie würde das genau gehen?
@Schultze
So einfach ist das nicht, da durch das abgebroche update, nicht alle datein richtig aktualisiert worden sind. Was noch alles falsch läuft das nicht vollständige updaten, ist noch nicht abzusehen.
Durch den händischen Aufruf des Skrips wurde dann bei mir aber die gravity.db erzeugt und gefüllt. Das Skript scheint also aktuell, wird aber von pihole -g nicht gestartet.
@Bucking_Horn
Hier haben wir dasselbe Problem: PiHole funktioniert nicht mehr nach Update - #20 by Rocky
Evtl. kann man die Threads zusammenführen und bei ähnlichen Threads entsprechend genau das ebenfalls prüfen. Ich schau mal den updater durch, ob es einen Grund/Fehler geben könnte der u.U. das update von gravity.sh verhindert.
@Schultze
Super info, d.h. /etc/.pihole ist aktuell, aber /opt/pihole nicht. Letzteres ist der Ort wo der pihole command die Skripts aufruft.
Ich würde vorschlagen, dazu zunächst einmal einen Feature Request aufzumachen und dort anzubieten, dass Du ggf. dabei unterstützen könntest.
Dann werden sich die Entwickler entsprechend zurückmelden.
Außerdem liesse sich an der Unterstützung für den FR viellleicht sehen, wie populär die Plattform ist. Aus den Fehlermeldungen alleine kann man das ja schlecht ableiten.
Um die Überprüfung auf Aktualität zu ermöglichen, hatte ich geschrieben:
Das deutet zusammengenommen nun darauf hin, dass /opt/pihole zwar aktuell ist, /usr/local/bin/pihole jedoch veraltet.
Nach Rückmeldung ist klar, dass /etc/.pihole aktualisiert wurde, dementsprechend das dort befindliche gravity.sh auch funktioniert, während /opt/pihole und /usr/local/bin/pihole veraltet sind.
Die Architektur sollte für alle shell scripts keine Rolle spielen, aber ich warte noch auf Rückmeldung beim anderen Thread ob das repo Verzeichnis dort ebenfalls aktuell ist. Immerhin wurde in beiden Fällen bei dem Update /opt/pihole nicht aktualisiert, was in beiden Fällen zur fehlenden gravity.db führte und in beiden Fällen zu entsprechend unvollständigem dashboard.
@ MichaIng das kann ich wiederlegen, ich hab meinen backup pi angeschlossen, pihole -up durch geführt udn er hat alles ohne fehlermeldung geupdated, in der innstallation klappte auch das update der gravity.db, die hatte ich auf meine nas kopiert und dann hat er geblockt.
cd /etc/.pihole
install -o "$(id -un)" -Dm755 -t "/usr/local/bin" pihole
Klappt das bei dir fehlerfrei?
Das heißt zunächst nur dass es auf einem System geklappt hat (bei all meinen ARM und x86 Systemen hat es ebenfalls geklappt) und bei einem anderen nicht. Ob das an der Architektur oder irgendeinem Anderen von unzähligen Faktoren liegt, weiß ich nicht. Aber ich kenne mich mit Shell gut aus und was im Installer passiert hat praktisch nichts mit der Architektur zu tun, bis auf die APT/yum Paket Architekturen natürlich, aber das wäre dann ein sichtbarer e.g. dpkg Fehler.
Also so wie ich das sehe kommen wir dem ganzen am besten auf den Grund wenn der Installer mit set -x ausgeführt wird um zu sehen ob/wie die entsprechende Funktion aufgerufen wird.
sed -i '/^set -e/a\set -x' '/etc/.pihole/automated install/basic-install.sh'
pihole -r
/etc/.pihole/gravity.sh ist aktuell und legt eine gravity.db an. /opt/pihole/gravity.sh ist veraltet und bearbeitet die gravity.list. Das letztere scheint von pihole-g aufgerufen zu werden.
.
: