Standardmäßig öffnet Visual Studio Code beim Start die zuletzt geöffneten Dateien, Ordner und SSH-Verbindungen. Wer dieses Verhalten nicht möchte, kann es in den Einstellungen ändern.
Vorgehen
Einstellungen öffnen mit STRG , (unter macOS: CMD ,).
In der Suchleiste nach window.restoreWindows suchen.
Die Einstellung von all auf none ändern.
window.restoreWindows in den Visual Studio Code Einstellungen
Damit startet Visual Studio Code künftig ohne automatisch geöffnete Sitzungen und bleibt beim Start leer.
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:
Navigiere im TYPO3 Backend zur Root-Seite des Seitenbaums.
Öffne die Seiteneigenschaften.
Gehe zur Registerkarte Verhalten.
Aktiviere die Option „Als Anfang der Website benutzen“.
Speichere die Änderungen und leere den Cache.
Nach dieser kleinen Anpassung wurde der <link rel="canonical"> Tag sofort wie gewohnt generiert.
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:
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.
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.
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.
Der Public Key basierte Login ist Standard beim Zugriff aus Linux Server. Doch was tun, wenn genau diese Methode plötzlich auf einem neuen Debian 12 Server mit der Fehlermeldung „Server refused our Key – No supported authentication methods available“ scheitert, obwohl sie bei Debian 11 Servern mit dem gleichen Schlüsselpaar problemlos funktioniert?
Problemursache
Der Kern des Problems liegt in der Tatsache, dass Debian 12 in seiner Standardkonfiguration keine SSH-Schlüssel unterstützt, die mit dem veralteten SHA RSA 1 Algorithmus generiert wurden. Dies ist eine Entscheidung der Debian-Entwickler, um die Sicherheit zu erhöhen, da ältere Algorithmen wie SHA RSA 1 als weniger sicher gelten.
Lösungsansätze
Lösung 1: Erzeugen eines neuen Schlüsselpaares
Die erste und empfohlene Lösung besteht darin, ein neues SSH-Schlüsselpaar mit einem moderneren und sichereren Algorithmus zu erzeugen. Der Befehl ssh-keygen -o -a 100 -t ed25519 erstellt beispielsweise ein neues Schlüsselpaar unter Verwendung des Ed25519 Algorithmus, der für seine hohe Sicherheit und Effizienz bekannt ist. Mehr Informationen zum Erstellen eines SSH-Schlüssels finden Sie in der Anleitung auf Heise Tipps & Tricks.
Lösung 2: Konfiguration des SSH-Dienstes
Falls das alte SSH-Schlüsselpaar weiterhin genutzt werden soll, besteht die Möglichkeit, den SSH-Dienst auf dem Debian 12 Server so zu konfigurieren, dass er auch die älteren SHA RSA 1 Schlüssel akzeptiert. Hierzu muss die Konfigurationsdatei /etc/ssh/sshd_config bearbeitet und die Zeile PubkeyAcceptedAlgorithms +ssh-rsa hinzugefügt werden. Nach einem Neustart des SSH-Dienstes werden die älteren Schlüssel wieder akzeptiert. Weitere Details zu dieser Lösung finden Sie auf DeployHQ’s Supportseite.
Fazit
Die Fehlermeldung „Server refused our Key – No supported authentication methods available“ beim Versuch, sich via Public-Key-Authentifizierung bei einem Debian 12 Server anzumelden, signalisiert ein Kompatibilitätsproblem aufgrund veralteter Algorithmen die beider Erzeugung des Schlüsselpaars verwendet wurden. Die Lösung dieses Problems kann entweder durch das Erzeugen neuer, sichererer Schlüssel oder durch eine Anpassung der Serverkonfiguration erfolgen, um ältere Schlüssel temporär weiterhin zu unterstützen. Letzteres sollte jedoch nur eine vorübergehende Lösung sein, da die Migration zu sichereren Schlüsseln langfristig die bessere Strategie darstellt.
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:
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.
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:
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.
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.
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.
