Pihole sub Windows

A

AdrianB1

Membru Senior
Sugar daddy
De ceva timp am un pihole care ruleaza intr-o masina virtuala CentOS pe un server Windows. De ce? Pentru ca serverul de Windows exista, am chestii care nu merg pe altceva (SQL Server) si e folosit si ca host pentru masini virtuale diverse.

Sub CentOS nu mai vrea sa faca update la pihole, zice ceva de mama ("Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist"). OK, problema e corectabila, dar da de gandit ca poate nu e cea mai buna varianta pentru 2022.

Daca e Windows, exista WSL. Chiar WSL2. Am incercat sa instalez direct Pihole in Ubuntu sub WSL2, dar are o problema cu lipsa systemd, care poate ca e rezolvabila si aia, dar nu prea usor.

Mai exista Docker. Dar mi se pare un pic scarpinat in diagonala sa rulezi o mini-aplicatie intr-un container intr-o masina virtuala intr-un server fizic. Se poate, probabil e chiar interesant pentru unii ca Marius '95 care au orgasme facand lucrurile cat mai complicat si cat mai anormal cu putinta, dar nu am nici timp si nici chef de chestii exotice.

Mai exista alta varianta, simpla, pentru Pihole sub Windows?
 
Off-topic: dacă prin SQL Server te referi la MS SQL Server, am înțeles că merge și pe Linux nativ (n-am încercat). Văzui acuma că este și versiune docker, deci poți migra tot serverul pe Linux și rulezi SQL Server și Pihole în docker. :smile:
 
  • Like
Reactions: Neo
Zici de Marius dar tu rulezi server Windows cu mașini virtuale :smile:

Eu am pus pihole pe un LXC care rulează sub Proxmox alături de alte VMs/LXC, i-am dat mai mult RAM și mai mult CPU decât are un Pi normal și merge super ok. Pi-hole vechi pe rPi mk1 rulează ca fallback în caz că dau restart la server.

Serverul Windows nu poate duce LXC? WSL și WSL2 nu mi se par fezabile dar sunt unii care se jură că-s soluții ok, ymmv.
 
MS SQL Server merge si sub Linux, dar nu totul si nu la fel (nu exista paritate completa), in special nu la fel de bine. Chiar daca e non-prod, sandbox pentru diverse proiecte, incerc sa evit problemele care se pot evita folosind common sense :smile:

Serverul are Hyper-V, e una din metodele rezonabile de a rula masini virtuale. Fiind masini virtuale nu conteaza OS, dar e un mix de Windows, Linux si FreeBSD si se inteleg foarte bine pana cand ocuparea memoriei trece de 100 GB. Masina cu Pihole are alocat 4 GB, mi se pare mult doar pentru asa ceva si din cauza asta voiam sa o rulez ca aplicatie sub WSL2, daca se poate. Chiar daca serverul are 128 GB de RAM, asta e maximul posibil si am avut nevoie de cateva ori sa opresc unele VM ca sa mearga altele, de pilda cand vreau sa incerc ceva cu un domeniu intreg de Windows si un cluster de SQL cu 4 noduri sau mai mult.
 
  • Like
Reactions: Neo
În cazul ăsta, din punctul meu de vedere, cea mai simplă variantă ar fi să reinstalezi un VM cu altă clona de RHEL (gen Rocky Linux sau ce e la modă acum). Ar trebui să fie același lucru, tot cu yum upgradezi. Dacă RHEL nu ține pasul cu update-urile necesare pentru pi-hole, atunci treci la altă distribuție (de exemplu Debian, eventual testing în loc de stable). E umpic de muncă să te obișnuiești (dar nu așa multă având în vedere că toată lumea e cu systemd acuma), dar mai puțină decât ai avea cu pihole în WSL (și tot felul de probleme care ar putea apărea pe-acolo).
 
  • Like
Reactions: Neo
Hyper-V ăla nu știe să ruleze direct un LXC? Văd că poate rula direct un container Docker, poți scoate direct unul gata făcut iirc și doar îi dai deploy. LXC al meu care rulează pi-hole are 256MB RAM și 512MB swap și este foarte mulțumit. Într-adevăr 4GB RAM este cam mult pentru pi-hole doar.

VM cu ceva Debian mi se pare next best thing până la WSL/WSL2, cum zice și jarod.
 
Multumesc, atunci Debian o sa fie. RHEL am la serviciu, cateva sute, dar nu ma atrage ideea de a pune vreo clona pe-acasa, CentOS era recomandarea la vremea cand am pus Pihole acum cativa ani.
 
Am o ciudatenie care se intampla de vreo 24 de ore: de pe telefon (Pixel) o gramada de pagini de internet incearca sa se incarce, stau pe la 5-10% in bara de progres (care de obicei nici nu apare) vreo 10-20 de secunde, apoi se incarca aparent normal. De pe desktop nu se intampla asa ceva. Ambele sunt configurate cu PiHole ca unic DNS, iar PiHole cu Cloudflare (4 de 1) si GOogle (4 de 8). Pe mobil pare un timeout de DNS, dar nu prea am unelte cu care sa depanez asa ceva. Pe desktop intrucat merge perfect nu am ce sa verific. PiHole nu raporteaza nici o problema, nici nu imi dau seama cum ar raporta.

Am auzit de ceva probleme cu DNS-ul de Cloudflare in ultimele saptamani, dar nimic prea clar. Idei?
 
Firefox pe Android cumva? Mie-mi afișează o pagină goală uneori la schimbarea tab-ului după ceva timp, până face iar reîncărcare și rendering.

Ai IPv6 activ în rețea?

În logs la pi-hole e ceva edificator? Poți filtra log-urile după device în Tools > Network.
 
E Chrome pe Android. Fara v6. Nimic in loguri.

Vad ca in unele pagini face 2 pauze. Prima pe la 5-10%, apoi pe la 30-40%. Daca navighez in acelasi site, prima pauza nu o mai face, dar uneori o face pe a doua - poate incearca sa incarce ceva reclame si au inceput sa manareasca JS sa tot incerce, ca masura anti-adblock?
 
Posibil. E vreo corelație cu momentul în care și-a făcut ultima oară Gravity update? Am mai pățit să încarc ceva gravity lists complet bușite.
 
Nu e o corelatie si am facut si update manual la Gravity.

Cred ca pe mobil sunt reclame diferite si mai multe decat pe desktop, asta ar putea explica de ce pe desktop nu se vede problema, dar e doar o speculatie.
 
Cu siguranta asa e, reclamele sunt altfel si multi au exploatat chestia asta.
Dar totusi nu m-as fi asteptat sa modifice comportamentul.
 
E un joc de-a șoarecele și pisica, nu ne putem aștepta că sistemul ăsta de filtrare bazat pe DNS să funcționeze forever. Industria și-a luat-o peste bot cu blocarea third party cookies prin care făceau tracking, și prin filtrarea DNS (fie cu pihole fie cu servicii gratuite sau premium de 3rd party DNS), iar răspunsul este „ba pe-a mă-tii” cu noi tehnici de cookieless fingerprinting.

Deja Google pregătește să facă rollout la A/B testing pentru 1% din userii de Chrome pentru asta, și cred că vine vremea când vom bloca JS și vom avea setări de user-agent pentru a divulga cât mai puține informații.

E doar o săptămână de când a fost un mic scandal că Youtube livrează maxim 1080 pentru Linux aarch64, aparent fiindcă această combinație a fost clasificată drept un TV hisense (dar care ridică și mai multe întrebări).

Mesajul clar e că poți primi un serviciu diferit în funcție de ce informații dai. Iar dacă e vorba de Android controlat integral de Google... good luck.
 
Aaa, hmmm, revin.

Ma gandesc sa inlocuiesc VM cu CentOS in care ruleaza PiHole cu un container in WSL2 cu Podman. Am aruncat o privire si nu pare chiar mainstream, ma gandesc sa nu cumva sa ma manance undeva degeaba si sa am idei a la Marius '95 , interesante dar nu neaparat practice.

Avand in vedere ca serverul host pentru toate virtualizarile e Windows (2022) si am atat VM-uri, dar si WSL2, iar pana acum totul ruleaza cuminte in VM, inclusiv Home Assistant, exista vreun beneficiu real in a muta din VM in container? Eu nu gasesc nici unul, container gata facut cu PiHole nu pare ca exista (se poate construi, dar nu e tot aia), cred ca tot atatea resurse o sa consume (si alea nu sunt o problema), cred ca merge fix la fel, securitatea in VM mi se pare mai buna (izolare reala vs "pe-acolo"), managementul VM e banal de tot, o poate face si bunica' lu Dorel. Nu am nici un plan sa trec pe Proxmox sau altceva pentru ca am nevoie de SQL Server si nu vreau sa il pun intr-un VM, ala chiar consuma resurse, iar cine mentioneaza ca SQL Server ruleaza si sub Linux nu are decat sa isi bata cuie in talpa si sa compare.

Deci, are rost sa incerc sau imi iau niste alifie ca sa imi treaca mai repede? Intrebarea nu e "cum fac?", ci "de ce sa fac?".
 
Mutarea din VM în container dă pe plus la economia de resurse (nu-ți mai trebuie un VM întreg pentru pihole) și la ușurința actualizărilor - actualizezi containerul cu totul, nu software-ul din el.

Container (docker) gata făcut cu pihole există de la mama lui, https://hub.docker.com/r/pihole/pihole . Nu există container LXC și ăla trebuie să ți-l faci singur.

Folosirea podman e fix ca docker doar că scrii podman în loc de docker în linia de comandă. Recomand să folosești volume pentru persistența datelor în afara containerului, și să-l rulezi pe rețeaua host ca să nu-l bage prin NAT degeaba (deși teoretic ăsta e un risc de securitate).

Bash: 
podman run -d --name=pihole --network=host -e TZ=Europe/Bucharest -e WEBPASSWORD=password -v pihole:/etc/pihole -v dnsmasq:/etc/dnsmasq.d --restart=unless-stopped pihole/pihole:latest
 
Da, corect, dar de ce? That is the question. Poate economisesc 0.5 GB de RAM, adica 10% dintr-un browser sau 1% dintr-un SQL.

Nu stiu daca e mai simplu sa actualizez containerul sau doar Gravity. Oricum o fac rar, chiar mi-ar fi placut sa nu fie nevoie sa o fac vreodata (self-update). Fire and forget. Lucrurile sunt mult prea complicate in zilele noastre, lumea nu se mai KISS.
 
De ce?
  • Pentru simplificarea stack-ului de intermediari între bare metal și aplicație.
  • Pentru a folosi ceva mai eficient resursele - da, ai RAM gârlă, dar dacă pihole poate rula fericit în 256MB de memorie, de ce să-i blochezi 4GB doar fiindcă e într-un VM? Pic cu pic se adună.
  • Pentru a-ți simplifica workload-ul de întreținere la atât de multe guest OS-uri când ai putea chiar să nici nu ai unul ([edit] separat pentru pihole).
  • Pentru a-ți simplifica workload-ul de întreținere la aplicația în sine până la zero. Io n-am făcut pihole -up niciodată și totuși am ultima versiune de software, iar gravity update își face singur automat.
Poate că acum ești deja la un pseudo-stadiu de „fire & forget” dar, măcar o dată la câțiva ani, ce ai instalat și ai abandonat că don't mess with it if it's not broken tot o să bășească o eroare cum că versiunea de OS nu mai e la zi, că repos au fost trase pe tușă și îngropate de mult, că aia, că ailantă, și uite că tot trebuie să faci un efort în a restaura serviciul pe un VM instalat nou. Da, ai putea pune un Ubuntu Server LTS care are și update-uri automate și până în aprilie 2032 nu mai trebuie să-i faci nimic, dar dacă tot pui mâna să faci ceva, de ce nu o soluție care nici măcar 2032 nu are ca dată de expirare și chiar este fire&forget? La așa un orizont lung de timp deja te poți gândi că intervine o slujbă de veșnică pomenire la un hardware mort, și atunci poate te pregătești cum să automatizezi și să simplifici reinstalarea la tot ce ai pe un hardware nou, într-un mod atât de universal valabil încât să fie complet transparentă și trecerea de la arhitectura x86-64 la ARM.
 
Last edited:
Cred ca motivul principal pentru care imi plac VMs e ca e extrem de usor sa fac un backup, snapshot sau migrare pe alt host: un file copy pentru backup sau migrare si un buton pentru snapshot. Atata timp cat exista un host cu HyperV (din cauza SQL), iar tehnologia in domeniul asta e aceeasi ca acum 15 ani, e simplu. Nu stiu daca peste 10 ani managementul containerelor va fi la fel, daca PiHole va mai fi relevant. poate ca da, poate ca nu, dar gardware pe care ruleaza acum sigur nu va mai exista (are deja vreo cativa ani vechime) si va trebui mutat altundeva.

Il mai las asa, peste un an mai analizez situatia, mai vad ce a aparut intre timp.
 
Cu asta-s de acord, și dacă nu ai o masă critică de beneficii care să încline balanța în direcția unei schimbări atât de semnificative, atunci n-are sens. Containerele par să meargă foarte bine pentru cine face devops și orchestrare, sau măcar are nevoia de a exersa undeva pentru eventuala folosire la job. Dar altfel, dacă ești fericit și eficient cu work patterns existente și nu te împinge licențierea VMware de exemplu la schimbare, stai pe ce ai.

Deci pentru VM nou, Rocky Linux pentru a rămâne în universul aproximativ RHEL și ca o continuare familiară la CentOS. Sau, Ubuntu 22.04 LTS dacă vrei debian derivative cu autoupdate, dar atenție că poate face niște figuri interesante. În primul rând că porturile sub 1024 sunt rezervate și ai niște pași suplimentari ca pihole să poată folosi 53, în al doilea rând fiindcă portul 53 este rezervat de resolver-ul local pe care va trebui să-l dezactivezi, însă dacă vreodată îți crapă pihole va trebui să reactivezi resolverul local ca să poți rezolva orice FQDN, inclusiv pentru instalat actualizări sau pachete.
 
You must log in or register to reply here.
Back
Top