1 21/05/2026 9 min

Su Amazon Linux 2023 la strada più pulita per MariaDB è partire dai repository ufficiali e tenere sotto controllo due cose: quale versione stai installando e come esponi il servizio. In un ambiente cloud il problema non è solo “far partire il database”, ma evitare che un’installazione veloce diventi un servizio raggiungibile da dove non dovrebbe, con credenziali deboli o parametri di default non coerenti con il carico reale.

Qui trovi un percorso lineare: verifica del sistema, installazione, avvio, hardening minimo e controllo finale. I comandi sono pensati per Amazon Linux 2023 con dnf e systemd. Se stai lavorando su un’istanza già usata da altri servizi, considera il blast radius prima di toccare pacchetti, porte e policy di rete.

Verifica preliminare: versione, rete e spazio disco

Prima di installare il database, conviene controllare tre punti: sistema operativo, spazio disponibile e raggiungibilità della porta 3306 solo dove serve. Non è un passaggio cosmetico: molte installazioni falliscono o restano instabili per filesystem pieni, SELinux/policy di rete non allineate o per una porta aperta troppo presto.

Esegui questi controlli base:

cat /etc/os-release
uname -r
df -h /
ss -ltnp | grep 3306 || true

Su Amazon Linux 2023 ti aspetti una release coerente con AL2023 e nessun servizio in ascolto su 3306 prima dell’installazione. Se il disco di root è già molto pieno, fermati: MariaDB scrive log, file di socket e dati, quindi partire con meno del margine operativo minimo è un invito ai problemi.

Installazione di MariaDB con dnf

Su AL2023 il metodo più semplice è installare il pacchetto server dai repository disponibili. In genere il nome del pacchetto è mariadb105-server o una variante equivalente a seconda del repository abilitato. Il punto non è memorizzare il nome esatto, ma verificare cosa offre il sistema prima di dare per scontata la versione.

Elenca i pacchetti disponibili e poi installa il server:

sudo dnf list available 'mariadb*'
sudo dnf install -y mariadb105-server

Se il nome del pacchetto cambia nel tuo repository, usa l’output di dnf list available come fonte di verità. Evita di aggiungere repository terzi senza motivo: per un’installazione standard la priorità è restare sul canale supportato dal sistema, così riduci il rischio di dipendenze incoerenti o aggiornamenti che rompono il pacchetto nel tempo.

Una volta installato il server, controlla che i file principali siano presenti e che il servizio systemd esista:

rpm -qa | grep -i mariadb
systemctl status mariadb --no-pager

Se systemctl status mostra il servizio come non avviato è normale: l’installazione non sempre lo parte in automatico. L’importante è che il pacchetto sia installato correttamente e che il binario sia disponibile.

Avvio del servizio e abilitazione all’avvio

Il primo avvio serve a creare i file iniziali e ad attivare i percorsi standard del database. Su una macchina nuova, questa è la verifica che separa un’installazione corretta da una che sembra completa ma non ha ancora inizializzato l’istanza.

Avvia e abilita il servizio:

sudo systemctl enable --now mariadb
sudo systemctl status mariadb --no-pager

Se il servizio non parte, leggi subito i log di systemd e cerca errori di filesystem, permessi o conflitti di porta:

sudo journalctl -u mariadb -n 100 --no-pager

In un’istanza sana dovresti vedere lo stato active (running). Se invece compare un errore di inizializzazione, non forzare modifiche casuali: prima identifica il punto preciso, perché su MariaDB il problema può essere un file di dati corrotto, un permesso errato oppure una policy di sicurezza che blocca l’accesso a directory o socket.

Controllo della porta e accesso locale

Prima di aprire il database alla rete, verifica che ascolti correttamente in locale. Questo ti dice se il servizio è vivo senza mischiare il problema applicativo con quello di firewall o security group.

Testa l’ascolto e una connessione locale:

ss -ltnp | grep 3306
sudo mysql -uroot

Se il socket locale risponde e riesci a entrare nella shell SQL, il servizio base è funzionante. In molte installazioni nuove l’accesso root può usare autenticazione via socket o una configurazione iniziale che non richiede password immediata. Non dare per scontato il comportamento: controllalo nel tuo caso concreto con SELECT USER(), CURRENT_USER(); una volta dentro.

SELECT USER(), CURRENT_USER();
SHOW DATABASES;

Se mysql non si connette ma il servizio è attivo, il problema è più spesso lato socket, permessi o autenticazione iniziale che non lato database “rotto”.

Hardening minimo con mysql_secure_installation

Una volta che il motore risponde, fai subito la pulizia di base. Su un server esposto anche solo in parte alla rete, lasciare account anonimi, database di test o root troppo permissivo è un errore che si paga dopo, non durante l’installazione.

Esegui la procedura guidata:

sudo mysql_secure_installation

Le scelte tipiche sono queste: rimuovere utenti anonimi, disabilitare il login root da remoto, eliminare il database di test e ricaricare i privilegi. Se il prompt ti chiede una password root e non ne hai impostata una, verifica prima il metodo di autenticazione configurato. In MariaDB moderno, l’accesso amministrativo iniziale può dipendere dal plugin di autenticazione e non da una password classica.

Se preferisci una verifica manuale invece della procedura guidata, controlla la presenza di account e database inutili:

sudo mysql -uroot -e "SELECT User, Host, plugin FROM mysql.user; SHOW DATABASES;"

Qui il punto non è fare una pulizia aggressiva, ma ridurre la superficie esposta. Se il database serve solo a un’app locale, il root remoto non dovrebbe proprio esistere. Se invece devi amministrarlo da remoto, usa un account dedicato con privilegi mirati e accesso limitato per host o subnet.

Configurazione pratica: bind-address, rete e file di tuning

Il comportamento di default spesso basta per un test locale, ma in produzione conviene esplicitare almeno il binding e qualche parametro operativo. Il file da toccare dipende dal layout del pacchetto, ma su sistemi MariaDB classici trovi una configurazione in /etc/my.cnf o in /etc/my.cnf.d/.

Prima di modificare, fai sempre un backup dello snippet che stai per cambiare:

sudo cp /etc/my.cnf /etc/my.cnf.bak.$(date +%F-%H%M%S)

Se il file principale include directory aggiuntive, verifica i parametri effettivamente caricati con:

sudo my_print_defaults mysqld

Per limitare l’ascolto a un indirizzo specifico, imposta bind-address. Esempio:

[mysqld]
bind-address=127.0.0.1

Questa scelta è corretta se MariaDB serve solo applicazioni sulla stessa macchina. Se invece deve essere raggiungibile da un’app su un’altra istanza, sostituisci 127.0.0.1 con l’IP privato corretto e limita l’accesso via security group o firewall al solo segmento necessario. Aprire la porta 3306 su Internet è quasi sempre una cattiva idea.

Dopo ogni modifica alla configurazione, riavvia il servizio e verifica che il binding sia quello atteso:

sudo systemctl restart mariadb
ss -ltnp | grep 3306

Firewall e security group: aprire solo ciò che serve

Su Amazon Linux 2023 il controllo reale dell’esposizione al mondo esterno passa soprattutto da security group e, se usato, da un firewall locale. Anche se MariaDB ascolta correttamente, può restare invisibile se la rete blocca la porta. Oppure, al contrario, può essere raggiungibile troppo facilmente se il gruppo di sicurezza è largo.

Se usi firewalld, controlla se è attivo e apri solo l’origine prevista:

sudo systemctl status firewalld --no-pager
sudo firewall-cmd --list-all

Se devi aprire temporaneamente la porta in una rete interna, fallo in modo consapevole e reversibile. Esempio:

sudo firewall-cmd --add-port=3306/tcp
sudo firewall-cmd --runtime-to-permanent

La parte davvero importante, però, è il security group su AWS: consenti 3306 solo dagli IP o dai gruppi che devono parlare con il database. Se l’app gira in un’altra istanza EC2, preferisci riferimenti a security group anziché a singoli IP pubblici quando puoi, così eviti di rincorrere cambi di indirizzo inutili.

Primo test applicativo: database, utente e permessi

A installazione finita, il test vero non è “MariaDB parte”, ma “l’app riesce a leggere e scrivere con un utente dedicato”. Crea un database e un account separato per l’applicazione, evitando di usare root per i servizi normali.

Accedi come amministratore locale e crea risorse minime:

sudo mysql -uroot

Dentro la shell SQL:

CREATE DATABASE appdb;
CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'SostituisciConUnaPasswordForte';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX ON appdb.* TO 'appuser'@'localhost';
FLUSH PRIVILEGES;

La password nell’esempio è solo un segnaposto: va sostituita con un segreto gestito correttamente, idealmente fuori da documenti e shell history. Se l’accesso deve arrivare da un host remoto, cambia l’host dell’account da localhost all’IP o alla subnet consentita, ma solo se la rete è già strettamente filtrata.

Testa l’accesso con un comando non ambiguo:

mysql -uappuser -p -h 127.0.0.1 appdb -e "SELECT NOW();"

Se il test va a buon fine, hai confermato autenticazione, rete locale e permessi minimi. Se fallisce, distinguere subito tra errore di password, host non autorizzato e blocco di rete ti fa risparmiare tempo rispetto a un debug generico.

Log utili quando qualcosa non torna

Quando MariaDB non si comporta come previsto, i tre punti da guardare per primi sono stato del servizio, journal e configurazione effettiva. Non andare a tentativi sulla base di supposizioni.

Verifiche rapide:

sudo systemctl status mariadb --no-pager
sudo journalctl -u mariadb -n 100 --no-pager
sudo grep -R "^bind-address\|^skip-networking\|^port" /etc/my.cnf /etc/my.cnf.d/ 2>/dev/null

Se il servizio parte ma l’app non si connette, controlla anche il DNS interno, l’IP di destinazione e il security group della macchina applicativa. In un ambiente AWS la causa non è sempre nel database: spesso il blocco è nel percorso tra applicazione e istanza, non nel motore SQL.

Nota operativa su backup e ripristino

Installare MariaDB senza definire almeno una strategia minima di backup è un errore di progettazione, non un dettaglio. Anche un’istanza piccola merita un piano semplice: dump logico, conservazione fuori macchina e verifica del restore.

Un dump base si fa così:

mysqldump -u root -p --all-databases --single-transaction --routines --events > /root/all-databases.sql

Il file generato non va trattato come un semplice artefatto locale: va copiato in uno storage separato e protetto. Se contiene dati sensibili, considera cifratura e controllo accessi. Il punto chiave è testare il ripristino, perché un backup non verificato è solo una speranza ben formattata.

Checklist finale prima di consegnare il server

Prima di dichiarare l’installazione pronta, controlla questi punti in ordine:

  1. Il servizio è attivo con systemctl status mariadb e non mostra errori nel journal.
  2. La porta 3306 ascolta solo sull’indirizzo previsto con ss -ltnp | grep 3306.
  3. L’utente applicativo accede con privilegi minimi e non usa root.
  4. Security group e firewall consentono la porta solo dalle sorgenti necessarie.
  5. Esiste almeno un backup testabile e conservato fuori dall’istanza.

Se questi cinque punti sono coperti, l’installazione non è solo riuscita: è anche difendibile in produzione. Su un sistema Linux moderno come Amazon Linux 2023 il vero lavoro non è installare il pacchetto, ma costruire attorno al servizio un perimetro coerente, verificabile e facile da mantenere.

Assunzione: i comandi sono eseguiti su Amazon Linux 2023 con repository standard abilitati e accesso amministrativo via sudo.