DirectAdmin 1.695 Breaking Change: Unificarea private_html cu public_html și ce înseamnă asta pentru site-urile tale

DirectAdmin 1.695, lansat pe 18 februarie 2026, modifică toate șabloanele de configurare ale serverului web pentru a folosi public_html ca document root pentru fiecare virtual host. Înainte de acest release, conexiunile HTTPS erau servite din private_html. Dacă serverul tău încă are domenii cu un director private_html separat în loc de un symlink către public_html, acele site-uri se vor strica după update. Rezolvarea este simplă, dar trebuie să acționezi înainte ca update-ul să ajungă pe serverul tău sau imediat după.

Acest articol explică ce s-a schimbat, de ce s-a întâmplat asta, care site-uri sunt afectate, cum să rulezi taskul de mentenanță integrat și cum să verifici totul manual din SSH.

Ce a schimbat de fapt DirectAdmin în 1.695

DirectAdmin livrează un set de șabloane de configurare pentru serverul web care generează fișierele efective de virtual host Apache, Nginx sau OpenLiteSpeed pentru fiecare domeniu de pe server. Înainte de versiunea 1.695, șabloanele cu TLS activat setau document rootul pe private_html. Șabloanele non-TLS indicau spre public_html. Asta însemna că HTTP și HTTPS puteau, din punct de vedere tehnic, să servească conținut diferit din directoare diferite.

În practică, aproape nimeni nu folosea această funcționalitate. Webul s-a mutat pe HTTPS-everywhere cu ani în urmă, iar servirea de conținut diferit pe HTTP față de HTTPS creează mai multe probleme decât rezolvă. DirectAdmin a recunoscut acest lucru încă din versiunea 1.649 (mai 2023), când a depreciat opțiunea pentru directorul private_html din skinul Evolution și a început să creeze domenii noi cu un symlink private_html -> public_html implicit.

Versiunea 1.695 finalizează treaba. Următoarele fișiere șablon referențiază acum public_html în loc de private_html:

• data/templates/nginx_server_secure.conf
• data/templates/nginx_server_secure_sub.conf
• data/templates/openlitespeed_vhost.conf
• data/templates/virtual_host2_secure.conf
• data/templates/virtual_host2_secure_sub.conf

După acest update, când un vizitator se conectează la site-ul tău prin HTTPS, serverul web caută în public_html. Dacă aveai un director private_html separat cu fișierele reale ale site-ului (nu un symlink), acele fișiere sunt acum inaccesibile. Vizitatorul primește o eroare 403 Forbidden sau vede o listă de directoare goală, în funcție de configurația ta.

Cine este afectat

Majoritatea serverelor nu sunt afectate. Începând cu DirectAdmin 1.52.0, domeniile noi au fost create cu private_html ca symlink care indică spre public_html în mod implicit. Dacă serverul tău a fost instalat în ultimii cinci-șase ani și nu ai creat niciodată manual directoare private_html separate, ești în siguranță.

Ești la risc dacă se aplică oricare dintre următoarele situații:

• Serverul tău a fost instalat inițial înainte de DirectAdmin 1.52.0 și domeniile nu au fost niciodată migrate la modelul cu symlink.
• Tu (sau un administrator anterior) ați setat default_private_html_link=0 în /usr/local/directadmin/conf/directadmin.conf la un moment dat.
• Ai migrat conturi de pe alt server sau alt panou de control, iar procesul de migrare a creat directoare private_html reale în loc de symlinkuri.
• Un utilizator a șters manual symlinkul și a creat un director prin skinul Enhanced sau prin SSH.

Din experiența noastră în administrarea serverelor DirectAdmin pentru clienții de web hosting, cel mai comun scenariu este cel al conturilor vechi (legacy) care au fost migrate între servere cu ani în urmă. Procesul de migrare a păstrat structura originală a directoarelor, și nimeni nu a observat, deoarece diferența dintre symlink și director a fost invizibilă pentru utilizatorul final până acum.

Cum să îți verifici serverul înainte de update

DirectAdmin oferă un task de mentenanță integrat special pentru această situație. A fost introdus în versiunea 1.649 și este accesibil la nivel de Admin în skinul Evolution.

Autentifică-te în DirectAdmin ca administrator. Navighează la Admin Tools > Maintenance Tasks. Caută taskul numit Ensure all domains private document roots link to public. Rulează-l. Taskul scanează fiecare cont de utilizator de pe server și raportează care domenii încă au un director private_html separat în loc de un symlink.

Dacă taskul raportează zero domenii afectate, poți face update la 1.695 fără griji. Dacă raportează domenii afectate, trebuie să rezolvi fiecare cont în parte înainte de update.

Rezolvarea domeniilor afectate

Rezolvarea depinde de faptul dacă directoarele private_html și public_html conțin aceleași fișiere sau fișiere diferite.

Scenariul 1: private_html are fișierele site-ului, public_html este gol sau învechit

Acesta este cel mai frecvent scenariu pe conturile legacy. Site-ul a fost instalat în private_html deoarece HTTPS era metoda principală de acces, iar public_html era fie gol, fie conținea fișiere învechite de la instalarea inițială. Rezolvarea este să muți fișierele din private_html în public_html, să ștergi directorul vechi și să creezi symlinkul.

Din SSH, logat ca root sau ca proprietar al domeniului:

cd /home/USERNAME/domains/DOMAIN.COM

# Fă un backup mai întâi
cp -a private_html private_html.bak

# Mută fișierele din private_html în public_html
rsync -av private_html/ public_html/

# Verifică dacă fișierele sunt în public_html
ls -la public_html/

# Șterge directorul vechi
rm -rf private_html

# Creează symlinkul
ln -s public_html private_html

# Verifică
ls -la private_html

Outputul ls -la ar trebui să arate private_html -> public_html. Dacă este așa, domeniul va servi același conținut atât prin HTTP, cât și prin HTTPS după update.

Scenariul 2: Ambele directoare conțin conținut diferit

Acest lucru este rar, dar posibil. Dacă cineva a servit în mod intenționat conținut diferit pe HTTP și HTTPS, trebuie să decizi ce versiune păstrezi. În aproape toate cazurile pe care le-am întâlnit, versiunea din private_html este cea de actualitate (deoarece majoritatea traficului este HTTPS), iar public_html este depășită.

Compară directoarele:

diff -rq /home/USERNAME/domains/DOMAIN.COM/public_html \
         /home/USERNAME/domains/DOMAIN.COM/private_html

Analizează diferențele. Fă backup la ambele directoare. Apoi urmează același proces de rsync, ștergere și creare de symlink din Scenariul 1, folosind ca sursă directorul care conține fișierele corecte.

Scenariul 3: Sute de domenii de reparat

Dacă administrezi un server de reseller cu multe conturi legacy, repararea domeniilor unul câte unul nu este practică. Iată un script care identifică toate directoarele private_html reale (nu symlinkuri) și le convertește automat. Rulează acest script ca root. Citește scriptul înainte de a-l executa. Fă backup mai întâi.

#!/bin/bash
# Găsește toate directoarele private_html care NU sunt symlinkuri
find /home/*/domains/*/private_html -maxdepth 0 -type d 2>/dev/null | while read dir; do
    domain_dir=$(dirname "$dir")
    public_dir="$domain_dir/public_html"
    private_dir="$domain_dir/private_html"

    echo "Procesez: $domain_dir"

    # Verifică dacă public_html există
    if [ ! -d "$public_dir" ]; then
        echo "  AVERTISMENT: Niciun public_html găsit, omit"
        continue
    fi

    # Sincronizează conținutul din private_html în public_html (păstrând fișierele existente în public_html)
    rsync -a "$private_dir/" "$public_dir/"

    # Redenumește private_html pentru backup
    mv "$private_dir" "${private_dir}.bak.$(date +%Y%m%d)"

    # Creează symlinkul
    ln -s public_html "$private_dir"

    echo "  FINALIZAT: Convertit în symlink"
done

După rularea scriptului, rulează din nou taskul de mentenanță DirectAdmin pentru a confirma că au rămas zero domenii afectate. Dacă ești un furnizor de găzduire reseller care administrează conturi de clienți, coordonează-te cu clienții tăi înainte de a șterge directoarele .bak pentru ca aceștia să poată verifica dacă site-urile lor funcționează corect.

A doua modificare pe care nu ar trebui să o ignori: Migrarea Secure Access Group

Release-ul DirectAdmin 1.695 include o altă modificare care primește mai puțină atenție, dar care poate cauza probleme de permisiuni pe serverele mai vechi. Update-ul activează automat opțiunea secure_access_group și forțează numele grupului la access.

Grupul de acces securizat face ca serviciile web, de email și FTP să împartă grupul UNIX access. Aceasta a fost setarea implicită pentru instalările noi încă de la DirectAdmin 1.33.3, lansat în aprilie 2009. Totuși, serverele anterioare acestei versiuni, sau serverele unde un administrator a schimbat numele grupului în altceva decât access, vor fi afectate.

Dacă serverul tău folosește un nume personalizat pentru grupul de acces securizat, update-ul 1.695 îl va redenumi în access. Acest lucru poate strica configurațiile de permisiuni pentru fișiere care referențiază numele vechi al grupului în ACL-uri, joburi cron sau scripturi personalizate. Verifică-ți configurația curentă înainte de a face update:

grep secure_access_group /usr/local/directadmin/conf/directadmin.conf

Dacă outputul arată secure_access_group=access sau opțiunea nu este prezentă (ceea ce înseamnă că setarea implicită este deja în vigoare), nu ai de ce să îți faci griji. Dacă arată un nume de grup diferit, auditează-ți sistemul pentru orice referințe la acel grup înainte de a permite instalarea update-ului.

Accesul API OPcache: O reparație silențioasă, dar utilă

Lansarea 1.695 actualizează, de asemenea, fișierul de configurare implicit OPcache (custombuild/configure/opcache/opcache.ini) pentru a nu mai bloca accesul la API-ul OPcache. În versiunile anterioare, configurația implicită seta opcache.restrict_api la o valoare care împiedica scripturile PHP să apeleze funcții OPcache precum opcache_reset() și opcache_get_status().

Acest lucru contează dacă folosești instrumente de deployment sau pluginuri WordPress care golesc OPcache-ul după modificări de cod. Înainte de această reparație, acele instrumente eșuau silențios sau aruncau erori în funcție de nivelul tău de raportare a erorilor din PHP. Dacă ai repornit manual PHP-FPM după deploymenturi deoarece OPcache nu se golea automat, acest update ar putea rezolva acea problemă de workflow. Pentru o înțelegere mai profundă a modului în care OPcache se integrează în strategia ta generală de caching, consultă ghidul nostru despre full page cache vs object cache vs opcode cache.

Checklist de verificare post-update

După actualizarea la DirectAdmin 1.695, parcurge aceste verificări pentru a confirma că nu s-a stricat nimic:

1. Verifică dacă symlinkurile sunt la locul lor. Rulează această comandă ca root pentru a găsi eventualele directoare private_html reale rămase:

find /home/*/domains/*/private_html -maxdepth 0 -type d 2>/dev/null | wc -l

Outputul ar trebui să fie 0. Orice număr mai mare de zero înseamnă că încă ai domenii care necesită atenție.

2. Testează HTTPS pe un eșantion de domenii. Folosește curl pentru a verifica dacă HTTPS returnează conținutul așteptat:

curl -sI https://domeniultau.ro | head -20

Caută un cod de status 200 OK. Un 403 Forbidden sau 404 Not Found pe un site care funcționa înainte de update indică probabil un director private_html care nu a fost migrat.

3. Verifică grupul de acces securizat. Verifică dacă grupul există și dacă procesele web sunt membre:

getent group access

4. Rescrie configurația serverului web. Dacă ai rezolvat probleme cu private_html abia după update, forțează DirectAdmin să regenereze toate configurațiile de virtual host:

echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue
echo "action=rewrite&value=nginx" >> /usr/local/directadmin/data/task.queue

Așteaptă câteva secunde ca task queue-ul să proceseze coada de așteptare, apoi verifică din nou site-urile.

5. Verifică reînnoirile Let's Encrypt. Un build anterior de 1.695 a avut o problemă în care calea challenge-ului HTTP .well-known eșua când era redirecționată către HTTPS. Un build ulterior a rezolvat acest lucru. Asigură-te că instanța ta DirectAdmin este pe cel mai recent build de 1.695 rulând /usr/local/directadmin/directadmin v și verificând data exactă a buildului.

De ce a făcut DirectAdmin această schimbare acum

Directorul private_html datează dintr-o perioadă în care certificatele SSL erau scumpe și majoritatea traficului era necriptat. Servirea de conținut diferit pe HTTP și HTTPS avea un caz de utilizare legitim (deși limitat). Acea eră s-a încheiat cu ani în urmă. Certificatele gratuite de la Let's Encrypt, avertismentele browserelor pe paginile non-HTTPS și factorii de ranking ai motoarelor de căutare au împins webul către TLS universal.

DirectAdmin a început deprecierea în versiunea 1.649 (mai 2023) prin eliminarea comutatorului private_html din skinul Evolution. Versiunea 1.650 a făcut din symlink opțiunea implicită pentru toate domeniile noi, indiferent de setarea default_private_html_link din directadmin.conf. Versiunea 1.695 finalizează procesul prin eliminarea completă a referințelor la private_html din șabloanele serverului web.

Echipa DirectAdmin a ales să nu execute o migrare forțată deoarece îmbinarea directoarelor cu conținut diferit ar putea cauza pierderi de date. În schimb, oferă taskul de mentenanță și lasă decizia privind momentul executării la latitudinea administratorilor de server. Aceasta este abordarea corectă pentru o modificare majoră (breaking change): documentează clar, oferă instrumentele necesare și lasă persoanele care cunosc serverul să ia decizia finală.

Ce trebuie să facă clienții ServerSpan

Dacă ești pe unul dintre planurile noastre de găzduire web, ne-am ocupat deja de acest lucru. Infrastructura noastră de găzduire partajată rulează DirectAdmin folosind modelul de symlink pentru toate conturile. Update-ul la 1.695 nu a stricat niciun site deoarece am migrat conturile legacy în timpul unui ciclu anterior de mentenanță.

Dacă ai un VPS cu DirectAdmin și îl administrezi singur, acest articol îți oferă tot ce ai nevoie pentru a-ți verifica și repara setupul. Dacă preferi să nu te bați la cap cu asta, serviciul nostru de administrare DirectAdmin acoperă exact acest tip de revizuire, audit pre-update, migrare și verificare.

Pentru conturile de reseller care administrează mai mulți clienți, acesta este genul de schimbare care separă furnizorii proactivi de cei reactivi. Rulează acum taskul de mentenanță, repară domeniile afectate și comunică schimbarea clienților tăi înainte ca aceștia să o descopere printr-un site căzut. Dacă ai nevoie de o platformă de hosting unde aceste update-uri ale panoului de control sunt gestionate pentru tine, aruncă o privire la pachetele noastre de găzduire reseller.

După ce rezolvi unificarea private_html, ia în considerare revizuirea întregului pipeline de livrare a site-ului tău. Îmbinarea unui setup DirectAdmin configurat corect cu Cloudflare poate elimina o întreagă clasă de probleme de performanță. Ghidul nostru despre cum să îți optimizezi planul Cloudflare gratuit detaliază setările care contează cel mai mult. Iar dacă pui în balanță DirectAdmin cu alte panouri pentru următorul tău server, comparația noastră DirectAdmin vs cPanel explică diferențele practice.