1 08/04/2026 8 min

Prerequisiti e scelta dello stack

vTiger CRM su Ubuntu 22.04 funziona in modo lineare con uno stack LAMP classico: Apache, MariaDB e PHP 8.1. La parte critica non è tanto l’installazione del pacchetto, quanto l’allineamento delle estensioni PHP, dei permessi sul filesystem e della configurazione del virtual host. Se salti questi punti, il risultato tipico è una pagina bianca, errori di sessione o problemi nel wizard iniziale.

Assumo un server Ubuntu 22.04 aggiornato, accesso root o sudo, un dominio già puntato al server e una directory dedicata per l’applicazione. Se stai lavorando in produzione, fai prima uno snapshot o un backup del volume/dataset che ospiterà i file e il database.

Aggiornamento base del sistema

Prima di installare il resto, porta il sistema allo stato corrente. È il modo più semplice per evitare conflitti con dipendenze vecchie o repository incompleti.

sudo apt update
sudo apt -y upgrade
sudo reboot

Dopo il riavvio, verifica che il sistema sia online e che non ci siano errori evidenti nei servizi di base:

systemctl --failed
uptime

Se hai servizi falliti, non proseguire alla cieca: correggi prima il problema base, altrimenti ti porti dietro errori difficili da distinguere da quelli dell’applicazione.

Installazione di Apache, MariaDB e PHP 8.1

Installa il web server, il database e PHP con le estensioni più comuni richieste da vTiger. Su Ubuntu 22.04 PHP 8.1 è la scelta naturale; in alcune installazioni specifiche possono servire moduli aggiuntivi, ma questi coprono la base.

sudo apt -y install apache2 mariadb-server libapache2-mod-php php php-cli php-common php-mysql php-xml php-curl php-gd php-mbstring php-zip php-soap php-imap php-intl php-bcmath unzip wget

Abilita e avvia i servizi:

sudo systemctl enable --now apache2 mariadb

Controlla che siano attivi:

systemctl status apache2 --no-pager
systemctl status mariadb --no-pager

Se Apache non parte, spesso il problema è una porta già occupata o una configurazione errata di un virtual host. Se MariaDB non parte, guarda i log di sistema e il journal del servizio.

Hardening minimo di MariaDB

Prima di creare il database, esegui la procedura guidata di sicurezza di MariaDB. Non è un hardening completo, ma elimina i punti più grossi di esposizione iniziale.

sudo mysql_secure_installation

In genere conviene:

  • impostare una password per root del database se non è già protetta;
  • rimuovere gli utenti anonimi;
  • disabilitare il login remoto di root;
  • rimuovere il database di test;
  • ricaricare le tabelle dei privilegi.

Se il server è esposto su rete pubblica, valuta anche di limitare l’ascolto di MariaDB a localhost, salvo necessità specifiche. Verifica il bind in /etc/mysql/mariadb.conf.d/50-server.cnf.

Creazione del database e dell’utente

Crea un database dedicato e un utente con privilegi limitati. Evita di usare account amministrativi globali per l’applicazione.

sudo mysql -u root -p

Dentro la console MySQL/MariaDB:

CREATE DATABASE vtiger CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'vtigeruser'@'localhost' IDENTIFIED BY 'SostituisciConUnaPasswordLunga';
GRANT ALL PRIVILEGES ON vtiger.* TO 'vtigeruser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

La scelta di utf8mb4 evita problemi con caratteri speciali ed emoji nei dati testuali. Se più avanti il wizard di vTiger segnala incompatibilità di collation, controlla che il database sia stato creato esattamente con questi parametri.

Download di vTiger CRM

Scarica il pacchetto ufficiale dal sito del progetto o da una sorgente verificata. Evita archivi non controllati o mirror non affidabili.

cd /tmp
wget -O vtigercrm.zip https://sourceforge.net/projects/vtigercrm/files/vtiger%20CRM%208.2.0/Core%20Product/vtigercrm8.2.0.zip/download

Se la versione cambia, sostituisci l’URL con quello corretto della release che vuoi installare. Prima di estrarre, è buona pratica verificare dimensione e integrità se il progetto fornisce checksum.

Estrai i file in una directory del web server:

sudo mkdir -p /var/www/vtiger
sudo unzip vtigercrm.zip -d /var/www/vtiger

Se l’archivio crea una sottocartella annidata, sposta i file nell’root web desiderata. L’obiettivo è che il contenuto applicativo sia direttamente sotto /var/www/vtiger o in una path equivalente che poi userai nel virtual host.

Permessi corretti sui file

Apache deve poter leggere i file e scrivere dove vTiger lo richiede durante installazione e operatività. Il compromesso corretto è assegnare la proprietà ad Apache solo dove serve, non sull’intera macchina in modo indiscriminato.

sudo chown -R www-data:www-data /var/www/vtiger
sudo find /var/www/vtiger -type d -exec chmod 755 {} \
;
sudo find /var/www/vtiger -type f -exec chmod 644 {} \
;

Se il wizard o l’applicazione richiede directory scrivibili specifiche, limita i permessi solo a quelle. In molte installazioni vTiger necessita di scrittura su alcune cartelle di cache, upload e configurazione. Il principio è semplice: apri il minimo indispensabile, poi richiudi appena completata l’installazione se il flusso lo consente.

Configurazione del virtual host Apache

Crea un virtual host dedicato al dominio di vTiger. In questo modo separi il sito dalle altre applicazioni e rendi più semplice eventuale troubleshooting.

sudo nano /etc/apache2/sites-available/vtiger.conf

Contenuto di esempio:

<VirtualHost *:80>
    ServerName crm.example.com
    DocumentRoot /var/www/vtiger

    <Directory /var/www/vtiger>
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/vtiger_error.log
    CustomLog ${APACHE_LOG_DIR}/vtiger_access.log combined
</VirtualHost>

Abilita il sito e i moduli necessari:

sudo a2enmod rewrite headers
sudo a2ensite vtiger.conf
sudo a2dissite 000-default.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

Il test apache2ctl configtest deve restituire Syntax OK. Se fallisce, correggi prima di ricaricare. Gli errori qui sono quasi sempre sintassi del file o direttive non consentite nel contesto sbagliato.

Configurazione PHP per vTiger

vTiger è sensibile a diversi parametri PHP. Se il wizard segnala limiti di upload, timeout o problemi di memoria, conviene impostare valori adeguati prima di iniziare l’installazione.

Individua il file di configurazione attivo:

php --ini

Di solito su Ubuntu 22.04 con Apache il file rilevante è /etc/php/8.1/apache2/php.ini. Modifica almeno questi parametri:

sudo nano /etc/php/8.1/apache2/php.ini

Valori consigliati come base:

memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300
max_input_time = 300
date.timezone = Europe/Rome

Riavvia Apache per applicare le modifiche:

sudo systemctl restart apache2

Se usi PHP-FPM invece di mod_php, i file cambiano e devi agire sul pool FPM e sul relativo servizio. Qui assumo il modello più semplice con Apache e mod_php.

Installazione via browser

A questo punto apri il dominio nel browser: http://crm.example.com. Dovresti vedere il wizard di installazione di vTiger. Se compare una pagina bianca, controlla prima i log Apache e PHP prima di cambiare altro.

Nel wizard inserisci:

  • nome database: vtiger
  • utente database: vtigeruser
  • password database: quella impostata in precedenza
  • host database: localhost

Completa i campi amministrativi dell’applicazione e termina l’installazione. Se il wizard segnala prerequisiti mancanti, non ignorarli: in genere indica una estensione PHP non caricata o un permesso filesystem non corretto.

Abilitazione HTTPS con Let’s Encrypt

Per un CRM esposto su Internet, HTTPS non è opzionale. Dopo che il sito risponde correttamente in HTTP, attiva un certificato valido.

sudo apt -y install certbot python3-certbot-apache
sudo certbot --apache -d crm.example.com

Segui la procedura guidata e scegli il redirect verso HTTPS se il sito deve essere usato solo in modo cifrato. Al termine verifica che il certificato sia servito correttamente e che il rinnovo automatico sia attivo.

sudo certbot renew --dry-run

Se usi un reverse proxy o una CDN davanti ad Apache, la configurazione TLS va adattata al tuo schema reale. In quel caso il certificato potrebbe dover stare sull’edge e non direttamente sul server origin.

Verifiche finali

Non considerare conclusa l’installazione finché non hai verificato almeno questi punti: accesso web, login, scrittura sul database, caricamento file e funzionamento base dei cron job se previsti dalla tua versione.

Controlli rapidi utili:

curl -I http://crm.example.com
curl -Ik https://crm.example.com

Gli output attesi sono uno status 200 o un redirect coerente verso HTTPS, senza errori TLS o risposte 5xx. Se ottieni 403, il problema è quasi sempre nel virtual host o nei permessi. Se ottieni 500, guarda il log applicativo e quello di Apache.

Log da controllare:

sudo tail -n 100 /var/log/apache2/vtiger_error.log
sudo tail -n 100 /var/log/apache2/error.log
sudo journalctl -u apache2 -n 100 --no-pager

Se il database dà errori, verifica anche MariaDB:

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

Per un controllo funzionale, esegui login, crea un record di prova e carica un allegato piccolo. Se questi tre passaggi riescono, la base è sana.

Manutenzione e backup

Dopo l’installazione, pianifica subito backup di due componenti: file applicativi e database. Senza entrambi, il ripristino non è affidabile.

Per esempio, puoi salvare il database con mysqldump e i file con uno snapshot o un archivio del document root. Se hai storage dedicato, valuta un backup giornaliero e retention adeguata al tuo RPO.

Inoltre, monitora spazio disco, RAM e log. Un CRM tende a crescere in allegati e cronologia attività, quindi il collo di bottiglia più comune nel tempo è lo storage, non il web server.

Assunzione operativa: stack Ubuntu 22.04 con Apache, MariaDB locale e vTiger esposto su un singolo virtual host; se usi Nginx, PHP-FPM, SELinux o un pannello hosting, alcuni passaggi vanno adattati.