TYPO3 CMS: Update von Version 6.2.14 auf 6.2.15 – Extension Manager weiße Seite

Nach dem Update des TYPO3 CMS von der Version 6.2.14 auf 6.2.15 kann es dazu führen, dass im TYPO3 Backend das Modul des Extension Managers nicht mehr aufgerufen werden kann. Bei einem Klick auf den Extension Manager erscheint eine weiße / leere Seite ohne Fehlermeldungen oder nur rotierendem Ajax-Loader Symbol.

Bei einem Update über Composer oder das manuelle Einspielen der neuen TYPO3 CMS Version 6.2.15, werden die FrontEnd- als auch Backend- und Systemcaches vom TYPO3 CMS nicht geleert, sodass im PHP Opcache oder alternativ eingesetzte PHP-Caches die Daten aus der vorherigen Version <= 6.2.14 vorliegen. Die Mischung aus den alten TYPO3 PHP-Klassen und den neuen aus dem Update führen zu einer Inkonsistenz. Die einfachste und schnellste Abhilfe für die Lösung des Problems ist … weiterlesen »

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

KVM / Libvirt: Virtuelle Maschine zu neuem Server migrieren

Ein frischer neuer Server mit einem KVM-Hypervisor steht bereit und es sollen bestehende virtuelle Maschinen (VM) vom alten KVM-Hypervisor zu einem neuen KVM-Hypervisor übertragen oder umgezogen werden. Über die Kommandozeile und dem Tool "virsh" lässt sich der VM-Guest (Gast - Virtuelle Maschine) mit seiner Konfiguration exportieren. Je nach VM-Typ muss unterschiedlich vorgegangen werden. Liegt die Gast-VM als Datei-Container vor, so kann die Datei (z.B. qcow2) direkt zum neuen Server kopiert werden. Handelt es sich um eine Gast-VM auf Basis eines Logical Volume (LVM), muss diese vorher mittels "DD (DiskDump) oder "qemu-img convert" exportiert werden.

Eingerichtet unter Ubuntu 14.04 LTS mit "qemu-system-x86" (QEMU / Libvirt / KVM) in der Version 2.6.x. Die Konfiguration kann je nach Ubuntu-/Debian- und QEMU / Libvirt / KVM-Version abweichen.

Hinweis: Dies ist keine KVM / Libvirt Live-Migration!

Vorgehensweise zur Migration der KVM-Guests zu einem neuen Server

  • Virtuelle Maschine (Guest) herunterfahren
  • Exportieren der Konfigurationen der virtuellen Maschine
  • Kopieren / Transferieren der virtuellen Maschine auf den neuen Server. (z.B. via Rsync oder SCP)
  • Definieren der virtuellen Maschine auf dem neuen KVM-Hypervisor
  • Virtuelle Maschine auf dem neuen KVM-Hypervisor starten
  • Alte virtuelle Maschine löschen

… weiterlesen »

Tags: , , , , , , , , , ,
von Jörg am 08.01.2015, unter Linux/Server. Keine Kommentare

Postfix (MTA): Smart Host (Satellitensystem – Relay-Mailserver) Setup mit STMP-Authentifizierung

Dieser Artikel beschreibt in fünf einfachen Schritten die Einrichtung eines Postfix-Mail-Server (MTA) als Smarthost / Satellitensystem. Alle E-Mails werden über den Mail-Relay-Server geleitet und versandt. Zur Anmeldung an den SMTP-Server wird die STMP-Authentifizierung mit dem SASL-Support verwendet. Wichtig ist hierbei, dass der Postfix-Dienst mit dem SASL-Support kompiliert wurde. Wurde Postfix über einen Paketmanager (apt oder yum) installiert, ist die SASL-Unterstützung bereits vorhanden.
Das unten genannte Beispiel wird auf einen Mailserver des Providers ALL-INKL.COM angewandt.

Eingerichtet unter Ubuntu 14.04 LTS mit Postfix in der Version 2.11.0. Die Konfiguration kann je nach Ubuntu-/Debian- und Postfix-Version abweichen.

1. Erstellung der Passwort-Map-Datei
Notwendige Datei /etc/postfix/relay_passwd zur Anmeldung an den SMTP-Relay-Mailserver erstellen.
Inhalt der Datei /etc/postfix/relay_passwd:

 w00XdXXX.kasserver.com BENUTZERNAME:PASSWORT

Hinweis: Mail-Relay-Server, Benutzernamen und Passwort ersetzen! Steht ein STMP-Fallback-Relay zur Verfügung, muss eine zweite Zeile in der /etc/postfix/relay_passwd Datei erzeugt werden. Ebenfalls mit Relay-Host, Benutzername und Passwort.

2. Setzen der richtigen Berechtigungen für die Datei

chown root:root /etc/postfix/relay_passwd
chmod 600 /etc/postfix/relay_passwd

3. Erstellen einer Hashdatei auf Basis der relay_passwd-Datei … weiterlesen »

Tags: , , , , , , , ,
von Jörg am 05.01.2015, unter Linux/Server. 4 Kommentare

Ubuntu 14.04 LTS: systemd-udevd – failed to execute hal/udev_event

Nach einem Update von Ubuntu 12.04 LTS auf 14.04 LTS kommt es bei zahlreichen Installationen zu der Fehlermeldung "systemd-udevd[395]: failed to execute '/lib/udev/socket:@/org/freedesktop/hal/udev_event' 'socket:@/org/freedesktop/hal/udev_event': No such file or directory". Die Fehlermeldung erscheint nach einem Server-Neustart im "dmesg"-Log und direkt im Boot-Screen.

Diese Fehlermeldung verursacht das Distributionspaket "HAL". HAL steht für "Hardware Abstraction Layer" und bildet eine Zwischenschicht zwischen Hardware und Software. Diese Zwischenschicht abstrahiert die die Zugriffe der Software auf die Hardware. Ab Ubuntu 10.04 Lucid Lynx entfällt HAL komplett, wurde jedoch noch bis Ubuntu 12.04 LTS als "veraltetes" Paket mitgeführt und im UDEV eingesetzt. Mit Ubuntu 14.04 LTS wurde der Hardware Abstraction Layer (HAL) komplett entfernt und … weiterlesen »

Tags: , , , , , , ,
von Jörg am 30.12.2014, unter Linux/Server. Keine Kommentare