Pi-Hole - mainosblokkeri raspberry pi:stä

Tämä kiinnostaa! Kun saat jotain tuloksia miten liikenne jakautuu primaryn ja secondaryn kesken, niin laita jakoon.

Tämä kiinnostaa itseänikin myös. Nyt on pyörinyt uusi secondary pihole noin 24 tuntia. Tässä ajassa Primary pihole on kerännyt total queries 39300 hittiä ja secondary samassa ajassa 2700.
Tämä oli itselleni yllätys. Olin kuvetellut, että secondaryä käytetään vain silloin jos Primary on poissa pelistä. Aikaisemmin olin määritellyt reitittimen asetuksista Primary DNS palvelimeksi piholen ja secondary DNS:ksi cloudflare 1.1.1.1. Aikaisemmin osa liikenteestä on tämän testin mukaan mennyt suoraan secondary serverille ohi piholen. Nyt reitittimessä ei ole asetettu ollenkaan ulkoista DNS palvelua. Vain kaksi pihole serveriä.

Joku joka tietää DNS toiminnasta enemmän voisi selittää miten primary ja secondary eroaa. koska käytetään secondaryä?
 
Se itseasiassa hieman vaihtelee käyttöjärjestelmästä ja versiosta toiseen. Syitä siihen voi olla monia, jos esim. Primary dns vastaa kerran-pari hitaasti, se voi aiheuttaa sen että käyttöjärjestelmä ohjaa seuraavat requestit secondary dns:lle joksikin aikaa.

E: Esim. MacOS versiot ennen 10.6 tai 10.7 taisivat ohjata requestit annetussa järjestyksessä, ja vasta primaryn mennessä täysin hiljaiseksi ohjasivat seuraavaan. Nykysin se vaihtelee sen mukaan, mistä käyttöjärjestelmä kulloinkin arpoo vastauksen saavansa nopeiten, ensisijaisesti kuitenkin ensimmäsienä määritettyyn.
 
Mä veikkaan että(jos itse olisin käyttöjärjestelmän tekijä), niin kysyisin kaikilta tiedossa olevilta dns-palvelimilta säännöllisesti (ylläpitäisin yksinkertaista nopeus-tilastoa) ja myös sen lisäksi silloin kun kyselyyn kulunut aika kasvaa jonkun trigger-arvon verran. Mutta siis veikkaan vaan:vihellys:
Täydellisessä maailma kyllä näin, mutta ihmisillä on tapana luottaa siihen että kaikki requestit menevät primarylle joten sitä täytyy suosia vaikka se hieman hitaampi olisikin joskus. Muutenhan noita tosiaan kannattaisi ohjata aina sinne missä on vähiten kuormaa.
 
  • Tykkää
Reactions: 111
Siis olette säätäneet käyttöjärjestelmästä suoraan nuo dns-palvelimet? Onko kellään reitittimeen asetettuna kahta piholea dns-servuiksi? Tai no osa niistäkin toimii eri tavalla ja osa jakaa kuormaa ja osa ei.
e: Olihan tuolla ylempänä kerrottu, että reitittimeen asetettu primary ja secondary dns:t.
 
Viimeksi muokattu:
Siis olette säätäneet käyttöjärjestelmästä suoraan nuo dns-palvelimet? Onko kellään reitittimeen asetettuna kahta piholea dns-servuiksi? Tai no osa niistäkin toimii eri tavalla ja osa jakaa kuormaa ja osa ei.
Hyvä tarkennus. Käyttöjärjestelmällä tarkoitin tässä tapauksessa mitä tahansa käyttöjärjestelmää siinä laitteessa joka sen viime kädessä päättää mihin requestit lähteee, oli se sitten Windows tai reitittimen OS. MacOS oli vain esimerkkinä, samalla tavalla noissa on kaikissa jopa eri versioiden välillä vaihtelua.

Tämä siis kokemuspohjaisesti, viisaammat korjatkoot.
 
Pihole pyörii tällä hetkellä ubuntu koneessa, joka ajaa kotiteatterin virkaa. Toisinaan pihole vetää jostain syystä itsensä hirteen kaataen koko verkon (näkyy tosin aktiivisena).

Onko tähän jotain fixiä jota kannattaisi kokeilla ettei muija kävisi uudestaan päälle aiheutuneesta harmista?

E: reitittimestä on dhcp palvelin pois päältä.
 
Itsekin tuli Pihole asenneltua Ubuntu Serveriin. Saa nähdä, pärjääkö pelkästään tällä vai pitääkö pykätä secondary DNS myös. Sen voisikin sitten tehdä raspilla.
 
Pihole pyörii tällä hetkellä ubuntu koneessa, joka ajaa kotiteatterin virkaa. Toisinaan pihole vetää jostain syystä itsensä hirteen kaataen koko verkon (näkyy tosin aktiivisena).

Onko tähän jotain fixiä jota kannattaisi kokeilla ettei muija kävisi uudestaan päälle aiheutuneesta harmista?

E: reitittimestä on dhcp palvelin pois päältä.

Itse en ole kertaakaan törmännyt Pihole jumiin. Pyörinyt jo varmaan kohta pari vuotta Raspissa ilman mitään ongelmia. DHCP:tä en käytä piholesta vaan tuon hoitaa Unifi USG. Nyt tosiaan pyörii rinnalla toinen secondary DNS:nä ja juuri kun katsoin niin viimeisen 24h aikana tullut 5500 hakua. Aika paljon mielestäni menee ohi primary dns:n. Kuten yllä oli puhetta niin eri OS:t käyttää ilmeisesti erilailla DNS kyselyitä.
 
Mitenkäs tuon Piholen DNS Conditional forwardingin saisi toimimaan TP-Linkin routteria (Archer C5 1200) käyttäessä, kun tuossa TP-linkissä ei ole mahdollista määritellä local domainia mihinkään?

DHCP-palvelimena on tuo TP-Link.

Jostain syystä Piholen statseissa Philipsin Hue Gateway, Sony Xperia ja työantajan läppäri eivät listaudukaan saamiensa IP-osoitteiden perusteella, vaan näiden kaikki DNS-pyynnöt listautuvat xx.xx.xx.xx.elisa-laajakaista.fi -osoitteen alle.
 
Mitenkäs tuon Piholen DNS Conditional forwardingin saisi toimimaan TP-Linkin routteria (Archer C5 1200) käyttäessä, kun tuossa TP-linkissä ei ole mahdollista määritellä local domainia mihinkään?

DHCP-palvelimena on tuo TP-Link.

Jostain syystä Piholen statseissa Philipsin Hue Gateway, Sony Xperia ja työantajan läppäri eivät listaudukaan saamiensa IP-osoitteiden perusteella, vaan näiden kaikki DNS-pyynnöt listautuvat xx.xx.xx.xx.elisa-laajakaista.fi -osoitteen alle.
Tarkistappa tuon TP-Linkin asetukset vielä pariin kertaan ajatuksen kanssa. Ei tuo ole normaalia, että sisäverkon laitteiden dns-kyselyt näkyvät ulkoverkon osoitteen alla.
 
Tarkistappa tuon TP-Linkin asetukset vielä pariin kertaan ajatuksen kanssa. Ei tuo ole normaalia, että sisäverkon laitteiden dns-kyselyt näkyvät ulkoverkon osoitteen alla.
Tuo ihmetyttää itseänikin, koska nuo kaikki laitteet näkyvät TP-Linkin DHCP-listalla, IP-osoite ja hostname

EDIT: Enpä kyllä keksi tuolta mitään säätämisen arvoista/mitään mikä voisi olla pielessä.

EDIT2: Katsoppas, nyt sattui vasta silmiin että onhan tuossa DHCP-asetuksissa mahdollisuus määritellä sisäverkon domain. Kokeillaanpa

EDIT3:No nyt pelaa kun määritteli default domainin TP-Linkin asetuksiin. Siinä vaan kun lukee että optional, niin olen aiemmin antanut olla tyhjänä
 
Viimeksi muokattu:
Tuo ihmetyttää itseänikin, koska nuo kaikki laitteet näkyvät TP-Linkin DHCP-listalla, IP-osoite ja hostname

EDIT: Enpä kyllä keksi tuolta mitään säätämisen arvoista/mitään mikä voisi olla pielessä.

EDIT2: Katsoppas, nyt sattui vasta silmiin että onhan tuossa DHCP-asetuksissa mahdollisuus määritellä sisäverkon domain. Kokeillaanpa

EDIT3:No nyt pelaa kun määritteli default domainin TP-Linkin asetuksiin. Siinä vaan kun lukee että optional, niin olen aiemmin antanut olla tyhjänä
Jaa. Ei näköjään ollutkaan mitenkään haitallista/haittaavaa.
 
Piti ottaa tuo conditional forwarding toistaiseksi pois päältä, kun jostain syystä se lisäsi 2-3 sekuntia viivettä (selaimen tilarivillä lukee resolving host) sellaisiin sivuihin, joiden osoitetta ei cachesta löydy.

Onko joku käyttänyt tuota conditional forwardingia?
 
Ainakin Orange Pi Zeron kautta kierrätettynä verkkoliikenne menee solmuun jos yrittää käyttää VPN:ää.

Tähän olettamukseen on tultu Vpn.ac-palvelun kohdalla. Jostain kumman syystä yhteys korjautuu pi-holen hetkellisellä poiskytkennällä, mutta logeista ei tuolle käytökselle löydä syytä kun ongelma on satunnainen

Lähetetty minun Z2 Plus laitteesta Tapatalkilla
 
Asus RT-AC68U hoitaa DHCP:n ja DNS Primary ja Secondary osoittaa tätä Piholea. Hyvin on toiminut, mutta nyt teidän kokeilujen jälkeen laitoin DNS Secondaryn osoittamaan NAS:in Piholea, kun ehtinyt sitä vielä purkaa. Katsotaan miten minulla jakaantuu Primaryn ja Secondaryn välillä...

AC68U vuotaa sitten jotkut DNS pyynnöt Pi-holen ohi, esim Chromecastistä ja Nintendon konsoleista joissa on koodattu DNS osoitteet firmikseen suoraan. Myös jotkut Googlen Android apit menevät suoraan Pi-holen ohi.

Näillä iptables komennoilla saa ohjattua kaikki DNS pyynnöt Pi-holeen (vaihda IP):
Koodi:
iptables -t nat -A PREROUTING -i br0 -p udp ! --source 192.168.1.10 ! --destination 192.168.1.10 --dport 53 -j DNAT --to 192.168.1.10
iptables -t nat -A PREROUTING -i br0 -p tcp ! --source 192.168.1.10 ! --destination 192.168.1.10 --dport 53 -j DNAT --to 192.168.1.10
iptables-save
 
Jep. Merlin itsellä käytössä ja vaatii nuo rimpsut.

En tiedä miten noita voisi muuttaa kahta Pi-holea varten, mutta yhdellä toimi loistavasti ja alkoi Pi-holen lokeihin tulemaan DNS pyyntöjä jotka reititin päästi ennen läpi.
 
Ajaako nämä rimpsut Asuksessa määritettyjen Primary ja Secondary DNS määrityksen yli? Ja kun rimpsuissa on Primary Pi-hole IP, niin Secondarylle ei mene sitten mitään?
Kuten kirjoittelin niin secondary ei tosiaan näillä toimi, tai toimii mutta sitten kaikki secondaryn DNS ohjaukset menee takaisin primääriin, eli ei järkeä pitää kahta noilla ohjauksilla. Omat iptables taidot ei riitä kahteen eri osoitteeseen ohjaus kaikkine ehtoineen.

Nuo rimpsut toimii kun WAN DNS1 kohdassa on yksi Pi-hole. Jos joku iptables velho haluaa noita rimpsuja parantaa niin kuulolla ollaan.
 
Ajaako nämä rimpsut Asuksessa määritettyjen Primary ja Secondary DNS määrityksen yli? Ja kun rimpsuissa on Primary Pi-hole IP, niin Secondarylle ei mene sitten mitään?

Ajaa. iptables NAT jutut pyörii reitityksessä ja DHCP on local palvelu.

Jos teillä on kaksi pi-holea niin sitten secondary ei saa mitään.
Jos tekee kaksi iptables rimpsua joista yksi ohjaa .10 ja toinen ohjaa .11 niin kun se DNS paketti tulee niin se menee siihen ensimmäiseen .10 osoitteeseen kun se on ensimmäisenä siinä listassa.

En ole iptables velho ja en kyllä nyt yhtäkkiä keksi miten tämän saisi toimimaan kahdella pi-holella..
Mutta...--source (ja myös --destination) voi olla network name, host name, pelkkä IP osoite tai IP osoite alue.
Eli --source tai --destination ei ole ongelma.
Ongelma on se DNAT --to x.x.x.x. Se voi olla vain yksi IP.

Pi-Hole tarvitsee kyllä kipeästi sen "sisäänrakennetun" high-availability ratkaisun. Mutta mitä DNATtiin tulee niin eipä se HA ratkaisu siihen auta.
Tähän nyt tarvittaisiin jokin load balancing kikkare väliin? Eli DNAT ohjaa paketin load balancing IP:hen joka sitten ohjaa jollain logiikalla PH1:lle tai PH2:lle?

Edit: Tosin mainitaan -m statistic --mode nth --every x. Googleen vaikka iptables round robin. Pitäkää hauskaa. Minulla ei ole laitteistoa millä tätä testata mutta mitä nyt teoriassa tätä pyörittelen päässäni niin kaksi rimpsua eri --to osoitteella voisi toimia jos käyttää tuota statistic countteria laskemaan paketteja ja ohjamaan paketteja? Eikä tarvitse edes määrittää IP osoite aluetta noihin source/destination kun voi käyttää luonnostaan useampaa rimpsua.
Paitsi että pitää jos haluaa että round robin toimii mahdollisimman hyvin? Jos nuo alla olevat rimpsut käytössä ja oikeasti toimivat niin jos laite lähettää dns kyselyn .11 niin se menee aina sinne.
Jos määrittää .10-.11 alueen niin ihan sama kumpaa osoitetta laite sattuu käyttämään? Se menee aina entten tentten joko .10 tai .11 riippuen menikö edellinen .10 vai .11.

statistic
This module matches packets based on some statistic condition. It supports two distinct modes settable with the --mode option.
Supported options:

--mode mode
Set the matching mode of the matching rule, supported modes are random and nth.
[!] --probability p
Set the probability for a packet to be randomly matched. It only works with the random mode. p must be within 0.0 and 1.0. The supported granularity is in 1/2147483648th increments.
[!] --every n
Match one packet every nth packet. It works only with the nth mode (see also the --packet option).
--packet p
Set the initial counter value (0 <= p <= n-1, default 0) for the nth mode.
Man page of iptables-extensions

Eli voisiko tämä esimerkiksi toimia?

Koodi:
iptables -t nat -A PREROUTING -i br0 -p udp ! --source 192.168.1.10 ! --destination 192.168.1.10 --dport 53 -m statistic --mode nth --every 2 --packet 0 -j DNAT --to 192.168.1.10
iptables -t nat -A PREROUTING -i br0 -p udp ! --source 192.168.1.11 ! --destination 192.168.1.11 --dport 53 -j DNAT --to 192.168.1.11
iptables -t nat -A PREROUTING -i br0 -p tcp ! --source 192.168.1.10 ! --destination 192.168.1.10 --dport 53 -m statistic --mode nth --every 2 --packet 0 -j DNAT --to 192.168.1.10
iptables -t nat -A PREROUTING -i br0 -p tcp ! --source 192.168.1.11 ! --destination 192.168.1.11 --dport 53 -j DNAT --to 192.168.1.11

Logiikka tässä että ensimmäiset kaksi on udp ja toiset kaksi on tcp.
Ensimmäinen rimpsu menee "entten tentten..", käsittelee siis joka toisen paketin ja toinen rimpsu käsittelee jokaisen paketin eli ne mitkä jää ensimmäiseltä yli (joka toinen).

Tämä on sitten ihan hakuammuntaa, vedin tuon rimpsun kasaan tämän perusteella
round robin to three ports on the same host with iptables
Tuossa esimerkissä -m statistic moduulia käytetään ohjaamaan paketit menossa tcp 9000 joko tcp 9001, 9002 tai 9003.

I
 
Viimeksi muokattu:

Rimpsut meni reitittimeen tuollaisenaan sisään ainakin ilman virheitä, testailen.

Edit: Alkoi tulemaan Unknown tuloksia lokiin reitittimestä ja kyselyiden määrät nousi melko rajusti, jokin ei ihan tykkää.

Capture.PNG

Capture2.PNG
 
Viimeksi muokattu:
Rimpsut meni reitittimeen tuollaisenaan sisään ainakin ilman virheitä, testailen.

Muokkailinkin tuota viestiä, sanoin ensin että --source tai --destination ei tarvitsisi IP osoite aluetta mutta jos laite sattuu käyttämään .11 niin se DNS kysely menee aina sinne.
En tiedä minkälaisella hyötysuhteella se round robin toimii noilla ylläolevilla säädöillä. Suurinosahan DNS kyselyistä menee aina primary osoitteeseen joten alla oleva säätäminen saattaa olla turhaa.

Mutta mainitaan nyt kuitenkin.

iprange
This matches on a given arbitrary range of IP addresses.
[!] --src-range from[-to]
Match source IP in the specified range.
[!] --dst-range from[-to]
Match destination IP in the specified range.
Man page of iptables-extensions

Ja näiden --src/dst-range kaveriksi tarvitaan vielä --match iprange kikkare.. Tarvitaanko se myös ! --dst-range eteen? En tiedä. Ehkä? Laitetaan varmuuden vuoksi

Koodi:
iptables -t nat -A PREROUTING -i br0 -p udp --match iprange ! --src-range 192.168.1.10-192.168.1.11 --match iprange ! --dst-range 192.168.1.10-192.168.1.11 --dport 53 -m statistic --mode nth --every 2 --packet 0 -j DNAT --to 192.168.1.10
iptables -t nat -A PREROUTING -i br0 -p udp --match iprange ! --src-range 192.168.1.10-192.168.1.11 --match iprange ! --dst-range 192.168.1.10-192.168.1.11 --dport 53 -j DNAT --to 192.168.1.11
iptables -t nat -A PREROUTING -i br0 -p tcp --match iprange ! --src-range 192.168.1.10-192.168.1.11 --match iprange ! --dst-range 192.168.1.10-192.168.1.11 --dport 53 -m statistic --mode nth --every 2 --packet 0 -j DNAT --to 192.168.1.10
iptables -t nat -A PREROUTING -i br0 -p tcp --match iprange ! --src-range 192.168.1.10-192.168.1.11 --match iprange ! --dst-range 192.168.1.10-192.168.1.11 --dport 53 -j DNAT --to 192.168.1.11

Hyhhyh, menee aina vain sekavamman näköiseksi..
 
Tosiaan kun tästä kaatuilusta ollut kokemuksia ittellä, niin asiaan voi suuresti vaikuttaa se että Pi3 on Wifi yhteydellä reitittimessä. Sehän saattaakin olla esim wlan ajurit mitkä kyykkää tms kun datapakettia tulee ahkeraan.
Muuten lämpö vaikuttaa Wlan yhteyden vakautueen joten jos se P3 on esim. suht umpinaisessa muovikotelossa niin että myös se Wlan pääsee lämpenemään (vaikka välillisesti) se voi aiheuttaa Wlan yhteyden epävakautta/siirtovirheitä.
 
Viimeksi muokattu:
Tälläinen typerä kysymys tässä pyörii mielessä ennen kuin vaihdan tuon minun retropien tähän pieholeen: Häiritseekö/monimutkaistaako tämä omaa teamspeak3 serverin pitämistä? Tällä hetkellä oma ts3 servu pyörii siis omalla koneella tuon no-ip:n tarjoaman dns palvelun kautta.
 
Onko mitään eroa sillä että primary ja secondary osoittaa samaan osoitteeseen versus, että käyttää vain primarya ja secondary yms. tyhjiä?
 
Onko mitään eroa sillä että primary ja secondary osoittaa samaan osoitteeseen versus, että käyttää vain primarya ja secondary yms. tyhjiä?

Ei ole mitään merkitystä eikä edes hyötyä olla kahta DNS:sää joka ohjaa samaan paikkaan... Kun DNS nurin on niin nurin se on. Mutta kotikäytössä riittää yksi kylläkin - harvoin se nyt rikki menee ja yhteys katkeaa siihen. Ja korjaaja on heti paikalla.
 
Ei ole mitään merkitystä eikä edes hyötyä olla kahta DNS:sää joka ohjaa samaan paikkaan... Kun DNS nurin on niin nurin se on. Mutta kotikäytössä riittää yksi kylläkin - harvoin se nyt rikki menee ja yhteys katkeaa siihen. Ja korjaaja on heti paikalla.
Mutta, jos se raspberrypi sattuisi jostain syystä kuolemaan niin yksikään url ei toimisi mikäli reitittimestä tai kaikista koneista on se raspi asetettuna ainoaksi dns-resolvaajaksi. Ei tuo kyllä ole mikään kovin suurella todennäköisyydellä tapahtuva asia, mutta varmennus on aina hyvästä. Nopeana korjauksena voi muuttaa reitittimen asetuksista dns:n vaikka 1.1.1.1 tai 8.8.8.8, vaikka etänä ja laittaa sen piholen kuntoon sen jälkeen. Tosiaan muistikortit on raspberrypi:n heikoin lenkki. Muuten sen pitäisi kestää käyttöä hyvin.

Joku kertoi tässä threadissä käyttävänsä piholea wlanin yli eli siis raspi on yhdistettynä tukiasemaan wlanin kanssa. Se ei todellakaan ole suositeltavaa. Enkä itse ainakaan haluaisi ylimääräistä 5-30ms viivettä jokaiseen dns-kyselyyni. Ja kuten kyseinen käyttäjä kertoi niin myös yhteys on epävakaa.
e: En ymmärrä lukemaani.
 
Viimeksi muokattu:
Mutta, jos se raspberrypi sattuisi jostain syystä kuolemaan niin yksikään url ei toimisi mikäli reitittimestä tai kaikista koneista on se raspi asetettuna ainoaksi dns-resolvaajaksi. Ei tuo kyllä ole mikään kovin suurella todennäköisyydellä tapahtuva asia, mutta varmennus on aina hyvästä. Nopeana korjauksena voi muuttaa reitittimen asetuksista dns:n vaikka 1.1.1.1 tai 8.8.8.8, vaikka etänä ja laittaa sen piholen kuntoon sen jälkeen. Tosiaan muistikortit on raspberrypi:n heikoin lenkki. Muuten sen pitäisi kestää käyttöä hyvin.

Joku kertoi tässä threadissä käyttävänsä piholea wlanin yli eli siis raspi on yhdistettynä tukiasemaan wlanin kanssa. Se ei todellakaan ole suositeltavaa. Enkä itse ainakaan haluaisi ylimääräistä 5-30ms viivettä jokaiseen dns-kyselyyni. Ja kuten kyseinen käyttäjä kertoi niin myös yhteys on epävakaa.

Sitten kaksi raspia ja pi-holea verkkoon niin ei ongelmaa mutta ei ole hyötyä että primary ja secondary ovat sama raspi :)
 
Laiton kaksi piholea pystyyn. MacOS Mojave ja Windows 10 1809 ja noiden verkkokortteihin nuo pihole koneiden ip:t primary ja secondary kenttiin. Windows 10 koneelta menee kyselyjä reilu 10% tuolle secondary pihole koneelle. MacOS koneelta ei mene yhtään. Ajoin tuon primary piholen nurin niin sitten menee macOS koneelta kyselyjä secondary pihole koneelle.
Tunnin verran tuota testailin.
 
Viimeksi muokattu:
Primary/Secondary ei siis ole suoranaisesti mikään load-balancing ratkaisu, vaan juurikin sitä varten jos primääri menee nurin.

Jos molemmat on hengissä niin Secondaryyn menee jokunen kysely jos Primary ei vastaa 5-10ms kuluessa (saattaa olla toinen DNS kysely käsittelyssä).
 
Täällä myös käyttiksenä DietPi, johon Pi-Hole asennettu.
Mukavasti pyörinyt jo useamman kuukauden.

Rautana alkuperäinen RaspberryPi model B rev.1 (256MB muistia).
Löytyi tällekin vielä järkevää käyttöä :)
 
Onko tässä docker installaatiossa jokin koira haudattuna vaiko miksei se lähde vain toimimaan?
Olen täältä näitä ohjeita seurannut ja alustana raspi. Pi-hole®: A black hole for Internet advertisements

Saan kyllä kaiken ns. pystyyn hetkellisesti kunnes homma vaan kaatuu ja container alkaa restarttailemaan. Aluksi kokeilin tuota valmista scriptiä mutta ei natsannut mitenkään, sitten tein oman ja sillä pääsin aikaisemmin mainittuun tilaan.
 
Onko tässä docker installaatiossa jokin koira haudattuna vaiko miksei se lähde vain toimimaan?
Olen täältä näitä ohjeita seurannut ja alustana raspi. Pi-hole®: A black hole for Internet advertisements

Saan kyllä kaiken ns. pystyyn hetkellisesti kunnes homma vaan kaatuu ja container alkaa restarttailemaan. Aluksi kokeilin tuota valmista scriptiä mutta ei natsannut mitenkään, sitten tein oman ja sillä pääsin aikaisemmin mainittuun tilaan.
Onko sulla jotain muuta pyörimässä siinä raspissa, joka käyttää portteja 53 tai 80? Miksi edes haluat ajaa sitä dockerilla raspin päällä?
 
Onko sulla jotain muuta pyörimässä siinä raspissa, joka käyttää portteja 53 tai 80? Miksi edes haluat ajaa sitä dockerilla raspin päällä?
Ei ole tuolle esteitä. Ajattelin innostuksesta vain kokeilla tuota Dockerin päällä. Löysinkin kyllä keslustelun missä vastaavaa ongelmaa käyty läpi.
Docker image doesn't works on RaspberryPi with docker · Issue #306 · pi-hole/docker-pi-hole

Edit. Tässähän se syy lienee
Container keeps restarting every 30s or less (v4.0_armhf on a 1st-gen RasPi B+) · Issue #336 · pi-hole/docker-pi-hole
 
Viimeksi muokattu:
Mikäs blocki vois olla syyllinen et www.hs.fi ei suostu aukeemaan android laitteilla chrome selaimella (honor 8, nexus 7 2013). Pöytäkoneen (Win10) chromella ei mitään ongelmaa.... Logeista ei oikee selviä ku queryjä tulee nii monta....
 
Niimpä tuo oli PiHole taas nurin, mutta olipa koko Rpi3. Kuuma kuin mikäkin, niin mitä lienee tiltannut. Ei voi noista kaatuiluista PiHolea syytellä, vaan on siellä taustalla joku muu joka tuon kaataa, ellei tietty PiHole vedä jojoon.
Nyt siellä on Minecraft palvelin perheelle pyörinyt, mutta ei kovin kauaa ja kaatuili se muutamat kerrat ennen sitäkin, niin sitä en syyttäisi. Kenties pitäisi kokeilla dist upgradea, jos olisi uudempaa tarjolla.
Aiemmin oli puhetta wlanin kaatuilusta, niin sen ajuri voisi tietysti vedellä jumiin ehkä tuon...
Kannattaa firmistäkin koittaa päivitellä sudo rpi-update komennolla
 
Soveltuuko Raspi + pihole linuxseen tutustumiseen? Monesti pitänyt asentaa linux johonkin koneeseen, ihan vaan kokeilumielessä, mutta jäänyt tekemättä koska ei ole ollut erityistä tarvetta. Pi hole+Raspi olisi sellainen sopiva väkertelyn kohde joka motivoisi opettelemaan jotain uutta.
 
Soveltuuko Raspi + pihole linuxseen tutustumiseen? Monesti pitänyt asentaa linux johonkin koneeseen, ihan vaan kokeilumielessä, mutta jäänyt tekemättä koska ei ole ollut erityistä tarvetta. Pi hole+Raspi olisi sellainen sopiva väkertelyn kohde joka motivoisi opettelemaan jotain uutta.

Pi-Hole on aika valmis sellaisenaan ja se vähäinen säätäminen tämän kanssa painottuu kotiverkon reitittimelle.

Muu Linuxiin tutustuminen toki onnistuu Raspberryllä. Työpöytäympäristö tässä on kyllä vähän liian hidas. Ilman graafista käyttöliittymää taas erittäin ripeä, mutta sitten ei ole visuaalista palautetta tukena ja turvana.

Erillisellä, Raspia tehokkaammalla, tietokoneella ehkä olisi paras aloittaa Linuxiin tutustuminen. Työpöytäympäristö toimisi ripeästi, mutta voisi kuitenkin komentorivi-ikkunasta harjoitella ohjelmien asentamista, tiedostojen luomista ym. ym. Siinä näkee heti, että onnistuimpa luomaan työpöydälle tekstitiedoston ja jopa kirjoittamaan sinne jotakin komentoriviltä ja ohjelmavalikkoonkin ilmestyi se äsken komentoriviltä asentamani ohjelma.
 
Kiitti vinkistä IL, ei ole komentoriviä tullut ikävä, graafinen käyttis passaa mulle parhaiten.
 
Soveltuuko Raspi + pihole linuxseen tutustumiseen? Monesti pitänyt asentaa linux johonkin koneeseen, ihan vaan kokeilumielessä, mutta jäänyt tekemättä koska ei ole ollut erityistä tarvetta. Pi hole+Raspi olisi sellainen sopiva väkertelyn kohde joka motivoisi opettelemaan jotain uutta.
VirtualBox nykyiseen koneeseen on myös hyvä harjoitteluympäristö.
 
Pi Hole ei enää estä Youtuben mainoksia Samsung Smart-TV:n Youtube:ssa. Muilla sama ongelma? Mainoksia tulee nyt 5 minuutin välein! En edes muistanut kuinka kauheaa on käyttää tuota ilman mainos blockkeria.
 

Statistiikka

Viestiketjuista
269 091
Viestejä
4 657 780
Jäsenet
76 342
Uusin jäsen
maissihiutale

Hinta.fi

Back
Ylös Bottom