Come installare OTRS su Ubuntu passo dopo passo

OTRS su Ubuntu: cosa serve prima di partire

OTRS è una piattaforma di ticketing che gira bene su Ubuntu, ma l’installazione va impostata con un minimo di ordine: web server, database, Perl, dipendenze, permessi e mail devono essere coerenti fin dall’inizio. Se salti un passaggio, il risultato tipico è una web UI che si apre ma non completa il setup, oppure errori Perl e problemi di connessione al database.

La procedura sotto è pensata per un’installazione classica su Ubuntu Server con Apache, MariaDB e OTRS in modalità standalone. Se usi Nginx, un database remoto o una versione specifica di OTRS/Ubuntu, alcuni dettagli cambiano, ma la logica resta la stessa.

Obiettivo: arrivare a una web UI funzionante, con database inizializzato, cron attivo, servizio OTRS operativo e accesso admin iniziale.

Prerequisiti e scelte architetturali

Prima di installare, chiarisci questi punti:

• Versione Ubuntu: idealmente una LTS supportata.
• Web server: Apache è la scelta più lineare per OTRS.
• Database: MariaDB o MySQL compatibile.
• Mail: SMTP locale o relay esterno per notifiche e ticket in ingresso.
• Hostname: deve essere corretto e risolvibile, meglio con FQDN dedicato.

Verifica subito i pacchetti base e l’identità del sistema:

lsb_release -a
hostname -f
ip a

Atteso: versione Ubuntu leggibile, FQDN valido e interfaccia di rete attiva. Se `hostname -f` fallisce, sistema prima DNS o `/etc/hosts`, perché OTRS e Apache possono ereditare comportamenti strani da un hostname incoerente.

Aggiornamento sistema e pacchetti base

Parti con un aggiornamento pulito del sistema e installa i pacchetti necessari. Su Ubuntu conviene sempre lavorare con repository aggiornati prima di aggiungere servizi applicativi.

sudo apt update
sudo apt -y upgrade
sudo apt -y install apache2 mariadb-server mariadb-client \
  perl libapache2-mod-perl2 \
  libdbd-mysql-perl libtimedate-perl libnet-dns-perl \
  libencode-hanextra-perl libtemplate-perl libyaml-perl \
  libdatetime-perl libmoo-perl libjson-xs-perl \
  unzip wget curl

Questi pacchetti coprono la base più comune. In alcune versioni di OTRS possono servire moduli Perl aggiuntivi; se l’installer li segnala mancanti, installali uno per uno invece di andare a tentativi.

Controlla subito lo stato dei servizi principali:

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

Atteso: entrambi attivi o almeno avviabili senza errori critici. Se MariaDB non parte, non procedere oltre: OTRS si appoggia molto alla fase di setup database.

Creare il database per OTRS

OTRS ha bisogno di un database dedicato e di un utente con privilegi limitati al solo schema applicativo. Non usare root per l’applicazione.

Entra in MariaDB e crea database, utente e permessi:

sudo mysql

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

Verifica che l’utente sia funzionante:

mysql -u otrs -p -h localhost otrs

Atteso: prompt del client MySQL/MariaDB senza errori di autenticazione. Se fallisce, controlla plugin di autenticazione, password e host associato all’utente.

Nota sicurezza: la password va gestita fuori dal testo operativo, idealmente in un password manager o in un file di provisioning protetto.

Scaricare e preparare OTRS

Il metodo più pulito è usare il pacchetto ufficiale della versione che vuoi installare. Prima di scaricare, verifica quale release è compatibile con la tua versione di Ubuntu e con i moduli Perl disponibili. Se installi una release vecchia su un sistema troppo nuovo, il problema più comune è la dipendenza Perl non soddisfatta.

In genere il flusso è questo: scarico, estraggo, sposto nella directory applicativa, assegno ownership corretta.

cd /tmp
wget https://otrs.example.org/path/to/otrs-package.tar.gz
sudo tar -xzf otrs-package.tar.gz -C /opt
sudo mv /opt/otrs-* /opt/otrs

Il link sopra è indicativo: usa il pacchetto reale della release scelta. Se hai un archivio `.rpm` o `.deb`, la procedura cambia. L’importante è che alla fine il codice stia in una directory stabile, ad esempio /opt/otrs.

Imposta il proprietario corretto:

sudo useradd -r -d /opt/otrs -s /bin/bash otrs 2>/dev/null || true
sudo chown -R otrs:otrs /opt/otrs

Atteso: il codice appartiene all’utente applicativo. Se lasci root come owner, il setup può funzionare ma poi gli aggiornamenti e i file temporanei diventano un problema.

Verificare le dipendenze Perl

OTRS è molto sensibile alle dipendenze Perl. Prima del setup vero e proprio, usa lo script di controllo integrato se presente nella distribuzione.

cd /opt/otrs
sudo -u otrs perl bin/otrs.CheckModules.pl

Atteso: elenco dei moduli con stato OK o, se mancano, nome preciso del modulo da installare. Questa è la fase in cui conviene chiudere i gap uno per uno. Se un modulo richiesto non è disponibile nei repo standard, valuta il pacchetto della release OTRS o la versione compatibile con Ubuntu.

Se il controllo segnala problemi, installa i moduli mancanti con apt quando disponibili:

sudo apt -y install nome-pacchetto-perl-mancante

Ripeti il controllo finché il quadro è pulito o almeno compatibile con la guida della tua release.

Configurare Apache per OTRS

Apache è la strada più semplice perché OTRS spesso fornisce configurazioni già pronte o quasi pronte. L’idea è pubblicare la web app in modo sicuro, con il minimo indispensabile esposto.

Abilita i moduli utili:

sudo a2enmod perl headers rewrite ssl

Se la distribuzione OTRS include un file di configurazione per Apache, copialo nella directory dei siti o dei conf di Apache secondo la struttura del pacchetto. In molte installazioni è necessario creare un VirtualHost dedicato su porta 80 o 443.

Esempio di struttura logica del virtual host:

<VirtualHost *:80>
  ServerName otrs.example.org
  DocumentRoot /opt/otrs/var/httpd/htdocs
  <Directory /opt/otrs/var/httpd/htdocs>
    AllowOverride None
    Require all granted
  </Directory>
</VirtualHost>

Il path esatto può cambiare in base alla versione. Se il pacchetto fornisce una directory diversa per il frontend, usa quella indicata dal vendor, non forzarne una a caso.

Dopo la modifica, valida la sintassi:

sudo apache2ctl configtest

Atteso: Syntax OK. Se non lo è, non riavviare Apache finché non hai corretto il file.

Creare la configurazione iniziale di OTRS

La parte più delicata è l’inizializzazione. Nella maggior parte dei casi OTRS mette a disposizione uno script di setup che legge i parametri del database e genera la configurazione iniziale.

Tipicamente il flusso è:

cd /opt/otrs
sudo -u otrs cp Kernel/Config.pm.dist Kernel/Config.pm 2>/dev/null || true
sudo -u otrs bin/otrs.SetPermissions.pl --otrs-user=otrs --web-group=www-data

Se la tua release usa un installer web, apri il browser e completa i campi richiesti: database, utente, password, host, nome istanza, mail. Se invece usa uno script CLI, segui l’output che ti chiede i dati del DB.

Le informazioni minime da avere pronte sono:

• Nome database: otrs
• Utente database: otrs
• Password database: quella definita prima
• Host database: localhost se locale
• FQDN pubblico o interno del servizio

Se il setup fallisce con errore di connessione al database, torna alla verifica MySQL/MariaDB; se fallisce con errore di permessi, controlla ownership e gruppo web.

Permessi e directory critiche

OTRS usa directory specifiche per cache, log, sessioni e file temporanei. Se i permessi sono sbagliati, la UI può aprirsi ma poi generare errori casuali.

Controlla le directory chiave:

ls -ld /opt/otrs /opt/otrs/var /opt/otrs/var/log /opt/otrs/var/tmp

Atteso: owner coerente con l’utente applicativo e gruppo che consenta ad Apache di leggere dove serve. In molte installazioni il gruppo web è www-data.

Se devi correggere i permessi, fallo in modo mirato:

sudo chown -R otrs:www-data /opt/otrs
sudo find /opt/otrs -type d -exec chmod 750 {} \;
sudo find /opt/otrs -type f -exec chmod 640 {} \;

Non applicare chmod aggressivi su tutta la tree senza capire la release: alcune directory devono essere eseguibili o scrivibili da componenti specifiche. Qui il riferimento resta la documentazione della tua versione.

Avvio dei servizi e test funzionali

Quando configurazione e permessi sono a posto, riavvia i servizi e testa la parte web.

sudo systemctl restart mariadb
sudo systemctl restart apache2
sudo systemctl status apache2 --no-pager
sudo systemctl status mariadb --no-pager

Apri il browser su http://otrs.example.org o sull’hostname scelto. Se tutto è corretto, dovresti vedere la pagina iniziale o il wizard di login/setup.

Test rapido da shell:

curl -I http://otrs.example.org

Atteso: risposta HTTP 200, 301 o 302 coerente con il flusso previsto. Se ricevi 500, guarda subito i log di Apache e di OTRS.

Log utili da controllare:

• /var/log/apache2/error.log
• /opt/otrs/var/log/otrs.log
• /var/log/mysql/error.log o journal di MariaDB

Per il journal:

journalctl -u apache2 -n 50 --no-pager
journalctl -u mariadb -n 50 --no-pager

Configurare cron e attività di manutenzione

OTRS dipende spesso da job periodici per code, notifiche, pulizia e processi interni. Se il cron non gira, il sistema può sembrare vivo ma degradare nel tempo.

Abilita la configurazione cron prevista dalla release. In molte installazioni esiste uno script o un file di esempio da copiare in /etc/cron.d/ o un servizio systemd timer.

Verifica i cron job presenti:

ls -l /etc/cron.d/
crontab -l -u otrs 2>/dev/null

Se il pacchetto prevede uno script per i cron, attivalo secondo la documentazione della versione. Dopo averlo fatto, monitora che i processi partano davvero e che non producano errori nei log.

Un controllo pratico è cercare eventi recenti nei log applicativi:

tail -n 50 /opt/otrs/var/log/otrs.log

Atteso: nessun errore ripetitivo sui job pianificati.

Mail, notifiche e ticket in ingresso

OTRS diventa utile davvero quando può inviare e ricevere mail. In questa fase puoi limitarti a configurare l’uscita SMTP e rimandare l’ingresso mail a un secondo momento, ma se vuoi un’installazione completa conviene farlo subito.

Controlla che il server abbia accesso al relay SMTP o al server MX previsto. Se usi un relay esterno, verifica connettività sulla porta giusta e autenticazione.

nc -vz smtp.example.org 587

Atteso: connessione aperta. Se la rete blocca la porta, il problema non è OTRS ma il routing o il firewall.

Per testare l’invio, usa un account di prova configurato nel pannello OTRS e verifica che i messaggi escano senza bounce. Se il sistema riceve mail in ingresso, configura un alias o una mailbox dedicata e controlla che il fetch funzioni come previsto.

Hardening minimo prima di andare in produzione

Una volta che OTRS funziona, fai il minimo indispensabile per non lasciarlo esposto in modo pigro.

• Usa HTTPS con certificato valido.
• Limita l’accesso amministrativo per IP o VPN se possibile.
• Non esporre il database su rete pubblica.
• Tieni separati utente applicativo e utente database.
• Verifica che i backup includano database e directory di configurazione.

Se abiliti HTTPS con Let’s Encrypt o certificato interno, controlla che il VirtualHost 443 sia coerente con il nome pubblico del servizio. Un mismatch tra certificato e FQDN genera errori al login e confusione lato utenti.

Backup e piano di rollback

Prima di considerare l’installazione chiusa, definisci un rollback semplice. Se qualcosa va storto dopo il setup, devi poter tornare indietro senza perdere dati.

Minimo sindacale:

• dump del database OTRS
• copia di /opt/otrs/Kernel/Config.pm e file di configurazione web
• snapshot VM se disponibile

Esempio dump:

mysqldump -u root -p otrs > otrs-backup.sql

Rollback tipico: stop servizi, ripristino database, ripristino file di configurazione, restart servizi, verifica web. Se non hai snapshot, il backup del DB e della configurazione è il minimo per evitare di rifare tutto da zero.

Verifica finale

Quando hai finito, controlla questi punti in sequenza:

1. systemctl status apache2 mariadb senza errori.
2. curl -I http://otrs.example.org con risposta coerente.
3. Login iniziale OTRS funzionante.
4. Creazione di un ticket di prova.
5. Invio email di test riuscito.
6. Log senza errori ripetuti in /opt/otrs/var/log/otrs.log e in Apache.

Se uno di questi punti fallisce, torna alla fase corrispondente: DNS e hostname, database, permessi, moduli Perl, virtual host o mail relay. La maggior parte dei problemi iniziali nasce da un’incoerenza tra questi componenti, non da OTRS in sé.

Assunzione: la release OTRS scelta è compatibile con la versione di Ubuntu e con i moduli Perl disponibili nei repository o nel pacchetto ufficiale.

Considerazioni operative dopo il go-live

Dopo l’installazione, il lavoro vero è la manutenzione: aggiornamenti, controllo log, backup e verifica delle code mail. Se il traffico cresce, monitora TTFB della web UI, uso CPU, I/O disco e saturazione del database. OTRS regge bene, ma diventa sensibile a storage lento e cron non eseguiti.

Se devi gestire più agenti o code, pianifica anche la governance: ruoli, SLA, notifiche, template email, policy di assegnazione. Questa parte non è tecnica pura, ma determina se l’installazione sarà usabile o solo “accesa”.