Îți stăm la dispoziție de Luni până Vineri în intervalul orar 09:00 - 18:00.
Îți stăm la dispoziție de Luni până Vineri în intervalul orar 09:00 - 18:00.
Societate: NAMEBOX SRL
Informații fiscale: RO29508628, J2012000006061
Birou: Frunzișului 91C, Cluj Napoca
ING Bank România
RO32INGB0000999902838749
Eroarea MariaDB106 cPanel poate aparea pe serverele VPS cu AlmaLinux 8 atunci cand cPanel incearca sa acceseze un repository MariaDB 10.6 care foloseste o adresa veche sau indisponibila. Desi eroarea poate fi afisata in MultiPHP Manager, cauza nu este neaparat PHP.
Am intalnit recent aceasta problema pe un VPS cPanel administrat de NameBox. La incercarea de a schimba versiunea unui domeniu de la PHP 8.4 la PHP 8.3, cPanel returna o eroare Python/DNF si refuza efectuarea modificarii. PHP 8.3 era instalat corect, insa procesul era blocat de repository-ul MariaDB106.
In acest articol prezentam problema exact asa cum a aparut pe un server AlmaLinux 8.10 aflat in productie, comenzile folosite pentru diagnosticare si solutia aplicata. Procedura este utila si pentru alte operatiuni cPanel care esueaza deoarece DNF nu poate descarca metadata unui repository.
Problema a aparut in WHM, in MultiPHP Manager, atunci cand am incercat sa schimbam versiunea PHP de la 8.4 la 8.3. Mesajul cPanel continea urmatoarea eroare relevanta:
Failed to download metadata for repo 'MariaDB106': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
In acelasi mesaj putea fi observat si raspunsul HTTP 404 pentru:
https://archive.mariadb.org/mariadb-10.6/yum/centos/8/x86_64/repodata/repomd.xml
La prima vedere, situatia poate crea impresia ca exista o problema cu PHP 8.3 sau PHP-FPM. In realitate, cPanel incerca sa obtina informatii despre pachetul ea-php83-php-fpm, iar procesul de interogare a pachetelor se oprea din cauza repository-ului MariaDB.
cPanel foloseste propriile componente de management al pachetelor peste infrastructura RPM/DNF a sistemului de operare. Atunci cand MultiPHP Manager trebuie sa verifice disponibilitatea unui pachet EasyApache, cPanel Packman initializeaza DNF si incarca repository-urile active ale serverului.
Asta inseamna ca nu este suficient ca repository-ul EasyApache sa functioneze. Un alt repository activ, chiar daca aparent nu are legatura cu PHP, poate determina esecul intregii operatiuni.
In cazul nostru, repository-ul MariaDB106 era activ. Configuratia sa indica insa o locatie din arhiva MariaDB care nu mai furniza fisierul repomd.xml la adresa configurata.
DNF incerca sa descarce metadata, primea raspuns HTTP 404 si transmitea eroarea mai departe catre cPanel Packman. MultiPHP Manager nu mai putea finaliza verificarea necesara schimbarii versiunii PHP.
Acesta este motivul pentru care o eroare MariaDB106 cPanel poate fi afisata in timpul unei operatiuni care, aparent, nu are nicio legatura cu serverul de baze de date.
Inainte de modificarea unui repository este important sa verifici distributia si versiunea sistemului de operare. Pe serverul analizat am rulat:
cat /etc/redhat-release
Rezultatul a fost:
AlmaLinux release 8.10 (Cerulean Leopard)
Am verificat apoi repository-urile MariaDB cunoscute de DNF:
dnf repolist all | grep -i mariadb
Rezultatul confirma ca repository-ul era activ:
MariaDB106 MariaDB106 enabled
Pentru identificarea fisierului in care era definita adresa repository-ului am folosit:
grep -RniE 'MariaDB106|archive.mariadb.org|mariadb-10.6' /etc/yum.repos.d/
Comanda a identificat fisierul:
/etc/yum.repos.d/MariaDB106.repo
Configuratia problematica era:
baseurl = https://archive.mariadb.org/mariadb-10.6/yum/centos/8/x86_64
Observam astfel un detaliu important: serverul ruleaza AlmaLinux 8.10, iar configuratia MariaDB folosise o locatie veche pentru CentOS 8.
Fisierul repomd.xml face parte din metadata unui repository RPM. Prin intermediul acestei metadata, DNF poate afla ce pachete sunt disponibile, versiunile acestora, dependentele si celelalte informatii necesare managementului pachetelor.
Daca adresa configurata prin baseurl este invalida si fisierul repodata/repomd.xml nu poate fi descarcat, DNF considera ca repository-ul nu poate fi incarcat.
De aceea mesajul:
Cannot download repomd.xml: All mirrors were tried
nu indica o problema cu fisierul PHP pe care cPanel incearca sa il instaleze sau sa il verifice. Mesajul trebuie citit impreuna cu numele repository-ului mentionat anterior in eroare. In situatia noastra acesta era explicit MariaDB106.
cPanel recomanda frecvent rularea comenzii dnf makecache atunci cand Packman intampina probleme la accesarea repository-urilor. Este o verificare buna, dar nu reprezinta automat si solutia.
Am rulat initial:
dnf clean all
Comanda a eliminat cache-ul local DNF. Am continuat cu:
dnf makecache
Repository-urile Node.js, EasyApache 4, cPanel Addons si cPanel Plugins au fost accesate corect. Procesul s-a oprit insa din nou la MariaDB106:
Status code: 404 for https://archive.mariadb.org/mariadb-10.6/yum/centos/8/x86_64/repodata/repomd.xml
Acest test este foarte util pentru diagnostic. El confirma ca nu avem doar metadata locala corupta sau expirata.
dnf clean all sterge datele salvate local, dar nu modifica fisierele din /etc/yum.repos.d/. La urmatorul dnf makecache, serverul citeste acelasi baseurl si incearca din nou sa acceseze adresa defecta.
Inainte de orice modificare am creat o copie a fisierului original. Pe un VPS cPanel aflat in productie recomandam sa existe intotdeauna posibilitatea revenirii rapide la configuratia anterioara.
Backup-ul a fost realizat cu:
cp -a /etc/yum.repos.d/MariaDB106.repo /etc/yum.repos.d/MariaDB106.repo.bak
Am schimbat apoi vechea locatie din arhiva MariaDB cu repository-ul MariaDB 10.6 pentru RHEL 8 compatibil cu sistemul utilizat:
sed -i 's#https://archive.mariadb.org/mariadb-10.6/yum/centos/8/x86_64#https://rpm.mariadb.org/10.6/rhel/8/x86_64#' /etc/yum.repos.d/MariaDB106.repo
Adresa utilizata dupa modificare a devenit:
baseurl = https://rpm.mariadb.org/10.6/rhel/8/x86_64
Fisierul MariaDB106.repo de pe server continea dupa modificare:
[MariaDB106]
name = MariaDB106
baseurl = https://rpm.mariadb.org/10.6/rhel/8/x86_64
gpgkey=https://archive.mariadb.org/PublicKey
https://supplychain.mariadb.com/MariaDB-Server-GPG-KEY
gpgcheck=1Dupa actualizarea repository-ului am eliminat din nou cache-ul si am fortat reconstruirea metadata:
dnf clean all dnf makecache
De aceasta data procesul a putut continua fara eroarea HTTP 404 generata anterior de MariaDB106.
Faptul ca dnf makecache functioneaza este un semn bun, dar pe un server cPanel preferam sa verificam si componenta care a generat efectiv eroarea.
Am verificat mai intai pachetul PHP-FPM pentru PHP 8.3:
/usr/local/cpanel/bin/packman_get_info_json ea-php83-php-fpm
cPanel a returnat corect informatiile despre pachet:
"name": "ea-php83-php-fpm", "version": "8.3.33", "_state": "installed"
Verificarea a demonstrat doua lucruri importante: pachetul PHP 8.3 FPM era deja instalat, iar cPanel Packman reusea acum sa interogheze sistemul de pachete.
Am efectuat si o verificare generala:
/usr/local/cpanel/bin/packman_get_list_json installed >/dev/null && echo "cPanel packman OK"
Rezultatul final a fost:
cPanel packman OK
Dupa aceste verificari, schimbarea PHP 8.4 la PHP 8.3 din MultiPHP Manager putea fi efectuata normal.
Nu, nu in acest scenariu. Una dintre greselile pe care le poti face atunci cand vezi eroarea in MultiPHP Manager este sa incepi reinstalarea versiunilor PHP sau chiar modificarea instalarii MariaDB.
Pe serverul analizat, PHP 8.3 era instalat si actualizat. Pachetul ea-php83-php-fpm exista si era recunoscut corect imediat dupa repararea repository-ului.
Nici serviciul MariaDB nu trebuia reinstalat. Problema era configuratia sursei din care DNF incerca sa obtina informatii despre pachete, nu functionarea efectiva a serverului MariaDB.
Pe un VPS de productie, reinstalarea inutila a MariaDB poate transforma o problema relativ simpla de repository intr-o interventie cu risc asupra bazelor de date. Diagnosticul trebuie facut inainte de modificarea serviciilor critice.
Dezactivarea temporara a unui repository poate fi folosita pentru diagnostic sau pentru anumite operatiuni punctuale. De exemplu, DNF permite executarea unei comenzi cu un repository exclus temporar.
Totusi, nu recomandam dezactivarea permanenta a MariaDB106 doar pentru ca MultiPHP Manager sa nu mai afiseze eroarea.
Daca pachetele MariaDB instalate pe server depind de acel repository pentru actualizari, problema este doar mascata. Urmatoarea operatiune de mentenanta poate avea rezultate neasteptate sau serverul poate ramane fara actualizari pentru pachetele respective.
Solutia corecta este identificarea motivului pentru care repository-ul nu poate fi accesat si repararea configuratiei atunci cand exista o sursa valida pentru versiunea si distributia utilizata.
Pe serverele cPanel instalate de mai multi ani putem intalni repository-uri adaugate pentru MariaDB, Node.js, software de securitate sau alte componente. Unele pot ramane configurate chiar si dupa modificari majore ale sistemului.
Lista completa poate fi verificata cu:
dnf repolist all
Pentru verificarea efectiva a accesului la metadata recomandam:
dnf clean all dnf makecache
Daca operatiunea esueaza, trebuie urmarit numele repository-ului indicat in mesajul de eroare si URL-ul pentru care apare raspunsul HTTP 404, timeout sau alta eroare de conectare.
Nu presupune automat ca ultimul serviciu modificat este si cauza. Exact asta s-a intamplat in cazul prezentat: operatiunea era schimbarea versiunii PHP, dar componenta defecta era repository-ul MariaDB.
Repository-urile controleaza sursele din care serverul obtine pachete si actualizari. Din acest motiv, modificarile trebuie facute controlat, mai ales pe serverele care gazduiesc website-uri si baze de date in productie.
/etc/yum.repos.d/;dnf makecache dupa modificare;Pe un server de productie recomandam si existenta unui backup extern functional inaintea interventiilor majore. Un backup automat stocat separat de VPS este important nu doar pentru probleme de repository, ci si pentru upgrade-uri cPanel, MariaDB, PHP sau sistem de operare.
Da. Un repository DNF defect nu trebuie privit exclusiv ca o problema a MultiPHP Manager. Acelasi repository poate afecta alte operatiuni care au nevoie sa incarce informatiile despre pachetele instalate sau disponibile.
De aceea recomandam sa nu ignori mesajele Failed to download metadata for repo, chiar daca serviciile website-urilor continua momentan sa functioneze.
Pe un VPS cu cPanel, CloudLinux sau AlmaLinux exista mai multe componente care interactioneaza cu sistemul de pachete. EasyApache, versiunile PHP si diverse operatiuni de mentenanta pot depinde de functionarea corecta a DNF.
Un simplu test periodic cu dnf makecache poate evidentia din timp repository-uri care nu mai sunt accesibile.
Daca serverul este unmanaged, administratorul VPS-ului trebuie sa investigheze erorile de repository, dependentele si compatibilitatea pachetelor. cPanel ofera interfata de administrare, dar nu poate repara automat orice repository extern configurat pe sistem.
Situatia devine mai sensibila atunci cand serverul gazduieste zeci sau sute de website-uri. O modificare efectuata fara verificarea versiunilor instalate poate afecta PHP, serverul web sau serviciul de baze de date.
In infrastructurile administrate de NameBox verificam astfel de probleme direct la nivelul sistemului de operare. Serverele VPS cu management pot utiliza cPanel/WHM, stocare NVMe si tehnologii precum CloudLinux, LiteSpeed, MariaDB, Redis si Imunify360, iar interventiile de acest tip fac parte din administrarea tehnica a stack-ului de hosting.
Daca MultiPHP Manager, EasyApache sau o alta componenta cPanel returneaza Failed to download metadata for repo 'MariaDB106', verifica intai repository-ul indicat de DNF. Nu reinstala PHP sau MariaDB doar pentru ca eroarea a aparut in timpul unei operatiuni asupra PHP.
In cazul prezentat, cauza a fost un baseurl vechi pentru MariaDB 10.6. Dupa actualizarea configuratiei, reconstruirea cache-ului DNF si verificarea cPanel Packman, PHP 8.3 a fost identificat corect si MultiPHP Manager a revenit la functionarea normala.
Daca folosesti un VPS cPanel in productie, pastreaza configuratiile importante sub forma de backup si investigheaza intotdeauna repository-ul mentionat explicit in mesajul DNF. O eroare repomd.xml 404 este in primul rand o problema de acces la metadata repository-ului si trebuie remediata la sursa.