Fehlendes Canonical Tag im Header einer TYPO3 Instanz

Damit sich nicht noch jemand durch das Internet quält und doch nichts findet: Vor Kurzem stand ich vor einem Problem mit einer TYPO3 Instanz, das scheinbar niemand sonst dokumentiert hat. Es ging darum, dass der <link rel="canonical"> Tag im Seitenheader fehlte. Trotz ausgiebiger Recherche war keine Lösung zu finden. Am Ende war die Ursache trivial – aber schwer zu entdecken.

Das Problem: Kein Canonical Tag

TYPO3 generiert normalerweise automatisch einen Canonical Tag für jede Seite, sofern die entsprechenden Einstellungen korrekt vorgenommen wurden. In meinem Fall jedoch fehlte dieser Tag bei allen Seiten. Im Seiten-Quellcode war kein <link rel="canonical"> Tag zu sehen. Eine Kontrolle der SEO-Einstellungen und der TypoScript-Konfiguration ergab keine Auffälligkeiten.

Die Ursache: Einstellung bei der Root-Seite

Die Ursache lag in den Seiteneigenschaften der Root-Seite des Seitenbaums. Unter der Registerkarte Verhalten war die Option „Als Anfang der Website benutzen“ nicht aktiviert. Diese Einstellung ist entscheidend dafür, dass TYPO3 die Root-Seite als Ausgangspunkt der gesamten Website erkennt. Fehlt diese Aktivierung, weiß TYPO3 nicht, wie es den Canonical Tag korrekt generieren soll.

Die Lösung: „Als Anfang der Website benutzen“ aktivieren

Die Lösung war denkbar einfach:

  1. Navigiere im TYPO3 Backend zur Root-Seite des Seitenbaums.
  2. Öffne die Seiteneigenschaften.
  3. Gehe zur Registerkarte Verhalten.
  4. Aktiviere die Option „Als Anfang der Website benutzen“.
  5. Speichere die Änderungen und leere den Cache.

Nach dieser kleinen Anpassung wurde der <link rel="canonical"> Tag sofort wie gewohnt generiert.

Tausende Logmeldungen im Application Log eines ADFS Servers Event ID 28005: Error: 15517, State: 1. Cannot execute as the database principal because the principal „dbo“ does not exist

Im Rahmen der Administration eines Active Directory Federation Service (ADFS) Servers stießen wir auf ein Problem: Tausende von Fehlermeldungen im Eventlog des Servers, die keinen direkten Einfluss auf die Funktionalität hatten, aber dennoch störend waren und die Übersicht im Log massiv beeinträchtigten. In diesem Blogartikel möchten wir die Ursache und Lösung des Problems im Detail erläutern.

Problem: Massenhaft Fehler im Application Log

Im Application Log eines ADFS-Servers fanden sich über 170.000 Fehlermeldungen innerhalb von 24 Stunden, was zu einer durchschnittlichen Rate von fast zwei Logeinträgen pro Sekunde führte. Der Logeintrag hatte die folgende Fehlermeldung:

An exception occurred while enqueueing a message in the target queue. Error: 15517, State: 1. Cannot execute as the database principal because the principal "dbo" does not exist, this type of principal cannot be impersonated, or you do not have permission.

Obwohl diese Fehler keinen direkten Einfluss auf die Funktionalität des ADFS-Servers hatten, waren sie störend und erschwerten das Monitoring und die Diagnose anderer potenzieller Probleme.

Ursache: Datenbank-Fehlkonfiguration

Nach einer eingehenden Untersuchung und einer Internetrecherche zeigte sich, dass das Problem durch eine Fehlkonfiguration in der Windows Internal Database (WID) verursacht wurde, die ADFS verwendet. Genauer gesagt war der Datenbankbesitzer („DBO“, Database Owner) der relevanten ADFS-Datenbanken nicht korrekt gesetzt. Der Fehler „Cannot execute as the database principal because the principal ‚dbo‘ does not exist“ deutete darauf hin, dass der Datenbankbesitzer in den betroffenen ADFS-Datenbanken NULL war.

Lösung: Anpassen des DBOwners der ADFS-Datenbanken

Um das Problem zu beheben, haben wir die folgenden Schritte durchgeführt:

  1. Installation von SQL Server Management Studio (SSMS)
    Um die Konfiguration der WID-Datenbanken zu ändern, ist es notwendig, das SQL Server Management Studio (SSMS) zu verwenden.
  2. Verbindung zur Windows Internal Database (WID)
    Als Nächstes haben wir uns mit der WID-Instanz auf dem ADFS-Server verbunden. Dies geschieht mit folgendem Verbindungsstring:
np:\\.\pipe\MICROSOFT##WID\tsql\query

Wichtiger Hinweis: SSMS muss als Administrator gestartet werden, da die Verbindung zur WID-Instanz sonst fehlschlägt.

Ändern des Datenbankbesitzers (DBOwner) für die ADFS-Datenbanken
In der WID-Instanz haben wir dann den Datenbankbesitzer für die beiden ADFS-Datenbanken „AdfsConfigurationV4“ und „AdfsArtifactStore“ geändert. Dies geschah mit den folgenden SQL-Befehlen:

use [AdfsConfigurationV4]
EXEC sp_changedbowner 'sa'

use [AdfsArtifactStore]
EXEC sp_changedbowner 'sa'

Vor dieser Änderung war der Besitzer der beiden Datenbanken auf NULL gesetzt, was die Fehlermeldungen verursachte.

    Ergebnis: Keine weiteren Fehlermeldungen

    Nach der erfolgreichen Änderung des DBOwners in der WID-Instanz wurden die störenden Logeinträge im Application Log vollständig beseitigt. Der ADFS-Server lief weiterhin ohne Probleme, und die Änderung hatte keinerlei negative Auswirkungen auf die Funktionalität des Servers.

    Hilfreichen Artikeln:

    Fehler bei der MS SQL Server 2022 Installation: „The RPC Server is unavailable“

    Die Installation von SQL Server 2022 kann in Umgebungen mit komplexen Netzwerkkonfigurationen zu Herausforderungen führen. Bei einer Installation ist beim Konfigurieren der Kontoinformationen für den SQL Server und den SQL Agent Dienst der Fehler „The RPC Server is unavailable“ und „The SQL Server service account login or password is not valid„, aufgetreten. Dieser Beitrag erklärt, wie dieses Problem in unserem spezifischen Szenario gelöst wurde.

    Problemstellung

    Während der Installation des SQL Server 2022 tritt beim Übergang zum nächsten Schritt des Installationsassistenten, in dem die Dienstkontoinformationen für den SQL Server und den SQL Agent konfiguriert werden, ein Fehler auf. Die Fehlermeldungen lauten „The RPC Server is unavailable“ und „The SQL Server service account login or password is not valid„. Obwohl die zweite Meldung suggeriert, dass Benutzername oder Passwort des Dienstkontos nicht korrekt seien, ist dies tatsächlich irreführend, da die Credentials korrekt sind.

    Ursache des Problems

    Die Ursache für den Fehler liegt in der Netzwerkkonfiguration, speziell im Zusammenhang mit der DNS-Konfiguration. In unserem Fall verwendet das Active Directory einen sogenannten Disjoined Namespace, bei dem die Member-Server einen vom AD-Namen unterschiedlichen DNS-Suffix haben. Der SQL Server Installer versucht offenbar, die Domäne nicht mit einem vollqualifizierten Domänennamen (FQDN) zu erreichen, sondern nur mit einem Hostnamen. Das Anhängen des DNS-Suffix des lokalen SQL Servers scheitert daher aufgrund des Disjoined Namespace.

    Lösung des Problems

    Eine erfolgreiche Lösung wurde nach eingehender Recherche auf der Webseite https://deibymarcos.wordpress.com/2016/04/06/sql-server-set-up-error-the-rpc-server-is-unavailable/ gefunden. Der entscheidende Tipp war, dass die DNS-Suffix-Liste vollständig konfiguriert sein muss.

    Um das Problem zu beheben, wurden die folgenden Schritte durchgeführt:

    1. Überprüfung der DNS-Einstellungen auf dem Server, auf dem SQL Server 2022 installiert werden soll.
    2. Hinzufügen des DNS-Suffix der Active Directory-Domäne zu den DNS-Einstellungen des Servers.
    3. Neustart des Installationsvorgangs für den SQL Server 2022.

    Nach der Konfiguration der DNS Search Suffixe verlief der MS SQL Installationsprozess ohne weitere Probleme.

    Fehler: „Oops, an error occurred!“ nach TYPO3 12.4 und News Extension 11.3.0 Update in Bezug auf den Fluid Viewhelper „includeFile“

    Nach dem Update einer TYPO3-Website auf Version 12.4 und einem gleichzeitigen Update der News Extension auf Version 11.3.0 kann es vorkommen, dass bestehende News-Artikel weder in der Übersichtsliste noch in den Detailansichten angezeigt werden. Stattdessen erscheint die Fehlermeldung „Oops, an error occurred! Code: 202401072011058d9760ff“. AdHoc konnte ich keine Fehlerursache erkennen auch waren bei einer Google Suche keine Lösungen für das Problem verfügbar.

    Ursache des Problems

    Die Ursache für diesen speziellen Fehler liegt in einer Änderung der ViewHelpers in der News Extension. In der Logdatei wird ein Fehler im Zusammenhang mit dem ViewHelper „<n:includeFile>“ angezeigt.
    Error: The ViewHelper "<n:includeFile>" could not be resolved.

    Dieser ViewHelper wurde in den früheren Versionen der News Extension verwendet, ist aber in der Version 11.3.0 nicht mehr vorhanden.

    In der Dokumentation der News Extension Version 10 wird der IncludeFile ViewHelper noch erwähnt, jedoch fehlt er in der Dokumentation der Version 11. Diese Änderung wurde offenbar nicht breit kommuniziert, da ich online keine Informationen darüber finden konnten.

    Lösung des Problems

    Die Lösung für dieses Problem wurde im offiziellen TYPO3 Slack-Kanal gefunden. Ein anderer Benutzer hatte das gleiche Problem geäußert, und der Entwickler der News Extension, Georg Ringer, gab einen entscheidenden Hinweis.

    In den originalen Fluid Templates ab Version 11 der News Extension ist ein neues, funktionierendes Code-Fragment zu finden. Anstelle von:

    <f:if condition="{settings.cssFile}">
	<n:includeFile path="{settings.cssFile}" />
</f:if>

    sollte jetzt folgender Code verwendet werden:

    <f:if condition="{settings.cssFile}">
	<f:asset.css identifier="ext-news" href="{settings.cssFile}" />
</f:if>

    Anscheinend hat der Autor der News Extension seinen eigenen, extension-spezifischen ViewHelper zugunsten eines standardmäßigen ViewHelpers mit identischer Funktion aufgegeben und aus der Extension entfernt.

    Bei mir half eine Änderung des Syntax in den News Fluid Templates Dateien Layouts/General.html und Layout/Detail.html aus, damit die News Extension in der neuen TYPO3 Instanz wieder funktionierte.

    Behebung der TYPO3 PHP-Warnung – PHP Warning: Undefined array key „tx_news_pi1“ – nach dem Update auf PHP 8

    Wenn Sie kürzlich Ihr TYPO3-System auf PHP 8 aktualisiert haben, könnten Sie auf eine hartnäckige PHP-Warnung im TYPO3 Systemlog gestoßen sein, die sich auf den Schlüssel „tx_news_pi1“ bezieht.

    Nach dem Update auf PHP 8 bemerkte ich hunderte von Warnungen im TYPO3 System Log, die alle auf die gleiche Typoscript Condition hinwiesen:

    [request.getQueryParams()['tx_news_pi1']['news'] > 0].

    Nach einiger Recherche stellte sich heraus, dass die Syntax für Conditions in TypoScript geändert wurde.

    Die Lösung liegt in der Anpassung der Typoscript Condition. Anstelle der alten Syntax verwendet man nun die neue Syntax:
    [traverse(request.getQueryParams(), 'tx_news_pi1/news') > 0].

    Diese Änderung beseitigt die PHP-Warnungen.

    In der TYPO3-Dokumentation findet man weitere Informationen zur Implementierung der Symfony Expression Language für TypoScript Conditions, welche die Änderungen in der Syntax erklärt. Der folgende Link führt Sie zur entsprechenden Dokumentation: TYPO3-Dokumentation.

    Führende Nullen in Dateinamen unter Linux hinzufügen

    Wenn Sie viele Dateien haben, die durchnummeriert sind, aber ohne führende Nullen, kann die Sortierung manchmal durcheinander geraten. Ein typisches Beispiel könnte eine Sammlung von Bilddateien sein, die als img_1.jpg, img_2.jpg, img_100.jpg usw. nummeriert sind. In diesem Fall wird img_100.jpg vor img_2.jpg sortiert, da die Sortierung als Zeichenkette und nicht numerisch erfolgt.

    Dieses Problem lässt sich lösen, indem man ein einfaches Bash-Skript verwendet, das durch alle Dateien geht und diejenigen umbenennt, die weniger als eine bestimmte Anzahl von Ziffern in ihrem Namen haben, in unserem Fall drei. Hier ist, wie Sie das tun können:

    for file in img_*.jpg; do
    # Extrahiere die Nummer aus dem Dateinamen
    num=$(echo $file | grep -o -E '[0-9]+')

    # Überprüfe, ob die Nummer weniger als 3 Stellen hat
    if [ ${#num} -lt 3 ]; then
        # Füge führende Nullen hinzu, um die Länge auf 3 zu bringen
        new_num=$(printf "%03d" $num)

        # Generiere den neuen Dateinamen
        new_file="img_${new_num}.jpg"

        # Umbenennen der Datei
        mv $file $new_file
    fi
done

    Dieses Skript extrahiert den numerischen Teil jedes Dateinamens, prüft seine Länge und fügt gegebenenfalls führende Nullen hinzu, um die Länge auf drei Stellen zu bringen. Es ignoriert Dateien, die bereits eine dreistellige Nummer haben.

    Bitte beachten Sie, dass das Skript davon ausgeht, dass alle Ihre Dateien im Format img_N.jpg vorliegen, wobei N eine Zahl ohne führende Nullen ist. Wenn Ihr Dateiformat abweicht, müssen Sie das Skript entsprechend anpassen.

    Zudem sollten Sie beachten, dass dieses Skript keine Sicherheitsmaßnahmen implementiert, um sicherzustellen, dass keine Dateien überschrieben werden. Stellen Sie daher sicher, dass Sie eine Sicherungskopie Ihrer Dateien haben, bevor Sie das Skript ausführen.

    SSL-Zertifikatstauschs beim Windows Admin Center (WAC)

    Im Gegensatz zu anderen Anwendungen bietet das Windows Admin Center keinen direkten Eintrag im Startmenü an, um einen Konfigurationsdialog zum Zertifikatstausch aufzurufen. Zudem wird es nicht über die IIS-Bindungen verwaltet, was die Sache noch komplizierter macht.

    Beginnen wir damit, wie man zum Konfigurationsdialog gelangt. Dieser befindet sich in den Einstellungen unter „Apps and Features“ oder „Programme hinzufügen und entfernen“. Hier muss man das Windows Admin Center auswählen und auf „Modify“ klicken, um den Setup-Dialog zu starten. Im Setup-Dialog muss man dann erneut auf „Ändern“ klicken.

    In dem folgenden Dialogfenster kann man den Thumbprint des neuen Zertifikats eingeben. Wichtig ist, dass dieses Zertifikat zuvor in den Zertifikatsstore von Windows importiert wurde.

    Nach Abschluss des Installationsassistenten des Windows Admin Centers wird das neue Zertifikat konfiguriert.

    Insgesamt handelt es sich hierbei um einen eher ungewöhnlichen und komplizierten Prozess.

    Es wäre wesentlich praktischer, wenn es einen direkten Eintrag im Startmenü gäbe, der den Konfigurationsassistenten aufruft. Des Weiteren würde eine Auswahl der möglichen Zertifikate anstatt der Eingabe des Zertifikats-Thumbprints den Prozess erleichtern und benutzerfreundlicher gestalten.

    Ändern der Zeitzone auf einem Debian System

    Um die Zeitzone auf einem Debian System zu ändern, können Sie die folgenden Schritte ausführen:

    1. Öffnen Sie das Terminal oder eine SSH-Verbindung zum Server.
    2. Überprüfen Sie die aktuelle Zeitzone des Systems mit dem Befehl timedatectl.
    3. Geben Sie den Befehl timedatectl set-timezone gefolgt von der Bezeichnung der neuen Zeitzone ein, um die Zeitzone zu ändern.
    4. Ersetzen Sie „Europe/Berlin“ durch den Namen der gewünschten Zeitzone. Eine Liste aller verfügbaren Zeitzone finden Sie unter /usr/share/zoneinfo/.
    5. Überprüfen Sie erneut die Zeitzone mit dem Befehl „timedatectl", um sicherzustellen, dass die Änderung erfolgreich war.

    Stellen Sie sicher, dass Sie über ausreichende Berechtigungen auf dem System verfügen, um diese Änderungen vorzunehmen

    Identifizieren defekter Disks in einem Storage Spaces Direct Cluster (S2D) mit PowerShell

    Das folgende PowerShell-Skript ermittelt defekte Disks in einem Storage Spaces Direct Cluster und zeigt den Namen des Clusterknotens, in dem die Disk verbaut ist:

    $errordisks=@()

foreach($ed in Get-PhysicalDisk |? Operationalstatus -ne 'OK'|Sort-Object FriendlyName)
{
    $Nodename=($ed|Get-StorageScaleUnit).friendlyname

    $cobject = [PSCustomObject]@{
        FriendlyName = $ed.FriendlyName
        SerialNumber = $ed.SerialNumber
        MediaType=$ed.MediaType
        OperationalStatus=$ed.OperationalStatus
        Size=$ed.Size/1GB
        HealthStatus=$ed.HealthStatus
        Nodename=$Nodename
    }
    $errordisks+=$cobject
}

$errordisks|ft

    Das Skript erstellt ein Array namens $errordisks, das die Informationen zu defekten Disks enthält. Es durchläuft alle physischen Disks, die einen vom Status „OK“ abweichenden OperationalStatus haben. Für jede gefundene Disk wird der zugehörige Clusterknotenname ermittelt und ein benutzerdefiniertes PowerShell-Objekt mit den relevanten Informationen erstellt. Schließlich wird das Array $errordisks ausgegeben, und die Informationen werden im Format einer Tabelle angezeigt.

    Beispiel: Anzeige einer defekten SSD in einem Storage Space Direct Cluster

    Mit einer kleinen Änderung des Scripts lassen sich alle Disks, unabhängig von ihrem Status, in einen Storage Space Direkt Cluster, zugeordnet zu dem jeweiligen Clusternode, anzeigen. 

    $S2Ddisks=@()

foreach($ed in Get-PhysicalDisk)
{
$Nodename=($ed|Get-StorageScaleUnit).friendlyname

 if($nodename)
 { 
 
  $cobject = [PSCustomObject]@{
                    FriendlyName = $ed.FriendlyName
                    SerialNumber = $ed.SerialNumber
                    MediaType=$ed.MediaType
                    OperationalStatus=$ed.OperationalStatus
                    Size=$ed.Size/1GB
                    HealthStatus=$ed.HealthStatus
                    Nodename=$Nodename
                    }


  $S2Ddisks+=$cobject
  }

}

$S2Ddisks|Sort-Object  Nodename,FriendlyName|ft
    Anzeigen aller Disks in einem Storage Space Direct Cluster, mit dem Clusterknoten in dem die Disk verbaut ist.