NexTool Solutions

In GLPI bedeutet „E-Mail konfigurieren“ nicht nur, auf einen SMTP-Server zu verweisen - es bedeutet sicherzustellen, dass aus einem Ereignis eine Nachricht wird, diese in die Warteschlange kommt und tatsächlich hinausgeht. Beim Betrieb von Kundenumgebungen ist in den meisten Fällen von „GLPI verschickt keine E-Mails mehr“ am SMTP nichts falsch: Kaputt ist die Abarbeitung der Warteschlange oder der Cron. Diese Anleitung deckt die vollständige Konfiguration ab und vor allem die Stellen, an denen die Zustellung wirklich scheitert.

Das mentale Modell: Ereignis, Warteschlange und Versand

Eine Benachrichtigung durchläuft drei Stufen, und jede scheitert auf andere Weise:

1. Ereignis - etwas passiert (neues Ticket, Folgeaktion, Lösung), und eine Benachrichtigung verknüpft dieses Ereignis mit einer Vorlage und den Empfängern.
2. Warteschlange - die Nachricht wird in der Tabelle glpi_queuednotifications gespeichert, nicht sofort versendet.
3. Versand - die automatische Aktion queuednotification, ausgelöst durch den Cron, arbeitet die Warteschlange per SMTP ab.

Merken Sie sich diese Trennung: Die meisten Vorfälle, die wir bearbeiten, liegen in Stufe 3 (die Warteschlange füllt sich, und niemand arbeitet sie ab), nicht in Stufe 1 (SMTP). Einen perfekten SMTP zu konfigurieren, ohne den Cron sicherzustellen, ist ein klassisches Rezept für „Ich habe alles eingerichtet, und nichts kommt an“.

Grundkonfiguration von SMTP

Aktivieren Sie unter Einstellungen > Benachrichtigungen > Konfiguration der E-Mail-Folgeaktionen (Setup > Notifications) die Folgeaktionen per E-Mail und füllen Sie aus:

• Versandmodus: in den meisten Fällen SMTP+TLS - vermeiden Sie mail() von PHP in Produktion.
• Server und Port: der Host des Relays + 587 (STARTTLS) oder 465 (SSL).
• Login/Passwort oder OAuth: je nach Anbieter.
• E-Mail-Adresse von Administrator und Absender: eine Adresse, als die ein Relay senden darf - dieses Detail entscheidet, ob eine E-Mail ankommt oder im Spam landet.

Ein Passwort wird verschlüsselt (GLPIKey) in der Spalte smtp_passwd gespeichert. Lesen Sie es nie per SQL aus: Es kommt verschlüsselt zurück und hilft bei der Diagnose nicht. Um die übrige Konfiguration direkt in der Datenbank zu prüfen:

-- Diagnóstico da configuração de envio (nunca leia smtp_passwd: vem cifrado)
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');

Wenn notifications_mailing den Wert 0 hat, sind E-Mail-Benachrichtigungen global ausgeschaltet - keine SMTP-Einstellung spielt eine Rolle, bis Sie dies einschalten.

Den Versandmodus wählen

Mit dieser Matrix entscheiden wir den Modus je nach Szenario:

Gmail und Microsoft 365 per OAuth 2.0

Gmail und Microsoft 365 haben die Basisauthentifizierung (Login + Passwort) gesperrt. Der unterstützte Weg ist OAuth 2.0 (GLPI 10.0.7+). Beim Anbieter registrieren Sie eine Anwendung (Google Cloud Console oder Azure App Registrations), erzeugen Client ID und Client Secret, hinterlegen die Redirect-URI von GLPI und autorisieren. In GLPI wählen Sie den Modus SMTP+OAuth, wählen den Anbieter und fügen die Zugangsdaten ein.

Die Falle, die bei Microsoft 365 am meisten Zeit kostet: Selbst mit korrektem OAuth deaktiviert M365 SMTP AUTH standardmäßig für ein Postfach. Ohne Aktivierung klappt die Authentifizierung, aber der Versand scheitert. Aktivieren Sie es für ein verwendetes Postfach:

# Microsoft 365: habilita o SMTP AUTH na caixa usada no OAuth (desabilitado por padrão)
Set-CASMailbox -Identity [email protected] -SmtpClientAuthenticationDisabled $false

Bei Gmail/Workspace lautet der Scope https://mail.google.com/, und bei Workspace-Konten muss ein Administrator die App möglicherweise freigeben. Konten mit 2FA akzeptieren als Plan B noch App-Passwörter, aber Google lässt diesen Weg nach und nach auslaufen.

Warteschlange und Cron: wo es wirklich bricht

Hier kommt ein Detail, das erst im Betrieb sichtbar wird. Die automatische Aktion queuednotification kann in zwei Modi laufen: GLPI (ausgelöst durch Zugriffe auf die Oberfläche) oder CLI (durch einen externen Cron). In einer Instanz mit wenig Verkehr - bei Kunden, die GLPI nur zu Geschäftszeiten nutzen - führt der Modus GLPI dazu, dass nächtliche Benachrichtigungen erst hinausgehen, wenn morgens jemand ein System öffnet. Ein Symptom kommt als „E-Mail verspätet“ oder „kommt nicht an“. Die Entscheidung, die wir im Betrieb standardisiert haben: alle automatischen Aktionen im Modus CLI, wobei front/cron.php jede Minute von einem externen Cron aufgerufen wird.

# GLPI - drena a fila de notificações a cada minuto (usuário do web server)
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

# Em Docker: dispare o cron do GLPI como o usuário do web server (ajuste nome/caminho)
* * * * * root docker exec -u www-data glpi php /var/www/glpi/front/cron.php >/dev/null 2>&1

Um zu sehen, ob die Warteschlange abgearbeitet wird, prüfen Sie, was ohne sent_time hängt:

-- Notificações presas na fila (fila cheia = cron não está drenando)
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;

Ein großer und wachsender Stapel hier, bei intaktem SMTP, bedeutet fast immer einen gestoppten Cron oder den Modus GLPI. Sie können es auch in der Oberfläche unter Verwaltung > Benachrichtigungswarteschlange verfolgen.

Vorlagen und Variablen

Unter Einstellungen > Benachrichtigungen > Benachrichtigungsvorlagen bearbeiten Sie den Text jedes Ereignisses. Variablen verwenden die Syntax ##...##:

<!-- Modelo "Novo chamado" - corpo HTML com variáveis do GLPI -->
<p>Olá ##ticket.author##,</p>
<p>Seu chamado <strong>##ticket.id##</strong> foi registrado:</p>
<ul>
  <li>Título: ##ticket.title##</li>
  <li>Prioridade: ##ticket.priority##</li>
  <li>Acompanhe em: ##ticket.url##</li>
</ul>

Eine Vorlage kann Versionen pro Sprache haben; fehlt eine Version in der Sprache des Empfängers, verwendet GLPI die Standardversion. Der häufige Fehler hier: nur den portugiesischen Text bearbeiten und sich wundern, dass ein Techniker mit englischem Profil noch die alte Vorlage erhält.

Fallen aus der Praxis

Die Symptome, die wir am häufigsten sehen, und wo Sie jeweils suchen sollten:

Ein Hinweis zum letzten Fall: Standardmäßig benachrichtigt GLPI den Autor einer Aktion nicht über seine eigene Aktion. Ein Techniker, der ein Ticket aktualisiert, erhält kein Echo seines eigenen Updates - erwartetes Verhalten, kein Bug. Dies mit einer „kaputten Benachrichtigung“ zu verwechseln, hat schon eine Nacht Diagnose für ein Problem gekostet, welches gar nicht existierte.

Über E-Mail hinaus

E-Mail ist asynchron und konkurriert mit dem Posteingang um Aufmerksamkeit. Damit ein Techniker ein Ticket in dem Moment sieht, in dem es sich ändert, ist E-Mail nicht der beste Kanal. Erwägen Sie Echtzeit-Benachrichtigungen mit Modul Smart Notify (Glocke in der Navigationsleiste) oder den Versand über WhatsApp und Telegram für Ereignisse, die nicht bis zum nächsten E-Mail-Zyklus warten können.

Wenn E-Mails aus dem GLPI Ihrer Umgebung unzuverlässig sind - mal kommen sie an, mal nicht -, liegt es normalerweise an Warteschlange und Cron, nicht am SMTP. NexTool übernimmt den Betrieb von GLPI mit Überwachung der Benachrichtigungswarteschlange und kontrolliertem Cron. Sprechen Sie mit uns über Support und Betrieb für GLPI.

Geprüft vom Team von NexTool Solutions.