[Pi-Hole] Ervaringen & discussie

[SyM]

Beste Tweakers,

Ik probeer al enige tijd mijn pi-hole werkend te krijgen in docker. Het draait wel, alleen als ik mijn client(s) wil verbinden naar mijn debian server met docker (pi-hole) dan werkt het niet (geen werkend internet op de client b.v. telefoon, windows computer etct)

Nu vermoed ik dat er iets mis gaat, maar kom er maar niet achter wat. Heb al wat zitten googlen maar zonder resultaat.

Heb Pi-hole met het volgende aangemaakt

code:

 docker run \
--name=pihole \
-e TZ=Europe/Brussels \
-e WEBPASSWORD=wachtwoord \
-e SERVERIP=192.168.1.110 \
-v pihole:/etc/pihole \
-v dnsmasq:/etc/dnsmasq.d \
--dns=127.0.0.1 --dns=1.1.1.1 \
-p 80:80 \
-p 53:53/tcp \
-p 53:53/udp \
--restart=unless-stopped \
pihole/pihole

Mijn resolv.config ziet er als volgt uit

code:

domain home
search home
nameserver 127.0.0.1

Heb ook al 8.8.8.8 geprobeerd aangezien dit in meerdere tutorials werd gebruikt, helaas zonder resultaat. Wellicht dat iemand mijn probleem ziet ?

Alvast bedankt.

[Airw0lf]

[quote]SyM schreef op vrijdag 16 september 2022 @ 23:40:

Wat is de status en config van Debian-firewall?

Wie of wat is dhcp-server? En wat staat daar als DNS-server en default gateway?

Probeer eens zonder 127.0.0.1? Dus alleen 1.1.1.1 of alleen 8.8.8.8?

[SyM]

Airw0lf schreef op zaterdag 17 september 2022 @ 00:22:
[quote]SyM schreef op vrijdag 16 september 2022 @ 23:40:

Wat is de status en config van Debian-firewall?

Wie of wat is dhcp-server? En wat staat daar als DNS-server en default gateway?

Probeer eens zonder 127.0.0.1? Dus alleen 1.1.1.1 of alleen 8.8.8.8?

Heb geen firewall draaien op mijn debian server. Mijn router is de dhcp-server, en de DNS is standaard geconfigureerd volgens mijn internet provider. ( het liefste zet ik alles richting de pi-hole maar mijn vrouw wil nog wel eens shoppen via google oid en begint dan te zeuren dat het niet werkt )

Als ik resolv.conf aanpass naar 1.1.1.1 dan heb ik nog steeds het zelfde probleem.

Tevens net de DNS in mijn router verwezen naar mijn pi-hole maar helaas zonder resultaat.

[ Voor 5% gewijzigd door SyM op 17-09-2022 09:00 ]

[Beun]

SyM schreef op zaterdag 17 september 2022 @ 08:55:
[...]


Heb geen firewall draaien op mijn debian server. Mijn router is de dhcp-server, en de DNS is standaard geconfigureerd volgens mijn internet provider. ( het liefste zet ik alles richting de pi-hole maar mijn vrouw wil nog wel eens shoppen via google oid en begint dan te zeuren dat het niet werkt )

Als ik resolv.conf aanpass naar 1.1.1.1 dan heb ik nog steeds het zelfde probleem.

Tevens net de DNS in mijn router verwezen naar mijn pi-hole maar helaas zonder resultaat.

DNS adres op het device eens wijzigen naar het Pi-Hole adres? En je hebt bij DNS op de router alleen het adres van de Pi-Hole ingevoerd?

[ Voor 19% gewijzigd door Beun op 17-09-2022 09:04 ]

[SyM]

Beun schreef op zaterdag 17 september 2022 @ 09:03:
[...]


DNS adres op het device eens wijzigen naar het Pi-Hole adres? En je hebt bij DNS op de router alleen het adres van de Pi-Hole ingevoerd?

Ja beide geprobeerd, op mijn android toestel dan wel mijn router, beide werken niet.

[Church of Noise]

Al eens wat dig commando's uitgevoerd op de Pi zelf?

Zoals

code:

dig google.com @192.168.1.110

, en heb je de status van je container geverifieerd?

[SyM]

Church of Noise schreef op zaterdag 17 september 2022 @ 09:39:
Al eens wat dig commando's uitgevoerd op de Pi zelf?

Zoals

code:

dig google.com @192.168.1.110

, en heb je de status van je container geverifieerd?

Als ik in mijn pihole container het volgende commando uitvoer
dan krijg ik dit

code:

root@a96270bffb01:/# dig google.com @192.168.1.110
;; reply from unexpected source: 172.17.0.1#53, expected 192.168.1.110#53

[Airw0lf]

SyM schreef op zaterdag 17 september 2022 @ 09:56:
[...]


Als ik in mijn pihole container het volgende commando uitvoer
dan krijg ik dit

code:

root@a96270bffb01:/# dig google.com @192.168.1.110
;; reply from unexpected source: 172.17.0.1#53, expected 192.168.1.110#53

En als je dit doet op de Docker host?
Maar zonder het "@192.168.1.110"

Graag de volledige output.

[ Voor 3% gewijzigd door Airw0lf op 17-09-2022 10:09 ]

[SyM]

Airw0lf schreef op zaterdag 17 september 2022 @ 10:04:
[...]


En als je dit doet op de Docker host?
Maar zonder het "@192.168.1.110"

Graag de volledige output.

in docker

code:

root@a96270bffb01:/# dig google.com @192.168.1.110
;; reply from unexpected source: 172.17.0.1#53, expected 192.168.1.110#53

;; reply from unexpected source: 172.17.0.1#53, expected 192.168.1.110#53

;; reply from unexpected source: 172.17.0.1#53, expected 192.168.1.110#53


; <<>> DiG 9.16.27-Debian <<>> google.com @192.168.1.110
;; global options: +cmd
;; connection timed out; no servers could be reached

op mijn docker host (debian)

code:

root@debian-server:/home/chris# dig google.com @192.168.1.110

; <<>> DiG 9.16.27-Debian <<>> google.com @192.168.1.110
;; global options: +cmd
;; connection timed out; no servers could be reached

En dit is mijn resolv.conf

code:

root@debian-server:/home/chris# cat /etc/resolv.conf
domain home
search home
nameserver 1.1.1.1

[Airw0lf]

SyM schreef op zaterdag 17 september 2022 @ 10:25:
[...]

Ik bedoelde: dig google.com (dus zonder het ip-adres van de dns-server)

En voor de zekerheid de debian-output van: ss -tulpn

[ Voor 63% gewijzigd door Airw0lf op 17-09-2022 10:30 ]

[SyM]

Airw0lf schreef op zaterdag 17 september 2022 @ 10:30:
[...]


Ik bedoelde: dig google.com (dus zonder het ip-adres van de dns-server)

En voor de zekerheid de debian-output van: ss -tulpn

Vanuit container pihole

code:

root@a96270bffb01:/#  dig google.com

; <<>> DiG 9.16.27-Debian <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3242
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             181     IN      A       142.250.179.142

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Sep 17 11:51:21 CEST 2022
;; MSG SIZE  rcvd: 55

Debain output

code:

root@debian-server:/home/chris# ss -tulpn
Netid          State           Recv-Q           Send-Q                      Local Address:Port                      Peer Address:Port          Process
udp            UNCONN          0                0                                 0.0.0.0:53                             0.0.0.0:*              users:(("docker-proxy",pid=269661,fd=4))
udp            UNCONN          0                0                                 0.0.0.0:68                             0.0.0.0:*              users:(("dhclient",pid=470,fd=9))
udp            UNCONN          0                0                                 0.0.0.0:111                            0.0.0.0:*              users:(("rpcbind",pid=96918,fd=5),("systemd",pid=1,fd=47))
udp            UNCONN          0                0                          172.17.255.255:137                            0.0.0.0:*              users:(("nmbd",pid=94464,fd=24))
udp            UNCONN          0                0                              172.17.0.1:137                            0.0.0.0:*              users:(("nmbd",pid=94464,fd=23))
udp            UNCONN          0                0                          172.19.255.255:137                            0.0.0.0:*              users:(("nmbd",pid=94464,fd=20))
udp            UNCONN          0                0                              172.19.0.1:137                            0.0.0.0:*              users:(("nmbd",pid=94464,fd=19))
udp            UNCONN          0                0                           192.168.1.255:137                            0.0.0.0:*              users:(("nmbd",pid=94464,fd=16))
udp            UNCONN          0                0                           192.168.1.110:137                            0.0.0.0:*              users:(("nmbd",pid=94464,fd=15))
udp            UNCONN          0                0                                 0.0.0.0:137                            0.0.0.0:*              users:(("nmbd",pid=94464,fd=13))
udp            UNCONN          0                0                          172.17.255.255:138                            0.0.0.0:*              users:(("nmbd",pid=94464,fd=26))
udp            UNCONN          0                0                              172.17.0.1:138                            0.0.0.0:*              users:(("nmbd",pid=94464,fd=25))
udp            UNCONN          0                0                          172.19.255.255:138                            0.0.0.0:*              users:(("nmbd",pid=94464,fd=22))
udp            UNCONN          0                0                              172.19.0.1:138                            0.0.0.0:*              users:(("nmbd",pid=94464,fd=21))
udp            UNCONN          0                0                           192.168.1.255:138                            0.0.0.0:*              users:(("nmbd",pid=94464,fd=18))
udp            UNCONN          0                0                           192.168.1.110:138                            0.0.0.0:*              users:(("nmbd",pid=94464,fd=17))
udp            UNCONN          0                0                                 0.0.0.0:138                            0.0.0.0:*              users:(("nmbd",pid=94464,fd=14))
udp            UNCONN          0                0                                    [::]:111                               [::]:*              users:(("rpcbind",pid=96918,fd=7),("systemd",pid=1,fd=50))
tcp            LISTEN          0                4096                              0.0.0.0:9000                           0.0.0.0:*              users:(("docker-proxy",pid=9546,fd=4))
tcp            LISTEN          0                50                                0.0.0.0:139                            0.0.0.0:*              users:(("smbd",pid=94474,fd=50))
tcp            LISTEN          0                4096                              0.0.0.0:111                            0.0.0.0:*              users:(("rpcbind",pid=96918,fd=4),("systemd",pid=1,fd=46))
tcp            LISTEN          0                4096                              0.0.0.0:80                             0.0.0.0:*              users:(("docker-proxy",pid=269635,fd=4))
tcp            LISTEN          0                4096                              0.0.0.0:8080                           0.0.0.0:*              users:(("docker-proxy",pid=9573,fd=4))
tcp            LISTEN          0                4096                              0.0.0.0:8081                           0.0.0.0:*              users:(("docker-proxy",pid=65729,fd=4))
tcp            LISTEN          0                4096                              0.0.0.0:53                             0.0.0.0:*              users:(("docker-proxy",pid=269648,fd=4))
tcp            LISTEN          0                128                               0.0.0.0:22                             0.0.0.0:*              users:(("sshd",pid=96924,fd=3))
tcp            LISTEN          0                20                              127.0.0.1:25                             0.0.0.0:*              users:(("exim4",pid=97186,fd=4))
tcp            LISTEN          0                50                                0.0.0.0:445                            0.0.0.0:*              users:(("smbd",pid=94474,fd=49))
tcp            LISTEN          0                4096                              0.0.0.0:8000                           0.0.0.0:*              users:(("docker-proxy",pid=9560,fd=4))
tcp            LISTEN          0                4096                            127.0.0.1:46881                          0.0.0.0:*              users:(("containerd",pid=615,fd=11))
tcp            LISTEN          0                50                                   [::]:139                               [::]:*              users:(("smbd",pid=94474,fd=48))
tcp            LISTEN          0                4096                                 [::]:111                               [::]:*              users:(("rpcbind",pid=96918,fd=6),("systemd",pid=1,fd=49))
tcp            LISTEN          0                32                                      *:21                                   *:*              users:(("vsftpd",pid=96916,fd=3))
tcp            LISTEN          0                128                                  [::]:22                                [::]:*              users:(("sshd",pid=96924,fd=4))
tcp            LISTEN          0                20                                  [::1]:25                                [::]:*              users:(("exim4",pid=97186,fd=5))
tcp            LISTEN          0                50                                   [::]:445                               [::]:*              users:(("smbd",pid=94474,fd=47))
               LISTEN                0                      32                                              [::]:53                                           [::]:*

[Airw0lf]

SyM schreef op zaterdag 17 september 2022 @ 11:51:

[...]

[/code]

Mmm... - als ik dat allemaal zo terugkijk dan lijkt het erop alsof 192.168.1.110 niet het adres is van je Debian/Docker host. Wat is op Debian de output van "ip a"? En voor de zekerheid de output van "ufw status"?

Voor nu neem ik even aan dat het IP adres wel klopt en ufw inderdaad uit staat.

Ik weet dat er wel eens problemen zijn met de IPtables. Daarom:
Pas de pihole-Docker-config eens aan zodat ie gebruik maakt van Docker zijn "host"-netwerk.
En dan opnieuw de output van "dig google.com" en "ss -tulpn".

[bluecupra]

Ik maak al geruime tijd gebruik van Pihole binnen Docker op mijn Synology NAS. Voor het updaten van het package gebruik ik Watchtower. Het updaten van core/web en ftl gaat hiermee prima echter blijft het image op versie 2002.4 staan en toont Pihole ook dat er een update beschikbaar is (2022.9.3)

Nu heb ik in Portainer gekozen voor een recreate en pull latest image echter wordt dit niet bijgewerkt naar de laatste versie.

Binnen Docker op de Synology heb ik ingesteld om het laatste officiële image te gebruiken.

Voor nu heb ik het opgelost door in Docker ipv latest image te kiezen voor de laatst beschikbare versie (2022.9.3), heb vervolgens het package verwijderd en opnieuw aangemaakt.

Is hier een makkelijkere methode voor of waarom update Wathctower de Pihole versie niet?

[Freee!!]

bluecupra schreef op zaterdag 17 september 2022 @ 14:24:
Ik maak al geruime tijd gebruik van Pihole binnen Docker op mijn Synology NAS. Voor het updaten van het package gebruik ik Watchtower. Het updaten van core/web en ftl gaat hiermee prima echter blijft het image op versie 2002.4 staan en toont Pihole ook dat er een update beschikbaar is (2022.9.3)

Nu heb ik in Portainer gekozen voor een recreate en pull latest image echter wordt dit niet bijgewerkt naar de laatste versie.

Binnen Docker op de Synology heb ik ingesteld om het laatste officiële image te gebruiken.

Voor nu heb ik het opgelost door in Docker ipv latest image te kiezen voor de laatst beschikbare versie (2022.9.3), heb vervolgens het package verwijderd en opnieuw aangemaakt.

Is hier een makkelijkere methode voor of waarom update Wathctower de Pihole versie niet?

Goede vraag, bij mij update Watchtower de PiHole wel correct. Zorg, dat Watchtower niet te vaak actief is, er zijn ondertussen restricties op hoe vaak je kunt kijken of er iets nieuws is en dat downloaden.

EDIT: Dat probleem met Portainer heb ik ook.

[Airw0lf]

Freee!! schreef op zaterdag 17 september 2022 @ 14:31:
[...]

Goede vraag, bij mij update Watchtower de PiHole wel correct. Zorg, dat Watchtower niet te vaak actief is, er zijn ondertussen restricties op hoe vaak je kunt kijken of er iets nieuws is en dat downloaden.

Voor zover nog niet gedaan: je zou Watchtower ook in een schedule kunnen steken?
Bijvoorbeeld een keer in de week op zaterdagmorgen om 5:00 uur:

code:

-e WATCHTOWER_SCHEDULE="0 0 5 * * 6" \

Hoewel er gewerkt wordt met een cronjob format moet je echt 6 posities gebruiken - met 5 werkt het niet goed. Ook op de afkortingen van de dagen van week gaat het mis!

[Freee!!]

Airw0lf schreef op zaterdag 17 september 2022 @ 21:08:
[...]
Voor zover nog niet gedaan: je zou Watchtower ook in een schedule kunnen steken?
Bijvoorbeeld een keer in de week op zaterdagmorgen om 5:00 uur:

code:

-e WATCHTOWER_SCHEDULE="0 0 5 * * 6"

Hoewel er gewerkt wordt met een cronjob format moet je echt 6 posities gebruiken - met 5 werkt het niet goed. Ook op de afkortingen van de dagen van week gaat het mis!

code:

 -e WATCHTOWER_POLL_INTERVAL=7200 \

Elke twee uur bij mij (in plaats van default elke vijf minuten/300 seconden).

[SyM]

Airw0lf schreef op zaterdag 17 september 2022 @ 12:33:
[...]


Mmm... - als ik dat allemaal zo terugkijk dan lijkt het erop alsof 192.168.1.110 niet het adres is van je Debian/Docker host. Wat is op Debian de output van "ip a"? En voor de zekerheid de output van "ufw status"?

Voor nu neem ik even aan dat het IP adres wel klopt en ufw inderdaad uit staat.

Ik weet dat er wel eens problemen zijn met de IPtables. Daarom:
Pas de pihole-Docker-config eens aan zodat ie gebruik maakt van Docker zijn "host"-netwerk.
En dan opnieuw de output van "dig google.com" en "ss -tulpn".

Container zijn network type aangepast naar host in plaats van bridge, nu werkt het bedankt voor jullie hulp.

[Airw0lf]

Freee!! schreef op zaterdag 17 september 2022 @ 21:52:

code:

 -e WATCHTOWER_POLL_INTERVAL=7200 \

Elke twee uur bij mij (in plaats van default elke vijf minuten/300 seconden).

Vanwaar elke twee uur?

[Freee!!]

Airw0lf schreef op zaterdag 17 september 2022 @ 22:53:
[...]
Vanwaar elke twee uur?

Omdat bij die frequentie (met meerdere Pi's en meerdere containers per Pi) mijn IP-adres niet geblokkeerd wordt, wat wel gebeurt bij een hogere frequentie. Elke drie uur zou ook kunnen, maar voor sommige zaken wil ik gewoon zo snel mogelijk updaten.

[Afiso]

Kan iemand voor me testen of www.rcgroups.com bereikbaar is en ook wanneer je hem toevoegd in je Whitelist? Ik kan het maar niet bereiken met Pi-hole aan en toegevoegd in m;n Whitelist.

alvast bedankt.

[Convoy]

Afiso schreef op zondag 18 september 2022 @ 13:31:
Kan iemand voor me testen of www.rcgroups.com bereikbaar is en ook wanneer je hem toevoegd in je Whitelist? Ik kan het maar niet bereiken met Pi-hole aan en toegevoegd in m;n Whitelist.

alvast bedankt.

Is hier gewoon te bereiken.

https://www.rcgroups.com/forums/index.php

[ Voor 6% gewijzigd door Convoy op 18-09-2022 14:06 ]

[Webgnome]

Geen probleem hier..

[Afiso]

Convoy schreef op zondag 18 september 2022 @ 14:05:
[...]


Is hier gewoon te bereiken.

https://www.rcgroups.com/forums/index.php

Bedankt voor het controleren. Ik zie dat de page nu wel bereikbaar is, nadat ik alleen rcgroups.com , ipv www.rcgroups.com heb toegevoegd aan de Whitelist.

[nero355]

Afiso schreef op zondag 18 september 2022 @ 14:34:
Bedankt voor het controleren. Ik zie dat de page nu wel bereikbaar is, nadat ik alleen rcgroups.com , ipv www.rcgroups.com heb toegevoegd aan de Whitelist.

Ik heb hier helemaal niks gedaan en het werkt gewoon dus misschien was de website bij jou effe offline of zo

Mocht je het nog niet ontdekt hebben dan kan je trouwens ook eens hier rondneuzen : Het grote RC cars topic - Deel 2

SyM schreef op zaterdag 17 september 2022 @ 22:47:
Container zijn network type aangepast naar host in plaats van bridge, nu werkt het bedankt voor jullie hulp.

Ik heb altijd van onze Pi-Hole + Unbound draaiende Docker Expert @Freee!! begrepen dat je gewoon het beste een MACVLAN Network kan draaien en dan elke Container een eigen IP adres op je LAN kan geven

SyM schreef op zaterdag 17 september 2022 @ 08:55:
Mijn router is de dhcp-server, en de DNS is standaard geconfigureerd volgens mijn internet provider. ( het liefste zet ik alles richting de pi-hole maar mijn vrouw wil nog wel eens shoppen via google oid en begint dan te zeuren dat het niet werkt )

Dat is op te lossen door bepaalde Whitelists/Blacklists aan bepaalde Clients te koppelen

[Freee!!]

nero355 schreef op maandag 19 september 2022 @ 00:37:
[...]
Ik heb altijd van onze Pi-Hole + Unbound draaiende Docker Expert @Freee!! begrepen dat je gewoon het beste een MACVLAN Network kan draaien en dan elke Container een eigen IP adres op je LAN kan geven

Ik zeg niet, dat dat het beste is, maar ik vind dat wel het gemakkelijkste werken omdat je dan meteen geen problemen hebt met poortnummers. Overigens draai ik niet alle Containers in macvlan, maar alleen die, waarbij het gemakkelijker is (Pi-Hole, Unbound, SMTP e.d.), Portainer werkt gewoon niet op die manier en Watchtower heeft het niet nodig.

[Afiso]

nero355 schreef op maandag 19 september 2022 @ 00:37:
[...]

Ik heb hier helemaal niks gedaan en het werkt gewoon dus misschien was de website bij jou effe offline of zo

Mocht je het nog niet ontdekt hebben dan kan je trouwens ook eens hier rondneuzen : Het grote RC cars topic - Deel 2

Thanks! Meestal ben ik van wege de FPV rc vliegtuigen hobby op rcgroups, maar heb ook een rc auto de HPI Truggy, nitro, dus komt goed uit.

Ik merk dat de Pi-hole op m'n raspberry na wat uurtjes niet te bereiken is en heb dan geen internet verbinding.

Gaat ie automatisch in sleeping modus ofzo?

[Webgnome]

zoek even in dit topic. Het kan een van de volgende dingen zijn

• Crappy voeding
• Crappy sd card
• iets anders..

[Afiso]

Webgnome schreef op maandag 19 september 2022 @ 18:44:
zoek even in dit topic. Het kan een van de volgende dingen zijn

• Crappy voeding
• Crappy sd card
• iets anders..

Sorry ff vergeten de zoek functie te gebruiken. Thanks!

[nero355]

@Webgnome @Afiso

Er was ook nog een brakke batch van die dingen of zo waarbij de LAN NIC zichzelf ophing...

[Workaholic]

Is er een eenvoudige manier om te troubleshooten waarom het internet browsen op de iphones traag aanvoelt via de pihole? Ik maak gebruik van een Raspberry Pi 4 Model B met 4GB ram.

Als ik wissel naar een ander Wifi netwerk via dezelfde router en ISP waar er direct DNS lookups worden gedaan op de firewall is er geen vertraging en alles zeer snel - dit is bij het wifi netwerk met pihole er tussen wel anders. Gemiddeld zijn 40-50% van de lookups langzaam, soms wel 1-3 sec wachten alvorens de pagina laad. Ik heb nog niet voldoende kunnen testen, maar het lijkt primair voor te komen op allebei onze iphones (12 en 14pro)

Wat heb ik al gecontroleerd
- top laat lage belasting zien
- geen vreemde blocks
- diagnostics geeft alleen melding over interface eth0.10 does not currently exist
- dns lookup gaat via router in hetzelfde subnet, dit is een UDM SE met als ISP KPN glasvezel met als DNS 1.1.1.1
- live log laat 0-20 ms zien afhankelijk van cached site of niet, zie hierbij een voorbeeld

[ Voor 6% gewijzigd door Workaholic op 20-09-2022 17:41 ]

[Webgnome]

Draai je nog meer op die pihole? Kijk even in de logs van hole wat de lookup tijd is

Laat maar..

[ Voor 10% gewijzigd door Webgnome op 20-09-2022 18:36 ]

[mrdemc]

Workaholic schreef op dinsdag 20 september 2022 @ 17:35:
Is er een eenvoudige manier om te troubleshooten waarom het internet browsen op de iphones traag aanvoelt via de pihole? Ik maak gebruik van een Raspberry Pi 4 Model B met 4GB ram.

Als ik wissel naar een ander Wifi netwerk via dezelfde router en ISP waar er direct DNS lookups worden gedaan op de firewall is er geen vertraging en alles zeer snel - dit is bij het wifi netwerk met pihole er tussen wel anders. Gemiddeld zijn 40-50% van de lookups langzaam, soms wel 1-3 sec wachten alvorens de pagina laad. Ik heb nog niet voldoende kunnen testen, maar het lijkt primair voor te komen op allebei onze iphones (12 en 14pro)

Wat heb ik al gecontroleerd
- top laat lage belasting zien
- geen vreemde blocks
- diagnostics geeft alleen melding over interface eth0.10 does not currently exist
- dns lookup gaat via router in hetzelfde subnet, dit is een UDM SE met als ISP KPN glasvezel met als DNS 1.1.1.1
- live log laat 0-20 ms zien afhankelijk van cached site of niet, zie hierbij een voorbeeld

Mogelijk heeft dat iets te maken met de private relay functionaliteit van Apple. Je zou daarover icm Pi-hole wel het een en ander moeten kunnen vinden.

[Church of Noise]

Webgnome schreef op dinsdag 20 september 2022 @ 18:35:
Draai je nog meer op die pihole? Kijk even in de logs van hole wat de lookup tijd is

Laat maar..

Dit dus.
Je DNS query tijden zijn zondermeer goed, zelfs een verdubbeling ervan ga je in praktijk niet merken.

Lijkt dus aan iets anders te liggen...

[bibi2205]

Workaholic schreef op dinsdag 20 september 2022 @ 17:35:
Is er een eenvoudige manier om te troubleshooten waarom het internet browsen op de iphones traag aanvoelt via de pihole? Ik maak gebruik van een Raspberry Pi 4 Model B met 4GB ram.

Ik heb dit ook gehad op de iPhones/iPads hier. Wanneer je op je iPhone "Limit IP Address Tracking" uitzet op het wifi netwerk met de Pihole heb je geen problemen meer.

[Workaholic]

Dank - ik ga dit proberen. Ik zie overigens twee opties :

Privé WiFi adres en beperk ip tracking. Adviseren jullie dan allebei uit te zetten ?

[Hansie_P]

Workaholic schreef op woensdag 21 september 2022 @ 09:45:
Dank - ik ga dit proberen. Ik zie overigens twee opties :

Privé WiFi adres en beperk ip tracking. Adviseren jullie dan allebei uit te zetten ?

Die tweede moet, die eerste kan. Private wifi adres genereert om de zoveel tijd een ander mac adres. Is niet handig als je pihole als dhcp gebruikt met static lease op mac adres

[dennis_LU]

Hansie_P schreef op woensdag 21 september 2022 @ 10:56:
[...]


Die tweede moet, die eerste kan. Private wifi adres genereert om de zoveel tijd een ander mac adres. Is niet handig als je pihole als dhcp gebruikt met static lease op mac adres

Private mac is per SSID (Wifinetwerk) dus die veranderd niet zomaar.

Ik heb het volgende in mijn config gezet:

/etc/pihole/pihole-FTL.conf
BLOCK_ICLOUD_PR=false

daarna herstart van pihole-FTL
Toen was het trage resolven op mijn apple-devices weg. zonder dat ik beperk ip tracking uit heb geschakeld

[ Voor 4% gewijzigd door dennis_LU op 21-09-2022 11:03 ]

[Webgnome]

Hansie_P schreef op woensdag 21 september 2022 @ 10:56:
[...]


Die tweede moet, die eerste kan. Private wifi adres genereert om de zoveel tijd een ander mac adres. Is niet handig als je pihole als dhcp gebruikt met static lease op mac adres

waarom zou je je telefoon een static ip geven?

[Raymond P]

Webgnome schreef op woensdag 21 september 2022 @ 11:44:
[...]


waarom zou je je telefoon een static ip geven?

Webdav? Ik trek wel eens een foto of een file van mijn phone.
M'n telefoon heeft al tijden geen static IP meer maar DNS wordt netjes geupdated, benaderbaar middels name dus.

Domotica / aanwezigheidsdetectie kan ook een goede reden zijn.

[nero355]

Webgnome schreef op woensdag 21 september 2022 @ 11:44:
waarom zou je je telefoon een static ip geven?

Static DHCP IP Mapping op basis van het MAC address is hier voor alles van toepassing en daar zit uiteraard een mooie Pi-Hole Local DNS Record aan vast zodat ik weet wat elk apparaat uitspookt op een makkelijke manier!

dennis_LU schreef op woensdag 21 september 2022 @ 11:02:
Private mac is per SSID (Wifinetwerk) dus die veranderd niet zomaar.

Maar die verandert toch bij elke DHCP Lease en/of elke keer als je met hetzelfde WiFi netwerk verbindt

Ik heb in ieder geval genoeg berichten gezien over iOS/Android apparaten die het netwerk zitten te vervuilen op die manier...

[ Voor 34% gewijzigd door nero355 op 21-09-2022 15:33 ]

[Airw0lf]

nero355 schreef op woensdag 21 september 2022 @ 15:31:
[...]

Static DHCP IP Mapping op basis van het MAC address is hier voor alles van toepassing en daar zit uiteraard een mooie Pi-Hole Local DNS Record aan vast zodat ik weet wat elk apparaat uitspookt op een makkelijke manier!

Als aanvulling: het is dan wel zaak dat je telefoon altijd hetzelfde mac-adres gebruikt!
Dus als je in je wifi-instellingen iets ziet als "randomized mac", dan die niet gebruiken.

[nero355]

Airw0lf schreef op woensdag 21 september 2022 @ 15:37:
Als aanvulling: het is dan wel zaak dat je telefoon altijd hetzelfde mac-adres gebruikt!
Dus als je in je wifi-instellingen iets ziet als "randomized mac", dan die niet gebruiken.

Daar hebben we het net over...

[Hansie_P]

Ik heb zelf ook iets raars op apple apparaten. Pihole zegt netjes dat ads worden geblokkeerd. Tweakers als voorbeeld:


De website laat echter wel ads zien:


Limit IP adress tracking staat uit op het netwerk evenals private relay. Het viel me wel op dat er een fdd5 ipv6 is toegewezen aan de ipad. Op mijn router is ipv6 helemaal uitgeschakeld. Zou dit het kunnen bypassen? Iemand nog een idee? Thanks!

[deHakkelaar]

Ik snap niet dat je al je clients een DHCP reservering meegeeft ... waarom?
Je hoort niet op IP niveau te verbinden met je clients maar op naam.
EDIT: Laat staan de moeite die je ervoor moet doen.
En de meeste DHCP services zijn "deterministic" met het uitdelen van IP's (EDIT: of kunnen daarvoor ingesteld worden) wat inhoud dat het IP bepaald wordt door het MAC adres vd clients ... in vele gevallen.
Dus als je client MAC niet verandert krijg je bijna altijd hetzelfde IP uitgedeeld van de DHCP server.

EDIT2: Ow en dat MAC kan wel "anonymised" zijn zolang maar niet elke keer is "randomised" met verbinden.
Onderstaande op je Pi:

code:

ip n

[ Voor 22% gewijzigd door deHakkelaar op 21-09-2022 22:04 ]

[deHakkelaar]

Hansie_P schreef op woensdag 21 september 2022 @ 16:49:
De website laat echter wel ads zien:

Tweakers is een slechte test omdat sommige ads van het tweakers.net domein afkomstig zijn.
Onderstaande is veel beter en toont bij mij geen enkele ad:

code:

https://www.speedtest.net/

[Hansie_P]

deHakkelaar schreef op woensdag 21 september 2022 @ 21:44:
[...]

Tweakers is een slechte test omdat sommige ads van het tweakers.net domein afkomstig zijn.
Onderstaande is veel beter en toont bij mij geen enkele ad:

code:

https://www.speedtest.net/

Die is ook geheel ad vrij bij mij. Dan zal tweakers wel een uitzondering zijn. Thanks!

[dss58]

deHakkelaar schreef op woensdag 21 september 2022 @ 21:39:
Ik snap niet dat je al je clients een DHCP reservering meegeeft ... waarom?
Je hoort niet op IP niveau te verbinden met je clients maar op naam.
EDIT: Laat staan de moeite die je ervoor moet doen.
En de meeste DHCP services zijn "deterministic" met het uitdelen van IP's (EDIT: of kunnen daarvoor ingesteld worden) wat inhoud dat het IP bepaald wordt door het MAC adres vd clients ... in vele gevallen.
Dus als je client MAC niet verandert krijg je bijna altijd hetzelfde IP uitgedeeld van de DHCP server.

EDIT2: Ow en dat MAC kan wel "anonymised" zijn zolang maar niet elke keer is "randomised" met verbinden.
Onderstaande op je Pi:

code:

ip n

exact, met de nadruk op bijna want heb rare dingen gezien

[deHakkelaar]

dss58 schreef op woensdag 21 september 2022 @ 22:22:
[...]

exact, met de nadruk op bijna want heb rare dingen gezien

Er zijn altijd uitzonderingen
Bv als je veel wisselende clients op je netwerk hebt en de lease pool leeg raakt.
Thuis zie ik dit niet snel gebeuren.

[ Voor 5% gewijzigd door deHakkelaar op 21-09-2022 22:27 ]

[dss58]

deHakkelaar schreef op woensdag 21 september 2022 @ 22:26:
[...]

Er zijn altijd uitzonderingen
Bv als je veel wisselende clients op je netwerk hebt en de lease pool leeg raakt.
Thuis zie ik dit niet snel gebeuren.

ik heb het gezien bij een vriend van me, die heeft 2 pi's waar ik op kan vanaf hier, 1 draait pihole, geen probleem, de ander werd het IP adres ineens "geconfisceerd" door later bleek applemeuk, kwam erachter door een nmap scan op OS nivo, maar OS op de pi is slimmer en krijgt meteen een nieuw ip adres van de DHCP server, dus dan ga ik in de logfiles spitten, die andere pi ook maar een static ip adres buiten de DHCP range, opgelost was leuk puzzeltje terwijl de gebruiker er niks van heeft gemerkt

[deHakkelaar]

@dss58 , ik zeg altijd met Linux hoef je maar één commando te weten namelijk: man ...
en grep, sed, awk, curl, netcat, stat, dd, tcpdump en nmap

[ Voor 6% gewijzigd door deHakkelaar op 21-09-2022 23:22 . Reden: ook curl ;) ]

[dss58]

deHakkelaar schreef op woensdag 21 september 2022 @ 23:17:
@dss58 , ik zeg altijd met Linux hoef je maar één commando te weten namelijk: man ...
en grep, sed, awk, curl, netcat, stat, dd, tcpdump en nmap

ja, dat heb je helemaal goed
ik heb nog wel wat te leren trouwens... maar is een leuke uitdaging

[ Voor 8% gewijzigd door dss58 op 22-09-2022 01:25 ]

[dennis_LU]

nero355 schreef op woensdag 21 september 2022 @ 15:31:

Maar die verandert toch bij elke DHCP Lease en/of elke keer als je met hetzelfde WiFi netwerk verbindt

Ik heb in ieder geval genoeg berichten gezien over iOS/Android apparaten die het netwerk zitten te vervuilen op die manier...

Nee hoor. Althans, niet op al mijn Apple devices.
Eenmalig macadres gegenereerd per ssid

[nero355]

dennis_LU schreef op donderdag 22 september 2022 @ 07:41:
Nee hoor. Althans, niet op al mijn Apple devices.
Eenmalig macadres gegenereerd per ssid

En die blijft ook hetzelfde als je laten we zeggen een week lang met een ander SSID verbindt en daarna weer terug gaat naar het SSID waarmee je eerst verbonden was

Hansie_P schreef op woensdag 21 september 2022 @ 16:49:
Ik heb zelf ook iets raars op apple apparaten. Pihole zegt netjes dat ads worden geblokkeerd. Tweakers als voorbeeld:
[Afbeelding]

De website laat echter wel ads zien:
[Afbeelding]

Hou er rekening mee dat Tweakers een of ander geintje flikt om je een advertentie voor te schotelen zelfs als je ze blokkeert!

Het enige waarmee je dat kan stoppen is door te rommelen met uBlock Origin bijvoorbeeld

Het viel me wel op dat er een fdd5 ipv6 is toegewezen aan de ipad.
Op mijn router is ipv6 helemaal uitgeschakeld.

Zou dit het kunnen bypassen?

Het IPv6 adres dat je noemt klinkt als Link-Local en die is precies dat : Puur een lokaal adres!

[Thasaidon]

Hansie_P schreef op woensdag 21 september 2022 @ 16:49:
Ik heb zelf ook iets raars op apple apparaten. Pihole zegt netjes dat ads worden geblokkeerd. Tweakers als voorbeeld:
...
De website laat echter wel ads zien:

Limit IP adress tracking staat uit op het netwerk evenals private relay. Het viel me wel op dat er een fdd5 ipv6 is toegewezen aan de ipad. Op mijn router is ipv6 helemaal uitgeschakeld. Zou dit het kunnen bypassen? Iemand nog een idee? Thanks!

Dat heeft niets met Apple te maken. Ik heb hetzelfde op mijn WIndows PC in bv Firefox en ook op mijn Chromebook in Chrome.
Op de een of andere manier komen specifieke adds op Tweakers er toch tussendoor.

Ik heb nog niet gevonden hoe die geblokkeerd kunnen worden, maar vind het wel rete irritant.

[Webgnome]

@Thasaidon dat komt omdat ze vanaf het zelfde domein worden gehost. Daarnaast zie je steeds vaker dat er html wordt gebruikt ipv afbeeldingen. Dus dan zie je de afbeeldingen uit die div niet (als ze vanaf een subdomein komen) maar wel de add tekst. Daar kan pihole niet tegenop.

offtopic:
Het zou fijn zijn als mensen zich een klein beetje zouden verdiepen in wat pihole doet, hoe het werkt en wat het wel en niet kan..

[ Voor 26% gewijzigd door Webgnome op 22-09-2022 19:08 ]

[Freee!!]

Webgnome schreef op donderdag 22 september 2022 @ 19:04:
@Thasaidon dat komt omdat ze vanaf het zelfde domein worden gehost. Daar kan pihole niet tegenop.

Datzelfde probleem speelt met YT.

[Sp33dFr34k]

Jullie hebben Tweakers niet gewhitelist?

[dennis_LU]

nero355 schreef op donderdag 22 september 2022 @ 14:45:
[...]

En die blijft ook hetzelfde als je laten we zeggen een week lang met een ander SSID verbindt en daarna weer terug gaat naar het SSID waarmee je eerst verbonden was

Bij mij wel.

[Raymond P]

Sp33dFr34k schreef op donderdag 22 september 2022 @ 19:22:
Jullie hebben Tweakers niet gewhitelist?

Wat non-woke van je.

Lastig posten hier als je die blacklisted hebt...

[Sp33dFr34k]

Raymond P schreef op donderdag 22 september 2022 @ 20:15:
[...]


Wat non-woke van je.

Lastig posten hier als je die blacklisted hebt...

Whut? Wie heeft het over blacklisten?

[deHakkelaar]

Raymond P schreef op donderdag 22 september 2022 @ 20:15:
[...]


Wat non-woke van je.

Lastig posten hier als je die blacklisted hebt...

Deze wordt bedoeld:

code:

pihole -w {aa,ab}.tweakers.nl --comment "tweakers.net advertenties"

pi@ph5b:~ $ pihole -q aa.tweakers.nl
 Match found in exact whitelist
   aa.tweakers.nl
 Match found in https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts:
   aa.tweakers.nl

En oa dit:
plan: Tweakers’ overstap naar advertenties zonder thirdpartytracking is een feit

[Raymond P]

@Sp33dFr34k Ik!

@deHakkelaar Aah zo, had ik moeten weten. Ik dacht dat die inmiddels van tweakers.net kwamen...

[nero355]

Thasaidon schreef op donderdag 22 september 2022 @ 18:36:
Dat heeft niets met Apple te maken. Ik heb hetzelfde op mijn WIndows PC in bv Firefox en ook op mijn Chromebook in Chrome.
Op de een of andere manier komen specifieke adds op Tweakers er toch tussendoor.

Ik heb nog niet gevonden hoe die geblokkeerd kunnen worden, maar vind het wel rete irritant.

uBlock Origin en dan die picker!

Maar een abonnement voor € 1,50 per maand vind ik ook geen ramp!

[bibi2205]

dennis_LU schreef op woensdag 21 september 2022 @ 11:02:
[...]


Private mac is per SSID (Wifinetwerk) dus die veranderd niet zomaar.

Ik heb het volgende in mijn config gezet:

/etc/pihole/pihole-FTL.conf
BLOCK_ICLOUD_PR=false

daarna herstart van pihole-FTL
Toen was het trage resolven op mijn apple-devices weg. zonder dat ik beperk ip tracking uit heb geschakeld

Het beperken van IP tracking is ook per netwerk (dus ik vond het handiger om het gewoon op mijn thuisnetwerk uit te schakelen) maar dit kan idd ook.

[Thasaidon]

nero355 schreef op donderdag 22 september 2022 @ 23:36:
[...]

uBlock Origin en dan die picker!

Ik gebruik uBlock Origin, maar toch komen sommige adds daar nog doorheen.
Je kunt dan wel aangeven dat de add geblocked moet worden, maar na een tijdje verschijnt hij toch weer.

En ja een abbo nemen om geen reclame meer te zien kan, maar het gaat mij om het principe.
Maar dat is een hele andere discussie

[nero355]

Thasaidon schreef op maandag 26 september 2022 @ 10:46:
Ik gebruik uBlock Origin, maar toch komen sommige adds daar nog doorheen.
Je kunt dan wel aangeven dat de add geblocked moet worden, maar na een tijdje verschijnt hij toch weer.

Bij mij leek het blokkeren van het element wel goed te werken, maar ik heb het niet echt heel erg uitgebreid getest heel eerlijk gezegd

[Beun]

Zojuist mijn meterkast wat netter gemaakt en hiervoor moest ik dus alle apparaten loskoppelen. Eenmaal opgestart had ik geen internetverbinding. Ik zag vrij vlot dat het een DNS issue was. Hierop heb ik Unbound uitgeschakeld en via Pi-Hole OpenDNS ingeschakeld. Nu heb ik weer verbinding. Zodra ik weer naar Unbound overschakel gaat het mis.

Wat heb ik al gedaan?
Unbound opnieuw gestart, config file gecheckt, Unbound opnieuw geïnstalleerd. Helaas mocht dit allemaal niet baten.

Iemand nog enig idee wat het kan zijn?

Edit:
Waarschijnlijk heb ik iets gevonden. Ik zie dat mijn Intel Nuc aangeeft dat het 7 augustus 2022 15:45 is. Zou dit het probleem kunnen veroorzaken?

Edit 2:
Probleem verholpen! De tijd stond verkeerd. Deze heb ik via de Terminal goed gezet en het werkt weer als een zonnetje.

[ Voor 20% gewijzigd door Beun op 26-09-2022 20:37 ]

[mrdemc]

Beun schreef op maandag 26 september 2022 @ 20:30:
Zojuist mijn meterkast wat netter gemaakt en hiervoor moest ik dus alle apparaten loskoppelen. Eenmaal opgestart had ik geen internetverbinding. Ik zag vrij vlot dat het een DNS issue was. Hierop heb ik Unbound uitgeschakeld en via Pi-Hole OpenDNS ingeschakeld. Nu heb ik weer verbinding. Zodra ik weer naar Unbound overschakel gaat het mis.

Wat heb ik al gedaan?
Unbound opnieuw gestart, config file gecheckt, Unbound opnieuw geïnstalleerd. Helaas mocht dit allemaal niet baten.

Iemand nog enig idee wat het kan zijn?

Edit:
Waarschijnlijk heb ik iets gevonden. Ik zie dat mijn Intel Nuc aangeeft dat het 7 augustus 2022 15:45 is. Zou dit het probleem kunnen veroorzaken?

Heb je de logs al eens bekeken?

[Beun]

mrdemc schreef op maandag 26 september 2022 @ 20:33:
[...]


Heb je de logs al eens bekeken?

Nee, niet gedaan. Heb daar zo 1,2,3 niet aan gedacht. Maar het probleem is opgelost! De tijd stond verkeerd en hierdoor was het voor Unbound niet mogelijk om te werken. Tijd en datum via de Terminal aangepast en het werkt weer als een zonnetje.

[ninjazx9r98]

Beun schreef op maandag 26 september 2022 @ 20:36:
[...]


Nee, niet gedaan. Heb daar zo 1,2,3 niet aan gedacht. Maar het probleem is opgelost! De tijd stond verkeerd en hierdoor was het voor Unbound niet mogelijk om te werken. Tijd en datum via de Terminal aangepast en het werkt weer als een zonnetje.

Nu nog even een NTP client installeren, blijft die tijd voortaan ook gewoon goed lopen

[Freee!!]

ninjazx9r98 schreef op maandag 26 september 2022 @ 21:26:
[...]
Nu nog even een NTP client installeren, blijft die tijd voortaan ook gewoon goed lopen

Werkt niet, die NTP client moet na een reboot eerst een IP-adres verkrijgen (via Pi-Hole en Unbound) voordat die de juiste tijd op kan halen en daarna aan kan geven.

[ninjazx9r98]

Freee!! schreef op maandag 26 september 2022 @ 21:51:
[...]

Werkt niet, die NTP client moet na een reboot eerst een IP-adres verkrijgen (via Pi-Hole en Unbound) voordat die de juiste tijd op kan halen en daarna aan kan geven.

Huh?
Geloof niet dat ik begrijp wat je hier nu bedoelt.
Bedoel je dat je geen NTP server kunt resolven omdat er nog niets draait? IP adres(sen) in de NTP config of een paar entries in /etc/hosts en gaan.
Als het puur om een reboot gaat zou iets ala fake hwclock ook nog een oplossing kunnen zijn om in ieder geval een soort van op tijd te beginnen.

[ Voor 12% gewijzigd door ninjazx9r98 op 26-09-2022 22:03 ]

[Freee!!]

ninjazx9r98 schreef op maandag 26 september 2022 @ 22:02:
[...]
Huh?
Geloof niet dat ik begrijp wat je hier nu bedoelt.
Bedoel je dat je geen NTP server kunt resolven omdat er nog niets draait? IP adres(sen) in de NTP config of een paar entries in /etc/hosts en gaan.

Dat zou inderdaad kunnen werken.

Als het puur om een reboot gaat zou iets ala fake hwclock ook nog een oplossing kunnen zijn om in ieder geval een soort van op tijd te beginnen.

Zit ook in Raspbian OS (of hoe dat deze maand ook weer mag heten).

[ninjazx9r98]

Freee!! schreef op maandag 26 september 2022 @ 22:06:
[...]

Dat zou inderdaad kunnen werken.

[...]

Zit ook in Raspbian OS (of hoe dat deze maand ook weer mag heten).

Vergeet nog een andere oplossing, de pihole server of "het ijzer" hoef je natuurlijk niet perse via pihole / unbound te laten lopen. Dan heb je in ieder geval resolving op de pihole zelf als processen niet willen starten. Wat dat betreft mogelijkheden genoeg

[nero355]

Beun schreef op maandag 26 september 2022 @ 20:30:
Edit:
Waarschijnlijk heb ik iets gevonden. Ik zie dat mijn Intel Nuc aangeeft dat het 7 augustus 2022 15:45 is. Zou dit het probleem kunnen veroorzaken?

Edit 2:
Probleem verholpen! De tijd stond verkeerd. Deze heb ik via de Terminal goed gezet en het werkt weer als een zonnetje.

ninjazx9r98 schreef op maandag 26 september 2022 @ 21:26:
Nu nog even een NTP client installeren, blijft die tijd voortaan ook gewoon goed lopen

Als het goed is synced een sub-proces van SystemD de tijd voor je dus check effe of die wel draait

Zie : https://feeding.cloud.gee...ion-with-ntp-and-systemd/

Dus doe effe een

# systemctl status systemd-timesyncd

om te checken wat daar mis is gegaan de volgende keer!

Freee!! schreef op maandag 26 september 2022 @ 21:51:
Werkt niet, die NTP client moet na een reboot eerst een IP-adres verkrijgen (via Pi-Hole en Unbound) voordat die de juiste tijd op kan halen en daarna aan kan geven.

DHCP is veel minder veeleisender of beter gezegd veel vergevender dan DNS als het gaat om de time offset

[Freee!!]

nero355 schreef op dinsdag 27 september 2022 @ 00:29:
[...]
DHCP is veel minder veeleisender of beter gezegd veel vergevender dan DNS als het gaat om de time offset

Weet ik, maar meestal moet de NTP-client eerst het IP-adres van een NTP-server ophalen voordat de juiste tijd opgehaald kan worden en daar refereerde ik aan.

[ninjazx9r98]

nero355 schreef op dinsdag 27 september 2022 @ 00:29:
[...]


[...]

Als het goed is synced een sub-proces van SystemD de tijd voor je dus check effe of die wel draait

Zie : https://feeding.cloud.gee...ion-with-ntp-and-systemd/

Dus doe effe een

# systemctl status systemd-timesyncd

om te checken wat daar mis is gegaan de volgende keer!

code:

systemctl status systemd-timesyncd
● systemd-timesyncd.service
     Loaded: masked (Reason: Unit systemd-timesyncd.service is masked.)
     Active: inactive (dead)

code:

[Time]
#NTP=
#FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048

Staat, iig op Debian Bullseye, kennelijk standaard niet aan. Maakt verder ook niet zoveel uit, NTP is handig en of dat nu geregeld wordt door een service die uit staat aan te zetten of door een andere client te installeren maakt voor het resultaat niet uit.
Moet er ook bij zeggen dat ik deze niet kende maar goed, iets met Rome en meerdere wegen

[Raymond P]

@nero355 Is systemd-timesyncd tegenwoordig default?

Het voordeel van ntpd is dat je 'm als source voor de rest van je netwerk kunt gebruiken door 'm als option mee te geven met dhcp. Wel zo handig als je toch al een dns/dhcp server hebt draaien.

[nero355]

ninjazx9r98 schreef op dinsdag 27 september 2022 @ 08:36:
Staat, iig op Debian Bullseye, kennelijk standaard niet aan.

Ik zal eens kijken wat mijn Debian Testing bakkie zegt de volgende keer dat die aan staat

Onder Kubuntu wordt die in ieder geval wel gebruikt!

Maakt verder ook niet zoveel uit, NTP is handig en of dat nu geregeld wordt door een service die uit staat aan te zetten of door een andere client te installeren maakt voor het resultaat niet uit.
Moet er ook bij zeggen dat ik deze niet kende maar goed, iets met Rome en meerdere wegen

Ik kwam daar ook veel te laat achter en had uit gewoonte al NTPd draaien op mijn RaspBian draaiende Raspberry Pi dus ik kan nu ook niet checken of ik gelijk heb, maar in principe zou het wel zo moeten zijn!

Raymond P schreef op dinsdag 27 september 2022 @ 09:20:
Is systemd-timesyncd tegenwoordig default?

Als het goed is wel!

Het voordeel van ntpd is dat je 'm als source voor de rest van je netwerk kunt gebruiken door 'm als option mee te geven met dhcp. Wel zo handig als je toch al een dns/dhcp server hebt draaien.

Die had ik dus ook uit gewoonte geïnstalleerd, maar echt veeeeel later kwam ik erachter dat SystemD dat gewoon regelt tegenwoordig...


Trouwens er is ook nog het

# ntpdate 

commando om effe snel zelf de tijd te syncen!

Maar als de offset te groot is dan moet je eerst effe knoeien met

# date 

om je bakkie een duwtje in de juiste richting te geven

/Voor de volledigheid

[ninjazx9r98]

nero355 schreef op dinsdag 27 september 2022 @ 14:01:
[...]

Ik kwam daar ook veel te laat achter en had uit gewoonte al NTPd draaien op mijn RaspBian draaiende Raspberry Pi dus ik kan nu ook niet checken of ik gelijk heb, maar in principe zou het wel zo moeten zijn!

Heb hier twee raspberries draaien met pihole, beide zijn echter wel wat langer in de lucht en hebben een upgrade gehad van Buster naar Bullseye.

code:

pi@pihole222:~ $ sudo systemctl status systemd-timesyncd
Unit systemd-timesyncd.service could not be found.
pi@pihole222:~ $ locate systemd-timesyncd
pi@pihole222:~ $

Dan heb ik nog een RPI om wat te spelen met Docker en die is vorige week vers geinstalleerd met Bullseye. Niet wetende dat timesyncd standaard aanwezig was heb ik daar chronyd op gezet.

code:

pi@dockerpi ~ → sudo systemctl status systemd-timesyncd
● systemd-timesyncd.service
     Loaded: masked (Reason: Unit systemd-timesyncd.service is masked.)
     Active: inactive (dead)

pi@dockerpi ~ → sudo systemctl status chronyd
● chrony.service - chrony, an NTP client/server
     Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2022-09-23 20:31:32 CEST; 3 days ago

Kennelijk bij Debian dus iets wat vanaf Bullseye bij een verse installatie standaard aanwezig is. Voor de twee piholes twijfel ik of die ook nog Stretch hebben gedraaid en dus Stretch - Buster - Bullseye hebben gedaan.

[nero355]

ninjazx9r98 schreef op dinsdag 27 september 2022 @ 14:18:
Heb hier twee raspberries draaien met pihole, beide zijn echter wel wat langer in de lucht en hebben een upgrade gehad van Buster naar Bullseye.

code:

pi@pihole222:~ $ sudo systemctl status systemd-timesyncd
Unit systemd-timesyncd.service could not be found.
pi@pihole222:~ $ locate systemd-timesyncd
pi@pihole222:~ $

Dat is wel een beetje raar...

Dan heb ik nog een RPI om wat te spelen met Docker en die is vorige week vers geinstalleerd met Bullseye. Niet wetende dat timesyncd standaard aanwezig was heb ik daar chronyd op gezet.

code:

pi@dockerpi ~ → sudo systemctl status systemd-timesyncd
● systemd-timesyncd.service
     Loaded: masked (Reason: Unit systemd-timesyncd.service is masked.)
     Active: inactive (dead)

pi@dockerpi ~ → sudo systemctl status chronyd
● chrony.service - chrony, an NTP client/server
     Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2022-09-23 20:31:32 CEST; 3 days ago

Zo ziet het er ook bij mij uit geloof ik door NTPd

Kennelijk bij Debian dus iets wat vanaf Bullseye bij een verse installatie standaard aanwezig is. Voor de twee piholes twijfel ik of die ook nog Stretch hebben gedraaid en dus Stretch - Buster - Bullseye hebben gedaan.

Mijn Raspberry Pi draait de één na meest recente versie dus dat zal dan wel Buster zijn en daar is dus systemd-timesyncd gewoon aanwezig, maar die is ook vanaf Stretch geüpgrade!

Bullseye wil ik gaan draaien als een totaal verse installatie vanwege dat /boot partitie gedoe die groter moet worden, maar daar heb ik effe geen zin in voorlopig

[Raymond P]

@nero355 Bij mij gaat ntpd ip mee naar dhcp clients met option ntp-servers en doe ik een broadcast op het subnet.

Als je enkel een client nodig hebt is timesyncd dus een optie, maar juist op een bak met pi-hole zie ik wel de meerwaarde om ntpd te hebben draaien.

edit: ik zie dat dat niet direct beschikbaar is in pi-hole interface. Neem aan dat je dan gewoon de config file van dnsmasq kan uitbreiden in /etc/dnsmasq.d/*.

[ Voor 23% gewijzigd door Raymond P op 27-09-2022 15:48 ]

[nero355]

Raymond P schreef op dinsdag 27 september 2022 @ 15:46:
edit: ik zie dat dat niet direct beschikbaar is in pi-hole interface.
Neem aan dat je dan gewoon de config file van dnsmasq kan uitbreiden in /etc/dnsmasq.d/*.

Uiteraard!

[deHakkelaar]

In een notendop:

pi@ph5b:~ $ lsb_release -d
Description:    Raspbian GNU/Linux 11 (bullseye)

pi@ph5b:~ $ systemctl is-enabled systemd-timesyncd.service
enabled

pi@ph5a:~ $ lsb_release -d
Description:    Raspbian GNU/Linux 10 (buster)

pi@ph5a:~ $ systemctl is-enabled systemd-timesyncd.service
enabled

dehakkelaar@vm:~$ lsb_release -d
Description:    Debian GNU/Linux 9.12 (stretch)

dehakkelaar@vm:~$ systemctl is-enabled systemd-timesyncd.service
enabled

Sommige distro's willen deze nog wel eens vervangen door chrony of ntpd omdat deze naast de client functie ook als NTP server kan functioneren wat bij systemd-timesyncd.service ontbreekt.
Het is ook een apparte package los van systemd:

pi@ph5b:~ $ dpkg -S systemd-timesyncd.service
systemd-timesyncd: /usr/share/man/man8/systemd-timesyncd.service.8.gz
systemd-timesyncd: /lib/systemd/system/systemd-timesyncd.service

Ik geloof dat als je ntpd of chrony installeert, dan masken ze de systemd-timesyncd.service unit als deze ook is geinstalleerd.
Ik weet dit niet 100% zeker maar heb dit masken wel vaker gezien in andere fora mbt ntpd en chrony:

pi@ph5b:~ $ man systemctl
[..]
       mask UNIT...
           Mask one or more units, as specified on the command line. This
           will link these unit files to /dev/null, making it impossible
           to start them. This is a stronger version of disable, since it
           prohibits all kinds of activation of the unit, including
           enablement and manual activation. Use this option with care.
           This honors the --runtime option to only mask temporarily until
           the next reboot of the system. The --now option may be used to
           ensure that the units are also stopped. This command expects
           valid unit names only, it does not accept unit file paths.

Datum/tijd en ofdat NTP "active" is en synced:

pi@ph5b:~ $ timedatectl status
               Local time: Tue 2022-09-27 19:24:19 CEST
           Universal time: Tue 2022-09-27 17:24:19 UTC
                 RTC time: n/a
                Time zone: Europe/Amsterdam (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Details mbt het syncen:

pi@ph5b:~ $ timedatectl timesync-status
       Server: 5.79.75.37 (2.debian.pool.ntp.org)
Poll interval: 34min 8s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 2
    Reference: A18F188D
    Precision: 1us (-23)
Root distance: 33.164ms (max: 5s)
       Offset: +181us
        Delay: 12.502ms
       Jitter: 1.784ms
 Packet count: 663
    Frequency: -17.921ppm

De systemd journals logt ook meldingen:

pi@ph5b:~ $ journalctl --full --no-pager -u systemd-timesyncd.service
[..]
Sep 12 04:58:08 ph5b systemd[1]: Started Network Time Synchronization.
Sep 12 05:12:42 ph5b systemd-timesyncd[201]: Initial synchronization to time server 5.79.75.37:123 (2.debian.pool.ntp.org).

De "fake HW clock" is deze:

pi@ph5b:~ $ systemctl list-units  "*fake*"
  UNIT                 LOAD   ACTIVE SUB    DESCRIPTION
  fake-hwclock.service loaded active exited Restore / save the current clock

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

pi@ph5b:~ $ man fake-hwclock
[..]
BACKGROUND
       Many  embedded  Linux  systems  do  not  have a functional hardware
       clock. Either they simply don't have a hardware  clock  at  all  or
       they have a hardware clock but it is not usable (e.g. because Linux
       doesn't know how to use it or because no battery is present).

       This can lead to time moving backwards to some default value (often
       1970)  when  the system is rebooted. Since lots of software assumes
       that time only moves forward this is a  bad  thing.  NTP  can  (and
       should where practical) be used to sync with an external timeserver
       but it is not available early in the boot process and  may  be  un‐
       available for other reasons.

       The  design expectation of fake-hwclock is that it will be run very
       late at shutdown and very early at boot. This will ensure that fsck
       has  a  vaguely sensible idea of system time at boot and won't com‐
       plain that the last-modified time in the filesystem is  not  hugely
       in  the past or future. Some users may not worry about this too use
       case, in which case it is possible to modify the init  system  con‐
       figuration to move things earlier/later as appropriate.

DESCRIPTION
       fake-hwclock  sets and queries a fake "hardware clock" which stores
       the time in a file. This program may be run by the system  adminis‐
       trator  directly  but is typically run by init (to load the time on
       startup and save it  on  shutdown)  and  cron  (to  save  the  time
       hourly).

       If  no  command is given then fake-hwclock acts as if the save com‐
       mand was used.

EDIT: Ow was deze vergeten:

pi@ph5b:~ $ cat /etc/cron.hourly/fake-hwclock
#!/bin/sh
#
# Simple cron script - save the current clock periodically in case of
# a power failure or other crash

if (command -v fake-hwclock >/dev/null 2>&1) ; then
  fake-hwclock save
fi

En waar @Freee!! naar refereert is de kip of het ei dilemma:
Wikipedia: Kip-en-eiprobleem

De NTP daemon is namelijk afhankelijk van juiste DNS resolutie van de NTP server domeinnamen.
En de DNS daemon is weer afhankelijk van de juiste tijd als DNSSEC wordt gebruikt zoals bv in de officiele Pi-hole Unbound gids.
Boel info hieronder mbt Pi-hole:
https://discourse.pi-hole...pi-hole-not-working/53805

[ninjazx9r98]

deHakkelaar schreef op dinsdag 27 september 2022 @ 19:55:

De NTP daemon is namelijk afhankelijk van juiste DNS resolutie van de NTP server domeinnamen.
En de DNS daemon is weer afhankelijk van de juiste tijd als DNSSEC wordt gebruikt zoals bv in de officiele Pi-hole Unbound gids.
Boel info hieronder mbt Pi-hole:
https://discourse.pi-hole...pi-hole-not-working/53805

Een NTP daemon is afhankelijk van de geconfigureerde NTP servers en niet per definitie van DNS. Als je hostnames gebruikt ben je op 1 of andere manier afhankelijk van resolving maar dat kan net zo goed een hosts file zijn met daarin 1 of meerdere IP die ergens op het internet aanwezig zijn.
Niemand houdt je ook tegen om IP adressen in de NTP configuratie te zetten in plaats van hostnames, been there done that en werkt prima.
Daarnaast zijn er routers die NTP server kunnen spelen en zijn er ook nog apparaatjes die zelf synchroniseren dmv GPS en vervolgens NTP server zijn voor je netwerk.

[deHakkelaar]

@ninjazx9r98 , en waarom vertel je mij dit?
Dit onderwerp is al meerdere keren hier en op Pi-hole Discourse besproken inclusief de oplossingen die jij aandraagt.
En je vergeet er 1tje namelijk een RTC.

[ninjazx9r98]

deHakkelaar schreef op woensdag 28 september 2022 @ 09:08:
@ninjazx9r98 , en waarom vertel je mij dit?
Dit onderwerp is al meerdere keren hier en op Pi-hole Discourse besproken inclusief de oplossingen die jij aandraagt.
En je vergeet er 1tje namelijk een RTC.

Dat staat toch in de quote waarom ik je dit vertel?

De NTP daemon is namelijk afhankelijk van juiste DNS resolutie van de NTP server domeinnamen.

Dat zijn toch jouw woorden en die kloppen niet zoals ze daar staan.

[deHakkelaar]

@ninjazx9r98 , tjemig, ik heb al zoveel info geplaats en dan is het nog niet genoeg.
Met default OOTB Pi-OS op een Raspi (zonder RTC) kan het voorkomen dat de tijd teveel uit sync is en dan krijg je het kip ei dilemma.
Lees dat linked draadje maar en zo heb ik meerder problemen voorbij zien komen met Raspi's en tijd syncen.
Ik heb het dus over OOTB!!!

[deHakkelaar]

ninjazx9r98 schreef op woensdag 28 september 2022 @ 09:11:
Dat zijn toch jouw woorden en die kloppen niet zoals ze daar staan.

Hier zijn de default geconfigureerde NTP server pools (allemaal namen):

pi@ph5b:~ $ cat /etc/systemd/timesyncd.conf
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See timesyncd.conf(5) for details.

[Time]
#NTP=
#FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048

En voor DNSSEC validatie is het nodig dat het tijdsverschil tussen server en client ik geloof niet hoger mag zijn als 1000 seconde ofzoiets.
EDIT: ow dat laatste is niet helemaal correct.
Zelfs al kan een NTP server worden benadert om te syncen, doet deze dat niet als het verschill groter is als 1000 seconde schijnt:
https://discourse.pi-hole...-working-isnt-now/53437/9

Dus en DNSEC validatie mislukt en NTP wil niet syncen als delta T > 1000 seconde.

[ Voor 13% gewijzigd door deHakkelaar op 28-09-2022 09:48 ]

[ninjazx9r98]

deHakkelaar schreef op woensdag 28 september 2022 @ 09:18:
@ninjazx9r98 , tjemig, ik heb al zoveel info geplaats en dan is het nog niet genoeg.
Met default OOTB Pi-OS op een Raspi (zonder RTC) kan het voorkomen dat de tijd teveel uit sync is en dan krijg je het kip ei dilemma.
Lees dat linked draadje maar en zo heb ik meerder problemen voorbij zien komen met Raspi's en tijd syncen.
Ik heb het dus over OOTB!!!

Ik ga helemaal niks lezen, nergens voor nodig ik weet prima hoe het zit.
Misschien zelf eens terug lezen hoe deze discussie begonnnen is en eens wat minder uit de hoogte doen? Een fijne manier van reageren/discusseren is dit in ieder geval niet en dat is niet de eerste keer dat je dit doet.
Het begon met een tijdverschil op een NUC, geen OOTB PI-OS of wat dan ook maar een NUC.
https://gathering.tweakers.net/forum/view_message/72918922
Daar heb ik op gereageerd kijk eens naar een NTP client en dat is ineens richting RPI en Raspbian/PI-OS gegaan inclusief kip en ei wat niet bestaat of hoeft te bestaan afhankelijk van je configuratie.

Vervolgens kom jij binnen met een berg aan info op een manier/toon die mij triggert om op een stukje daarvan te reageren omdat je ondanks die berg info niet genuanceerd/duidelijk genoeg bent.

Zo ook nu weer met je screenshot van timesyncd om mij te bewijzen dat daar namen van pool servers staan. Dat hoef je mij niet te bewijzen, ik weet dat die daar staan (mits timesyncd aanwezig is), weet dat je ze aan kunt passen (ook naar IP adressen) maar weet ook dat er OOTB geen garantie is dat timesyncd aanwezig is afhankelijk van wanneer je OOTB moment was en mogelijk ook nog distributie afhankelijk. Sterker nog, ik heb gisteren hier nog laten zien dat timesyncd er helemaal niet hoeft te zijn.

code:

pi@pihole222:~ $ cat /etc/systemd/timesyncd.conf
cat: /etc/systemd/timesyncd.conf: No such file or directory

code:

pi@pihole233:~ $ cat /etc/systemd/timesyncd.conf
cat: /etc/systemd/timesyncd.conf: No such file or directory

[deHakkelaar]

ninjazx9r98 schreef op woensdag 28 september 2022 @ 09:49:
Misschien zelf eens terug lezen hoe deze discussie begonnnen is en eens wat minder uit de hoogte doen?

Dat was precies waarom ik een beetje prikkelbaar reageerde.
En als je niet wilt lezen is mij ook prima.

[Stimulate14]

Is er ergens een truc om je wachtwoord te achterhalen? Gaat om de ssh login, niet de webinterface.

[nero355]

Stimulate14 schreef op woensdag 28 september 2022 @ 10:56:
Is er ergens een truc om je wachtwoord te achterhalen?

Voor zover ik weet niet, maar ik heb me daar dan ook nooit mee bezig gehouden

Gaat om de ssh login, niet de webinterface.

Raspberry Pi of een Intel NUC of VM of zo ??

Indien één van de laatste twee : Single User Mode booten en dan je wachtwoord aanpassen!

Ik heb namelijk het idee dat door het ontbreken van GRUB2 je dat niet kan doen i.c.m. RaspBian/Raspberry Pi OS maar misschien zit ik ernaast...

[deHakkelaar]

Stimulate14 schreef op woensdag 28 september 2022 @ 10:56:
Is er ergens een truc om je wachtwoord te achterhalen? Gaat om de ssh login, niet de webinterface.

Het probleem is dat het werkelijk wachtwoord niet wordt opgeslagen.
In plaats daarvan wordt er een hash opgeslagen die is afgeleid van je opgevoerde wachtwoord.
Voor de meeste Linux distro's staat deze voor alle gebruikers opgeslagen in onderstaande bestandje:

pi@ph5b:~ $ sudo cat /etc/shadow
root:<PASSWORD_HASH>:0:99999:7:::
[..]
www-data:*:18930:0:99999:7:::
[..]
pi:<PASSWORD_HASH>:19090:0:99999:7:::
[..]
pihole:!:18944::::::
[..]
dehakkelaar:<PASSWORD_HASH>:19090:0:99999:7:::
[..]

Bovenstaande <PASSWORD_HASH> wordt dan gegenereerd met zoiets als:

pi@ph5b:~ $ echo -n "wachtwoord" | openssl passwd -6 -stdin
$6$LklkGtO.g6avFQm2$hbisPjAHeAEscxZUqqjy0BlGAInFzWkLj/bXYz3DO.L9BAZLOPEwAtIPRW05g7epyr07krS0Tf/jJEJEE9FJ61

En tegenwoordig zelfs als een dubbele hash om rainbow attacks te vermoeilijken:

pi@ph5b:~ $ echo -n "wachtwoord" | openssl passwd -6 -stdin | openssl passwd -6 -stdin
$6$62QTN1TYCAihSLcg$25m9ne5qxb.Hbho7veQGc.kQdy1tm1oZQdC8nu1Jo3b6wZ4bPVsuEPrDJLcUom.iM6QmJciTIvlT.Hq0S6iJz/

Het echte wachtwoord welke je hebt ingevoerd valt dan dus niet meer te achterhalen.

EDIT: Ow en vaak worden die hashes ook nog salted:

pi@ph5b:~ $ openssl passwd --help
[..]
 -salt val           Use provided salt

Meer info daarover hieronder:
https://www.omnicybersecu...ash-mean-is-it-effective/

[ Voor 20% gewijzigd door deHakkelaar op 28-09-2022 19:57 . Reden: openssl ipv sha256 ]

[Raymond P]

Als je bij die file kan dan kan je ook chrooten lijkt mij?

Edit: Niet dat je dan je oude wachtwoord kunt zien. Maareh, ik weet die van mijn thuisserver ook niet.

[ Voor 48% gewijzigd door Raymond P op 28-09-2022 20:16 ]

[deHakkelaar]

nero355 schreef op woensdag 28 september 2022 @ 14:34:
Ik heb namelijk het idee dat door het ontbreken van GRUB2 je dat niet kan doen i.c.m. RaspBian/Raspberry Pi OS maar misschien zit ik ernaast...

Ik vroeg me af wat onderstaande thd proces was (helemaal onderaan):

pi@ph5b:~ $ pstree
systemd─┬─2*[agetty]
        ├─cron
        ├─dbus-daemon
        ├─dhcpcd
        ├─lighttpd───php-cgi───4*[php-cgi]
        ├─master─┬─pickup
        │        └─qmgr
        ├─monit─┬─cputemp.sh
        │       └─{monit}
        ├─pihole-FTL───18*[{pihole-FTL}]
        ├─rngd───3*[{rngd}]
        ├─rsyslogd───3*[{rsyslogd}]
        ├─smartd
        ├─sshd─┬─sshd───sshd───bash
        │      └─sshd───sshd───bash───pstree
        ├─2*[systemd───(sd-pam)]
        ├─systemd-journal
        ├─systemd-logind
        ├─systemd-timesyn───{systemd-timesyn}
        ├─systemd-udevd
        ├─thd
        └─unbound

pi@ph5b:~ $ man thd
[..]
DESCRIPTION
       Triggerhappy is a hotkey daemon that operates on a system wide
       scale. It watches all configured input devices for key, switch or
       button events and can launch arbitrary commands specified by the
       administrator. In contrast to hotkey services provided by desktop
       environments, Triggerhappy is especially suited to hardware related
       switches like volume or wifi control; it works independently from a
       specific user being logged in and is also suitable for embedded
       systems that do not a graphical user interface.

Blijkt dat deze wordt gebruikt om het keyboard te scannen tijdens booten ofdat je de SHIFT toets ingedrukt houdt voor "recovery mode".
Snelle DuckDuck:
https://forums.raspberrypi.com/viewtopic.php?t=86578

[deHakkelaar]

Raymond P schreef op woensdag 28 september 2022 @ 20:15:
Als je bij die file kan dan kan je ook chrooten lijkt mij?

Yep, dat kan ook idd met het passwd commando:

pi@ph5b:~ $ man passwd
[..]
       -R, --root CHROOT_DIR
           Apply changes in the CHROOT_DIR directory and use the
           configuration files from the CHROOT_DIR directory.

[Raymond P]

Ah, dat wist ik niet.

[ninjazx9r98]

nero355 schreef op woensdag 28 september 2022 @ 14:34:
[...]

Raspberry Pi of een Intel NUC of VM of zo ??

Indien één van de laatste twee : Single User Mode booten en dan je wachtwoord aanpassen!

Ik heb namelijk het idee dat door het ontbreken van GRUB2 je dat niet kan doen i.c.m. RaspBian/Raspberry Pi OS maar misschien zit ik ernaast...

Zou wel mogelijk moeten zijn maar is alweer een flinke tijd geleden dat ik dat een keer gedaan heb.
SD kaartje/USB stick of wat dan ook uit/van de RPI halen en aan een ander systeem "knopen"
Bestand cmline.txt editten en "init=/bin/sh" toevoegen aan de regel die daarin staat (zonder de quotes uiteraard)
SD kaartje of wat dan ook terug aan/in de RPI en dan

code:

mount -o remount, rw /
password <gebruikernaam bijv pi>
sync

Kaartje of wat dan ook weer aan het andere systeem, cmdline.txt weer aanpassen naar hoe het oorspronkelijk was en daarna kun je weer booten en het nieuwe wachtwoord gebruiken.

Andere optie als er een ander Linux systeem beschikbaar is is om de root partitie daar te mounten, editten van /etc/shadow en daar de hash van het voormalige default password in plakken dat overal en nergens op internet te vinden is of er zelf eentje generen en die erin plakken.
Voormalig default omdat de huidige versies van "Raspberry Pi OS" geen default password meer hebben, deze moet je kiezen bij de eerste boot en indien je headless boot kun je dit regelen ala ssh enablen door middel van een userconf of userconf.txt bestand met specifieke inhoud.

Komt een beetje neer op dat wat je zou kunnen doen op een regulier systeem met single user mode maar is iets bewerkelijker.

[deHakkelaar]

ninjazx9r98 schreef op woensdag 28 september 2022 @ 21:08:
Andere optie als er een ander Linux systeem beschikbaar is is om de root partitie daar te mounten, editten van /etc/shadow en daar de hash van het voormalige default password in plakken dat overal en nergens op internet te vinden is of er zelf eentje generen en die erin plakken.

Zo te zien kun je daarvoor mkpasswd gebruiken voor gemak:

pi@ph5b:~ $ man mkpasswd
[..]
NAME
       mkpasswd - Overfeatured front end to crypt(3)

SYNOPSIS
       mkpasswd PASSWORD [SALT]

DESCRIPTION
       mkpasswd  encrypts  the given password with the crypt(3) libc func‐
       tion, using the given salt.

OPTIONS
       -S, --salt=STRING
              Use the STRING as salt. If it begins with $ then it will  be
              passed straight to crypt(3) without any checks.

       -R, --rounds=NUMBER
              Use  NUMBER  rounds.  This argument is ignored if the method
              chosen does not support variable  rounds.  For  the  OpenBSD
              Blowfish  method  this  is  the  logarithm  of the number of
              rounds.  The behavior is undefined if this  option  is  used
              without --method.

       -m, --method=TYPE
              Compute the password using the TYPE method.  If TYPE is help
              then the list of available methods is printed.  If TYPE  be‐
              gins  and end with $ characters then the string is passed to
              crypt_gensalt(3) as-is.

       -5     Like --method=md5crypt.

       -P NUM, --password-fd=NUM
              Read the password from file descriptor NUM instead of  using
              getpass(3).   If  the  file descriptor is not connected to a
              tty then no other text than the hashed password  is  printed
              on stdout.

       -s, --stdin
              Like --password-fd=0.

pi@ph5b:~ $ mkpasswd "wachtwoord"
$y$j9T$oGKy4bwJVVF2gk1lODb/E0$pqXnndia4CiHzhEWu8kFdKDnXVuV0Jc5MLvtJhwOZnC

pi@ph5b:~ $ dpkg -S /usr/bin/mkpasswd
whois: /usr/bin/mkpasswd

EDIT: Ow en voor meer:

pi@ph5b:~ $ mkpasswd -m help
Available methods:
yescrypt        Yescrypt
gost-yescrypt   GOST Yescrypt
scrypt          scrypt
bcrypt          bcrypt
bcrypt-a        bcrypt (obsolete $2a$ version)
sha512crypt     SHA-512
sha256crypt     SHA-256
sunmd5          SunMD5
md5crypt        MD5
bsdicrypt       BSDI extended DES-based crypt(3)
descrypt        standard 56 bit DES-based crypt(3)
nt              NT-Hash

[ Voor 9% gewijzigd door deHakkelaar op 28-09-2022 22:18 ]