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.

TYPO3 Extension Repository kann nicht mehr aktualisiert werden. Fehler: An exception occurred while executing; INSERT INTO tx_extensionmanager_domain_model_extension …….incorrect string value:

Beim Versuch bei einer TYPO3 Installation die Extension Repository zu aktualisieren trat folgender Fehler auf:

An exception occurred while executing; INSERT INTO `tx_extensionmanager_domain_model_extension ……. Incorrect string value: ‘\xC4\x85gol)’ for column `DBNAME`.`tx_extensionmanager_domain_model_extension`.`update_comment` at row 8

Dieser Fehler trat auf einem neuen Debian 10 Server mit alten TYPO3 Installationen auf. Bei Debian 9 funktionierte das Update der Repository noch ohne Probleme.

“Incorrect string value: ‘\xC4\x85gol)&#039” deutet auf ein Zeichensatz Problem hin. Bei einer Netzrecherche fand ich gleichartige Problem die nicht nur auf TYPO3 bezogen waren. Dort wurde vorgeschlagen den Zeichensatz der betreffenden Tabelle auf utf8mb4 zu konvertieren.
Glücklicherweise löste dies das Problem mit dem fehlgeschlagenen Repository Update in TYPO3. Anschließend musste noch die betreffende Tabelle geleert werden.

Lösung:
ALTER TABLE tx_extensionmanager_domain_model_extension CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

TRUNCATE table tx_extensionmanager_domain_model_extension;

Fehler: “Oops, an error occurred!” beim Updaten der TYPO3 Extension “Dynamic Content Elements (DCE)

Problem: Nach dem Update der TYPO3 Extension “Dynamic Content Elements (DCE)

tritt im Backend die Fehlermeldung “Oops, an error occurred!” auf.

Lösung: Dieses Problem lässt sich leicht beheben, indem man im Installtool von TYPO3 die Extension Autoload Informationen mit dem Befehl “Create autoload information for extension” neu aufbaut:

Danach funktioniert TYPO3 wieder ohne Probleme.

Wenn man ein DCE Update plant, öffnet man das Installtool am besten vor dem DCE Update in einem anderen Browserfenster. Dann ist die Lösung nur ein Klick weit entfernt.

Wenn man Shellzugriff auf die TYPO3 Installation kann man alternativ auch den Ordner “autoload” im Ordner typo3conf löschen.

TYPO3 8.7 form_legacy Wizard ausblenden / Code anzeigen / Form definition anzeigen / Hide Form Wizard

Bei der form_legacy Extension in TYPO3 8.7 kann man nicht wie bei der Form Extension in TYPO3 7 zwischen Form Code Definition und Wizard / WYGIWYS Editor / Assistent umschalten. Es wird standardmäßig nur der Wizard angezeigt. Um wieder Zugriff auf den Code der Form Konfiguration zu erhalten muss man das User TSConfig des aktuellen Benutzers anpassen.

Folgender Typoscriptbefehl blendet den Formwizard aus:

setup.default.tx_form.showWizardByDefault = 0

Quellen: 

 

 

 

TYPO3 8.7 Update der DCE RTE Flexform Konfiguration bei DCE Elementen aus TYPO3 7.6

Problem:

Durch den Wechsel des TYPO3 HTML Editors auf den CKEditor tritt bei einen DCE Inhaltselement mit einem RTE Element ein Problem auf, dass beim Speichern jedes Mal zusätzliche Leerzeilen zur Ausgabe hinzugefügt werden.

Beispiel der DCE HTML Ausgabe eines RTE Steuerelements mit alter Flexform Config (TYPO3 7.6) nach mehrmaligen speichern:

p><strong>Modernisieren Sie jetzt!&nbsp;</strong></p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>

Um dieses Problem zu beheben, muss man bei der TYPO3 8.7 DCE Definition das RTE Flexform Config updaten.

DCE RTE Flexform Konfig in TYPO3 7.6
<config>
    <type>text</type>
    <rows>5</rows>
    <cols>30</cols>
    <eval>trim,required</eval>
</config>
<defaultExtras>richtext[]:rte_transform[mode=ts_css]</defaultExtras>

DCE RTE Flexform Konfig in TYPO3 8.7

<config>
    <type>text</type>
    <rows>5</rows>
    <cols>30</cols>
    <eval>trim,required</eval>
    <enableRichtext>1</enableRichtext>
    <richtextConfiguration>default</richtextConfiguration>
</config>

Um das Update für alle DCE RTE Elemente in der Datenbank auf einmal zu erledigen, kann man dies direkt mit folgender SQL-Abfrage tun:

USE dbname;
update tx_dce_domain_model_dcefield set configuration=
'<config>
    <type>text</type>
    <rows>5</rows>
    <cols>30</cols>
    <eval>trim,required</eval>
    <enableRichtext>1</enableRichtext>
    <richtextConfiguration>default</richtextConfiguration>
</config>'
where configuration like '%rte_transform%';

Nach TYPO3 Update auf 8.7 werden bei DCE Inhalts- Elementen „Kopie 1“ oder „Kopie 2“ im Inhalt angezeigt

Die Ursache ist mir noch ein wenig unklar, warum nach dem Update auf TYPO3 8.7 bei kopierten Inhaltselementen des Plugins DCE die Header Spalten der tt_content Tabelle angezeigt werden. Darin befinden sich bei kopierten DCE Elementen die Zeichenfolge “Kopie 1”. Wobei die Zahl bei mehreren Elementen hochgezählt wird. Vorhanden waren die Einträge vor dem Update auf TYPO3 8.7 zwar auch schon, wurden aber nicht angezeigt. Erst nach dem TYPO3 Update haben die kopierten DCE Elemente einen h2 Header mit dem Inhalt “Kopie n”.

Eine Recherche hat zwei Lösungsvorschläge gebracht, die leider für mich nicht in Frage kamen.

Der erste Lösungsvorschlag war eine Typoscript Konfiguration

TCEMAIN.table.tt_content {
disablePrependAtCopy = 1
disableHideAtCopy = 1
}

Diese zeigte bei meiner TYPO3 Seite keine Wirkung. Die Header mit “Kopie 1” wurden immer noch angezeigt. Ich gehe davon aus, dass sich die Typoscript Einstellung nur auf neue kopierte Elemente auswirkt.

Der zweite Lösungsvorschlag war, die bei DCE Inhaltselementen standardmäßig ausgeblendete Spalte “Header” mittels “Sonstige” -> “Vefügbare Objekte” -> “Überschrift(header)” einzublenden und bei allen Inhaltselementen die Headerspalte manuell zu leeren.

Diese Lösung funktioniert zwar prinzipiell, ist aber bei umfangreichen TYPO3 Webseiten sehr aufwendig, da alle Inhaltselemente noch einmal bearbeitet werden müssen.

Nach einem Blick in die tt_content Tabelle der betreffenden TYPO3 Datenbank, kam mir die Idee das Problem auf Datenbankebene zu lösen.

update tt_content set header='' where header like '%Kopie%';

Mit dieser SQL Abfrage werden alle Header Elemente in der in der tt_content Tabelle geleert, die das Muster %Kopie% in der Spalte “header” enthalten. Nach einem Cachelöschen waren die unerwünschten Überschriften wie “Kopie 1” aus dem Inhalt der Webseite verschwunden.

Benchmark / Test: STRATO vServer V80 vs. STRATO Hardware Server D410

Hier sollen die STRATO – Hardware Server 400er Linie mit dem STRATO vServer Flaggschiff verglichen werden. Auf dem Papier sehen die Leistungswerte des größten STRATO vServers (V-Server Linux V80) nicht schlecht aus: 16CPU Kerne, 32GB Ram und 1TB HDD/SSD. Gegen diesen virtualisierten Server tritt ein dedizierter Hardwareserver mit vergleichbaren Werten an (Hardware Server Linux D410): 4 CPU Kerne, 8 Threads, 32GB RAM, 480GB SSD.

Stand 07/2018

Hier die Daten der beiden Server:

Bezeichnung €/Monat RAM CPU Cores CPU MHz HDD Inodes
Hardware Server Linux D410-81 63,00 € 32GB

4

3500

 480GB 28.991.488
Strato vServer Linux V80-49 30,00 € 32GB

16

2000

 1000GB 132.382.720

Beide Server wurden mit Debian 9 installiert. Als Benchmark wird Sysbench verwendet.

CPU Benchmark:

Befehl: sysbench –test=cpu –cpu-max-prime=10000 –num-threads=XX run

Gemessen wird hier die Zeit in Sekunden. (Kleinere Werte besser)

Threads
Bezeichnung

1

2

4

8

16

32
Hardware Server Linux D410-81

7,3

3,8

1,9

1,1

1,1

1,1
Strato vSserver Linux V80-49

16,3

8

4,6

2,7

2,3

2,1

Hier geht der Hardwareserver klar als Sieger aus dem Rennen. Obwohl der vServer auf dem Papier 4-mal so viele CPU Kerne hat, ist der Hardwareserver bei allen Threadzahlen schneller als der vServer. Das könnte neben dem Virtualisierungsoverhead unter anderem daran liegen, dass der vServer CPU Takt auf 2000 MHz limitiert ist. Bei einem Thread ist die Hardware CPU mehr als doppelt so schnell wie die vServer CPU.

RAM Benchmark:

Befehl: sysbench –num-threads=xx –test=memory –memory-block-size=1M –memory-total-size=100G

Gemessen wird hier die Zeit in Sekunden. (Kleinere Werte besser)

Threads
Bezeichnung

1

2

8

32
Hardware Server Linux D410-81

8,1

4,4

2,2

2,2
Strato vServer Linux V80-49

20,4

12,2

6,5

5,4

Beim RAM-Benchmark zeigt sich wieder die Überlegenheit des Hardwareservers. Beide Server haben 32GB RAM, doch der Hardwareserver benötig für das Beenden des Benchmarks, über alle Thread Anzahlen, weniger als die Hälfte der Zeit.

FILE-IO Benchmark:

Befehl: sysbench –test=fileio –file-total-size=8G –file-test-mode=rndrw –init-rng=on –max-time=300 –max-requests=0 –file-block-size=4K run

Gemessen wird hier Datenübertragungsrate in MB/s. (Größere Werte besser)

Bezeichnung

MB/s
Hardware Server Linux D410-81

34,23
Strato vServer Linux V80-49

12,79

Auch hier zeigte sich, dass die beim vServer beworbene “topmodernen Hochleistungs-Speicherplattform HP 3PAR – für allerhöchste Zugriffsstabilität, sowie ultraschnelle Lese- und Schreib-Geschwindigkeiten” nicht gegen lokalen SSD Speicher bestehen kann. Der Hardwareserver erreichte beim Sysbench Filie-IO ReadWrite Benchmark fast die dreifache Leistung gegenüber dem vServer.

MySQL Online-Transaction-Processing Benchmark:

Befehl: sysbench –test=oltp –oltp-table-size=10000000 –mysql-db=sysbench –mysql-user=sysbench –mysql-password=password –max-time=60 –max-requests=0 –num-threads=xx –oltp-reconnect-mode=random run

Gemessen wird hier absolute Anzahl der durchgeführten Datenbanktransaktionen. (Größere Werte besser)

Dieser Benchmark bildet am besten einen realistischen Workload ab bei dem CPU, RAM und FILE IO zusammenspielen müssen.

Hier kann man, wie bei den Einzelergebnissen der CPU, RAM und File-IO Benchmarks sehen, dass der Hardwareserver fast die dreifache Leistung gegenüber erreicht.

Fazit:

Obwohl der STRATO vServer auf dem Papier die gleiche oder sogar bessere Ausstattung gegenüber dem dedizierten Hardwareserver hat, kann er in keinem Benchmark gegen diesen bestehen. Beim aussagekräftigsten MySQL Benchmark erreicht der Hardwareserver fast die dreifache Leistung gegenüber dem vServer.

Kurz zusammengefasst: Hardware kann man nur durch noch mehr Hardware ersetzten. Selbst der größte vServer v80 kommt in Punkto Performance nicht an einen einfachen dedizierten Hardwareserver heran.

Tipp: Kostenloses Homebanking Programm/Onlinebanking Programm Jameica/Hibiscus

Nachdem ich mich jahrelang mit überfrachteten und schlecht bedienbaren Onlinebanking-Programmen wie Starmoney, Lexware, WISO Mein Geld herumgeärgert hatte, sprang mir heute die Meldung “Nutzungsperiode abgelaufen” beim Start von WISO Konto Online entgegen. Statt ein Abo für die Software abzuschließen, machte ich mich auf die Suche nach Alternativen. Dabei musste ich feststellen, dass es gerade bei den Onlinebanking-Programmen sehr wenig Auswahl gibt. Eine Suche nach “online banking software” bei Amazon brachte fast nur WISO und Lexware Software. Dann bemühte ich Google. Dabei sah ich, dass es sogar eine kostenlose Homebanking -Software gibt. Jameica/Hibiscus von Olaf Willuhn . Zuerst war ich skeptisch, aber nach dem Download und dem Start der Software lies sich mein Girokonto mit optischen chipTAN Verfahren so schnell und problemlos einrichten, dass sich meine Skepsis in Neugierde wandelte. Der Funktionsumfang des Programms deckt genau das ab was ich von einem Onlinebanking-Programm erwarte:

  • Einfaches Einrichten des Kontos
  • Schneller Abgleich der Umsätze
  • Ein Kategoriensystem um die einzelnen Umsätze Kategorien zuzuordnen
  • Ein flexibler Mechanismus um regelbasiert Umsätze automatisch bestimmten Kategorien zuzuordnen
  • Schnelle und effiziente Möglichkeit Überweisungen zu tätigen
  • Unterstützung des optischen chipTAN Verfahrens
  • Adressverwaltung von Überweisungsempfängern

Ich werde dem Programm auf jeden Fall eine Chance geben. Im Moment sieht es sehr vielversprechend aus. Gerade im Vergleich zu der WISO Onlinebanking-Software, die mich auch nach Jahren nicht überzeugen konnte.

Jedem der auf der Suche nach einem alternativen Onlinebanking-Programm ist, kann ich nur empfehlen sich Jameica/Hibiscus anzuschauen: http://www.willuhn.de/products/hibiscus/

Ansible: Verwenden einer Variable als Name einer Liste mit with_items

Nach dem Update von Ansible 1.7 auf Ansible 2.4 funktionierte eine Ansble Rolle nicht mehr. Bei dieser Rolle wird der Wert einer Variable als Namen einer Liste in einem with_items Konstrukt verwendet.

In Ansible 1.7 funktionierte folgender Syntax noch:

VARS main.yml
---
chooselist: list1

list1:
- { port: '443', src: 'any', proto: 'tcp'}
- { port: '80', src: 'any', proto: 'tcp'}

list2:
- { port: '22', src: 'any', proto: 'tcp'}
- { port: '53', src: 'any', proto: 'tcp'}

TASK:main.yml
---
- name: with_items_test
  debug: msg="{{ item.port }}|{{ item.src }}|{{ item.proto }})"
  with_items: "{{ chooselist }}"

In Ansible 2.4 wird bei obigen Syntax ein Fehler ausgegeben: “The task includes an option with an undefined variable.”

Nach einiger Suche fand ich in folgenden Beitrag “SOLVED: ansible 2.0: with_items: “{{ variable }}_fixstring” resolve issue #14032” die Lösung.

Damit nun Variablen als Namen von Listen mit with_items verwendet werden können, muss man statt

with_items: "{{ chooselist }}"

folgenden Syntax mit dem vars Schlüsselwort verwenden:

with_items: "{{ vars[chooselist] }}"

Der komplette, in Ansible 2.4, funktionierende Task sie dann wie folgt aus aus:

---
- name: with_items_test
  debug: msg="{{ item.port }}|{{ item.src }}|{{ item.proto }})"
  with_items: "{{ vars[chooselist] }}"