IT Niedersachsen verwechselt Mailserver ;)

Aus der Reihe: „Was kann bei SMTP schon schief gehen“ heute die: IT Niedersachsen.

IT Niedersachsen verwechselt Mailserver 😉

Wenn man viel Infrastruktur hat, kann einem das schon mal passieren. Vor einigen Jahren hatte ich mal einen Beitrag ĂŒber die Stadt WolfenbĂŒttel im IT Sec Vortrag, weil deren Mailserver komische Zertifikate fĂŒr SMTP benutzt hatte, die keiner kennen konnte, weil selbst-signiert und fĂŒr interne Testserver gedacht. Damals hatte deren IT das Problem, es ĂŒberhaupt zu finden, weil die Microsoftlösung Ihnen einen vom Pferd erzĂ€hlt hatte 🙂

Vielleicht ist das jetzt so etwas Àhnliches:

Wenn man eine Email an eine Adresse schicken will, die von diesem Server bedient wird:

80.228.54.249 „inetmail23.niedersachsen.de“

Dann bekommt man im Exim das hier:

SSL verify error: certificate name mismatch: DN=“/C=DE/ST=Niedersachsen/L=Hannover/O=Land Niedersachsen/OU=IT.Niedersachsen, FG 24a/CN=inetmail14.niedersachsen.de

Weil das ausgelieferte Zertifikat nicht mit dem Hostnamen ĂŒbereinstimmt. Vermutlich wurde einfach nur das falsche Zertifikat verteilt. Witzig ist nur, daß es auf beiden Servern passiert ist, denn ein „host inetmail23.niedersachsen.de“ zeigt zwei verschiedene IPs an. Da darf man von einem Deployserverproblem ausgehen, also hat es keiner mit Handarbeit verteilt 🙂

 

Fedora: wie man mit RPM sein System auf IntegritĂ€t prĂŒft.

Heute geht es um DateiintegritĂ€t und wie man das mit RPM prĂŒft und ggf. behebt. Grund ist das Pinephone.

Fedora: wie man mit RPM sein System auf IntegritĂ€t prĂŒft.

Wenn man sein Pinephone zum ersten mal bootet, startet es mit dem Image auf der internen Storage mmcblk2. Will man etwas anderes Booten, so steckt man eine SD Karte rein, auf dem das Bootimage drauf ist. Das ist gerade am Anfang, wenn man viel Testet eine normale Sache, weil man die MicroSD Karte leicht wieder mit einem SD-Kartenreader am PC neu bespielen kann.

Wenn man aber zu an einen Punkt gekommen ist, wo das System gut genug funktioniert, möchte man es auf die interne Speicherkarte kopieren. Das könnt Ihr via rsync machen, oder Ihr kopiert die SD-Karte mit dem Tool dd rĂŒber. Das hat aber einen Haken: Von dem System habt Ihr gerade gebootet und das lĂ€uft noch. Da man die Karte im laufenden Betrieb nicht wechseln sollte, steht Ihr vor einem Problem. Rsync umgeht das, aber Systemfiles lassen nicht so einfach syncen. WĂŒrde man so z.b. ein Fedora 33 auf ein anderes Fedora 33 syncen, wĂŒrde es vermutlich laufen, aber (wie hier) ein Fedora auf Manjaro Syncen geht sehr wahrscheinlich voll in die Hose.

Wenn wir also dd steigt zwar die Erfolgschance, aber ein Datenverlust steht im RAM, weil die Programme auf der Partition rumwerkeln und die sich beim Kopieren Àndern. Also am besten ALLES was geht beenden: Desktop, Services, alles bis auf SSHd und das Netzwerk.

Schritt 1 – Ermitteln was drauf ist

Dazu fĂŒhrt Ihr „rpm -qa > rpms“ aus. Nicht vergessen das File nachher wieder zu löschen.

Schritt 2 – jedes Paket prĂŒfen

Dazu brauchen wir awk und ein klein wenig Bashmagie:

awk < rpms ‚{print „rpm -V –nolinkto –nomtime –nomode –nouser –nogroup –nordev –nodeps „$1;}‘ | bash > log

Das liest die Liste der RPMs Zeile-fĂŒr-Zeile ein und prĂŒft das Paket, ob die Checksummen mit den Dateien ĂŒbereinstimmen. Einige Tests sind absichtlich abgeschaltet worden, weil fĂŒr den Test, ob eine Datei beschĂ€digt ist oder nicht, nicht nötig. Ob ich da mal dran war und die absichtlich verĂ€ndert habe, war nicht die Aufgabe, kann man so aber auch machen, wenn man die –no Flags weglĂ€sst. „–nodeps“ sollte man aber drin lassen, weil sonst jedes Paket immer mit allen AbhĂ€ngigkeiten geprĂŒft wird und wir prĂŒfen eh alle einzeln 😉

Schritt 3 – Defekte Dateien finden

Da wir in Schritt 2 eine Log-Datei angelegt haben, werten wir die aus und lassen uns gleich die Paketnamen der defekten Dateien geben. Das „sort -u“ wirft doppelte raus:

grep „\.5\.\.“ log | grep -v “ c “ | grep -v “ d „| grep -v ^S | awk ‚{print „rpm -qf „$2;}‘ | bash | sort -u

.5… ist die Ausgabe, wenn die Datei beschĂ€digt ist und z.b. keine Configdatei ist. Configs können sich natĂŒrlich jederzeit Ă€ndern, deswegen sind die nicht gleich defekt.

Ein paar Beispiele was die Ausgaben so meinen:

S.5…… c /etc/ssh/sshd_config  Datei hat andere Checksumme, ist aber eine Configdatei
fehlend d /usr/share/man/fr/man1/manconv.1.gz Datei ist eine Dokumentation, nicht tragisch, wenn die nicht da ist.
fehlend /boot/efi/overlays/adau1977-adc.dtbo Datei fehlt und sollte aber da sein.
..5…… /usr/bin/mokutil Datei ist defekt und sollte ersetzt werden.

Schritt 4 – Reparieren

Nun haben wir eine Liste mit Paketnamen und mĂŒssen die nur noch reparieren. In meinem Fall waren es vier defekte Pakete:

dnf reinstall dcraw efibootmgr f2fs-tools mokutil -y

Das muß natĂŒrlich bei Euch so nicht passen, es könnte auch gut gehen oder andere Dateien betreffen!

Vom efibootmgr wissen wir jetzt, daß er gar nicht nötig ist auf einem Pinephone, weil das U-Boot benutzt und so gesehen kein EFI Bios vorhanden ist.

Ein Wort noch zum Pinephone:

Kopiert das System ruhig auf die interne Karte, weil das dann ca. 5x schneller ist: beim Booten, beim Runterfahren, Apps starten und updaten. Es lohnt sich wirklich.