Die Sonos-Geräte wurden irgendwann auf zwangsweise Cloudnutzung umgestellt, selbst dann, wenn man die Cloudfunktionen überhaupt nicht nutzen wollte. Seitdem funken sie munter Telemetrie-Daten nach Hause.
Für mich war das ein Grund, diese Geräte aus dem Haus zu verbannen, aber das muss jeder selbst entscheiden. (klicken für mehr)
Wer schon zuvor Cloud-Dienste genutzt hat wie z.B. die Anbindung an eine Sprachsteuerung, wird das wohl eher hinnehmen (wobei es auch für die Cloudanbindung der Sprachsteuerung keinen zwingenden Grund gibt, leider aber auch kaum brauchbare und gleichzeitig einfach zu bedienende Alternativen).
Man sollte sich dann nur bewusst machen, dass damit die Funktonsfähigkeit von Geräten im eigenen Haus direkt von einem stabilen Internetzugang und der Verfügbarkeit der Server der entsprechenden Diensteanbieter abhängt. Stellt so ein Anbieter seinen Dienst ein, führt das auch zu Problemen mit den Geräten.
Daneben sind manche Diensteanbieter auch schon auf die Idee kommen, den Zugang zu den Cloudfunktionen über ein kostenpflichtiges Abo-Modell zu monetarisieren.
In Verbindung mit einem Cloudzwang grenzt das für mich an Erpressung.
Genug philosophiert:
Um die von Deinen IoT-Geräten angefragten Domänen zu erkennen. könnte ein Blick auf folgenden Beitrag helfen:
Ich habe das vergangene Query Log geprüft.
Die einzigen geblockten Domains der Sonos Geräte ist "msmetrics.ws.sonos.com"
Ob sie jetzt Telemetrie Daten nachhause schicken oder nicht, ist mir relativ egal.
Da bin ich nicht so.
Aber meine o.g. Probleme sind es mir eben auch nicht wert, "werbefreie" Netzwerkgeräte zu besitzen.
Dann schalte ich den PiHole lieber wieder ab.
Das mag jeder anders sehen.
Ich für meinen Teil halte es für absolut ausgeschlossen, sich komplett vor ungewollter Preisgabe von personenbezogenen Daten zu schützen.
Auch wenn der PiHole hier im Heimnetz einiges leistet, hilft er nicht mehr sobald man das Haus verlässt.
Ich will auch keine Grundsatzdiskussion starten.
WIe gesagt, jeder sieht es viellecht etwas anders.
Ich danke die für deine große HIlfe bei der EInrichtung und dem Verstehen des PiHole.
Wie gesagt, mit v5.0 kannst du auch nur für deine Sonos Geräte Pihole "umgehen" - und der Rest deines Netzwerks kommt trotzdem in den Genuss von weniger Werbung
Das soll auch jeder.
Wir machen keine Vorschriften, wir teilen hier nur unsere Erfahrungen.
Es wäre sinnvoll, dies auch live zu tun:
Möglichst nur die auffälligen Geräte laufen lassen und dann die eingehende Anfragen unter Tools | Tail pihole.log beobachten, und dann daraus mögliche Whiteliste-Einträge ableiten.
Wenn das nichts bringt oder mit vielen Domänen zu unübersichtlich wird, kannst Du analog zu yubiusers v5-Vorschlag auch für Pihole v4 über manuelle Anpassungen für dnsmasq einen client-spezifischen DNS-Bypass legen.
Da Du Docker einsetzt:
Die Beta ist schon weitgehend stabil (aber immer noch Beta).
Wenn Du Dir das mal anschauen möchtest:
In Docker-Compose folgende Zeile
Ich habe es hinbekommen.
Und zwar musste ich zunächste per SSH "docker pull pihole/pihole:beta-v5.0" ausführen.
Dann tauchte im DOcker auf der Syno unter "Abbilder" das geladene PiHole5 Image auf.
Habe das INterface wieder auf bond0 geändert und meine ServerIP (10.0.0.123) eingetragen.
Leider kann der Container irgendwas nicht zuordnen.
Es ist genau das gleiche Problem wie hier bereits beschrieben,
nur dass ich die Umgebungsvariable "SERVERIP" bereits bei der Installation gefüllt habe.
Und bei mir gehts um eine anderen Port:
(network.c.464) can't bind to port: 10.0.123 80 Address already in use
Dort half zunächst ein Neustart ohne volumes. Das ist einen Test wert.
Eventuell gibt es mit einigen Deiner Einstellungen Konflikte. Die sollte man dann allerdings beheben, denn die volumes braucht man, sonst überlebt Deine Konfguraton einen Neustart nicht.
Ich habe aktuell aber keine Dockerinstallation mehr laufen, so dass ich das aktuell nicht nachbauen kann.
Hast Du jetzt oder vorher einen anderen Port in Pi-hole verwendet?
Port 80 ist der Standardport, insofern würde es mich wundern, wenn der Port bei Dir zu Konflikten führt. Ich vermute eher, dass die IP-Adresse 10.0.0.123 Probleme bereitet, eventuell weil diese bereits im Einsatz war und daher von Docker intern noch benutzt wird.
In Deinem Fall ginge es wohl um einen Abgleich der Infos aus dieser Datei mit den entsprechenden Docker-Environment-Variablen.
/etc/lighttpd/lighttpd.conf gilt für einen Zugriff innerhalb des Pi-hole-Containers. Du öffnest eine interaktive Bash-Shell im Docker-Container über docker exec:
docker exec -it <container-id-or-name> bash
Damit kannst Du Kommandos wie auf einem normalen Rechner absetzen. Am Ende verlässt Du sie mit:
exit
Eventuell gibt es über Deine Web-Oberfläche einen einfacheren Weg, eine Shell zu öffnen.
Manipulationen an diesen Dateien würde ich weder über den von Dir genannten Subvolume-Pfad noch über eine Shell vornehmen (höchstens zu Testzwecken).
Nur Dateien unter den über volumes konfigurierten Pfaden überleben einen Docker-Neustart.
Habe den Container einfach per Web Oberfläche in Docker installiert.
Wenn man dort "gleiches Netzwerk nutzen wie Host" wählt, kann man keine Ports mappen.
Ist immer ein wenig schwierig, wenn man das andere System nicht sieht und statt Kommandozeile (geht immer) eine Web-Oberfläche involviert ist (variiert in Verfügbarkeit und Aussehen).
Die Optionen für die clientspezifischen Einstellungen findest Du unter Group Management.
Vielleicht kann @yubiuser hier ein paar Tips beisteuern - als jemand, der die Beta 5 schon länger nutzt.und damit auch getestet hat.
Der Docker Container heißt PiHole5.
Der Container ist zu dem Zeitpunkt wohl neu gestartet weil ich im Terminal "STRG + C" gedrückt habe!?
Zu sehen am "^C[cont-finish.d]...."
Gruppen habe ich erstellt.
Clients habe ich auch zugewiesen.
Für diese Gruppen kann ich jetzt auch eigene White- und Blacklists erstellen.
Aber wie kann ich PiHole für die komplett deaktivieren?
