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
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
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
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.
Okt 20
12
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
Für die Weiterentwicklung des TYPO3 CMS und Extension-Programmierung wird als LAMP Stack mehr und mehr Docker in Verbindung mit dem DDEV Tool eingesetzt.
Mit der neuen Version 1.8.0 von ddev, wurden gültige SSL-Zertifikate für die Entwicklungsumgebung eingeführt. Um die SSL-Zertifikate zu generieren, wird das Tool "mkcert" benötigt. Die Installation unter Linux (Ubuntu, Debian) ist einfach und kann mit ein paar Zeilen umgesetzt werden.
sudo su -
apt install libnss3-tools
wget https://github.com/FiloSottile/mkcert/releases/download/v1.3.0/mkcert-v1.3.0-linux-amd64 -O /usr/local/bin/mkcert
chown LOCALUSERNAME:users /usr/local/bin/mkcert
chmod +x /usr/local/bin/mkcert
Nach der Installation kann mittels mkcert -install der Prozess zur Generierung der SSL-Zertifikate angestoßen werden und das TYPO3 CMS kann nach dem gewohnten Start von ddev über den Browser und mittels https aufgerufen werden, ohne das eine Warnung vom Browser ausgeworfen wird.