1 25/05/2026 11 min

Su Debian 11 Bullseye Cacti gira senza problemi, ma solo se chiudi bene i tre punti che di solito vengono trattati in fretta: database, PHP e raccolta dati. L’installazione “base” porta la web UI online; l’installazione fatta bene porta grafici affidabili, polling stabile e meno sorprese quando il server cresce.

Qui sotto trovi una procedura lineare per un’installazione con Apache, MariaDB e PHP su Debian 11. L’obiettivo non è solo aprire la pagina iniziale, ma arrivare a un’istanza utilizzabile in produzione, con configurazione pulita, permessi corretti e controlli finali che ti dicono subito se qualcosa è fuori posto.

Prima di iniziare: cosa serve davvero

Cacti non è pesante come stack, ma dipende da più pezzi che devono essere coerenti tra loro. Ti serve un host Debian 11 aggiornato, accesso root o sudo, un nome DNS risolto correttamente se esponi la UI, e almeno questi componenti: Apache, MariaDB, PHP con estensioni adeguate, RRDtool e un metodo di polling, preferibilmente Spine per gli ambienti con molti oggetti monitorati.

Se stai lavorando dietro reverse proxy, CDN o bilanciamento, la parte web cambia poco; quello che non cambia è la necessità di avere sessioni, URL e time zone ben impostati. Se il server è in produzione, considera il blast radius: un errore sul database o sui permessi può bloccare sia la UI sia la raccolta dati. Fai un backup prima di toccare il database o la configurazione applicativa.

Pacchetti da installare su Debian 11

Parti dai repository ufficiali e installa i pacchetti principali. Su Bullseye i nomi possono variare leggermente a seconda della versione disponibile nei repo, ma la base è questa:

sudo apt update
sudo apt install apache2 mariadb-server php libapache2-mod-php \ php-mysql php-xml php-ldap php-mbstring php-gd php-gmp php-zip \ php-snmp php-curl php-intl php-cli php-common php-pear \ snmp snmpd rrdtool git unzip

Se il pacchetto Cacti è disponibile nel tuo repository, puoi installarlo direttamente. In molti casi conviene comunque verificare la versione e la presenza delle dipendenze prima di procedere. Il comando sotto ti dice se il pacchetto esiste nel tuo ambiente:

apt-cache policy cacti

Se il pacchetto non è presente o è troppo vecchio per le tue esigenze, puoi installare Cacti dai sorgenti ufficiali, ma in questo articolo assumo il percorso più pulito e semplice: pacchetto Debian se disponibile, oppure tarball ufficiale in una directory dedicata. In entrambi i casi la logica di configurazione resta la stessa.

MariaDB: database dedicato e parametri minimi

Cacti usa il database in modo costante, non solo al primo accesso. La scelta più sensata è creare un database dedicato con utente dedicato e privilegi limitati. Non usare l’account root del DB per l’applicazione.

sudo mysql
CREATE DATABASE cacti DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'cactiuser'@'localhost' IDENTIFIED BY 'PASSWORD_FORTE_E_RUOTATA';
GRANT ALL PRIVILEGES ON cacti.* TO 'cactiuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Se il server ospita anche altro, controlla che MariaDB abbia parametri compatibili con il carico previsto. Cacti non richiede tuning estremo, ma beneficia di buffer adeguati e storage affidabile. Per un controllo rapido, verifica che il servizio sia attivo e che il socket sia raggiungibile:

systemctl status mariadb --no-pager
mysql -u cactiuser -p -e 'SHOW DATABASES;'

Se il login fallisce, non andare oltre: prima risolvi credenziali, host o permessi. Un errore qui si manifesta più tardi come pagina bianca, wizard bloccato o polling che scrive a metà. Il rollback, in caso di problema, è semplice: revoca l’utente e ricrea il database da backup o snapshot.

Installazione del pacchetto Cacti

Se il pacchetto è presente, installalo insieme alle dipendenze principali. Debian di solito si occupa di creare file iniziali, directory e integrazione con Apache. Dopo l’installazione, verifica dove il pacchetto ha posizionato i file di configurazione e l’eventuale schema SQL.

sudo apt install cacti

Durante il setup interattivo, quando richiesto, indica il database creato prima e l’utente dedicato. Se il pacchetto ti propone l’integrazione con il web server o il popolamento automatico del database, accettalo solo se hai già verificato che l’istanza MariaDB sia raggiungibile e che la password sia corretta. In caso di dubbio, fermati e controlla i log di installazione.

Se invece stai installando da sorgente, una collocazione tipica è /usr/share/cacti o una directory equivalente sotto /var/www. In quel caso devi importare manualmente lo schema nel database e configurare il file include/config.php o l’equivalente previsto dalla versione che hai scaricato.

Importazione dello schema e configurazione del database

Il punto che crea più confusione è l’import dello schema. Se il pacchetto non lo esegue automaticamente, devi individuare il file SQL corretto e importarlo nel database appena creato. Il percorso cambia in base al pacchetto o al tarball, quindi prima cerca il file invece di assumere il nome a memoria.

dpkg -L cacti | grep -E 'sql|schema|cacti.sql'

Se trovi un file come cacti.sql, puoi importarlo così:

mysql -u root -p cacti < /usr/share/doc/cacti/cacti.sql

Se il percorso è diverso, sostituiscilo con quello corretto. Dopo l’import, fai una verifica minima sulle tabelle:

mysql -u cactiuser -p -e 'USE cacti; SHOW TABLES;'

Ora passa alla configurazione applicativa. Il file più importante è quello che contiene i parametri del database. Nelle installazioni classiche è /etc/cacti/debian.php oppure un file equivalente sotto la directory dell’applicazione. Controlla che host, nome database, utente e password siano coerenti con i dati creati prima.

sudo grep -nE 'database|password|host' /etc/cacti/debian.php

Se il file non esiste, cerca la configurazione con find e non andare a intuito:

sudo find /etc /var/www /usr/share -name 'config.php' -o -name 'debian.php' 2>/dev/null

Per sicurezza, conserva una copia del file prima di modificarlo. È un cambio reversibile e ti evita di perdere il riferimento originale in caso di errore.

sudo cp /etc/cacti/debian.php /etc/cacti/debian.php.bak

Apache: virtual host e accesso alla UI

Con Apache la parte critica è semplice: il sito deve puntare alla directory corretta e PHP deve essere eseguito con il modulo giusto. Su Debian 11 la combinazione più lineare resta apache2 con libapache2-mod-php. Se preferisci PHP-FPM, va bene lo stesso, ma allora devi essere coerente dall’inizio e non mischiare moduli a caso.

Se il pacchetto ha già creato un file di configurazione Apache, controlla che sia abilitato:

sudo a2enconf cacti
sudo systemctl reload apache2

Se invece devi creare il virtual host, usa una configurazione essenziale e pulita. Un esempio minimo:

<VirtualHost *:80> ServerName cacti.example.com DocumentRoot /usr/share/cacti/site <Directory /usr/share/cacti/site> Options FollowSymLinks AllowOverride All Require all granted </Directory> ErrorLog ${APACHE_LOG_DIR}/cacti_error.log CustomLog ${APACHE_LOG_DIR}/cacti_access.log combined
</VirtualHost>

Dopo aver creato o modificato il vhost, verifica la sintassi prima del reload:

sudo apache2ctl configtest
sudo systemctl reload apache2

Se la pagina iniziale restituisce 403 o 404, il problema di solito è nel DocumentRoot o nei permessi della directory. Se ottieni un errore PHP, controlla i log di Apache e la versione PHP caricata dal web server.

PHP: estensioni, time zone e limiti pratici

Cacti è sensibile alle estensioni PHP mancanti. Le più comuni sono mysql, snmp, gd, curl, mbstring, xml e intl. Se il wizard mostra errori rossi su moduli assenti, non ignorarli: spesso la UI funziona comunque, ma poi fallisce su grafici, import template o polling.

Controlla il file /etc/php/7.4/apache2/php.ini o il percorso corrispondente alla tua installazione. Su Debian 11 la versione tipica è PHP 7.4. Imposta almeno la timezone e i limiti sensati per l’interfaccia:

sudo grep -nE 'date.timezone|memory_limit|max_execution_time' /etc/php/7.4/apache2/php.ini

Un set ragionevole per molte installazioni è questo:

date.timezone = Europe/Rome
memory_limit = 256M
max_execution_time = 60
upload_max_filesize = 20M
post_max_size = 20M

Dopo la modifica, ricarica Apache. Se usi PHP-FPM, ricarica il servizio relativo invece del modulo Apache. La verifica più semplice è aprire una pagina phpinfo() temporanea o controllare il pannello di Cacti e vedere se la sezione requisiti passa in verde.

Spine e polling: la parte che fa la differenza

Per pochi host il poller classico può bastare. Appena cresci un po’, Spine è la scelta più sensata perché riduce la latenza dei cicli di raccolta. Non è obbligatorio per partire, ma è il primo upgrade che farei dopo una installazione pulita.

Installa Spine se disponibile nei repository o dai pacchetti del progetto, poi verifica il binario e i permessi. In molti casi il servizio usa un utente dedicato, spesso cactiuser o un utente analogo definito dalla configurazione. Il binario deve essere eseguibile e la configurazione deve puntare ai percorsi giusti.

which spine
spine -v

Se il comando non esiste, continua pure con il poller standard, ma sappi che stai scegliendo la strada meno efficiente. Se invece Spine è installato, verifica il file di configurazione del poller dentro Cacti e imposta il percorso binario corretto. Dopo il cambio, controlla i log del poller per eventuali problemi di permessi o timeout.

SNMP e raccolta dati dai device

Cacti vive di SNMP. Se vuoi grafici affidabili, devi avere almeno una prova che il target risponda correttamente. Prima di aggiungere device nella UI, testa SNMP dal server Cacti verso un host reale.

snmpwalk -v2c -c COMMUNITY 192.0.2.10 sysDescr.0

Se non ottieni risposta, il problema non è Cacti. Può essere community errata, ACL sul device, firewall o versione SNMP non coerente. Risolvere quel punto prima evita di inseguire falsi problemi nel front-end.

Per installazioni nuove, preferisci SNMPv3 quando possibile. È più verboso da configurare, ma evita di lasciare community in chiaro in giro sulla rete. Se usi SNMPv2c per compatibilità, limita la portata con ACL e segmentazione di rete.

Wizard web: controlli che non vanno saltati

Apri la UI da browser e completa il wizard iniziale. Qui non devi correre: ogni schermata ti sta dicendo se la base è sana. Se il wizard segnala problemi, il punto giusto per intervenire è quello, non il grafico finale.

Controlla in ordine: connessione al database, directory scrivibili, estensioni PHP, RRDtool, SNMP e permessi dei file. Se il pacchetto ha creato directory con proprietario sbagliato, sistemale senza allargare i permessi più del necessario.

sudo chown -R www-data:www-data /usr/share/cacti/site
sudo chown -R www-data:www-data /var/lib/cacti

Attenzione a non applicare chmod 777 per comodità. È una scorciatoia che nasconde il problema e ti lascia una superficie d’attacco inutile. Se un path non è scrivibile, trova il gruppo corretto o la directory prevista dal pacchetto e usa quel modello.

Cron, poller e job periodici

La raccolta dati deve partire in modo regolare. Verifica che il cron o il timer del poller sia presente e attivo. Su installazioni Debian classiche spesso trovi un file in /etc/cron.d/ o una schedulazione equivalente prevista dal pacchetto.

ls -l /etc/cron.d/ | grep -i cacti
systemctl list-timers | grep -i cacti

Se il polling non parte, guarda i log del cron e quelli dell’applicazione. Un errore di permessi, un path errato al binario RRDtool o un database non raggiungibile si vede quasi sempre lì prima che nella UI.

Verifiche finali che ti evitano sorprese

Quando l’installazione sembra finita, fai una passata di controlli concreti. Non limitarti a “la home si apre”. Devi verificare che il sistema stia davvero raccogliendo dati e scrivendo grafici.

  • Apri http://cacti.example.com/ e verifica che la login page sia raggiungibile senza errori HTTP 5xx o redirect anomali.

  • Controlla che la dashboard mostri lo stato del poller e che non ci siano warning persistenti sui requisiti mancanti.

  • Verifica la scrittura dei file RRD nella directory prevista, ad esempio /var/lib/cacti/rra o quella configurata nel tuo ambiente.

  • Testa un device SNMP e controlla che compaia almeno un grafico con dati aggiornati.

  • Controlla i log di Apache e dell’applicazione per errori ricorrenti nelle ultime ore.

  • Un controllo rapido utile è questo:

    curl -I http://127.0.0.1/
    ls -lah /var/lib/cacti/rra
    journalctl -u apache2 --since '1 hour ago' | tail -n 50

    Se vuoi un criterio pratico di accettazione, considera OK solo quando la UI è accessibile, il poller non produce errori e almeno un device SNMP genera grafici con timestamp aggiornati. Se manca uno di questi tre segnali, l’installazione è incompleta.

    Problemi tipici e lettura veloce dei sintomi

    Pagina bianca: quasi sempre PHP, estensioni o errori nel file di configurazione. Controlla /var/log/apache2/error.log e l’eventuale log PHP-FPM. Errore di connessione al database: credenziali, socket o database non importato. Nessun grafico aggiornato: poller, cron, Spine o SNMP.

    Se il sistema parte ma i grafici restano vuoti, non fare subito refactor. Parti dalla catena minima: device raggiungibile, SNMP risponde, poller attivo, permessi corretti, file RRD scrivibili. È quasi sempre uno di questi passaggi, non un problema “misterioso” di Cacti.

    Chiusura operativa

    A questo punto hai un Cacti installato su Debian 11 Bullseye con una base solida: web server funzionante, database dedicato, PHP coerente e raccolta dati verificata. Il passo successivo, se l’istanza deve crescere, è passare a Spine, curare i template e standardizzare SNMP sui device da monitorare.

    Assunzioni: installazione su Debian 11 con Apache e MariaDB locali, accesso sudo disponibile, e uso di SNMP per il monitoraggio dei device.