Beiträge von skoeber

QVR Pro liegt bei mir auch mit ca. 1,4 GB im Speicher.

Das Update zeigt auf meiner TS-251+ bisher keine Auffälligkeiten oder Probleme.

Ich hatte mal einen Schreibzugriffsfehler im Container. Ich dachte, dass das ulimit ausgeschöpft ist und habe es hochgesetzt. Letztlich war das aber ein Fehler der ContainerStation (dazu gibt es auch noch einen anderen Thread hier im Forum, wo ich etwas dazu schrieb). Das ist also letztlich eine Altlast und kann auch weggelassen werden.

Ich hatte die Fritzbox auch schon als DNS2 gesetzt und 9.9.9.9 als DNS1. Das machte keinen Unterschied. Ich hatte dazu auch das Logfile beobachtet und festgestellt, dass Pi-hole offenbar die DNS-Requests an beide DNS Server gleichzeitig schickt und das erste Ergebnis verwertet. So war zumindest damals meine Beobachtung, ist aber auch schon ein paar Tage her.

Zitat von phoneo

Wer mit dem Pi-Hole nicht nur lästige Werbeeinblendungen filtern möchte, sondern auch Wert auf Privatsphäre legt, sollte auf freie DNS-Server setzen die in dem Ruf stehen DNS-Anfragen nicht auszuwerten.

Ansonsten gebe ich dir Recht: Freie DNS-Server sind zu bevorzugen. Evtl. stelle ich das auch nochmal um. Ich hatte damit mal kurzzeitig Probleme und bin dann seitdem einfach bei meinem funktionierenden Setup geblieben.

Bei mir ist alles in einem Netz.

Die Fritzbox als Gateway sollte bei dir, wie bei mir, passend sein. Der DHCP der Fritzbox vergibt bei mir Adressen ab 192.168.178.50. Darunter vergebe ich feste Adresse für alle dauerhaft laufenden Dienste, für den Pi-hole ist es die 192.168.178.7 (siehe docker-Befehl).

Pi-hole selber filtert ja nur DNS Anfragen, alle nicht gefilterten Anfragen werden an "richtige" DNS Server weitergeleitet. Diese konfiguriert man mit DNS1 und DNS2. DNS1 ist bei mir die Fritzbox, weil sie ja vom Provider einen DNS zugewiesen bekommt und ich damit vermutlich auf der sicheren Seite bin. Zudem cached die Fritzbox erfahrungsgemäß viel und beantwortet die DNS Anfragen am schnellsten. DNS2 ist bei mir 9.9.9.9, der ja auch sehr schnell sein soll. Bei mir spielt DNS2 aber kaum eine Rolle. Wie gesagt, laut der Pi-hole-Statistik beantwortet die Fritzbox nahezu alles am schnellsten (siehe angehangener Screenshot).

Hattest du denn die Container Station mal komplett deinstalliert, die Konfigurationsdaten gelöscht und neu installiert? Wenn nicht, dann wäre das mein Ratschlag. Ansonsten habe ich leider auch keine Idee.

Hallo,

bei deinem spezifischen Problem kann ich dir leider nicht helfen. Ich habe OpenHAB2 jedoch schon einige Zeit als Docker Container laufen und das funktioniert tadellos und stabil. Ich nutze dazu folgenden Aufruf:

docker run -d --name openhab --restart always --net=qnet-static-eth1-a1b2c3 --ip=192.168.178.8 --hostname openhab --tty -v /etc/localtime:/etc/localtime:ro -v /share/NASext/container-data/timezone:/etc/timezone:ro -v /share/NASext/container-data/openhab/conf:/openhab/conf -v /share/NASext/container-data/openhab/userdata:/openhab/userdata -v /share/NASext/container-data/openhab/addons:/openhab/addons openhab/openhab:2.4.0

Achtung, ich habe da ein paar Spezialitäten drin:

- Daten auf einer per USB angeschlossenen SSD

- Netzwerkinterface an virtuellen Switch verwendet und eigene IP vergeben - das ginge auch über die GUI

Daher verwende ich auch den direkten Docker-Befehl über die Shell.

Wenn die Variante per Docker (Container Station) für dich interessant ist, kann ich gern unterstützen, sag einfach bescheid.

Zitat von wurstbrot0815

mir kommt es so vor als ob sich pihole versuch neu zu installieren da sich der container mit einer neuen Mac Adresse angemeldet hat

Ich hatte das gleiche Problem. Siehe dazu mein Issue im pi-hole-docker Projekt:

https://github.com/pi-hole/docker-pi-hole/issues/330

Um es kurz zu fassen: Es liegt an der Container Station. Nach einer Odyssey aus Deinstallieren/Installieren/Upgraden/Bereinigen von Container Station ging es dann irgendwann. Mehr, als die Container Station und alle zugehörigen Daten wegzuputzen und neu aufzusetzen, kann ich dir leider dazu nicht sagen.

Um noch mehr Werbung zu blockieren, könntest du dich mit weiteren Listen beschäftigen. Ich hatte dazu weiter vorn etwas verlinkt.

Meistens sind es irgendwelche Javascripts, die überprüfen, ob die Werbung im Browser vorhanden ist oder nicht. Wenn die Werbung nun gar nicht erst abgerufen wird, weil pi-hole diese Anfragen ins Nirvana schickt, dann erkennen das die Scripte und bringen die entsprechende Meldung. Da kann pi-hole leider nichts ausrichten.

Hast du unter Environment wieder den Parameter "ServerIP" angegeben bzw. ist er richtig geschrieben? Laut Fehlermeldung fehlt der.

Ansonsten habe ich den Wechsel vom diginc Container auf den pi-hole Container auf dem QNAP schon durch und das lief ohne Probleme. Genau heute habe ich meine 4.0 Installation auf die aktuelle 4.1.1 aktualisiert, auch das ohne Probleme. Weiter vorn in diesem Thead habe ich meinen kompletten Aufruf-Befehl (ich setze den Container per direkten Docker-Aufruf auf, weil da noch ein bisschen mehr möglich ist). Der funktioniert unverändert.

Bitte aufpassen, der Container von diginc ist nicht mehr gepflegt. Er macht das jetzt direkt für das pi-hole Projekt und der aktuelle Container ist hier zu finden:

https://hub.docker.com/r/pihole/pihole/

Meine Listen sind folgende:

https://mirror1.malwaredomains.com/files/justdomains     
https://zeustracker.abuse.ch/blocklist.php?download=domainblocklist     
https://hosts-file.net/ad_servers.txt     
https://adaway.org/hosts.txt     
http://www.malwaredomainlist.com/hostslist/hosts.txt     
http://winhelp2002.mvps.org/hosts.txt     
https://raw.githubusercontent.com/notracking/hosts-blocklists/master/hostnames.txt     
https://raw.githubusercontent.com/AdguardTeam/AdguardFilters/master/MobileFilter/sections/adservers.txt     
https://raw.githubusercontent.com/AdguardTeam/AdguardFilters/master/MobileFilter/sections/spyware.txt     
https://media.kuketz.de/lists/mobile_list.txt     
https://raw.githubusercontent.com/crazy-max/WindowsSpyBlocker/master/data/hosts/win10/spy.txt     
https://raw.githubusercontent.com/quidsup/notrack/master/trackers.txt     
https://v.firebog.net/hosts/AdguardDNS.txt     
https://v.firebog.net/hosts/Easylist.txt     
https://v.firebog.net/hosts/Easyprivacy.txt

Umfangreiche Quelle ist https://firebog.net/

Lesenswert außerdem auch:

https://www.kuketz-blog.de/adb…en-geraeten-unzureichend/

https://www.kuketz-blog.de/tra…terliste-vom-kuketz-blog/

Zitat von cbronson

Was muss ich machen, damit nicht bei jedem Neustart der Containers ein neues Passwort vergeben wird

Du musst beim Erstellen des Containers den passenden Environment-Parameter mitgeben:

 -e WEBPASSWORD="geheimesPasswort"

Dann wird es dauerhaft gesetzt. Ich habe das Passwort leer gelassen, so dass keinerlei Passwort-Abfrage kommt. Das sieht dann so aus:

-e WEBPASSWORD=""

Update:

Das Problem besteht weiterhin unverändert. Ich habe den Hybrid Backup Job komplett neu angelegt, ohne Verbesserung. Ein Upload zu OneDrive via Browser nutzt die verfügbare Upstream-Bandbreite aus (2 MBit/s). In der aktuellen Form ist das Hybrid Backup für mich leider kaum brauchbar. Gibt es hierzu von anderen Beobachtungen?

Hallo,

interessant. Ich beobachte gerade das gleiche bei mir. Im Unterschied zu dir handelt es sich bei mir aber lediglich um einen Ordner mit ca. 7GB (auf knapp 6.000 Dateien verteilt). Die Daten sind schon seit einer Weile im OneDrive und werden täglich per Hybrid Backup Sync abgeglichen. Derzeit wird der Job innerhalb von 24h nicht fertig.

Ich denke, eine Traffic-Beschränkung ist das in dem Fall nicht (mir ist auch nicht bekannt, dass es da eine gibt). Leider weiß ich nicht ganz genau, wann dieses Problem bei mir losging. Evtl. hängt es mit der Firmeware 4.3.5.0760 zusammen, die ich seit Release drauf habe. Läuft die bei dir auch?

Hallo davood88,

bezugnehmend auf deinen Screenshot musst du links auf den Berech "Environment" klicken und dann dort in der Tabelle einen Eintrag ergänzen "ServerIP" mit dem Wert "192.168.178.70". Damit wird in die pi-hole Konfiguration die IP deines Containers geschrieben. Die braucht pi-hole (noch) zwingend für den Betrieb.

Ich hatte weiter oben in diesem Thema meine Konfiguration gepostet (als Shell-Command). Daran kannst du dich auch etwas orientieren. Alle Parameter mit "-e" entsprechen solchen Einträgen bei Environment.

Ich hoffe, das hilft dir.

Ich habe das Update von der letzten 4.3.4 jetzt auch auf meiner TS-251+ gewagt. Bisher scheint alles anstandslos zu funktionieren. Wichtig sind mir vor allem meine Container, die nach dem Container-Station Update alle sofort und ohne Fehler wieder hochgefahren sind. Meine virtuellen Switche sind erhalten geblieben und funktionieren wir gewohnt.

Leider läuft bei der aktuellen Container-Station der Docker-Deamon immernoch im Debug-Modus. Ich hatte gehofft, dass das endlich verbessert wird, weil das für sekündliche Schreibvorgänge auf den Platten führt (und auch keinen gesteigerten Sinn ergibt im normalen Betrieb).

Die 169.254.100.100 IP taucht jetzt bei mir auch erstmals im Netzwerk auf.

Hallo,

ich betreibe derzeit pi-hole mit folgenden Aufrufen:

docker network create -d qnet --ipam-driver=qnet --ipam-opt=iface=eth1 --subnet=192.168.178.0/23 --gateway=192.168.178.1 qnet-static-eth1-a1b2c3
docker run -d --ulimit nofile=90000:90000 --name pihole --restart always --net=qnet-static-eth1-a1b2c3 --ip=192.168.178.7 --hostname pihole --dns=127.0.0.1 -v /share/NASext/container-data/pihole:/etc/pihole -v /share/NASext/container-data/pihole/log/pihole.log:/var/log/pihole.log -e ServerIP="192.168.178.7" -e IPv6="False" -e TZ="Europe/Berlin" -e WEBPASSWORD="" -e DNS1="192.168.178.1" -e DNS2="9.9.9.9" pihole/pihole:latest

Mit der erste Zeile lege ich ein Netzwerk an, das mittels virtuellem Switch an den zweiten phyischen Port gebunden ist. Der pi-hole Container erhält dann eine feste IP (--ip=192.168.178.7). Mit dem Parameter -e WEBPASSWORD="" wird ein leeres Passwort gesetzt, so dass man sich für die Web-GUI nicht einloggen muss.

Ich hoffe, das hilft weiter. Ich fahre damit im Moment sehr gut (abgesehen von anderen Problemchen, die aber auf allgemeine ContainerStation-spezifische Problemchen zurückzuführen sind).