TYPO3 CMS & Sentry.io: Optimieren der Fehlerbehandlung mit logWriterComponentIgnoreList

Sentry.io ist ein leistungsstarkes Tool zum Überwachen von Exceptions, Fehlermeldungen und Stack-Traces. Es hilft, Fehler in Echtzeit zu verfolgen, zu überwachen und zu beheben. In Verbindung mit dem TYPO3 CMS bietet Sentry.io die Möglichkeit, Fehler systematisch zu identifizieren und zu handhaben.
Dazu muss lediglich die TYPO3 Extension "sentry client" installiert werden. Zum Beispiel mittels composer.

composer req networkteam/sentry-client

Eine besonders nützliche Konfiguration ist die "logWriterComponentIgnoreList", die es ermöglicht, gezielt Fehlermeldungen auszuschließen, die einer bestimmten Komponente zugeordnet sind.

Konfiguration der logWriterComponentIgnoreList in TYPO3 Version 12

In TYPO3 CMS Version 12 erfolgt diese Konfiguration in der Datei config/system/additional.php.

(static function (): void {
$GLOBALS['TYPO3_CONF_VARS'] = \array_replace_recursive(
$GLOBALS['TYPO3_CONF_VARS'],
[
'EXTENSIONS' => [
'sentry_client' => [
'dsn' => 'https://sentry-server-url/project/xx',
'release' => '1.0.0',
'logWriterComponentIgnorelist' => 'Plan2net.Webp.EventListener.AfterFileProcessing, TYPO3.CMS.Core.Resource.Processing.LocalImageProcessor',
],
],
],
);
})();

In diesem Beispiel wird die logWriterComponentIgnoreList mit zwei Komponenten konfiguriert: Plan2net.Webp.EventListener.AfterFileProcessing und TYPO3.CMS.Core.Resource.Processing.LocalImageProcessor. Dies bedeutet, dass alle Fehlermeldungen, die von diesen spezifischen Komponenten generiert werden, nicht an Sentry.io übermittelt werden.

Konfiguration der logWriterComponentIgnoreList in TYPO3 Version 11

In der TYPO3 CMS Version 11 kann diese Konfiguration in der Datei typo3conf/AdditionalConfiguration.php vorgenommen werden. Die Struktur ist identisch zur TYPO3 Version 12, nur die Konfigurationsdatei lautet anders.

Wann ist diese Konfiguration nützlich?

Die Konfiguration der logWriterComponentIgnoreList ist besonders nützlich, wenn bestimmte Komponenten bekanntermaßen nicht kritisch sind oder wenn Fehlermeldungen von diesen Komponenten bewusst ignoriert werden sollen. Dies kann die Sentry.io-Oberfläche von unnötigem Rauschen befreien und ermöglichen, sich auf kritische Fehler zu konzentrieren.

Angenommen wir haben einen eigenen Event-Listener für die Verarbeitung von WebP-Dateien (Plan2net.Webp.EventListener.AfterFileProcessing) und wissen, dass dieser Event-Listener einige Fehler verursacht, die nicht unbedingt kritisch sind. In diesem Fall können wir diese Fehlermeldungen von der Überwachung ausschließen

Tags: ,
von Jörg am 21.12.2023, unter TYPO3. Keine Kommentare

TYPO3 CMS Update auf 10.4.19 – Probleme mit figure HTML Tag im Frontend

Mit dem TYPO3 Update auf die Version 10.4.19 kann es dazu führen, dass das <figure>-Tag im Frontend (FE) nicht mehr richtig ausgespielt, sondern in HTMLEntities umgewandelt wird.

Es ist dem TYPO3 HTML Sanitizer Team als Issue im Github Repo gemeldet worden, dass es mit der neuesten TYPO3 CMS Version 10.4.19 und der Aktualisierung des HTML Sanitizers zu Problemen im TYPO3 CMS führt.

Issue + aktueller Workaround: https://github.com/TYPO3/html-sanitizer/issues/16

Tags: , , , ,
von Jörg am 11.08.2021, unter TYPO3. Keine Kommentare

Ubiquiti UDM-Pro (UDMP) Controller mit individuellen Dynamic DNS Anbieter

Mit der neuen Ubiquiti UDM-Pro (Dream Machine Pro) oder auch abgekürzt UDMP ist es möglich einen dynamic DNS Server zu definieren, um bei einer dynamische und öffentlichen IP eine Domain für den externen Zugriff zu aktualisieren.

Ein typischer Anwendungsfall ist der, dass man sich per VPN auf sein Heimnetzwerk verbinden möchte. Da sich die öffentliche IPv4 oder IPv6 Adresse am WAN-Interface in der Regel alle 24 Stunden ändert, ist es mühsam seine öffentliche IP-Adresse zu ermitteln. Dafür wurde DDNS ins Leben gerufen, sodass ein Script oder eine Software die aktuelle WAN-IP an einen Dienst per REST-API sendet und die Domain die öffentliche IP-Adresse als A-Record erhält.

Wer seinen DDNS Service selber hosted und z.B. die DNS API von der Firma Netcup verwendet, kann mit der Ubiquiti UDM-PRO (UDMP) und der aktuellsten Unifi Controller Version, seine öffentliche IP-Adresse über einen "Dynamic DNS" Eintrag registrieren.

Bei einem custom DDNS Service, lässt sich die öffentliche IPv4 über einen Platzhalter "%i" übergeben. Der Platzhalter "%h" steht für den Hostname der Konfiguration.

myDomain.tld/nic/update?hostname=%h&myip=%i
Unifi UDMP Dream Machine Pro - Dynamic DNS Settings for custom REST-API

Zur Überprüfung der Konfiguration, einfach per SSH auf der UDM-Pro einloggen und den Befehl ausführen. So wird das Debugging gestartet und wir erhalten Informationen darüber, ob der externe DDNS Server / die DDNS API unsere Anfrage richtig entgegen nimmt.

/usr/sbin/inadyn -n -s -C -f /run/inadyn.conf -1 -l debug --foreground

Quelle für den INADYN Befehl: Community von Unifi

Roborock S6 MaxV Firewall Ports für Roborock App & Unifi Controller

Der Roborock S6 MaxV Saug- und Wischroboter benötigt für die Kommunikation zwischen der Handy App und dem Wlan freigegebene Ports. Durch die Freigabe ist es möglich innerhalb der App die Reinigung zu starten, das Andocken/Laden anzuordnen, die Videoübertragung und Gegenstanderkennung abzurufen, die Fernsteuerung zu aktivieren und vieles Mehr.

Bis dato ist es mir nicht gelungen eine offizielle Aussage der verwendeten Ports für den Roboter selbst im Wlan und der App von Roborock zu finden.

Über das Tool tcpdump habe ich in meinem IoT Netzwerk die angefragten Ports von meinem Handy bei der Verwendung der Roborock App ausgelesen, sodass die Kommunikation und Steuerung des Roborock S6 MaxV Saug- und Wischroboters möglich wird.

Ports
- 8883/tcp - Secure MQTT
- 443/tcp - HTTPs
- 80/tcp - HTTP

Wichtig ist hierbei der TCP Port 8883 (Secure MQTT), sodass die Karte für den Raum in der APP geladen und die Steuerrung des Roboters ausgelöst werden kann. Ist dieser Port nicht freigeschaltet, erhaltet ihr die Fehlermeldung "Karte wird geladen, eine langsame Internetverbindung liegt vor."

Bei einer Netzwerkinfrastruktur mit Ubiquiti Unifi Produkten, kann dafür im Unifi Controller eine Port-Gruppe erstellt werden, die die Ports 8883, 443 und 80 enthält. Damit lässt sich gezielt die Freigabe in der Firewall steuern.

TYPO3 CMS Mail Transport mit DDEV

In der modernen TYPO3 CMS Entwicklungs kommt häufig das Tool drud ddev zum Einsatz, um in kurzer Zeit mittels Docker eine Entwicklungsumgebung mit PHP, Nginx/Apache, MariaDB/MySQL und einem lokalen Maildienst zu schaffen.

Bei der Migration von Bestands- oder Altprojekten existieren in der LocalConfiguration.php oder in der AdditionalConfiguration.php Datei häufig die Mail Transport Parameter. Die Konfigurationsparameter verweisen meist auf /usr/sbin/sendmail oder einen fremden SMTP Mailserver.

Wird das TYPO3 Install-Tool geöffnet oder sich im TYPO3 Backend angemeldet, erscheint sofort die Fehlermeldung "Connection to process /usr/sbin/sendmail -bs has been closed unexpectedly" in Verbindung mit der PHP-Exception Symfony\Component\Mailer\Exception\TransportException.

Ursache der Fehlermeldung
Das Tool drud ddev verwendet im internen Docker-Stack kein sendmail, sondern einen SMTP-Server um die Mails an einen lokalen Dienst weiterzuleiten, um diese dann in der Mailhog-Weboberfläche zur Verfügung zu stellen. Sofern ein externer SMTP Server eingetragen wurde, kann keine Verbindung zu dem SMTP Server hergestellt werden.

Behebung der Fehlermeldung

Der Mail Transport muss von Sendmail auf SMTP umgestellt und zugleich die Konfiguration des "transport_smtp_server" auf "localhost:1025" eingestellt werden.

$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport'] = 'smtp';
$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_smtp_server'] = 'localhost:1025';

Nach der Anpassung der TYPO3_CONF_VARS Mailer Transport Parameter, muss der TYPO3 Cache über das Install-Tool oder Backend geleert werden, sodass die neue Konfiguration geladen wird.

---
Github Issue & Lösungsansatz: https://github.com/drud/ddev/issues/924#issuecomment-397906961