O jumătate de an la înălțime
Luna aceasta se împlinesc șase luni de când a început odiseea mea întru self-hosting - mai pe românește, mi-am închiriat un server de tip VPS - pe care am instalat Alpine Linux, a cărei siglă este în imaginea de mai sus -, de unde acum rulez mai multe servicii pe Internet, inclusiv un motor de căutare, un serviciu de mesagerie și așa mai departe...
Dar să începem cu începutul.
Anul trecut, am plonjat în lumea Linux și a alternativelor gratuite, open-source și/sau descentralizate la programele și serviciile pe care le foloseam în trecut - o tranziție lentă și un pic dureroasă (încă nu s-a încheiat pe deplin), dar enorm de satisfăcătoare. Am încheiat 2025 cu decizia de a închiria un domeniu pentru un site al cărui proiect îl aveam în minte de acum mai mulți ani: o bază de date pentru cărți de poezie, proiect pe care l-am derulat timp de mulți ani pe o pagină etern provizorie de Blogger; ani de zile, am căutat finanțare pentru a face un site nou de la zero... Nu am obținut o finanțare propriu-zisă, dar niște bani simbolici (pe care i-am dat imediat pe alte datorii...) tot am obținut, în ianuarie 2026, de pe urma premiului literar Gheorghe Iova.
Prin aceeași perioadă s-a întâmplat ca R., o persoană din cercurile mele linuxiste, să dea un anunț că are un server și ar fi dispusă pro bono să aloce altcuiva un colț și niște spațiu... și mi-am zis că acum ar fi momentul... Dar ce ar fi trebuit să fie relativ simpla instalare a pachetului MediaWiki pe NixOS s-a dovedit până la urmă a fi o operațiune deloc simplă - dă-i cu instalarea de plugin-uri, mentenanță PHP, dă-i cu instalarea manuală de skin-uri și schimbarea de variabile în .env, dă-i cu instalarea altor plugin-uri ca să meargă plugin-urile de mai devreme, dă-i cu schimbarea limitei de memorie, dă-i și luptă... până la o eroare unde PHP-ul vieții s-a lovit de sistemul de permisiuni de pe NixOS, moment în care R., cu tot dragul și toată bunăvoință din dotare, m-a anunțat că va trebui colaborarea noastră să înceteze, deoarece a acceptat în primă fază în ideea că va fi ceva ce poate rula fără să implice troubleshooting și am sfârșit prin a-i da de lucru, muncă neremunerată... Astfel a trecut prima lună, luna "pilot", a site-ului meu Princeps Poesis, înainte de a deveni un site administrat în întregime de către mine (mai jos în imagine se văd niște funcții pe care le-am adăugat prin plugin-uri interfeței de administrare MediaWiki).
Sincer, mă speria ideea a mă înhăma la un asemenea proiect fără a avea experiență... În aceeași perioadă, poetul Grigore Șoitu, singurul om pe care îl cunoșteam mai bine că administrează site-uri și rețele, era ocupat cu familia și îmi spunea că nu ar mai avea timpul și energia să se înhame la așa ceva... Dar norocul a făcut ca, în martie, să reușesc să rămân cu niște bani după plătirea facturilor și să-mi fac ceva mai mult timp liber...
După un efort de deliberare (poate insuficientă), m-am înhămat la un abonament pe... Hostinger. Nu numai pentru că erau reduceri, ci și pentru că eram în căutarea unui VPS într-o țară a cărei legislație să nu fie explicit ostilă libertăților de diseminare a informației pe Internet (pe care tot mai multe țări caută acum să-l reglementeze tot mai agresiv, iar marile platforme, în încercarea disperată de a nu risca și mai multe amenzi, au ajuns să le implementeze cu exces de zel, folosindu-se, colac peste pupăză, și de așa-zisa inteligență artificială pentru a închide orbește conturi care nici nu sunt întotdeauna vinovate de încălcări, în timp ce conturi care comit activități nu degeaba ilegale trec neobservate pe sub acest radar sau chiar își cumpără imunitatea!). Cum VPS-urile din Islanda erau mai scumpe, mi-am zis că ar putea fi suficient, cel puțin în primul an, un VPS de la Hostinger în țara lor de baștină, Lituania! Ceea ce s-a dovedit până acum a fi o alegere bună, mai ales la capitolul latență. Cu toate acestea, nu exclud a mă muta la alt provider, mai ales dacă Rusia ar încerca să invadeze țările baltice... Doamne ferește!
(Nu mai zic, încă nu-mi este clar dacă Hostinger tolerează găzduirea de site-uri .i2p sau .onion (lucru pe care alți provideri am văzut că-l interzic explicit), ceva ce iau în calcul dacă nu voi mai putea găzdui nici măcar site-ul meu MediaWiki de mi se va cere să implementez verificarea vârstei utilizatorilor - nu există versiune a acestei legislații care să nu violeze flagrant dreptul nostru la intimitate și pare că nici nu există companie terță specializată în verificarea de buletine care să nu fi avut probleme de securitate, ca să nu mai spunem că toți acești incompetenți cer bani pentru serviciile lor cu "inteligență" artificială de două parale! În acest punct poate părea că sunt paranoic, dar mai toți experții în materie de securitate, ca să nu mai spunem de privacy activists, sunt de acord în privința riscurilor iminente.)
Cum a fost experiența mea până acum?
Nu știu alții cum sunt, dar mi-am zis că poate îmi va prinde bine dacă depun eforturi de a acumula niște experiență de sysadmin sau, mai corect spus, de webmaster. Așa că în loc să aleg calea mai ușoară, cea de a instala vreun Linux mai mainstream, precum Debian, Ubuntu sau derivatele RHEL (aveam să constat în timp că foarte mulți dezvoltatori de software FOSS își construiesc documentația pornind de la premisa că sigur folosești unul din aceste distro-uri pe bază de systemd!) și de a-l folosi cu interfață grafică, am ales o altă cale...
Alpine Linux brut, CLI, în terminal, fără X11 sau Wayland.
Cine mi-a mai citit blog-ul poate ține minte că, mai înainte, am folosit, timp de alte câteva luni, Alpine Linux pe desktop (care a însemnat un proces de două zile în care am instalat și stricat și reinstalat până ajunsesem să nu-mi mai fie "frică" de terminal; din contră, multiplele momente în care nu puteam decât să resetez calculatorul m-au făcut să apreciez altfel "colacul de salvare" oferit de emergency shell - atât timp cât mai poți accesa orice fel de shell, totul va fi bine!). Ironia face ca eu să fi ales Alpine pe server cu foarte puțin timp înainte de a ajunge la decizia că pe desktop ar fi mai bine să folosesc OpenBSD... și asta în condițiile în care atât Alpine Linux cât și OpenBSD sunt considerate a fi sisteme de operare pentru servere, nu pentru desktop. Momentan, nu mă pregătesc să înlocuiesc OpenBSD cu iarăși altceva (deși mă tentează să încerc vreun OS pe bază de microkernel în cadrul căruia să folosesc mașinării virtuale Linux și BSD unde e cazul), dar am început să planific înlocuirea instalării Alpine de pe VPS cu OpenBSD, deși foarte probabil unele din serviciile mele vor ajunge rulate tot din niște mașinării virtuale Alpine, deoarece OpenBSD nu are suport pentru Docker, iar în loc de containere dezvoltatorii recomandă folosirea vmm în loc de QEMU...
Motivul pentru care m-aș înhăma la înlocuirea Alpine cu OpenBSD ar fi acela că Alpine, din păcate, este doar o distribuție de Linux, iar încrederea mea față de Linux a scăzut vertiginos anul acesta. Cum am mai zis, dacă vine vorba de comparat vulnerabilitățile descoperite de-a lungul anilor, între OpenBSD și vasta majoritate a lumii Linux este o diferență ca de la cer la pământ, deoarece cei de la OpenBSD au fost obsedați de securitate proactivă și de corectitudinea codului de-a lungul ultimelor trei decenii, nefăcând niciun compromis în vederea acestui scop, indiferenți la pragmaticii ca Linus Torvalds, care vorbea despre ei ca despre "niște maimuțe care se masturbează"!...
Dar să acordăm "alpiniștilor" ce-i al lor!...
Mă refer aici la dezvoltatorii Alpine Linux (din Norvegia + alte țări). Nici pe când le foloseam distribuția pe desktop nu credeam despre ei că ar fi niște moftangii care doar dintr-un capriciu s-au gândit să înlocuiască systemd cu OpenRC (în imaginea de mai sus aveți un exemplu de script care rulează la nivelul rc-service), GNU core utils cu BusyBox și glibc cu musl, în contra direcției dominante din lumea Linux... Știam că aceste alegeri au fost efectiv făcute în vederea optimizării distribuției pentru sistemele embedded și servere, știam că Docker folosește implicit containere pe bază de Alpine din acest motiv - știam, dar încă nu apreciam îndeajuns.
Spațiul mediatic Linux a fost zguduit anul acesta de știrile conform cărora un val de vulnerabilități trivial de executat, descoperite prin intermediul AI și botezate Copy Fail, Dirty Frag ș.a.m.d., au ajuns pe GitHub înainte ca dezvoltatorii de distribuție să facă patch-urile necesare, obligându-i pe utilizatori să facă mitigări manuale. Se titra că mai toate sistemele Linux ar fi afectate... ca apoi să constat cu mare plăcere că nu am putut face aceste mitigări pe Alpine, deoarece... Alpine nu era afectat, era deja hardened! Vorbim de vulnerabilități care au afectat părți obscure din kernel care nici nu prea sunt folosite... Cu ocazia aceasta, am aflat că "veteranii" nu sunt deloc surprinși de așa ceva (abia atunci am înțeles cum de Linux a adunat atâtea CVE-uri de-a lungul anilor), dar că, pe de altă parte, dezvoltatorii OpenBSD s-au folosit de-a lungul timpului tocmai de lecțiile ce se pot învăța de pe urma vulnerabilităților din Linux pentru a putea preîntâmpina vulnerabilități similare în OpenBSD (poate motivul principal pentru care numărul CVE-urilor descoperite pe OpenBSD în aceeași perioadă este mult mai mic, șocant de mic). Însă ceea ce atât Alpine cât și OpenBSD au în comun - și motivul pentru care ambele folosesc doas în loc de sudo - este grija pentru a avea o suprafață de atac cât mai redusă - tot din acest motiv am ales să mă obișnuiesc cu a "locui" în terminal cât lucrez pe VPS...
Cum arată VPS-ul meu și ce tot meșteresc pe el?...
Evident că nu pot divulga aici absolut toate serviciile de care mă folosesc și nici toate măsurile pe care le-am luat (nu știi niciodată când un atacator s-ar putea folosi de informațiile împărtășite aici), dar, pentru început, ceea ce recomand tuturor este blocarea accesului prin parolă la contul "root", folosirea în schimb a "cheilor", și implementarea unei politici absolut restrictive de firewall prin iptables. (Momentan este iptables; dacă mă mut pe OpenBSD, acolo se folosește pf, care pare a fi o alternativă interesantă...) Securitatea este importantă indiferent dacă este vorba de un proces mărunt cum ar fi un server de Gopher, unde de asemenea am parte, din ce înțeleg din loguri, de boți care bâjbâie după fișiere care nu există și comit căutări ciudate (vezi mai jos).
Amprenta redusă în sine a Alpine-ului, peste care nu am adăugat niciun fel de desktop, m-a ajutat la a economisi memorie și a înghesui în numai 2-3 GB un număr semnificativ de servicii diferite, unele în forma unor containere Docker, altele rulate dinadins prin intermediul unor utilizatori neprivilegiați și orchestrate prin OpenRC - jos pălăria! Asta înseamnă totodată că am evitat a risipi memoria RAM pe servicii consumatoare de multe resurse, cum ar fi Matrix Synapse, unde este recomandată alocarea a cel puțin 1-2 GB RAM, în timp ce serverul de XMPP pe care îl rulez acum consumă în mod normal sub 100 MB RAM. Rulez mai multe instanțe de rețele sociale descentralizate - snac consumă sub 10 MB RAM (vezi dovada mai jos), în timp ce Hubzilla se ridică la 575 MB RAM, ceea ce tot este mai optimizat decât Mastodon, care, din ce am auzit, poate ajunge la 1-2 GB RAM (și da, nu rulez Mastodon, asta mai lipsea!).
A existat un caz fericit în care am reușit să-mi pun pe picioare o instanță SearXNG în numai 15 minute, în pauza de masă de la serviciu, intrând de pe mobil pe VPS mulțumită Termux, dar trebuie spus că nimic altceva nu a fost prea ușor pentru mine, fie din cauza pașilor în plus (de la crearea manuală de scripturi OpenRC până la sfânta compilare!) pe care uneori a trebuit să-i fac doar pentru că am ales să folosesc Alpine (singura chestie pe care le-aș reproșa-o este tendința frecventă APK de a numi pachetele ce țin de limbaje de programare și compilare altfel decât pe APT), fie din cauza chichițelor inerente software-ului rulat (despre peripețiile prilejuite de instanța Bluesky voi povesti pe larg în "Rețelele sociale descentralizate"), fie din motive de rețelistică - ba că mi se băteau cap în cap Apache cu Nginx, ba că se încălecau configurațiile Nginx editate de mine cu fișierul default.conf în care umbla Certbot, ba că uitam să pornesc sau să repornesc Nginx, ba că nu căscam ochii la ce scrie într-un anume docker-compose.yaml și mă trezeam ă Docker a inițializat o altă instanță de Nginx numai pentru containerul respectiv, ba că Certbot mai voia o dată la câteva luni niște lapte la biberon (vezi mai jos), ba că mai greșeam numerele port-urilor... culmea prostiei fiind momentul în care am încercat să rulez două servicii pe același port TCP, ceea ce a reușit să dea peste cap întregul Nginx - sau n-a fost neapărat prostie, fiindcă astfel am avut motivația de a înlocui Nginx cu Caddy.
Sigur, multe din aceleași greșeli puteam să le fac și pe Caddy - după ce am trecut prin acele lecții cu Nginx, Caddy pare mai lejer. Ceea ce apreciez la Caddy este eleganța simplificărilor din Caddyfile, dar și faptul că mă scutește de grija Certbot-ului care cerea reînnoiere periodică și filepath-uri explicite în configurațiile de Nginx! Pe de altă parte, anul acesta am citit pe Hacker News că Let's Encrypt vor interzice folosirea certificatelor lor în țările asupra cărora Statele Unite au impus sancțiuni, ceea ce înseamnă că mă voi interesa foarte curând să înlocuiesc toate certificatele mele de la LE cu altele emise de vreo alternativă europeană, precum Actalis. Scenariul dezastruos în care Statele Unite ar impune sancțiuni asupra Uniunii Europene este același scenariu din cauza căruia am căutat să renunț la Windows - mi se părea absolut inacceptabil ca, la un ordin al lui Trump, eu și mai toată lumea din UE să ne trezim cu datele luate ostatece de către un BitLocker devenit armă politică!...
Revenind la bucătăria mea internă... Nu știu ce altceva ar mai fi de spus în afară de faptul că, trebuie să recunosc, pe cât de mult mă mândresc de anumite descoperiri pe cont propriu (cum ar fi că pot menține unele procese active tot timpul atât timp cât rulează neîntrerupt în interiorul tmux) sau de anumite decizii (cum ar fi că am înlocuit WriteFreely, o alternativă oarecum minimalistă la WordPress, cu BSSG, așa cum am anunțat într-un alt articol pe acest site), trebuie să amintesc contribuțiile esențiale ale câtorva dezvoltatori care au acceptat să mă ajute cu suport tehnic după ce m-am lovit de fundături bazându-mă prea tare pe instrucțiunile improvizate de "agentul AI" al celor de la Hostinger... În același timp, trebuie să admit că "agentul" cu pricina a reușit cu alte ocazii să mă ghideze acolo unde trebuie, uneori în chestiuni tehnice pentru care mi-ar fi fost rușine să mai deranjez pe cineva pro bono (mai ales la orele la care tind să operez). Desigur, încerc în timpul acesta să am grijă și să casc ochii pe instrucțiuni (o dată, "agentul" mi-a oferit o configurație unde două subdomenii diferite erau arondate aceluiași port, dar din proprie experiență știam deja că ar fi fatal să repet această greșeală)...
Una peste alta, self-hosting-ul poate fi o treabă ușor obositoare, dar suficient de satisfăcătoare încât să poată deveni un side quest care să distragă cu brio de la main quest-ul tău: în cazul meu, am cam neglijat până acum a profita la maxim de spațiile pe care mi le-am creat, deoarece mi se pare mereu că mai e loc de meșterit și de adăugat servicii sau de optimizat... Pe de altă parte, mă uit în calendar și, deși pare că a trecut mai mult timp de atunci, văd că sunt doar șase luni, iar eu am avut multe de învățat (SSH știu că vă place, dar nici cu scp și sfcp nu mi-e rușine!) și cred că încă mai sunt, inclusiv la capitolul îmbunătățirii securității și reducerii dependenței de, bunăoară, Docker... Una până alta, mă bucur că am mai mult control asupra a ceea ce folosesc! În zilele ce urmează aștept cu nerăbdare lansarea oficială a codului-sursă de la littleFedi, cel mai interesant server minimal ActivityPub de până acum, despre care o să mai auziți de la mine...