Monthly Archives: November 2024

An die IT der Stadt Braunschweig in Sachen MAILSERVER – 2024 Edition

Posted on by

Ihr erinnert Euch noch an diesen Artikel aus dem Jahr 2021?

An die IT der Stadt Braunschweig in Sachen MAILSERVER

Da gibt es ein unrühmliches Update 😀

An die IT der Stadt Braunschweig in Sachen MAILSERVER – 2024 Edition

Im Jahr 2021 hatte ich einen offenen Brief an die IT-Verantwortlichen der Stadt Braunschweig geschickt, den könnte Ihr digital oben lesen. Weil wir gerade Mailserverprobleme einer anderen Stadtverwaltung bearbeiten, dachte ich mir, schau doch mal nach, was daraus geworden ist. Hier die 2024 – Edition 😀

Liebe IT-Verantwortliche der Stadt Braunschweig,

wie wir Euch im Jahre 2018, und dann nochmal im Jahr 2021, mitgeteilt haben, sind Eure SSL-Zertifikate im Mailserver nichts wert. Glauben Sie schon wieder nicht? Bitte schön:

# openssl s_client –connect mailin02.braunschweig.de:25 -starttls smtp -verify_hostname mailin02.braunschweig.de
CONNECTED(00000003)
depth=0 CN = braunschweig.de
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = braunschweig.de
verify error:num=62:hostname mismatch
verify return:1
depth=0 CN = braunschweig.de
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = braunschweig.de
verify return:1
—
Certificate chain
0 s:CN = braunschweig.de
i:C = US, O = Let’s Encrypt, CN = R10
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Aug 20 10:47:48 2024 GMT; NotAfter: Nov 18 10:47:47 2024 GMT
—
Server certificate
—–BEGIN CERTIFICATE—–
MIIE7jCCA9agAwIBAgISBJuzUCXTWYKiCMJPi/QRdpaNMA0GCSqGSIb3DQEBCwUA

Jetzt heißen Eure Mailserver für die Domain braunschweig.de aber nicht braunschweig.de sondern:

;; QUESTION SECTION:
;braunschweig.de. IN MX

;; ANSWER SECTION:
braunschweig.de. 300 IN MX 10 mailin02.braunschweig.de.
braunschweig.de. 300 IN MX 20 mailin01.braunschweig.de.

Also kann auch hier wieder nicht festgestellt werden, daß wir wirklich mit dem richtigen Mailserver reden.

Damit gilt leider, was auch schon 2018 galt: schlecht gesetuped.

Es gibt aber auch Positives zu melden: Die Stadt nutzt Let’s Encrypt für die Zertifikate und kann TLS 1.3, was, wie wir leider feststellen müssen, auch in 2024 keine Selbstverständlichkeit ist.

Neue Serverhardware fürs Blog

Posted on by

Zugegeben, es war nicht das Blog, daß hier ausschlaggebend war, aber „Hey, neue Hardware“ \o/

Neue Serverhardware fürs Blog

Die neue CPU „Intel Xeon w5-2445“ des Servers hat 100% mehr Leistung pro Kern, das merkt man auch sofort wenn man mit WordPress arbeiten muß \o/

Dazu kommt noch ein schnelleres RAM, denn vorher war es DDR4 2133 MHZ ( 2400 standen drauf, hat der Chip an dem alten Mainboard wohl nicht geschafft ), jetzt  ist es DDR5 4800 MT/s \o/ Das trägt natürlich nicht unwesentlich dazu bei, daß die CPU ihre Leistung auch voll entfalten kann.

Für die Hardware interessierten unter Euch, so sieht das im Detail aus:

DNF5 – neue Reihenfolge von Argumenten

Posted on by

DNF5 ist toll, weil es schnell ist. DNF5 ist nicht ganz so toll, weil trotz des Wrappers für den Befehl dnf, es leider nicht 100% kompatibel ist.

DNF5 – neue Reihenfolge von Argumenten

DNF5 räumt mit alten Pythonzöpfen auf und ist in C++ implementiert, was es deutlich schneller macht als das alte DNF4, aber leider ist es eben auch eine Neuprogrammierung. Diese Neuprogrammierung hatte nun zur Folge, daß z.B. –allowerasing und –skip-broken, die man oft bei distro-syncs braucht, nicht mehr erkannt werden, wenn sie vorne in der Zeile stehen.

Diese müssen, weil DNF5 jetzt kontextsensitiv ist, aber ans Ende der Befehlszeile gestellt werden. Leider hat man vergessen darauf hinzuweisen, was zu einigem Frust geführt hat. Daher hat sich das RPM Team entschlossen, in der Main-Man-Page von DNF einen Hinweis einzufügen.

Beispiel:

DNF 4: dnf –allowerasing –releasever=40 –setopt=deltarpm=false distro-sync 
DNF 5: dnf –releasever=40 –setopt=deltarpm=false distro-sync –allowerasing