1 13/10/2026 10 min

Su CentOS 8 la strada più pulita per PostgreSQL è installarlo dal repository ufficiale del progetto, non dai pacchetti del sistema. La differenza non è cosmetica: il repository di PostgreSQL ti dà versioni aggiornate, pacchetti coerenti e meno sorprese quando devi fare manutenzione o aggiornamenti di sicurezza. Qui sotto trovi una procedura lineare, pensata per un server Linux recente con systemd, adatta a un’installazione base ma già impostata in modo sensato per un ambiente reale.

Il punto da tenere fermo è semplice: prima verifichi il contesto, poi installi, poi controlli che il servizio sia davvero in ascolto, infine fai il primo hardening. Se salti questi passaggi e ti limiti a lanciare un dnf install, ottieni un database acceso ma non necessariamente pronto per essere esposto o usato in produzione.

1. Verifica preliminare del sistema

Prima di toccare i pacchetti, controlla che il nodo sia davvero CentOS 8 e che l’orologio di sistema sia corretto. PostgreSQL non perdona bene i sistemi fuori tempo: log, certificati e autenticazione possono diventare più difficili da leggere se la macchina ha una clock skew evidente.

Esegui questi controlli minimi:

cat /etc/centos-release
hostnamectl
timedatectl

Atteso: una release CentOS 8 riconoscibile, hostname coerente e sincronizzazione oraria attiva. Se timedatectl mostra System clock synchronized: no, sistemalo prima di andare avanti, soprattutto se il server dovrà parlare con altri nodi o usare autenticazione TLS.

2. Abilitare il repository ufficiale PostgreSQL

Il repository ufficiale di PostgreSQL per RHEL/CentOS è il punto di partenza corretto. Su CentOS 8 evita di affidarti al modulo AppStream se vuoi una versione specifica e prevedibile. Se ti serve una versione moderna, scegli il ramo che ti serve già ora, non quello “di default” lasciato dal sistema.

Per esempio, per PostgreSQL 16:

sudo dnf -y install https://download.postgresql.org/pub/repos/yum/reporpms/EL-8-x86_64/pgdg-redhat-repo-latest.noarch.rpm

Subito dopo disabilita il modulo PostgreSQL del sistema, altrimenti rischi conflitti tra pacchetti di origini diverse:

sudo dnf -qy module disable postgresql

Questo passaggio è importante perché CentOS 8 tende a proporti il modulo integrato, ma nella pratica il repository ufficiale del progetto è quello che vuoi usare se devi mantenere il controllo della versione e del ciclo di aggiornamento.

3. Installare server e client

A questo punto installa il pacchetto server e, se prevedi accessi amministrativi locali, anche il client. Per una macchina database vera e propria il pacchetto server basta; il client è utile per i test e per le operazioni di routine.

sudo dnf -y install postgresql16-server postgresql16

Se vuoi verificare subito cosa è stato installato:

rpm -qa | grep -E '^postgresql16'

Atteso: pacchetti come postgresql16-server, postgresql16 e dipendenze correlate. Se compare una versione diversa da quella scelta, fermati e controlla il repository abilitato prima di procedere.

4. Inizializzare il cluster dati

Installare il pacchetto non basta: PostgreSQL deve inizializzare il proprio cluster dati. Su CentOS 8 e derivati il percorso standard del data directory è sotto /var/lib/pgsql/16/data per la versione 16, ma il package ti crea la struttura solo dopo l’inizializzazione.

Avvia l’inizializzazione con:

sudo /usr/pgsql-16/bin/postgresql-16-setup initdb

Se preferisci controllare a mano il contenuto creato, osserva la directory dati:

sudo ls -la /var/lib/pgsql/16/data

Atteso: file come PG_VERSION, postgresql.conf, pg_hba.conf e le directory interne del cluster. Se la directory è vuota o il comando fallisce, guarda subito il journal del servizio o l’output della shell: in genere il problema è un permesso errato, uno spazio disco insufficiente o un filesystem non montato come previsto.

5. Avviare e abilitare il servizio systemd

Una volta creato il cluster, puoi avviare il servizio e abilitarlo al boot. Qui entra in gioco systemd, quindi conviene verificare lo stato subito dopo l’avvio e non dare per scontato che tutto sia andato a buon fine.

sudo systemctl enable --now postgresql-16
sudo systemctl status postgresql-16 --no-pager

Atteso: stato active (running). Se il servizio risulta failed, il primo posto dove guardare è il journal:

sudo journalctl -u postgresql-16 -b --no-pager

Qui trovi di solito il motivo reale del blocco: directory non inizializzata, permessi sbagliati, porta già occupata o configurazione corrotta. Non partire subito con modifiche a caso: prima leggi il messaggio che il servizio sta già scrivendo.

6. Verificare che il server ascolti sulla porta corretta

Il servizio attivo non significa automaticamente che il database sia raggiungibile dall’esterno. Devi controllare la porta di ascolto e, se necessario, la policy del firewall. La porta predefinita è la 5432.

sudo ss -lntp | grep 5432

Atteso: una riga con LISTEN su 127.0.0.1:5432 o 0.0.0.0:5432, a seconda della configurazione. Se vedi solo loopback, il server accetta connessioni locali ma non remote. Se non compare nulla, il demone non ha aperto la porta e devi tornare al journal.

7. Primo accesso locale con l’utente postgres

L’utente amministrativo iniziale su PostgreSQL è quello di sistema postgres. Accedi localmente per verificare che il motore risponda e che il client funzioni senza dipendere da configurazioni esterne.

sudo -iu postgres psql

Se il prompt cambia in postgres=#, il collegamento locale è valido. A questo punto puoi verificare la versione e lo stato del server con query semplici:

SELECT version();
SELECT current_user;
\l

Questa verifica è utile anche per capire se stai davvero usando il binario corretto e non un client vecchio rimasto nel PATH. In ambienti misti è un errore più comune di quanto sembri.

8. Impostare una password amministrativa e il minimo hardening

Di base, l’accesso locale su molte installazioni iniziali è gestito tramite ident o peer authentication. Va bene per il bootstrap, ma non è il punto di arrivo se prevedi accessi remoti o operazioni amministrative da postazioni diverse. Il primo passo pratico è impostare una password robusta per l’utente postgres nel database e poi decidere con precisione chi può collegarsi.

Dentro psql:

ALTER USER postgres WITH PASSWORD 'una_password_forte';

Questa è una modifica sensibile: non lasciare password in chiaro in script condivisi o repository. Se devi automatizzare, usa un secret manager o almeno un file protetto e fuori dal controllo versione. Il testo della password qui sopra è solo un esempio operativo da sostituire subito con un valore reale e gestito correttamente.

Per capire come è impostata l’autenticazione, apri il file /var/lib/pgsql/16/data/pg_hba.conf. È il punto decisivo per autorizzare o bloccare connessioni locali e remote. Un esempio minimale e prudente per iniziare è questo:

local all all peer
host all all 127.0.0.1/32 scram-sha-256
host all all ::1/128 scram-sha-256

Se devi aprire il database a una rete specifica, aggiungi una riga dedicata, non un’apertura larga. Esempio:

host all all 10.10.20.0/24 scram-sha-256

Dopo ogni modifica al file di autenticazione ricarica il servizio, non riavviarlo a occhi chiusi:

sudo systemctl reload postgresql-16

Il reload è meno invasivo e ti dice subito se la sintassi del file è accettata. Se hai dubbi sulla configurazione, il journal e i log di PostgreSQL ti diranno quale riga è problematica.

9. Aprire il firewall solo se serve

Su un server database non ha senso esporre la porta 5432 se il servizio è usato solo localmente. Se invece devi accettare connessioni da altre macchine, apri il firewall in modo mirato. Su CentOS 8 il firewall tipico è firewalld.

sudo firewall-cmd --permanent --add-service=postgresql
sudo firewall-cmd --reload
sudo firewall-cmd --list-services

Atteso: il servizio postgresql compare nell’elenco. Se vuoi una regola più stretta, puoi aprire la porta solo verso una zona o usare regole dirette, ma per un caso standard questa è la via semplice e leggibile. Se non devi esporre nulla, non aggiungere questa eccezione: lasciando il firewall chiuso riduci la superficie d’attacco senza perdere funzionalità locale.

10. Test di connessione remota

Se hai deciso di abilitare accessi da rete, prova subito da un client autorizzato. Non aspettare di scoprire il problema quando l’applicazione prova a collegarsi in produzione.

psql -h IP_DEL_SERVER -U postgres -d postgres

Atteso: richiesta di password, poi prompt psql. Se ricevi connection refused, il problema è quasi sempre tra ascolto, firewall o listen_addresses. Se ricevi no pg_hba.conf entry, la rete arriva al server ma la policy di autenticazione non autorizza quell’IP o quell’utente.

Per capire se il database ascolta su tutte le interfacce, controlla il parametro:

sudo -iu postgres psql -c "SHOW listen_addresses;"

Se il valore è localhost, le connessioni remote non passeranno. In tal caso modifica /var/lib/pgsql/16/data/postgresql.conf con attenzione:

listen_addresses = '*'

Questa impostazione va usata solo se hai già definito chi può entrare in pg_hba.conf e, idealmente, se il firewall limita davvero i sorgenti. Aprire l’ascolto senza controllare l’autenticazione è una scorciatoia che non conviene.

11. Creare un database e un utente applicativo

Per un’installazione utile a un’applicazione, non usare sempre l’account superuser. Crea un utente dedicato e un database dedicato, poi concedi solo i privilegi necessari. È una regola semplice che evita di trasformare ogni problema applicativo in un rischio amministrativo.

sudo -iu postgres psql
CREATE USER appuser WITH PASSWORD 'password_specifica_e_forte';
CREATE DATABASE appdb OWNER appuser;
GRANT ALL PRIVILEGES ON DATABASE appdb TO appuser;

Se vuoi un controllo più fine, non concedere ALL PRIVILEGES oltre il necessario e limita il ruolo alle sole operazioni richieste dall’applicazione. La scelta giusta dipende dal software che dovrà usare il database, non da una formula rigida valida per tutti i casi.

12. Dove leggere i log quando qualcosa non torna

Quando PostgreSQL non parte o rifiuta connessioni, i log sono più utili di qualsiasi tentativo cieco. Su CentOS 8, con installazione da repository ufficiale, il journal systemd è il primo posto da controllare; in parallelo puoi cercare il file di log specifico sotto la directory dati o nelle impostazioni del cluster.

sudo journalctl -u postgresql-16 -b --no-pager
sudo ls -la /var/lib/pgsql/16/data/log

Se hai abilitato la raccolta su file, verifica anche che il proprietario e i permessi siano coerenti con l’utente di sistema postgres. Un errore banale di ownership può bloccare la scrittura dei log o l’accesso al data directory. In quel caso il sintomo tipico è un servizio che prova a partire e poi termina quasi subito.

13. Verifica finale operativa

Una installazione fatta bene non si limita a “servizio attivo”. Deve superare almeno questi controlli: servizio in esecuzione, porta in ascolto, accesso locale funzionante, autenticazione coerente, e connessione remota solo se prevista.

systemctl is-active postgresql-16
ss -lntp | grep 5432
sudo -iu postgres psql -c "SELECT 1;"

Se tutti e tre i controlli passano, il server è pronto per lo step successivo: tuning, backup, replica o integrazione con l’applicazione. Se uno fallisce, non andare avanti con altre modifiche finché non hai chiuso il problema di base. In particolare, non ha senso ottimizzare parametri di performance su un’istanza che non si connette in modo affidabile.

14. Note pratiche su backup e manutenzione

Appena il database è online, pensa già al backup. Non è un extra, è parte dell’installazione corretta. Anche se qui non entriamo nel dettaglio di pg_basebackup o delle strategie WAL, il minimo sindacale è avere un piano di esportazione e un test di restore. Un PostgreSQL installato ma non recuperabile non è un servizio completo.

Allo stesso modo, la manutenzione deve prevedere aggiornamenti periodici del sistema e del ramo PostgreSQL scelto. Il vantaggio del repository ufficiale è proprio questo: hai un percorso chiaro per ricevere patch e versioni di sicurezza, senza dover inseguire pacchetti vecchi o compatibilità improvvisate.

Se vuoi tenere l’installazione pulita nel tempo, documenta subito: versione installata, percorso del data directory, file modificati, porte aperte, regole pg_hba.conf e credenziali applicative create. Sono dettagli banali solo finché non devi ricostruire il server dopo mesi.

15. Comandi essenziali da ricordare

Se devi riprendere in mano il server dopo un po’, questi sono i comandi che conviene avere pronti:

sudo systemctl status postgresql-16 --no-pager
sudo journalctl -u postgresql-16 -b --no-pager
sudo -iu postgres psql
sudo -iu postgres psql -c "SELECT version();"
ss -lntp | grep 5432

Con questi controlli copri il 90% dei casi reali: servizio fermo, cluster non inizializzato, porta chiusa, autenticazione sbagliata o ascolto limitato al loopback. Il resto, di solito, è configurazione applicativa o tuning specifico del carico.

Una volta completata l’installazione, il passo successivo sensato non è aggiungere funzioni a caso, ma consolidare tre aree: backup, monitoraggio e accesso sicuro. È lì che un’installazione “funzionante” diventa davvero gestibile.