1 21/05/2026 11 min

Su AlmaLinux 8 e Rocky Linux 8 Centreon si installa bene, ma solo se si mette in ordine prima la base: repository esterni, PHP compatibile, MariaDB pronto, SELinux gestito senza scorciatoie e un server con risorse sufficienti. La parte che fa perdere più tempo non è il wizard web, è tutto quello che gli sta attorno.

Qui non ha senso partire dal browser e sperare che il resto si sistemi da solo. Centro del lavoro: preparare il sistema, installare i pacchetti richiesti, completare il setup via interfaccia web e chiudere con controlli minimi su servizi, database e code di polling. L’obiettivo è arrivare a una piattaforma funzionante, non a una demo che cade al primo reload.

Requisiti realistici prima di installare

Centreon non è pesante in modo assurdo, ma neppure leggero. Per un’installazione singola, senza grandi volumi di host e servizi, io partirei con almeno 4 vCPU, 8 GB di RAM e disco SSD con spazio libero vero, non solo nominale. Se prevedi decine o centinaia di host, alza subito la soglia: il collo di bottiglia arriva prima su database e polling che sul front-end.

Prima di toccare i pacchetti verifica che il sistema sia aggiornato e che l’orario sia corretto. Una piattaforma di monitoraggio con time skew è una fabbrica di falsi allarmi e ticket inutili.

Comandi base:

dnf -y update
systemctl enable --now chronyd
chronyc tracking

Se `chronyc tracking` mostra offset anomali o il servizio non parte, sistemalo prima di continuare. Un NTP sballato rompe certificati, schedulazioni e correlazione eventi.

Repository e pacchetti: la parte che va fatta con ordine

Su AlmaLinux 8 e Rocky Linux 8 conviene usare i repository ufficiali di Centreon per evitare dipendenze sparse e versioni incompatibili. La logica è semplice: prima si aggiunge il repository, poi si verifica che il sistema veda i pacchetti corretti, infine si installa il metapacchetto o i componenti necessari.

Prima di installare controlla quali release sono disponibili nel tuo contesto, perché i nomi dei pacchetti possono cambiare tra major release. Il punto non è memorizzare il nome esatto, ma verificare che il repository esponga i pacchetti attesi.

dnf install -y dnf-plugins-core
# aggiunta repository Centreon: usa il metodo ufficiale previsto per la tua release
# verifica che il repo sia visibile
dnf repolist | grep -i centreon
# ispeziona i pacchetti disponibili dnf list available | grep -i centreon

Se il repository non compare, non forzare installazioni da RPM casuali presi in giro. Prima verifica URL repository, firma del pacchetto e compatibilità con EL8. Il modo pulito per chiudere il gap è guardare il file repo in ` /etc/yum.repos.d/ ` e l’output di `dnf repolist -v`.

Scelta architetturale: tutto in uno o separato

Per un ambiente piccolo, l’installazione all-in-one è la strada più rapida: web, database, broker e polling sullo stesso nodo. È la scelta giusta se l’obiettivo è partire in fretta e tenere la complessità sotto controllo. Se invece hai già un’infrastruttura con database dedicato o vuoi isolare il polling, conviene separare almeno il motore SQL dal resto.

In pratica: se il sistema nasce per pochi siti e poche decine di servizi, non complicarti la vita. Se sai già che crescerà, separa da subito database e front-end. Il costo iniziale è leggermente più alto, ma eviti una migrazione traumatica dopo qualche mese.

Installazione base del nodo Centreon

Una volta sistemato il repository, installa i pacchetti richiesti dal ruolo che hai scelto. Il nome esatto del metapacchetto dipende dalla versione disponibile, quindi qui conta la verifica più che la memoria. L’idea è arrivare a servizi web e database attivi prima di aprire il wizard.

# esempio di verifica pacchetti prima dell'installazione dnf search centreon # installa i pacchetti del ruolo previsto dalla documentazione ufficiale della versione scelta
# esempio generico: web + core + broker + plugins dnf install -y \ centreon \ centreon-web \ centreon-engine \ centreon-broker

Se `dnf` segnala dipendenze mancanti, il problema di solito è uno tra questi: repository incompleto, versione EL8 non allineata, conflitto con moduli PHP o pacchetti già presenti da altre sorgenti. Non andare a colpi di `--allowerasing` senza capire cosa stai rimuovendo.

Verifica subito lo stato dei servizi installati:

systemctl status mariadb httpd php-fpm --no-pager
ss -ltnp | egrep ':(80|443|3306)\b'

Se uno dei demoni non esiste ancora, non è un errore: dipende dal pacchetto scelto. Se invece esiste ma non parte, guarda il journal con `journalctl -u nome-servizio -xe` e i log specifici sotto `/var/log/`.

Database: MariaDB prima del wizard, non dopo

Centreon usa MariaDB/MySQL in modo intensivo. La configurazione minima sensata è un database che accetti connessioni locali, con charset e collation coerenti. Se il database è già presente sul server, controlla che non ci siano residui di configurazioni vecchie o tuning aggressivo ereditato da altri servizi.

Controlli rapidi:

systemctl enable --now mariadb
mysql -uroot -p -e "SELECT VERSION();"
mysql -uroot -p -e "SHOW VARIABLES LIKE 'character_set_server'; SHOW VARIABLES LIKE 'collation_server';"

Se la connessione root fallisce, non insistere a caso. Su installazioni nuove può essere necessario usare la procedura di hardening iniziale del motore SQL o la password temporanea prevista dal pacchetto. Il punto è chiudere il gap leggendo il file di log di MariaDB, tipicamente in `/var/log/mysqld.log` o nel journal di systemd.

Per ambienti piccoli, lascia il database sullo stesso host solo se hai margine di risorse. Se il polling cresce, il database diventa il primo componente da separare. I sintomi sono query lente, code che si accumulano e interfaccia web che sembra “viva” ma risponde male.

PHP e web server: errori banali che bloccano tutto

La pagina bianca o il 500 iniziale quasi sempre dipendono da PHP, moduli mancanti o permessi sbagliati su cache e directory runtime. Su EL8 la combinazione tipica è `httpd` più `php-fpm`, con moduli coerenti alla versione richiesta dalla release di Centreon.

Verifica che PHP giri davvero nella versione attesa e che i moduli richiesti siano caricati:

php -v
php -m | egrep 'mysqli|pdo_mysql|intl|mbstring|xml|gd|curl'
systemctl status php-fpm httpd --no-pager

Se manca un modulo, installalo dal repository corretto, non da sorgenti miste. Se `php-fpm` è attivo ma `httpd` risponde 503 o 500, controlla socket, permessi e SELinux prima di cambiare configurazioni a caso.

Un controllo utile è aprire i log in parallelo mentre ricarichi il wizard:

tail -f /var/log/httpd/error_log /var/log/php-fpm/error.log

Se i log non esistono in quei percorsi, cerca i path effettivi con `systemctl cat httpd` e la configurazione del pool PHP. Non dare per scontato il layout, soprattutto se il sistema è stato toccato prima da altri admin o da automazioni parziali.

SELinux: tenerlo attivo senza sabotarsi

Disabilitare SELinux per comodità è una scorciatoia che poi si paga. Su un nodo Centreon è più utile capire quali avvisi blocchino davvero i servizi e applicare contesto o policy corrette. In molti casi basta sistemare i context su directory di cache, socket e file di runtime.

Prima verifica se SELinux sta davvero intervenendo:

getenforce
ausearch -m avc -ts recent | tail -n 20

Se trovi AVC coerenti con il problema, il fix pulito è con `restorecon` sui path corretti o con un boolean mirato, quando previsto dal componente. Se non hai ancora identificato il path, non creare regole custom alla cieca.

Esempio di correzione non distruttiva su directory con context errato:

restorecon -Rv /var/lib/centreon /var/log/centreon /var/cache/centreon

Se il problema persiste, il passo successivo è leggere l’AVC completo e capire quale processo sta tentando quale accesso. Questo è il punto in cui si passa da “funziona solo con permissive” a una configurazione sostenibile.

Wizard web di Centreon: cosa va compilato davvero

Quando apri il wizard, non compilare tutto d’istinto. Prima verifica che l’URL del server, il database e le credenziali siano coerenti con quello che hai preparato. Un errore di host, porta o charset si trasforma subito in una procedura che sembra bloccata ma in realtà sta solo fallendo su una connessione SQL.

Le informazioni chiave da avere pronte sono queste: host database, nome database, utente applicativo, password, percorso dei binari se richiesto e parametri del broker. Se stai lavorando su un’installazione separata, tieni a portata anche gli indirizzi IP dei componenti remoti.

Durante il wizard, se compare un errore di permessi o scrittura, non proseguire a tentativi. Ferma lì la procedura e verifica i path indicati dal messaggio, poi correggi ownership e context SELinux con criterio.

Permessi, ownership e directory runtime

Le installazioni falliscono spesso su dettagli banali: directory non scrivibili, file di configurazione generati con owner sbagliato, socket non accessibili dal processo giusto. Il controllo minimo è vedere chi deve scrivere cosa, non dare permessi larghi ovunque.

ls -ld /var/lib/centreon /var/log/centreon /var/cache/centreon
ls -l /etc/centreon

Se noti owner errati, correggi in modo mirato, poi verifica che il servizio riparta. Evita `chmod 777`: risolve un sintomo e crea un problema di sicurezza più grosso del precedente.

In ambienti con hardening serio, la verifica minima include anche i gruppi di servizio e l’utente con cui gira `php-fpm` o `httpd`. Un file leggibile dal web server ma non dal backend o viceversa produce errori intermittenti difficili da leggere senza log aperti.

Verifiche finali: non fermarti alla schermata verde

Il fatto che l’interfaccia si apra non basta. Dopo l’installazione fai almeno quattro controlli: login, connessione al database, stato dei servizi di polling e scrittura dei primi dati di monitoraggio. Se uno di questi manca, sei ancora a metà.

Controlli utili:

systemctl status centreon-engine centreon-broker --no-pager
journalctl -u centreon-engine -n 50 --no-pager
journalctl -u centreon-broker -n 50 --no-pager

Se il polling non parte, guarda i log del motore e del broker prima di mettere mano al database. Se il broker non scrive, spesso il problema è un path, un permesso o un mismatch di configurazione generato dal wizard.

Un segnale sano è vedere i servizi attivi senza restart continui e, lato web, nessun errore ricorrente nel log di Apache o PHP. Un segnale malato è un’interfaccia raggiungibile ma piena di dati mancanti o widget che non si popolano.

Tuning iniziale che vale davvero la pena fare

Nel primo giorno non serve ottimizzare tutto. Serve evitare colli di bottiglia evidenti. Le aree da guardare sono database, limiti file descriptor, spazio su disco e frequenza dei controlli. Se il polling cresce troppo in fretta, la latenza si vede prima nelle code che nella CPU.

Misure sensate dopo il go-live:

  • latenza media del polling;
  • tempo di apertura dashboard web;
  • numero di servizi in ritardo rispetto alla finestra prevista;
  • uso disco della partizione che ospita database e log;
  • errori PHP e codice HTTP 5xx.

Se vedi disco vicino al limite, intervieni subito con logrotate, pulizia controllata e spazio aggiuntivo. Un monitoraggio che si blocca per disco pieno è un classico: prima rallenta, poi smette di scrivere, poi i sintomi si confondono con il resto.

Quando separare i componenti

La separazione ha senso quando uno dei tre segnali compare in modo stabile: il database cresce, il polling introduce ritardi o il front-end risponde lentamente nelle ore di picco. In quel momento, tenere tutto su una sola macchina diventa una scelta di comodità, non di qualità operativa.

La migrazione più pulita è quella preparata prima: database esterno, polling dedicato e front-end su nodo separato. Se invece parti monolitico, documenta subito i path, i backup e la topologia, così la separazione futura non diventa archeologia.

Errori tipici e come leggerli senza perdere tempo

Alcuni errori ricorrenti si leggono bene già dai sintomi. Se la UI non carica e il web server è sano, guarda PHP e database. Se la UI carica ma i dati non arrivano, guarda broker ed engine. Se tutto sembra fermo, verifica prima DNS, certificato e stato del servizio HTTP.

Una traccia pratica è questa:

  1. `curl -I http://localhost/` o `curl -kI https://localhost/` per vedere status e redirect;
  2. `systemctl status` dei servizi principali;
  3. log applicativi negli ultimi 50 eventi;
  4. spazio disco con `df -h` e inode con `df -ih`;
  5. eventuali AVC SELinux con `ausearch`.

Con questi cinque controlli di solito capisci già se stai inseguendo un problema di configurazione, un errore di permessi o una dipendenza mancante. Il resto viene dopo.

Chiusura operativa

Installare Centreon su AlmaLinux 8 o Rocky Linux 8 non è complicato, ma richiede disciplina: repository corretti, stack coerente, SELinux gestito bene e verifica finale sui servizi reali, non solo sul browser. La differenza tra un’installazione pulita e una problematica sta quasi sempre nei primi controlli fatti con metodo.

Se il tuo obiettivo è un nodo affidabile, evita le scorciatoie: niente pacchetti pescati a mano, niente permessi larghi, niente disabilitazioni definitive “per provare”. Parti dalla base, verifica ogni layer e solo dopo passa al tuning.