M-a lovit răceala, așa că am 5 minute să caligrafiez niște cerneală virtuală.
A venit momentul să-mi bag oleacă picioarele prin proxmox. Dar să nu ne grăbim, ci să începem povestea de unde trebuie, și anume de la nevoi.
Momentan am nevoie să ruleze permanent în rețea un pihole. Pentru asta, un Raspberry Pi 3B+ este mai mult decât suficient și foarte eficient energetic. Iar pentru că rulez pihole într-un container docker care vine de-a gata pregătit cu toate dependențele ce-i mai trebuie, îmi permite să separ aplicația și datele/setările mele, și să automatizez complet actualizarea containerului fără să trebuiască să fac nici un fel de mentenanță. În curând însă vin nevoile unei case noi, cu un OpenHAB pentru smart home și integrarea diverselor sisteme, și un controller software pentru AP-urile TP-Link Omada. Pe RPi n-o să încapă toate astea, poate pe un Odroid N2+ sau ceva și mai potent.
Am prins anul trecut o pleașcă de Lenovo Tiny M710q, cu un procesor i5 generația a 8-a, 16GB de memorie, SSD, silențios, low power, crecă are și vPro și AMT, numa' bun pentru făcut chestii headless cu el. Iar acum am zis să încerc să pun proxmox pe el, ca să împart capacitatea în VM-uri și containere LXC, că doar cât poate să fie de greu.
Buuuuun... Am instalat PVE de vreo trei ori, că în două ocazii mi-am tăiat singur craca cu niște modificări la rețeaua virtuală încercând să rezolv o problemă - more on that in a bit. În cele din urmă l-am lăsat cum vine default la rețea și i-am pus un container pe template-ul Debian 12 pentru pihole, și încă un container pe template-ul Ubuntu 22.04 LTE pentru Omada.
Problema dubioasă era că din containerul Debian inițial părea că nu am acces la net, ceea ce era puțin ciudat fiindcă totuși containerul primea IP din LAN de la router. După niște alte încercări de a afla ce am setat prost la container în PVE, am descoperit că trafic pot face dacă destinația e un IP, doar DNS-ul nu merge. Și de ce nu merge DNS-ul? Fiindcă n-are nameservere setate în container, iar dacă le pun manual, la fiecare restart al containerului dispar. Asta putea fi de la PVE care modifică dinamic niște fișiere de configurare din containere în funcție de ce setări am pus la container în PVE, însă n-a fost asta. Pur și simplu pare a fi un bug în Debian, în care dacă pui manual IPv4 cu gateway și DNS-uri dar lași DHCP la IPv6, răspunsul DHCP primit la pornire face overwrite la setările manuale pentru IPv4 fiindcă le era prea gol frigiderul sau ceva. Nici o altă setare la interfețe nu l-au putut convinge, ultima opțiune ar fi fost să fac override la scriptul ce generează resolv.conf când primește răspunsul DHCP, dar am zis că așa ceva nu fac și adio. În cele din urmă am descoperit că dacă setez containerul să aibă și IPv6 manual dar fără să specific o valoare, asta dezactivează DHCP pe IPv6 în container și atunci păstrează DNS-urile setate manual. Amin.
Apoi am pus controllerul Omada în celălalt container. Asta a fost mai cu cântec, fiindcă TP-Link dă doar pachetul .deb la descărcat și e treaba ta să instalezi prerequisites: mongodb 3 sau 4, care are pachet doar pentru Ubuntu 20 jammy, cu niște biblioteci aferente, OpenJava 8 sau 11 și încă câteva chestii. Deja a început să mă râcâie containerizarea LXC comparativ cu eleganța docker-ului, unde am imagini gata făcute și doar trebuie să mapez niște căi din interiorul containerului spre storage-ul permanent de pe gazdă. Dar în cele din urmă l-am făcut să meargă și pe ăsta, descoperind că în mod curent mănâncă 1,7GB de memorie.
Problema care mi-a pus capacul e că am observat LED-ul de disc cum clipește o dată la câteva secunde. Niște căutări pe net mai târziu și aflu că proxmox are un istoric de a mânca pe pâine SSD-uri, cu recomandarea empirică a unora pentru SSD-uri enterprise, nu de-astea consumer level. Cineva stătuse cu microscopul pe un proxmox proaspăt instalat și care nu făcea nimic, și a descoperit că scria câteva zeci de GB de date pe zi fără ca să facă nimic. WTF.
Am dezactivat cele trei servicii pentru lucrul în cluster, că nu-s necesare pentru un nod standalone. Am configurat logging-ul la minim. Am instalat log2ram. M-am uitat cu iotop ce mai accesează discul pe-acolo. În containerul cu pihole am dezactivat logging-ul detaliilor de destinații și sisteme, și am setat retenția la baza de date long term la zero, dar write access la baza de date tot apare de câteva ori pe minut. Mai nasol a fost în containerul Omada, unde mongodb băgase zeci de MB în doar juma' de oră, și mai era și un log4j pe-acolo. Bine, de fapt aș putea să opresc controllerul cu totul că n-am nevoie de el decât la provizionarea unor echipamente noi în rețea (dacă mi-e lene să fac asta manual din aplicația de pe telefon), dacă vreau să fac monitorizare și jurnalizare istorică (nu vreau) și dacă vreau să rulez un portal captiv pentru autentificare în browser pentru guest network (nici aia nu vreau). Dar totuși... mongodb 4? Versiunea curentă parcă e 7...
Cu asta s-au mai liniștit accesările la disc, dar nu suficient. În continuare lucrează la fiecare 2-3 secunde jurnalizarea la ext4 căreia n-am ce să-i fac, și încă niște servicii de proxmox pe care nu le pot opri fără a se buși. Beculețul ăla de acces la disc pâlpâie fără nici un motiv funcțional o dată la 7 secunde, nu la 2-3. Adică nu-mi moare SSD-ul în juma' de an ci în vreun an jumate. Gee, thanks. Așa nu merge. Experimentul cu proxmox a fost interesant și edificator că nu mi se potrivește.
Pentru viitor aș putea să pun un Ubuntu ceva direct pe bare metal în loc de proxmox și să rulez containere Docker, eventual suplimentând SSD-ul cu un disc mecanic. Aș putea să iau un Odroid, la fel cu containere Docker, și eventual un stick USB3 pentru scrieri frecvente de aiureli de care să nu-mi pară rău dacă se buștește, dar protejând eMMC-ul. Dacă n-ar fi și OpenHAB-ul, aș putea sta bine mersi pe actualul Raspberry Pi fără nici o problemă.
Deci... rămâne cum am stabilit.