Installare phpMyAdmin su AlmaLinux 9 o 8 con Apache

Su AlmaLinux 8 e 9 phpMyAdmin non si “butta dentro” e basta: va trattato come un’applicazione web esposta su Apache, quindi con attenzione a repository, versione PHP, accesso amministrativo e hardening minimo. La strada più pulita è usare i pacchetti della distribuzione, tenere separato il virtual host, limitare l’accesso e verificare subito che il stack risponda con una configurazione coerente con la versione del sistema.

Prerequisiti che contano davvero

Prima di installare, verifica che Apache e PHP siano già presenti o che tu sia pronto a installarli insieme. Su AlmaLinux 9 la base è più moderna, su AlmaLinux 8 devi stare un po’ più attento alla combinazione tra modulo PHP e repository aggiuntivi. phpMyAdmin richiede un backend PHP funzionante e un database da amministrare, ma non deve mai essere considerato un componente “di default” da esporre pubblicamente senza controllo.

Se il server è già in produzione, considera il blast radius: tocchi web server, PHP, accesso a una console DB e potenzialmente il punto di ingresso per un pannello amministrativo. Il rollback deve essere semplice: rimuovere il virtual host dedicato, disabilitare l’alias o ripristinare la configurazione precedente da backup.

Le verifiche minime prima di partire sono queste:

• Apache risponde in locale con curl -I http://127.0.0.1/
• PHP è caricato in Apache con php -v e, se usi mod_php o php-fpm, il servizio corrisponde alla tua architettura
• Hai accesso root o sudo per installare pacchetti e scrivere in /etc/httpd/

Repository e pacchetti su AlmaLinux 8 e 9

phpMyAdmin spesso arriva da EPEL. Su AlmaLinux 9 la sequenza è lineare; su AlmaLinux 8 può essere necessario assicurarsi che EPEL sia abilitato e che il canale PHP usato sia quello previsto dalla tua distribuzione o da un repository compatibile. Non mescolare a caso sorgenti terze per PHP: il risultato tipico è un pannello che parte, ma con estensioni mancanti o incompatibilità silenziose.

Installa i repository e il pacchetto base così:

sudo dnf install -y epel-release
sudo dnf makecache
sudo dnf install -y httpd php php-cli php-common php-mysqlnd php-xml php-mbstring php-gd php-json php-zip php-curl phpMyAdmin

Se il pacchetto non viene trovato, il problema quasi sempre è uno di questi: repository non abilitato, metadati non aggiornati, oppure nome pacchetto diverso nella tua combinazione di release. In quel caso verifica con dnf search phpmyadmin e dnf repolist prima di inventarti workaround. Se usi una build minima o un server isolato, chiudi il gap controllando l’output di dnf list --available | grep -i phpmyadmin.

Installazione del pacchetto e primo controllo

Dopo l’installazione, il primo obiettivo non è aprire subito il browser: è verificare dove è finita la configurazione e se Apache la vede davvero. Su molte distribuzioni RHEL-like il file di configurazione di phpMyAdmin viene installato sotto /etc/httpd/conf.d/phpMyAdmin.conf. È lì che si decide chi può entrare, da dove e con quale percorso URL.

rpm -ql phpMyAdmin | grep -E 'conf|phpmyadmin|index'
sudo apachectl configtest
sudo systemctl enable --now httpd

Il comando apachectl configtest deve restituire Syntax OK. Se fallisce, non andare avanti: il problema è quasi sempre un file in /etc/httpd/conf.d/ o un alias duplicato. Se il servizio parte ma la pagina non si apre, guarda i log di Apache in /var/log/httpd/error_log e l’eventuale access log dedicato. Non serve procedere per tentativi ciechi quando il server ti sta già dicendo dove si rompe.

Accesso ad Apache: meglio limitare subito

La configurazione di default di phpMyAdmin può essere troppo permissiva per un server esposto. In un ambiente serio conviene restringere l’accesso a IP specifici, VPN o rete di amministrazione. Se il pannello resta raggiungibile da Internet senza restrizioni, hai già aumentato la superficie d’attacco più del necessario.

Apri il file di configurazione del pacchetto e controlla la sezione <Directory> o la regola di accesso associata. Il percorso esatto può variare leggermente, ma in genere è questo:

sudo cp -a /etc/httpd/conf.d/phpMyAdmin.conf /etc/httpd/conf.d/phpMyAdmin.conf.bak.$(date +%F)

Poi applica una restrizione chiara. Un esempio pratico è consentire solo una subnet di gestione:

Alias /phpmyadmin /usr/share/phpMyAdmin

<Directory /usr/share/phpMyAdmin/>
    AddDefaultCharset UTF-8
    Require ip 192.0.2.0/24
    Require ip 198.51.100.10
</Directory>

Se hai bisogno di accesso da più sedi, non allargare la rete “per comodità”: usa un reverse proxy autenticato, una VPN o una allowlist stretta. Il rollback è semplice: ripristini il backup del file e ricarichi Apache con sudo systemctl reload httpd. Il blast radius resta limitato al solo pannello.

Autenticazione e file di configurazione

phpMyAdmin può usare l’autenticazione standard verso MySQL/MariaDB, ma il punto delicato è come proteggi il login amministrativo. Evita di lasciare account DB con privilegi eccessivi, soprattutto se il pannello è accessibile da più operatori. Il principio corretto è: account separati, privilegi minimi, accesso tracciabile.

Il file principale di configurazione applicativa è in genere /etc/phpMyAdmin/config.inc.php o un percorso equivalente installato dal pacchetto. Se manca, spesso esiste un template come config.sample.inc.php da copiare e adattare. Non inserire segreti in chiaro più del necessario e, se devi usare una chiave di blowfish o simili, ruotala se sospetti che sia stata esposta.

sudo cp -a /etc/phpMyAdmin/config.inc.php /etc/phpMyAdmin/config.inc.php.bak.$(date +%F)

Una configurazione minima sensata include server locale, metodo di autenticazione cookie e una chiave segreta robusta generata in modo non interattivo. Esempio:

<?php
$cfg['blowfish_secret'] = 'INSERIRE_QUI_UNA_STRINGA_LUNGA_E_RANDOM_GENERATA_DA_TE';
$i = 1;
$cfg['Servers'][$i]['auth_type'] = 'cookie';
$cfg['Servers'][$i]['host'] = '127.0.0.1';
$cfg['Servers'][$i]['AllowNoPassword'] = false;
?>

Qui c’è un punto importante: non lasciare segreti in chiaro in un documento condiviso. Se devi distribuire questa configurazione, redigi il valore e genera la chiave localmente sul server con un comando dedicato o da un vault. Il gap si chiude con una generazione sicura e con permessi stretti sul file, ad esempio chmod 640 e owner coerente con il servizio web.

SELinux: il dettaglio che blocca tutto quando sembra già pronto

Su AlmaLinux SELinux è normalmente attivo. È uno dei motivi principali per cui phpMyAdmin installato correttamente continua a dare errori strani, pagine vuote o accessi negati senza motivi apparenti. Prima di disabilitarlo, osserva il log di audit e verifica se il blocco è davvero un problema di contesto o di policy.

sudo ausearch -m AVC,USER_AVC -ts recent
sudo journalctl -t setroubleshoot --since "1 hour ago"

Se il problema è di lettura file o accesso a directory, spesso basta correggere il contesto SELinux. Per esempio, se hai spostato file fuori dai percorsi standard, assegna il tipo corretto con semanage fcontext e restorecon. Non fare il classico errore di spegnere SELinux a livello globale: risolve il sintomo e lascia aperta una falla più ampia del necessario.

sudo semanage fcontext -a -t httpd_sys_content_t '/usr/share/phpMyAdmin(/.*)?'
sudo restorecon -Rv /usr/share/phpMyAdmin

Se invece phpMyAdmin deve parlare con un database locale su socket o rete, il contesto non è sempre la causa. In quel caso la verifica va fatta sui log di Apache e sul backend DB, non con ipotesi generiche. La metrica utile qui è il tasso di errori 403/500 e la presenza di AVC nel periodo del test.

PHP: estensioni minime e coerenza con la versione del sistema

phpMyAdmin senza estensioni PHP adeguate funziona male o in modo parziale. Le estensioni più comuni sono mysqli o mysqlnd, mbstring, xml, json, zip e curl. Se manca qualcosa, il pannello può aprirsi ma poi fallire in funzionalità specifiche, e questo è il tipo di guasto più fastidioso perché sembra un problema di login mentre è un problema di runtime.

php -m | egrep 'mysqli|mbstring|xml|json|zip|curl'
systemctl status php-fpm 2>/dev/null || true

Se usi php-fpm invece di mod_php, ricorda che Apache e PHP devono essere allineati. Un errore tipico è installare phpMyAdmin ma tenere un pool PHP inattivo o una socket non raggiungibile. In quel caso il browser mostra 502 o 503, ma il problema è nel backend PHP, non nel pannello in sé. La falsificazione rapida è semplice: curl -I http://127.0.0.1/phpmyadmin/ e lettura del log error di Apache e del servizio PHP.

Verifica end-to-end del pannello

Una volta completata l’installazione, fai una verifica completa dal layer HTTP fino al login. Non basta che la home del server risponda: devi sapere se il virtual host espone la directory giusta, se l’alias è corretto e se il backend DB è raggiungibile. La metrica obiettivo qui non è “si apre la pagina”, ma “risposta 200, asset caricati, login funzionante, nessun errore in log”.

curl -I http://127.0.0.1/phpmyadmin/
sudo tail -n 50 /var/log/httpd/error_log
sudo tail -n 50 /var/log/httpd/access_log

Se il test locale passa ma da remoto no, il problema è quasi sempre firewall, ACL Apache, SELinux o DNS del nome host. Se invece il pannello apre ma il login fallisce, controlla credenziali DB, socket, host del server e eventuali restrizioni di plugin o autenticazione. Non cambiare tre cose insieme: prima isola il layer, poi correggi.

Hardening minimo che vale la pena fare subito

phpMyAdmin è uno strumento amministrativo, non una pagina pubblica. Per questo conviene applicare almeno tre misure: limitazione rete, aggiornamenti regolari e logging leggibile. Se il pannello deve essere raggiungibile da fuori, aggiungi autenticazione aggiuntiva a livello Apache o reverse proxy. Se resta interno, mettilo dietro rete privata o VPN.

Un hardening sensato include anche queste misure:

1. Permessi stretti su /etc/phpMyAdmin/config.inc.php e niente segreti distribuiti in chiaro.
2. Accesso Apache limitato con Require ip o meccanismo equivalente.
3. Aggiornamenti del pacchetto tramite normale ciclo di manutenzione con verifica post-update di Apache e PHP.
4. Rotazione delle credenziali DB se il pannello è stato esposto oltre il previsto.

Se vuoi un controllo rapido della superficie esposta, verifica porte e virtual host attivi con ss -lntp e apachectl -S. Ti basta spesso per capire se hai pubblicato più del necessario o se il pannello è appeso al vhost sbagliato.

Problemi ricorrenti e lettura corretta dei sintomi

Pagina bianca: quasi sempre PHP, estensioni mancanti o errore runtime; guarda /var/log/httpd/error_log e il log PHP-FPM se presente. 403: access control o SELinux; controlla direttive Require e AVC. 404: alias o path errato; verifica apachectl -S e il file in conf.d. 500: configurazione rotta o dipendenza PHP non caricata. 502/503: backend PHP giù o socket errata. Questo è il tipo di diagnosi che fa risparmiare tempo perché evita di toccare il database quando il problema sta ancora davanti al web server.

Un errore che vedo spesso è trattare phpMyAdmin come una semplice directory statica. In realtà ha dipendenze applicative e di sicurezza molto più sensibili del normale contenuto web. Se il server è multi-tenant o ospita più siti, il pannello va isolato con più attenzione del resto dell’ambiente.

Manutenzione e rollback senza sorprese

Prima di ogni modifica, conserva una copia dei file toccati. Il rollback deve essere banale: ripristino del file, reload di Apache e verifica. Se hai cambiato pacchetti, conserva anche l’elenco installato con rpm -qa | grep -E 'phpMyAdmin|php|httpd' per capire cosa è stato introdotto. In ambienti con change control, questo è il minimo per non perdere tracciabilità.

sudo cp -a /etc/httpd/conf.d/phpMyAdmin.conf /root/phpMyAdmin.conf.rollback.$(date +%F)
sudo systemctl reload httpd
curl -I http://127.0.0.1/phpmyadmin/

Se il reload fallisce, torna subito al backup e controlla la sintassi. Se il reload va a buon fine ma il pannello non risponde, il problema è quasi certamente altrove: PHP, firewall, SELinux o il database. L’obiettivo non è “farlo sembrare risolto”, ma chiudere il circuito con una verifica oggettiva.

Assunzione operativa: il server è AlmaLinux 8 o 9 con Apache già previsto come web server, e phpMyAdmin deve essere accessibile in modo controllato, non pubblico.