MediaMill Blog

Kategorie: Allgemein

  • Visual Studio Code: Zuletzt geöffnete Fenster deaktivieren

    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

    1. Einstellungen öffnen mit
      STRG ,
      (unter macOS: CMD ,).
    2. In der Suchleiste nach window.restoreWindows suchen.
    3. Die Einstellung von all auf none ändern.
    Visual Studio Code
    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.

  • 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.

  • Ä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

  • Dateien älter als ein bestimmtes Datum unter Linux löschen

    Verwenden Sie den folgenden Befehl, um Dateien zu finden und zu löschen, die älter sind als ein bestimmtes Datum:

    find /pfad/zum/verzeichnis -type f -not -newermt 'YYYY-MM-DD' -print0 | xargs -0 rm

    Bevor Sie den Befehl ausführen, empfiehlt es sich, die gefundenen Dateien ohne den | xargs -0 rm-Teil zu überprüfen, dass wirklich nur die gewünschten Daten gelöscht werden.

  • Schneller Zugriff auf den Zertifikatspeicher des lokalen Computers unter Windows

    Obwohl es mehrere Möglichkeiten gibt, auf den Zertifikatspeicher (Certificate Store) von Windows zuzugreifen, möchte ich in diesem Blogbeitrag eine schnelle und effiziente Methode vorstellen und die ich gerne mit euch teilen möchte.

    Die gängige Methode, um auf den Zertifikatspeicher des lokalen Computers zuzugreifen, besteht darin, die Microsoft Management Console (MMC) zu verwenden, das Zertifikat-Snap-In hinzuzufügen und dann den lokalen Computer als Ziel auszuwählen. Dieser Prozess kann jedoch zeitaufwändig sein, insbesondere wenn man regelmäßig auf den Zertifikatspeicher zugreifen muss.

    Glücklicherweise gibt es eine einfachere und schnellere Methode, um direkt auf den Zertifikatspeicher des lokalen Computers zuzugreifen. Anstatt die MMC zu öffnen und manuell das Zertifikat-Snap-In hinzuzufügen, kann man einfach den Befehl certlm.msc verwenden.

    Um den Zertifikatspeicher des lokalen Computers direkt aufzurufen, befolgen Sie die folgenden Schritte:

    1. Drücken Sie die Windows-Taste + R, um das „Ausführen“-Dialogfeld zu öffnen.
    2. Geben Sie certlm.msc ein und drücken Sie Enter.

    Der Zertifikatspeicher des lokalen Computers wird nun geöffnet, und Sie können die Zertifikate einsehen und verwalten.

    „Windows Certifiacte Store Local Machine“ mit dem Befehl certlm.msc direkt aufrufen.
    Windows Zertifikatspeicher lokaler Computer

  • Ein HP LaserJet Netzwerkdrucker erscheint nach erfolgreicher Installation als „offline“

    Nachdem ein HP LaserJet Netzwerkdrucker anhand seiner IP-Adresse in Windows erfolgreich installiert wurde, erscheint er als „offline“. Ein Drucken ist nicht möglich.

    Grund für dieses Problem war, dass Windows den Druckerzustand anhand von SNMP versucht zu ermitteln. Hier war bei den Drucker Anschlusseinstellungen beim SNMP-Communityname „SET“ eingetragen. Diese Communityname war aber nicht mit dem SNMP-Communityname des Druckers identisch. Deshalb konnte Windows den Druckerstatus nicht per SNMP ermitteln und zeigte den Drucker „offline“ an.

    Als der SNMP-Communityname auf den Standardwert „public“ geändert wurde, konnte Windows den Druckerstatus ermitteln und schaltete den Drucker sofort auf „online“.

    Es wäre auch möglich gewesen, die SNMP Statusabfrage komplett zu deaktivieren indem die entsprechende Checkbox deaktiviert wird.

  • Hyper-V Cross Cluster Migration ohne System Center Virtual Machine Manager

    Migration einer VM zwischen 2 Hyper-V Clustern ohne dass die VM offline genommen wird. Dabei wird nur der lokale Hyper-V Manager verwendet. Eine System Center Virtual Machine Manager Umgebung ist dafür nicht notwendig.

    Wichtig!

    Eine Migration einer VM ist nur möglich wenn die VM Version kleiner oder gleich der Version des Ziel-Hyper-V Clusters ist. Wenn die VM einer größere Version als das Zielhyper-V Cluster hat bricht die Migration mit dem Fehler Migration Operation Failed und dem Error Code 32784 ab.

    Dies ist dann der Fall, wenn eine VM z.B. mit Hyper-V 2019 (VM Configuration-Version 9) erstellt wurde und auf einen Hyper-V 2016 (VM Configuration-Version 8) migriert werden soll.

    Ein Downgrade einer VM Version ist nicht möglich. Eine Notlösung wäre die Erstellung einer neuen VM mit der niedrigeren Version und einhängen der virtuellen Festplatte der VM.

    Migrationsablauf

    1. Entfernen der VM aus dem Cluster. Im Failoverclustermanager, beim Kontextmenü der VM auf Remove klicken. Die VM wird aus dem Cluster entfernt, läuft aber noch auf dem lokalen Hyper-V Knoten ohne Unterbrechung weiter.

    2. Im lokalen Hyper-V Manager im Kontextmenü der VM auf Move klicken.

    3. Als Move Type Move the virtual machine auswählen.

    4. Als Ziel ein Knoten des Ziel-Hyper-V Clusters auswählen

    5. Bei den Move Options Move the virtual machine’s date to a single location auswählen.

    6. Beim nächsten Wizard-Schritt muss der Zielordner im Clusterstorage des Ziel – Hyper-V Knotens angegeben werden. Wichtig, hier ist ein dedizierter Ordner für die VM anzugeben, sonst wird die VM direkt im übergeordneten Ordner abgelegt.

    7. Falls sich die Namen der logischen Switche bei den Quell und Ziel-Hyper-V unterscheiden, kann es notwendig sein einen virtuellen Switch manuell zuzuordnen.

    8. Danach wird die VM im laufenden Betrieb auf den ziel Hyper-V Host migriert.

    9. Auf dem Ziel Hyper-V Cluster ist es jetzt noch notwendig die VM in das Cluster aufzunehmen. Dazu ist im Failovercluster Manager unter Roles auf Configure Roles zu klicken. Nicht auf New Virtual Machine.

    10. Bei Select Role ist Virtual Machine auszuwählen.

    11. Dann kann man aus einer Liste der VMs die sich noch nicht im Cluster die migrierte VM auswählen um diese ins Hyper-V Cluster aufzunehmen.

    12. Danach ist die Migration abgeschlossen. Die VM wurde ohne Downtime ins Ziel-Hyper-V Cluster migriert. Eventuell ist die Netzwerkkonnektivität zu überprüfen und anzupassen.

  • Im TYPO3 Backend fehlen nach einem Update auf TYPO3 9.5 die Adminwerkzeuge

    Bei einem Versionsupdate von TYPO3 8 auf TYPO3 9 kann es vorkommen, dass nach dem Update im Backend die Adminwerkzeuge fehlen, obwohl der Benutzer „Adminstatus“ besitzt. Unter anderem fehlt der wichtige Menüpunkt / das Icon „Erweiterungen“.

    Fehlende Menüpunkte / Icons unter der Kategorie „Adminwerkzeuge“.

    Auf Stackoverflow.com fand ich die Lösung für das Problem : TYPO3 admin backend modules are missing.
    Die 2. Antwort brachte mich auf die richtige Fährte.

    Aus welchem Grund auch immer, fehlte dem aus TYPO3 8 nach TYPO3 9 migrierten Admin-User die „System Maintainers“-Berechtigungen. Mit den „System Maintainers“- Rechten wird das Installtool von den bisherigen TYPO3 überflüssig. Die Installtool-Funktionalitäten wandern bei Admin-Usern mit „System Maintainers“-Rechten in das normale TYPO3 Backend.

    Um dem Admin-User die „System Maintainers“-Berechtigungen zu geben, muss man noch einmal das Install-Tool bemühen. Unter dem Menüpunkt Settings –> Manage System Maintainers kann man die TYPO3 User auswählen die „System Maintainer“ sein sollen.

    „System Maintainers“- Verwaltung im TYPO3 Installtool

  • Fehler: imap-login: Error: Failed to initialize SSL server context: Can’t load DH parameters: error:1408518A:SSL routines:ssl3_ctx_ctrl:dh key too small – Nach einen Upgrade von Debian 9 auf Debian 10 Buster funktioniert die Anmeldung an dem Dovecot IMAP Server nicht mehr.

    Nach dem Update von Debian Stretch auf Debian Buster, bei dem auch der IMAP Server Dovecot auf die Version 2.3.4.1 aktualisiert wurde, funktioniert die Authentifizierung nicht mehr. Bei Login-Versuchen sieht man in der Logdatei /var/log/dovecot.log folgende Fehlermeldung:

    imap-login: Error: Failed to initialize SSL server context: Can’t load DH parameters: error:1408518A:SSL routines:ssl3_ctx_ctrl:dh key too small

    Bei einer Webrecherche ergaben sich schnell einige Fundstellen zu dem Problem:

    In der Upgradedoku von Dovecot Version v2.2 to v2.3 wird darauf hingewiesen dass man eine neue Einstellung ssl_dh der Dovecot Config hinzufügen muss.


    ssl-parameters.dat file is now obsolete. You should use ssl_dh setting instead: ssl_dh=</etc/dovecot/dh.pem

    Lösungsschritte:

    • Erzeugen einer Datei dh.pem für die Diffie-Hellman Parameter
      • openssl dhparam -out /etc/dovecot/dh.pem 4096
        • Hinweis: Die Ausführung des Befehls kann durchaus mehrere Minuten dauern.
    • Ändern der Dovecot Config
      • Bearbeiten der Datei /etc/dovecot/dovecot.conf
      • Hinzufügen folgender Zeile am Ende der Datei:
        • ssl_dh=</etc/dovecot/dh.pem
    • Neustart des Dovecot Service

    Danach funktionierte die Authentifizierung mit Dovecot wieder wie vorher.

  • Die Apache SSL Client Zertifikatsauthentifizierung funktioniert nicht mehr. Fehler: Forbidden You don’t have permission to access this resource.Reason: Cannot perform Post-Handshake Authentication.

    Wenn z.B. nach einem Update auf Debian 10 Buster eine vorher funktionierende Apache SSL Client Certificate Authentication nicht mehr funktioniert und der Fehler

    Forbidden You don’t have permission to access this resource.Reason: Cannot perform Post-Handshake Authentication.

    auftritt, dann liegt es daran, dass es bei TLS1.3 Probleme mit der Authentifizierung mit Client Certificates gibt:

    Als kurzfristige Lösung kann man in der Apache SSL Config die Verwendung von TLS1.3 deaktivieren.
    vim /etc/apache2/mods-available/ssl.conf

    SSLProtocol all -SSLv3 -TLSv1.3

    Nach einem Reload der Apache Config funktioniert die Client Zertifikats Authentifizierung wieder.