UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[MartinP]

Angeregt durch diesen Thread habe ich mich auch mal an PiHole gewagt, bin aber ein wenig gescheitert ...

https://forum.iobroker.net/topic/79939/pihole-adapter-ohne-funktion-nach-pi-hole-update-auf-v6/35

Zuerst wollte der Docker Container nicht starten (port 53 war belegt, aufgrund einem lokal laufenden DNSProxy, aber nachdem ich das nach dem Kochrezept hier geändert hatte startet der Container zumindest:

https://discourse.pi-hole.net/t/pihole-via-docker-ubuntu-port-forwarding-port-53-taken-solved/29973/2

Intern auf der Konsole des LXC-Container scheint PiHole schon zu funktionieren, wenn ich als DNS-Server die IP-Adresse des Containers oder localhost wähle googlesyndication wird geblockt:

martin@DockerKlon1:~$ nslookup heise.de 172.18.0.2
Server:         172.18.0.2
Address:        172.18.0.2#53

Non-authoritative answer:
Name:   heise.de
Address: 193.99.144.80
Name:   heise.de
Address: 2a02:2e0:3fe:1001:302::

martin@DockerKlon1:~$ nslookup pagead2.googlesyndication.com 172.18.0.2
Server:         172.18.0.2
Address:        172.18.0.2#53

Name:   pagead2.googlesyndication.com
Address: 0.0.0.0
Name:   pagead2.googlesyndication.com
Address: ::

martin@DockerKlon1:~$ nslookup pagead2.googlesyndication.com localhost 
Server:         localhost
Address:        ::1#53

Name:   pagead2.googlesyndication.com
Address: 0.0.0.0
Name:   pagead2.googlesyndication.com
Address: ::

martin@DockerKlon1:~$ 

Von einem anderen LXC auf dem gleichen PVE aus komme ich aber nicht an das PiHole DNS

martin@DebianTest:~$ nslookup heise.de dockerklon1
;; communications error to 192.168.2.146#53: timed out
;; communications error to 192.168.2.146#53: timed out
^C
martin@DebianTest:~$ ping dockerklon1
PING dockerklon1.fritz.box (192.168.2.146) 56(84) bytes of data.
64 bytes from 192.168.2.146 (192.168.2.146): icmp_seq=1 ttl=64 time=0.126 ms
64 bytes from 192.168.2.146 (192.168.2.146): icmp_seq=2 ttl=64 time=0.135 ms
^C
--- dockerklon1.fritz.box ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.126/0.130/0.135/0.004 ms
martin@DebianTest:~$ 

Hier noch die lsof-Ausgabe auf dem Docker LXC:

martin@DockerKlon1:~$ sudo lsof -i -P -n | grep 53
[sudo] password for martin: 
docker-pr  756            root    4u  IPv4 166697338      0t0  TCP *:53 (LISTEN)
docker-pr  787            root    4u  IPv6 166697376      0t0  TCP *:53 (LISTEN)
docker-pr  824            root    4u  IPv4 166696382      0t0  UDP *:53 
docker-pr  844            root    4u  IPv6 166696409      0t0  UDP *:53 

Und das docker-compose.yml

Spoiler

# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services:
 pihole:
   container_name: pihole
   image: pihole/pihole:latest
   ports:
     # DNS Ports
     - "53:53/tcp"
     - "53:53/udp"
     # Default HTTP Port
     - "80:80/tcp"
     # Default HTTPs Port. FTL will generate a self-signed certificate
     - "443:443/tcp"
     # Uncomment the below if using Pi-hole as your DHCP Server
     #- "67:67/udp"
   environment:
     # Set the appropriate timezone for your location (https://en.wikipedia.org/wiki/List_of_tz_database_time_zones), e.g:
     TZ: 'Europe/Berlin'
     # Set a password to access the web interface. Not setting one will result in a random password being assigned
     FTLCONF_webserver_api_password: 'weggemacht'
   # Volumes store your data between container upgrades
   volumes:
     # For persisting Pi-hole's databases and common configuration file
     - './etc-pihole:/etc/pihole'
     # Uncomment the below if you have custom dnsmasq config files that you want to persist. Not needed for most starting fresh with Pi-hole v6. If you're upgrading from v5 you and have used this directory before, you should keep it enabled for the first v6 container start to allow for a complete migration. It can be removed afterwards. Needs environment variable FTLCONF_misc_etc_dnsmasq_d: 'true'
     #- './etc-dnsmasq.d:/etc/dnsmasq.d'
   cap_add:
     # See https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
     # Required if you are using Pi-hole as your DHCP server, else not needed
     # NET_ADMIN
     # Required if you are using Pi-hole as your NTP client to be able to set the host's system time
     # SYS_TIME
     # Optional, if Pi-hole should get some more processing time
     - SYS_NICE

[David G.]

@martinp

Ist zwar keine Lösung für dein Problem.....

Aber warum nimmst du nicht das?
https://community-scripts.github.io/ProxmoxVE/scripts?id=pihole

[MartinP]

@david-g Wollte den Wildwuchs an LXC-Containern limitieren...
Wenn man das ernsthaft machen will, muss man da ja wieder mit dem RAM schachern ...

[mickym]

@martinp sagte in PiHole in Proxmox->LXC->Docker:

@david-g Wollte den Wildwuchs an LXC-Containern limitieren...
Wenn man das ernsthaft machen will, muss man da ja wieder mit dem RAM schachern ...

Das ist mE nicht ganz richtig. Der Overhead der LXC Container ist nach meiner Erfahrung nicht so hoch und ich habe aktuell 6 LXC bei 8 GB RAM laufen und die Auslastung des Knotens liegt bei 30%

[crunchip]

@mickym sagte in PiHole in Proxmox->LXC->Docker:

ich habe aktuell 6 LXC bei 8 GB RAM laufen

laut deinem screen hast du 10 LXC's und 3 VM's auf deinem Rechner.
Nun stell ich die einfache Frage,

kannst du problemlos alle aktivieren?

die Antwort, ist....?
und genau darauf bezieht sich

@martinp sagte in PiHole in Proxmox->LXC->Docker:

muss man da ja wieder mit dem RAM schachern

[MartinP]

@mickym Trotzdem sollte man bei mehreren LXC-Containern dafür sorgen, dass man in Summe nicht mehr RAM an die Container verteilt, als verfügbar ist, wenn man ein stabiles System behalten will...

Wenn alles, was an RAM verfügbar ist vergeben ist, muss man da irgendwo etwas abzweigen, wenn man einen weiteren LXC auf das System quetschen will.

Das Gleiche gilt natürlich auch eigentlich für Docker-Container, aber die liegen ja eine Ebene tiefer, und können dann "nur" den LXC in Verdrückung bringen, auf dem sie laufen ...

Hier noch der Portscan von einem anderen LXC aus:

martin@DebianTest:~$ nmap -v -A dockerklon1
Starting Nmap 7.93 ( https://nmap.org ) at 2025-02-23 14:51 CET
NSE: Loaded 155 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 14:51
Completed NSE at 14:51, 0.00s elapsed
Initiating NSE at 14:51
Completed NSE at 14:51, 0.00s elapsed
Initiating NSE at 14:51
Completed NSE at 14:51, 0.00s elapsed
Initiating Ping Scan at 14:51
Scanning dockerklon1 (192.168.2.146) [2 ports]
Completed Ping Scan at 14:51, 0.00s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 14:51
Completed Parallel DNS resolution of 1 host. at 14:51, 0.02s elapsed
Initiating Connect Scan at 14:51
Scanning dockerklon1 (192.168.2.146) [1000 ports]
Discovered open port 22/tcp on 192.168.2.146
Discovered open port 443/tcp on 192.168.2.146
Discovered open port 80/tcp on 192.168.2.146
Discovered open port 53/tcp on 192.168.2.146
Discovered open port 631/tcp on 192.168.2.146
Discovered open port 8000/tcp on 192.168.2.146
Discovered open port 3000/tcp on 192.168.2.146
Discovered open port 32768/tcp on 192.168.2.146
Completed Connect Scan at 14:51, 0.23s elapsed (1000 total ports)
Initiating Service scan at 14:51
Scanning 8 services on dockerklon1 (192.168.2.146)

martin@DebianTest:~$ 

[MartinP]

@crunchip sagte in PiHole in Proxmox->LXC->Docker:

laut deinem screen hast du 10 LXC's und 3 VM's auf deinem Rechner.
Nun stell ich die einfache Frage,

Wo siehst Du bei mir 10 LXCs und 3 VMs?

Die zwei VMs sind eigentlich Karteileichen, und kommen bei Gelegenheit wegm sind eigentlich Karteileichen, und ich sollte sie eigentlich wegschmeißen, weil ich sie seit Monaten nicht mehr laufen gelassen habe ...

Zum Thema "mit dem RAM schachern": Best Practise ist natürlich, jedem LXC nur so viel RAM zu geben, dass in Summe nicht mehr verteilt wird, wie auch physisch vorhanden ist. In gewissen Grenzen KANN natürlich auch ein Setup laufen, was jedem LXC so viel RAM zuweist, dass es kracht, wenn die LXCs wirklich einmal alle gleichzeitig ihre Quotas ausreizen.

In der Aufbauphase kann man sicherlich erstmal großzügig sein, aber irgendwann sollte man da schon saubere Grenzen abstecken ...

[mickym]

@crunchip sagte in PiHole in Proxmox->LXC->Docker:

@mickym sagte in PiHole in Proxmox->LXC->Docker:

ich habe aktuell 6 LXC bei 8 GB RAM laufen

laut deinem screen hast du 10 LXC's und 3 VM's auf deinem Rechner.
Nun stell ich die einfache Frage,
kannst du problemlos alle aktivieren?
die Antwort, ist....?
und genau darauf bezieht sich

Nun ja - die Frage ist, trotzdem braucht man das und ja ein VM braucht wesentlich mehr, als ein LXC.

Und um die Frage zu beantworten - ja ich kann alles starten, aber dann ist der Speicher am Anschlag - das liegt alleine schon an meiner Win11Pro VM.

Wenn ich die Windowsmaschine aber herunterfahre - und die braucht nun mal viel Speicher, dann kann ich mich bei

10 Container und 2 VMs nicht beklagen.

[mickym]

@martinp sagte in PiHole in Proxmox->LXC->Docker:

Wo siehst Du bei mir 10 LXCs und 3 VMs?

Das war auf mich gemünzt.

[MartinP]

@mickym Okay, habe ich auch gerade bemerkt ....

[mickym]

@martinp sagte in PiHole in Proxmox->LXC->Docker:

@mickym Trotzdem sollte man bei mehreren LXC-Containern dafür sorgen, dass man in Summe nicht mehr RAM an die Container verteilt, als verfügbar ist, wenn man ein stabiles System behalten will...

Sehe ich nicht so - die Maschine fängt zwar zu swappen an - aber der Clou an der Sache ist ja, dass die Resourcenverteilung so intelligent ist, dass man nicht den physischen Speicher braucht, der theoretisch verbraucht werden kann.

[MartinP]

@mickym Wenn man keine zeitkritischen Anwendungen hat, mag das stimmen, aber man sollte sich da nicht wundern, wenn dann alles unbedienbar wird, wenn die LXCs sich gegenseitig den Platz streitig machen und anfangen, sich aus dem RAM zu kicken ...

https://forum.proxmox.com/threads/trying-to-understand-lxc-ram-and-swap-allocation.89166/

Zurück zum Thema

martin@DockerKlon1:~/gitea/pihole$ sudo lsof -i -P -n | grep 53
docker-pr  756            root    4u  IPv4 166697338      0t0  TCP *:53 (LISTEN)
docker-pr  787            root    4u  IPv6 166697376      0t0  TCP *:53 (LISTEN)
docker-pr  824            root    4u  IPv4 166696382      0t0  UDP *:53 
docker-pr  844            root    4u  IPv6 166696409      0t0  UDP *:53

Bei UDP fehlt das "(LISTEN)", könnte das eine Spur sein?

[crunchip]

@mickym sagte in PiHole in Proxmox->LXC->Docker:

Sehe ich nicht so - die Maschine fängt zwar zu swappen an

eine einzelne, sprich, ein LXC, aber nicht der HOST selbst, denn der braucht selbst auch etwas RAM, überdimensioniert, kanns in die Hose gehen, wenn gleichzeitig mal etwas mehr benötigt wird.

Beispiel
du hast 8GB RAM zur Verfügung
du hast 3 LXC laufen, jedem stellst du 6GB RAM zur Verfügung, die laufen im ruhigen Zustand zwar nur mit 2,5GB( die restlichen Vergebenen 3,5GB pro LXC sind übrig), ergo benötigen gesamt 7,5GB + Host ca 1-2GB RAM
und nun läuft ein LXC aus dem Ruder und verbraucht seinen komplett vergebenen RAM

2,5+2,5+6=11 und nun hat der Host nichts mehr und das System stürzt ab

[David G.]

@martinp sagte in PiHole in Proxmox->LXC->Docker:

@david-g Wollte den Wildwuchs an LXC-Containern limitieren...
Wenn man das ernsthaft machen will, muss man da ja wieder mit dem RAM schachern ...

Ich nutze Adguard anstatt pihole.
Der CT hat 512mb zu Verfügung wovon 47mb in Benutzung sind.

[MartinP]

Zurück zum Thema:

Das Web-Interface von PI-Hole hat die Lösung:

Manchmal sollte man nicht zu stolz sein, auch da mal nachzuschauen ;-)

EDIT Und in der Web-UI war dann auch die Lösung, diesen Haken eins weiter nach Unten gesetzt:

"Potentially dangerous" sollte sich relativieren, wenn der Server aus dem Internet nicht erreichbar ist ...

[MartinP]

Noch ein etwas deprimierender Nachtrag:
Entweder muss in im Docker noch einen größeren Aufriss machen, oder ich lasse PiHole abseits von Docker laufen: Derzeit hat Docker hier nur IPv4 konfiguriert. Das führt dazu, dass viel Werbung von PiHole nicht geblockt werden kann ...
Auch Werbung, die über IPv4 Adressen ausgeliefert wird ist davon betroffen. Wenn die DNSv4 Antwort vom PiHole nicht passt, wird der DNSv6 Server nach der IPv4 Adresse gefragt ...

"Dicht" ist man wahrscheinlich nur, wenn man den kompletten DNS-Verkehr über PiHole leitet ...

[Marc Berg]

@martinp sagte in [gelöst] PiHole in Proxmox->LXC->Docker:

Derzeit hat Docker hier nur IPv4 konfiguriert.

Wenn du kein MACVLAN nutzt (sondern ein Bridge-Netzwerk), kannst Du piHole trotzdem über die IPv6 Adresse des Hosts erreichen, auch wenn Docker selbst nicht für IPv6 konfiguriert ist.

Entscheidend ist, dass der Client DNS-seitig auch bei IPv6 auf den Docker Host zeigt.

[MartinP]

@marc-berg Der Host hat nun eine SLAAC Adresse (vorher nur link lokal IPv6).
Die hängt aber mit dem AdressRange zusammen, den die Fritzbox zugewiesen "2A02:8071:....." bekommen hat.

Wahrscheinlich braucht der LXC aber eine statische Link-Lokale IPv6 https://en.wikipedia.org/wiki/Unique_local_address

[Marc Berg]

@martinp sagte in [gelöst] PiHole in Proxmox->LXC->Docker:

Wahrscheinlich braucht der LXC aber eine statische Link-Lokale IPv6

Wie es sich verhält, wenn der LXC dazwischen hängt, kann ich nicht sagen. Mit "Docker-only" ist das unproblematisch.

[MartinP]

@marc-berg Ich habe jetzt mit der Fritzbox ein wenig gebastelt

Und das hier:

Habe dann gedacht, dass der LXC mit diesen Parameters gut bedient ist:

Adresse: fd00:BC24:118D:96FE:3ea6:2fff:fe78:eb53/64

Gateway fd00:0:0:0:3ea6:2fff:fe78:eb53

Leider lässt sich die FD00:.... Adresse aus dem Heimnetz nicht anpingen...

Die Fritzbox aber schon

Bei den Punkt "Unique Local Addresses (ULA) immer zuweisen" habe ich etwas Bauchschmerzen, ihn zu aktivieren - ob dann AUCH die Provider-Adressen zugewiesen werden. Hätte es nicht gerne, wenn die Geräte keine öffentlichen IPv6 Adressen mehr hätten

EDIT: Habe den Punkt mal aktiviert, und der LXC kriegt dann eine Öffentliche Adr und eine ULA

Die ULA lässt sich dann auch anpingen, also alles fein.

Interessant ist auch die Zuweisung ...

    inet6 fd00::be24:11ff:fe8d:96fe/64 scope global dynamic mngtmpaddr 
       valid_lft 7179sec preferred_lft 3579sec
    inet6 xxxx:xxxx:xxxx:xxxx:be24:11ff:fe8d:96fe/64 scope global dynamic mngtmpaddr 
       valid_lft 7179sec preferred_lft 3579sec

Statisch ist die ULA anscheinend nicht...

MAC-Adresse BC:24:11:8D:96:FE

Die letzten vier Gruppen sind bei beiden IPv6 Adressen identisch