NexTool Solutions

In GLPI, "configurare l'email" non è solo puntare a un server SMTP: è garantire che l'evento diventi messaggio, entri in coda e parta davvero. Nella manutenzione di ambienti dei clienti, la maggior parte dei casi di "GLPI ha smesso di inviare email" non ha nulla di sbagliato nell'SMTP: ciò che si è rotto è lo svuotamento della coda o il cron. Questa guida copre la configurazione completa e, soprattutto, i punti in cui la consegna fallisce sul serio.

Il modello mentale: evento, coda e invio

Una notifica attraversa tre fasi, e ognuna fallisce in modo diverso:

1. Evento - accade qualcosa (nuovo ticket, follow-up, risoluzione) e una Notifica associa l'evento a un Modello e ai destinatari.
2. Coda - il messaggio viene scritto nella tabella glpi_queuednotifications, non inviato subito.
3. Invio - l'azione automatica queuednotification, avviata dal cron, svuota la coda via SMTP.

Tenga a mente questa separazione: la maggior parte degli incidenti che gestiamo sta nella fase 3 (la coda si riempie e nessuno la svuota), non nella fase 1 (SMTP). Configurare un SMTP perfetto senza mettere in sicurezza il cron è la classica ricetta del "ho configurato tutto e non arriva niente".

Configurazione base dell'SMTP

In Configurazione > Notifiche > Configurazione dei follow-up via email (Setup > Notifications), abiliti i follow-up via email e compili:

• Modalità di invio: SMTP+TLS nella maggior parte dei casi - eviti il mail() di PHP in produzione.
• Server e porta: l'host del relay + 587 (STARTTLS) o 465 (SSL).
• Utente/password o OAuth: a seconda del provider.
• Email dell'amministratore e del mittente: un indirizzo che il relay è autorizzato a usare come mittente - questo dettaglio decide se l'email arriva o finisce in spam.

La password è memorizzata cifrata (GLPIKey) nella colonna smtp_passwd. Non la legga mai via SQL: esce mescolata e non aiuta la diagnosi. Per controllare il resto della configurazione direttamente nel database:

-- Diagnostica della configurazione di invio (non leggere mai smtp_passwd: è cifrato)
SELECT name, value
FROM glpi_configs
WHERE context = 'core'
  AND name IN ('smtp_mode','smtp_host','smtp_port','smtp_username',
               'smtp_check_certificate','admin_email','from_email',
               'notifications_mailing','use_notifications');

Se notifications_mailing restituisce 0, le notifiche via email sono disattivate a livello globale - nessuna impostazione SMTP conta finché non lo attiva.

Scegliere la modalità di invio

Questa è la matrice che usiamo per decidere la modalità per scenario:

Gmail e Microsoft 365 con OAuth 2.0

Gmail e Microsoft 365 hanno bloccato l'autenticazione di base (utente + password). Il percorso supportato è OAuth 2.0 (GLPI 10.0.7+). Presso il provider registra un'applicazione (Google Cloud Console o Azure App Registrations), genera un Client ID e un Client Secret, indica la redirect URI di GLPI e autorizza. In GLPI sceglie la modalità SMTP+OAuth, seleziona il provider e incolla le credenziali.

La trappola che consuma più tempo su Microsoft 365: anche con l'OAuth corretto, M365 disabilita SMTP AUTH per impostazione predefinita sulla casella. Senza abilitarlo, l'autenticazione passa e l'invio fallisce. Lo abiliti sulla casella usata:

# Microsoft 365: abilita SMTP AUTH sulla casella usata dall'OAuth (disabilitato per default)
Set-CASMailbox -Identity [email protected] -SmtpClientAuthenticationDisabled $false

Su Gmail/Workspace lo scope è https://mail.google.com/ e, sugli account Workspace, l'amministratore potrebbe dover autorizzare l'app. Gli account con 2FA accettano ancora una password per app come ripiego, ma Google sta ritirando questa strada.

La coda e il cron: dove si rompe davvero

Ecco il dettaglio che emerge solo in esercizio. L'azione automatica queuednotification può girare in due modalità: GLPI (avviata dall'accesso all'interfaccia) o CLI (tramite cron esterno). Su un'istanza a basso traffico - il cliente che usa GLPI solo in orario d'ufficio - la modalità GLPI fa sì che le notifiche notturne partano solo quando qualcuno apre il sistema al mattino. Il sintomo arriva come "email in ritardo" o "non arriva". La decisione che abbiamo standardizzato nella manutenzione: tutte le azioni automatiche in modalità CLI, con front/cron.php richiamato da un cron esterno ogni minuto.

# GLPI - svuota la coda di notifiche ogni minuto (utente del web server)
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

# In Docker: avvia il cron di GLPI come utente del web server (adatta nome/percorso)
* * * * * root docker exec -u www-data glpi php /var/www/glpi/front/cron.php >/dev/null 2>&1

Per vedere se la coda si svuota, guardi cosa è bloccato senza sent_time:

-- Notifiche bloccate in coda (coda piena = il cron non la sta svuotando)
SELECT id, itemtype, recipient, create_time, send_time, sent_time, sent_try
FROM glpi_queuednotifications
WHERE sent_time IS NULL
ORDER BY send_time ASC
LIMIT 20;

Una pila grande e crescente qui, con l'SMTP intatto, è quasi sempre cron fermo o in modalità GLPI. Può seguirla anche nell'interfaccia in Amministrazione > Coda delle notifiche.

Modelli e variabili

In Configurazione > Notifiche > Modelli di notifica modifica il corpo di ogni evento. Le variabili usano la sintassi ##...##:

<!-- Modello "Nuovo ticket" - corpo HTML con le variabili di GLPI -->
<p>Ciao ##ticket.author##,</p>
<p>Il tuo ticket <strong>##ticket.id##</strong> è stato registrato:</p>
<ul>
  <li>Titolo: ##ticket.title##</li>
  <li>Priorità: ##ticket.priority##</li>
  <li>Seguilo su: ##ticket.url##</li>
</ul>

Un modello può avere versioni per lingua; senza la versione della lingua del destinatario, GLPI usa quella predefinita. L'errore comune qui è modificare solo il corpo in portoghese e sorprendersi che il tecnico con profilo in inglese riceva il modello vecchio.

Trappole sul campo

I sintomi che vediamo di più e dove indagare per ciascuno:

Un avviso sull'ultimo caso: per impostazione predefinita GLPI non notifica l'autore della propria azione. Il tecnico che aggiorna il ticket non riceve l'eco del proprio aggiornamento - è comportamento atteso, non un bug. Confonderlo con "notifiche rotte" è già costato una nottata di diagnosi a inseguire un problema inesistente.

Oltre l'email

L'email è asincrona e compete per l'attenzione con la casella di posta. Perché il tecnico veda il ticket nell'istante in cui cambia, l'email non è il canale migliore. Valuti la notifica in tempo reale con il modulo Smart Notify (campanella nella barra) o l'invio via WhatsApp e Telegram per gli eventi che non possono attendere il prossimo ciclo di email.

Se l'email del Suo GLPI è intermittente - a volte arriva, a volte no - di solito è la coda e il cron, non l'SMTP. NexTool si occupa della manutenzione di GLPI con il monitoraggio della coda di notifiche e il cron sotto controllo. Ci parli di supporto e manutenzione di GLPI.

Revisionato dal team NexTool Solutions.