Această serie explică pas cu pas cum să creezi un site complet, de la achiziția domeniului până la instalarea și configurarea WordPress, folosind panoul de administrare CyberPanel.
🔹Episodul 0: Fundația. Cluster Proxmox și High Availability (HA)
„Dacă nu este pe o bază solidă, un site este doar un castel de nisip care așteaptă prima eroare de sistem.”
Bun venit la începutul unei călătorii fascinante. Înainte de a cumpăra domenii sau de a instala WordPress, trebuie să vorbim despre unde va locui viitorul tău proiect. Majoritatea tutorialelor te învață să pui un site pe un hosting ieftin și să speri că va merge. În această serie, facem lucrurile altfel: construim propria noastră infrastructură de tip Enterprise.
De ce începem cu un Cluster?
Imaginează-ți că serverul tău are o problemă hardware în mijlocul nopții. Într-un setup obișnuit, site-ul tău dispare. Într-un Cluster Proxmox cu Arbitru (QDevice), celălalt server preia ștafeta imediat.
Ce vei învăța în această prefață:
Transformarea hardware-ului obișnuit: Cum să legi două mini-PC-uri (NUC-uri) într-o singură entitate inteligentă.
Puterea Arbitrului (QDevice): Cum un al treilea dispozitiv (chiar și un laptop vechi cu Ubuntu) poate decide cine rămâne online în caz de avarie.
Depanarea reală: Nu vă arăt doar varianta „perfectă”, ci și cum să treceți peste erorile de permisiuni SSH, repository-uri blocate și configurări de rețea care dau bătăi de cap chiar și profesioniștilor.
Nota autorului: Acest episod este fundația. Poate fi cea mai tehnică parte a seriei, dar odată ce ai terminat, vei avea o liniște pe care niciun serviciu de hosting de 5 euro nu ți-o poate oferi: certitudinea că site-ul tău stă pe o infrastructură indestructibilă.
Ghid: Configurarea unui Quorum Device (Arbitru) în Proxmox 8/9
Atunci când ai un cluster format din doar două noduri Proxmox, ai nevoie de un al treilea vot pentru a menține majoritatea (Quorum) în cazul în care un server pică. Acest rol este îndeplinit de un QDevice (un simplu container sau PC cu Linux).
⚠️ NOTĂ CRUCIALĂ: Alegerea Sistemului de Fișiere Înainte de a rula orice comandă, asigurați-vă că la instalarea Proxmox, în ecranul Target Harddisk -> Options, ați selectat zfs (RAID0).
De ce ZFS și nu LVM-ul implicit? Fără ZFS, nu veți putea folosi funcția de Replication (Oglindire). ZFS ne permite să trimitem automat datele de pe un server pe altul în fiecare minut, asigurându-ne că site-ul nostru are o copie identică gata să pornească dacă hardware-ul principal cedează.
a. Pregătirea nodurilor Proxmox (PVE1 și PVE2)
Implicit, Proxmox vine cu repository-urile „Enterprise” activate. Pentru varianta gratuită, trebuie să curățăm sursele apt pentru a putea instala pachetul de corosync.
Comenzi de curățare și activare surse No-Subscription:
# Eliminarea surselor enterprise (format .list și .sources)
rm -f /etc/apt/sources.list.d/pve-enterprise.list
rm -f /etc/apt/sources.list.d/pve-enterprise.sources
rm -f /etc/apt/sources.list.d/ceph.sources
# Adăugarea surselor gratuite
echo "deb http://download.proxmox.com/debian/pve trixie pve-no-subscription" > /etc/apt/sources.list.d/pve-no-sub.list
echo "deb http://download.proxmox.com/debian/ceph-squid trixie no-subscription" > /etc/apt/sources.list.d/ceph-no-sub.list
# Actualizarea și instalarea pachetului QDevice
apt update && apt install corosync-qdevice -y
b. Pregătirea Arbitrului (Ubuntu / Debian – IP: 192.168.1.101)
Arbitrul are nevoie de pachetul de rețea corosync și de acces SSH relaxat pentru configurarea inițială.
Pe Arbitru:
sudo apt update && sudo apt install corosync-qnetd -y
Deblocarea accesului pentru Proxmox (Soluția pentru “Permission Denied”): Proxmox forțează conexiunea prin utilizatorul root. Dacă folosim un alt utilizator (ex: bogdan), trebuie să mutăm cheile:
# Execută pe Ubuntu pentru a permite accesul root cu cheia utilizatorului
sudo mkdir -p /root/.ssh
sudo cp /home/bogdan/.ssh/authorized_keys /root/.ssh/authorized_keys
sudo chmod 700 /root/.ssh
sudo chmod 600 /root/.ssh/authorized_keys
# Asigură-te că SSH permite logarea root
sudo sed -i 's/#PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_config
sudo systemctl restart ssh
Configurarea Accesului SSH cu Parolă pentru Root: Pentru ca nodurile Proxmox să poată instala serviciul de Quorum, laptopul Arbitru trebuie să permită logarea utilizatorului root cu parolă (doar pentru etapa inițială de configurare).
# Editează fișierul de configurare SSH
sudo nano /etc/ssh/sshd_config
# Caută și modifică aceste linii să arate exact așa (elimină # dacă există):
PermitRootLogin yes
PasswordAuthentication yes
# Salvează (Ctrl+O, Enter) și Ieși (Ctrl+X)
# Apoi restartează serviciul pentru a aplica modificările:
sudo systemctl restart ssh
# Setează o parolă pentru utilizatorul root (dacă nu ai făcut-o deja):
sudo passwd root
De ce este obligatoriu acest pas?
Chiar dacă am copiat cheile SSH, utilitarul
pvecm qdevice setup(comanda de la pasul c.3) are nevoie de o conexiune inițială bazată pe parolă pentru a schimba certificatele de securitate între noduri și Arbitru. FărăPasswordAuthentication yes, vei primi eroarea “Permission Denied” la finalul procedurii.
Sfat de securitate: După ce ai verificat cu pvecm status că ai 3 voturi, este recomandat să revii la acest fișier și să schimbi PasswordAuthentication înapoi pe n
c. Legarea Clusterului (Marea Unire)
Această etapă transformă serverele individuale într-o singură entitate. Deoarece Proxmox folosește SSH pentru comunicarea securizată, trebuie să “împrietenim” nodurile fără parole.
Pe Proxmox (PVE1):
# 1. Trimitem cheia SSH către Arbitru (ASUS)
# Notă: Dacă ați mai avut un cluster vechi, rulați întâi: ssh-keygen -f "/root/.ssh/known_hosts" -R "192.168.1.101"
ssh-copy-id [email protected]
# 2. Crearea Clusterului
pvecm create RenukaCluster
# 3. Configurarea finală a QDevice (Arbitrul)
# Folosim -f pentru a forța scrierea noilor certificate de securitate
pvecm qdevice setup 192.168.1.101 -f
d. Verificarea statusului
Pentru a confirma că avem acum 3 voturi, folosim:
pvecm statusRezultatul dorit:
Total votes: 3
Quorum: 2
Flags: Quorate Qdevice
“Prin alegerea ZFS și configurarea acestui Arbitru, am creat un mediu unde datele nu sunt doar stocate, ci sunt vii și mobile. În episoadele următoare, vom instala WordPress-ul pe această fundație și vom activa Replicarea la fiecare 60 de secunde. Somnul liniștit al unui administrator de sistem începe aici.”
🔹 Episodul 1: Alegerea și cumpărarea unui domeniu ieftin – Namecheap –
1. Vizualizarea procesului de “Upselling” (Evitarea costurilor inutile)
- Namecheap o să vă propună SSL, VPN sau Premium DNS în coș. Nu le bifați! În episoadele următoare, vă voi arăta cum să obțineți aceleași beneficii (și chiar mai bune) folosind Cloudflare și propriul nostru server. De ce să plătești abonament anual când poți avea control total și costuri zero?
2. “Privacy Protection” (WhoisGuard)
- În timp ce alții îți cer 10-15$ pe an doar ca să nu îți facă publică adresa de acasă și numărul de telefon, Namecheap oferă această protecție GRATUIT, pe viață.
⚠️ Atenție la „Prețul de Reînnoire” și Decontarea Automată
Chiar dacă Namecheap este una dintre cele mai corecte platforme, trebuie să fii un cumpărător informat. Iată cele două reguli de aur:
- Verifică prețul din anul 2
Multe promoții (de exemplu, domenii .com la 5-6$) sunt valabile doar pentru primul an. Înainte de a plăti, uită-te sub prețul actual; vei vedea „Retail price” sau „Renewal price”. De regulă, acesta sare la 14-16$.
Sfat: Dacă proiectul tău este unul pe termen lung, calculează-ți bugetul pornind de la prețul de reînnoire, nu de la cel promoțional.
- Oprește „Decontarea Automată” (Auto-Renew)
Dacă doar testezi o idee și nu vrei să te trezești cu banii luați de pe card peste 12 luni, trebuie să dezactivezi reînnoirea automată.
🔹 Episodul 2: Configurarea domeniului în Cloudflare + SSL gratuit
PREAMBUL
1. De ce Cloudflare și nu SSL-ul plătit de la Namecheap?
- În episodul anterior am refuzat ofertele de SSL de 10-15$ pe an. De ce? Pentru că Cloudflare ne oferă același lucru (și mult mai mult) GRATUIT. Cloudflare nu este doar un furnizor de certificate SSL; este un scut de protecție (WAF), un sistem de accelerare a site-ului și un manager DNS mult mai rapid decât cel standard.
2. “Propagarea DNS” (Răbdarea e cheia)
- După ce schimbi Nameserverele în Namecheap (https://www.google.com/search?q=ns1.cloudflare.com, https://www.google.com/search?q=ns2.cloudflare.com), s-ar putea să te panichezi că site-ul nu merge imediat. Propagarea DNS poate dura de la 5 minute până la 24 de ore. Nu te apuca să schimbi setările de zece ori; verifică statusul în Cloudflare până când apare eticheta verde: “Great news! Cloudflare is now protecting your site.”
⚠️ Atenție la Configurarea SSL: Modul “Full” vs “Flexible”
Cloudflare îți oferă mai multe opțiuni de criptare. Iată ce trebuie să știi pentru a evita erorile de tip “Too many redirects”:
- Modul Flexible: Criptează doar traficul dintre vizitator și Cloudflare. (Util dacă serverul tău nu are deloc SSL).
- Modul Full / Full (Strict): Criptează tot traseul, de la vizitator până la serverul tău Proxmox/CyberPanel.
Sfat: Deoarece în Episodul 3 vom instala propriul nostru panou de control, îți recomand să setezi de acum modul Full. Este standardul de securitate pentru 2026.
Două setări “Must-Have” în Cloudflare
Activează imediat aceste două opțiuni din tab-ul SSL/TLS -> Edge Certificates:
- Always Use HTTPS: Redirecționează automat orice vizitator care scrie http:// către varianta securizată https://. Zero efort, securitate maximă.
- Automatic HTTPS Rewrites: Rezolvă problemele de “Mixed Content” (când ai poze sau scripturi vechi care încarcă pe legături nesecurizate).
🔹 Episodul 3: Arhitectura Invizibilă. Cloudflare Tunnel și Replicarea ZFS
„Securitatea adevărată nu înseamnă doar un perete înalt, ci să fii imposibil de găsit. Astăzi, facem noul nostru domeniu renuka.site invizibil pentru hackeri și indestructibil în fața defecțiunilor hardware.”
Până acum avem un domeniu cumpărat și scutul Cloudflare activat. Dar cum conectăm serverul nostru Proxmox de acasă la internet fără să ne expunem adresa IP reală? În mod normal, ar trebui să facem Port Forwarding în router, ceea ce expune rețeaua ta privată și te obligă să gestionezi reguli complicate de firewall. În acest episod, eliminăm acest risc folosind Cloudflare Tunnels.
🚀 Revoluția Zero Trust: Adio IP Static și Port Forwarding
Cel mai mare avantaj al acestui model este că nu mai ai nevoie de un IP static de la furnizorul de internet (ISP).
⚠️ NOTĂ PENTRU UTILIZATORUL CASNIC: > Cel mai mare beneficiu? Uită de costurile suplimentare pentru un IP static! Deoarece tunelul inițiază conexiunea din interiorul rețelei tale către Cloudflare (Inside-Out), site-ul tău va rămâne online chiar dacă furnizorul de internet (Digi/Orange/Vodafone) îți schimbă adresa IP de zece ori pe zi. Cloudflare actualizează automat rutele DNS (înregistrările CNAME) fără ca tu să miști un deget. Este soluția ideală pentru hosting-ul de acasă.
Conexiune Securizată: Serverul tău stabilește o conexiune criptată cu Cloudflare.
Automatizare DNS: Când definești o rută în tunel, Cloudflare creează automat un
CNAMEcare punctează către serverul tău.Router „Blindat”: Routerul tău rămâne închis. Niciun port deschis, nicio poartă de intrare pentru atacatori.
a. Pregătirea Tunelului în Cloudflare Zero Trust
Înainte de configurația pe server, pregătim „țeava” digitală în dashboard-ul Cloudflare:
Navighează la Zero Trust -> Networks -> Tunnels.
Creează un tunel nou numit
renuka-production-tunnel.Selectează conectorul Debian (64-bit).
Copiază Token-ul unic (șirul lung de caractere de la finalul comenzii de instalare). Păstrează-l, acesta este cheia care va lega containerul tău de rețeaua globală.
b. Crearea Containerului (CT) în Proxmox
Nu instalăm conectorul direct pe sistemul de operare al serverului (PVE), ci într-un mediu izolat pentru o gestionare mai bună:
Download Template: În interfața Proxmox, mergi la storage-ul
local->CT Templates->Templatesși descarcădebian-12-standard.Create CT: Folosește acest template pentru un nou container (ex: ID 105, nume
Cloudflare-Connector).Setarea de Aur (Nesting): După ce containerul a fost creat (dar înainte de a-l porni), mergi la: Container (105) -> Options -> Features -> Dublu click pe Nesting și bifează-l. Fără această bifă activată, serviciul de tunel nu va avea permisiunile necesare să pornească!
c. Instalarea Conectorului (Comenzile Terminal)
Pornește containerul, intră în consola acestuia și rulează următoarele comenzi pentru a activa tunelul:
# 1. Actualizăm sistemul și instalăm utilitarul curl
apt update && apt upgrade -y
apt install curl -y
# 2. Descărcăm pachetul oficial Cloudflared (conectorul)
curl -L --output cloudflared.deb https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
# 3. Instalăm pachetul pe sistem
dpkg -i cloudflared.deb
# 4. Activăm serviciul de tunel (Înlocuiește [TOKEN] cu cel obținut anterior)
cloudflared service install [TOKEN_UL_TAU_AICI]
Verificare: În dashboard-ul Cloudflare, statusul tunelului trebuie să devină verde: Healthy.
d. Replicarea ZFS: Oglinda între PVE1 și PVE2
Pentru a asigura continuitatea site-ului renuka.site, configurăm Proxmox să oglindească acest container pe al doilea server din cluster:
Selectează containerul (105) -> Replication -> Add.
Target: PVE2 (al doilea nod din cluster).
Schedule:
*/1(la fiecare minut).Rezultat: Dacă serverul principal (PVE1) are o defecțiune hardware, containerul poate fi pornit instant pe PVE2. Conexiunea tunelului se va restabili automat, iar site-ul va reveni online în câteva secunde.
e. Maparea Rutei Principale
În tab-ul Public Hostname din Cloudflare Tunnel, adăugăm poarta de acces pentru vizitatori:
Subdomain: (lasă gol pentru domeniul principal)
Domain:
renuka.siteService:
http://[IP_INTERN_SERVER](Aici vom introduce adresa locală a serverului unde vom instala WordPress în episodul următor).
🔹 Episodul 4: Serverul Nemuritor. Instalare CyberPanel și High Availability (HA)
„Un server care rulează este bine. Un server care reînvie singur după o defecțiune hardware este invincibil. Astăzi transformăm infrastructura noastră locală într-o fortăreață folosind CyberPanel și redundanța Proxmox.”
După ce în episodul anterior am securizat legătura cu exteriorul prin Cloudflare Tunnel, astăzi ne ocupăm de „motorul” site-ului nostru: CyberPanel-Server (VM 101). Dar, așa cum se întâmplă în viața reală de admin, drumul a fost plin de erori de permisiuni și obstacole tehnice pe care le-am rezolvat pas cu pas.
🚀 Reziliență Totală: Instalarea Agentului și Lupta cu Permisiunile
Cel mai important pas în pregătirea mașinii virtuale este instalarea QEMU Guest Agent, „traducătorul” dintre Ubuntu și Proxmox.
⚠️ NOTĂ TEHNICĂ: > Fără acest agent, replicarea ZFS nu poate executa funcția fsfreeze. Această funcție „îngheață” scrierile pe disc pentru o secundă, asigurând că snapshot-ul bazei de date este perfect consistent și necorupt în timpul sincronizării între servere.
QEMU Agent: Permite Proxmox-ului să vadă IP-ul intern și să execute Safe Shutdown.
Root Access: CyberPanel necesită drepturi depline, iar comanda
sudo su -este obligatorie.Safe Install: Descărcarea scriptului pe disc elimină erorile de tip „pipe” precum
/dev/fd/63.
a. Pregătirea Sistemului (Comenzi Terminal)
Înainte de instalarea panoului, actualizăm sistemul și activăm comunicarea cu hypervisor-ul:
# 1. Actualizăm sistemul și instalăm QEMU Agent
sudo apt update && sudo apt upgrade -y
sudo apt install qemu-guest-agent -y
# 2. Activăm serviciul
sudo systemctl enable qemu-guest-agent
sudo systemctl start qemu-guest-agent
b. Instalarea CyberPanel (Depanarea CLI)
Pentru a evita erorile de permisiuni detectate în timpul tutorialului, urmăm metoda descărcării locale:
Download:
wget -O install.sh https://cyberpanel.net/install.shSwitch to Root:
sudo su -(Cratima încarcă profilul complet de root).Execute: Mergem în folderul unde am descărcat scriptul:
cd /home/[utilizatorul_tau]/și lansăm sh install.sh.
c. Recuperarea Parolei (adminPass)
Dacă logarea eșuează sau parola default nu este recunoscută, folosim utilitarul intern CyberPanel (obligatoriu din modul root):
# Resetarea parolei de admin în cazul erorilor de acces
sudo su -
adminPass noua_ta_parola_sigura
d. Replicarea ZFS și High Availability (HA)
Pentru a asigura „nemurirea” serverului, configurăm Proxmox să oglindească VM-ul pe al doilea server din cluster:
Selectează VM (101) -> Replication -> Add (Schedule:
*/1).HA Manager: Adăugăm VM 101 în Datacenter -> HA cu setarea Max. Relocate: 1.
Rezultat: În cazul unei pene de curent pe PVE1, clusterul (ajutat de QDevice/Arbiter) va reporni automat CyberPanel pe PVE2 în mai puțin de 2 minute.
e. Rezultatul Testului de Failover
În log-ul sistemului, vedem procesul de replicare funcționând impecabil:
Freeze: Agentul QEMU oprește scrierile.
Snapshot: ZFS creează punctul de referință.
Sync: Datele sunt trimise către al doilea server.
🔹 Episodul 5: De la Local la Live. Cloudflare Tunnel și Instalare WordPress
„Un site online este doar începutul. Astăzi finalizăm legătura dintre infrastructura noastră locală și internetul public, demonstrând că poți avea un site funcțional fără a deschide niciun port în router și fără setări complicate de SSL local.”
După ce în episodul anterior am asigurat redundanța hardware prin High Availability, astăzi ne ocupăm de „fațada” proiectului. Trecem de la un IP local la un domeniu live, rezolvând dilema porturilor și realizând prima instalare de WordPress sub protecția Cloudflare Tunnel.
🚀 Conexiunea Inteligentă: Cloudflare Tunnel pe Portul 80
Momentul critic al acestui episod a fost găsirea rutei optime pentru trafic, evitând erorile de tip SSL Handshake (Bad Gateway).
⚠️ NOTĂ TEHNICĂ: În această configurație, am setat ruta tunelului către HTTP port 80. Deoarece tunelul Cloudflare este deja un canal criptat și securizat între serverul nostru și marginea rețelei lor, nu mai este necesar să configurăm certificate SSL locale pe CyberPanel pentru a vedea site-ul live.
Cloudflare Tunnel: Serviciul care face legătura securizată între containerul Proxmox și internet, păstrând IP-ul de acasă ascuns.
No Open Ports: Routerul rămâne închis. Zero Port Forwarding înseamnă securitate maximă împotriva atacurilor directe.
WordPress Live: Confirmăm că tot sistemul — de la replicarea ZFS la tunelul Cloudflare — funcționează perfect.
a. Configurarea rutei în Networks -> Tunnels
Pasul esențial pentru a face site-ul vizibil a fost definirea punctului de ieșire în panoul Cloudflare:
Public Hostname: În secțiunea Networks -> Tunnels, am editat tunelul activ și am adăugat domeniul dorit.
Service Type: Am selectat HTTP (nu HTTPS), lăsând tunelul să gestioneze criptarea.
URL: Am specificat IP-ul intern al VM-ului și portul 80 pentru a elimina eroarea 502.
b. Instalarea WordPress via CyberPanel
Cu domeniul acum accesibil din exterior, am trecut la instalarea motorului de site prin interfața CyberPanel:
Website Creation: Am adăugat domeniul în CyberPanel, pregătind structura de fișiere.
Application Installer: Am folosit scriptul de WordPress pentru a configura baza de date și fișierele automat.
Confirmare: Am verificat accesul la Dashboard, confirmând că tot lanțul de comunicație este funcțional.
c. Securitatea la Margine (Edge Certificates)
Deși la interior folosim portul 80 pentru stabilitate, vizitatorul beneficiază de criptare totală prin Cloudflare:
Edge SSL: Cloudflare gestionează certificatul SSL la „margine”.
HTTPS: Vizitatorul vede lăcățelul verde, traficul fiind securizat până la serverul nostru local prin tunel.
