Fedora: nfs-utils 2.5.4 nicht funktional

Einen Fall von Load 200 bei einem Idlefaktor von 96% sieht man nicht alle Tage, also schauen wir uns den mal an wie das mit NFS zusammenhängt 😉

Fedora: nfs-utils 2.5.4 nicht funktional

Schreck in der Morgenstunde: „Email vom Server : Load 100+“ Da hatte ich schon eine böse Vorahnung, daß ich per SSH nicht mehr in diesen Server reinkomme und den Hart rebooten muß. Ihr könnt Euch vorstellen, daß ich sehr überrascht war, als der Login flott und ohne Probleme ablief. Ein Blick in TOP und die Load zeigte tatsächlich 111 an. Etwas später waren es 150, dann 180 und irgendwann wurde die 200 durchbrochen (vermutlich), aber da habe ich nicht mehr hingesehen 😉

Jetzt ist das ein sehr bizarres Bild, wenn man eine Load von 180 im Top sieht, aber nur einen Prozess mit 10% CPU Last überhaupt arbeiten will. Die Load beschreibt das Verhältnis von cpuwollenden Prozessen zur Anzahl der Kerne einer CPU, was voraussetzt, daß es Prozesse mit CPU Verbrauch gibt, gab es aber nicht 😀

Also schauen wir uns pstree an, jede Menge Prozesse, aber nichts steht, alles arbeitet „normal“. Und dann stehst Du da als Admin und verstehst die Welt nicht mehr:  Load 180+, die CPU langweilt sich zu Tode, und alle CronJobs und Services ( Web, FTP, Mail etc. ) laufen wie am Schnürchen.

Bevor ich das auflöse, gebe ich den erfahrenen Admins Gelegenheit das nochmal zu durchdenken 🙂

5

4

3

2

1

Auflösung

NFS

Ok, ich kann Eure Gesichter jetzt förmlich sehen 🙂 Ich habe es auch nur durch Zufall gefunden, weil … Trommelwirbel … es im /var/log/messages einen Hinweis gab, daß gegen 6 Uhr morgens ein NFS Server nicht reagiert hat. Es war also nicht einmal der Server mit der Load der das Problem hatte, sondern der Fileserver 😉

Der NFS Mount funktionierte nicht mehr, wurde aber via Webserver Repository regelmäßig von allen Servern im Cluster mit Anfragen bombardiert, ob es neue Pakete gibt. Jede dieser Anfragen erzeugte einen „httpd“ Prozess, der aber keine Leistung ziehen konnte, es aber wollte, weil die IO zum Fileserver stillstand. Jetzt fallen ein paar mehr httpd Prozesse auf einem Webserver nicht wirklich auf.

So, damit war geklärt wieso wir eine Load von knapp 200 hatten, aber wieso ging der Mount nicht mehr?

Kurz ein paar Grafiken und Zahlen für Euch:

Die einzige reale CPU-Last war das nächtliche Backup 😉Der Graph wird nur alle 5 Minuten erzeugt, daher die leicht abgeflachte Spitze

und so sah das in Zahlen aus, minütlich ab 07:07:2021-08:02:01:

LOAD: 128.25 112.19 107.39 12/1536 3283086
LOAD: 162.90 124.62 111.94 12/1597 3283496
LOAD: 182.58 137.25 117.08 13/1608 3283850
LOAD: 190.78 147.84 121.98 16/1598 3284211
LOAD: 194.96 156.89 126.72 9/1582 3284999
LOAD: 195.70 164.04 131.06 14/1661 3285411
LOAD: 195.92 169.87 135.14 11/1649 3285732
LOAD: 196.50 174.77 139.00 10/1659 3286091
LOAD: 180.98 175.53 141.56 23/899 3286449
LOAD: 67.34 143.85 132.80 12/846 3287234
LOAD: 25.92 117.98 124.59 14/859 3287613
LOAD: 11.42 97.05 116.97 11/856 3287959

Das NFS UPDATE

Vor ein paar Tagen gab es ein NFS Update:

2021-07-07T04:01:45+0200 SUBDEBUG Upgrade: libnfsidmap-1:2.5.4-0.fc33.x86_64
2021-07-07T04:01:45+0200 SUBDEBUG Upgrade: nfs-utils-1:2.5.4-0.fc33.x86_64
2021-07-07T04:01:46+0200 SUBDEBUG Upgraded: nfs-utils-1:2.5.3-2.fc33.x86_64
2021-07-07T04:01:46+0200 SUBDEBUG Upgraded: libnfsidmap-1:2.5.3-2.fc33.x86_64

was zu diesem Resultat führte:

# systemctl status nfs-mountd
● nfs-mountd.service – NFS Mount Daemon
Loaded: loaded (/usr/lib/systemd/system/nfs-mountd.service; static)
Active: failed (Result: exit-code) since Wed 2021-07-07 09:20:22 CEST; 9s ago
Process: 4925 ExecStart=/usr/sbin/rpc.mountd (code=exited, status=0/SUCCESS)
Main PID: 4928 (code=exited, status=1/FAILURE)
CPU: 43ms

Jul 07 09:20:22 XXX systemd[1]: Starting NFS Mount Daemon…
Jul 07 09:20:22 XXX rpc.mountd[4928]: Unable to watch /proc/fs/nfsd/clients: No such file or directory
Jul 07 09:20:22 XXX systemd[1]: Started NFS Mount Daemon.
Jul 07 09:20:22 XXX systemd[1]: nfs-mountd.service: Main process exited, code=exited, status=1/FAILURE
Jul 07 09:20:22 XXX systemd[1]: nfs-mountd.service: Failed with result ‚exit-code‘.

Es blieb nur das Downgrade übrig:

dnf downgrade https://kojipkgs.fedoraproject.org//packages/nfs-utils/2.5.3/2.fc33/x86_64/libnfsidmap-2.5.3-2.fc33.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/nfs-utils/2.5.3/2.fc33/x86_64/nfs-utils-2.5.3-2.fc33.x86_64.rpm

Aber danach, lief der NFS Server wieder normal und die Probleme verschwanden.

Emergency Bugreport ist erstellt, ich fürchte Test-Driven-Development gibt es nicht überall 🙁

Sicherheitslücke in RPM: alte Keys werden nicht ungültig

Wie ZDNET gerade berichtet, haben RPM / DNF System wie Fedora, CentOS , RHEL und andere ein kleines Problem mit einer möglichen Supply-Chain-Attack.

Sicherheitslücke in RPM: alte Keys werden nicht ungültig

RPM Pakete aus Distro Repos werden i.d.R. signiert mit dem Key der jeweiligen Distro. RPM / DNF prüfen nach dem Download die Signatur des Pakets und nur wenn die gültig ist, wird das Paket installiert oder aktualisiert.

Die Prüfung ist leider nicht vollständig, weil alte Schlüssel nicht ungültig werden, da keine Revocationliste gefragt wird, ob der Key nicht zurückgezogen oder abgelaufen ist.

Das führt zu einer Supply-Chain-Attacke die uns allen dumm auf die Füsse fallen kann, wenn jemand die Repo Mirrors knacken sollte um dort geänderte Pakete mit alten Keysignaturen zu versehen. Damit wäre die Sicherheit der ganzen Installation gefährdet. Erschweredn kommt hinzu das immer noch unsignierte Pakete akzeptiert werden, auch wenn die GPG Signaturenprüfung aktiviert ist, meinen jedenfalls die Finder der Lücke.

Zwei Workarounds sind denkbar:

  1. Mirrorliste der Repos abschalten und nur noch die Hauptserver von Fedora /CentOs/ RHEL benutzen. Temporär wäre das eine Maßnahme, aber es belastet die Hauptserver kräftig.
  2. Die alten Keys vom System entfernen, dann sind die Signaturen nicht prüfbar => Problem erst einmal gelöst, außer es lassen sich wirklich unsignierte Pakete installieren, das wäre fatal.

Quelle: https://www.zdnet.com/article/major-linux-rpm-problem-uncovered/

Wie man von einer nachgerüsteten NVME SSD bootet

Meine langjährige Linux-Notlösung ging letzte Woche eine innige Verbindung zwischen Mainboard und Netzteil ein, das führte leider zu neuer PC-Hardware, wovon Ihr jetzt allerdings profitiert 😉

Wie man von einer nachgerüsteten NVME SSD bootet

Hier eine Impression der neuen permanenten Verbindung zwischen Mainboard und Netzteil:

ATX 12V Leitung ins Mainboard

Nur mit Gewalt konnten Buchse und Stecker getrennt werden. Eine Inspektion ergab dann, daß drei Spannungswandler, die befinden sich unter dem Kühlkörper links im Bild, ein bisschen zu warm geworden sind.

Hinweis: Für alle Linux am Dienstag Teilnehmer, abweichend zum gestrigen Textchat, gibt es bei den Anweisungen für die UUIDs noch eine kleine Erweiterung wo man die ersetzen muß.

Der neue RYZEN 5600X

Weil ich mir gleich was vernünftiges kaufen wollte, kam ein ASROCK B550µ Pro4 und ein RYZEN 5600X in den Warenkorb, noch NVME SSD (Samsung 1TB), RAM und Netzteil dazu gepackt und beim Großhändler sammeln lassen.

Das Board kannte ich einem früheren Einkauf und entsprechend wußte ich, daß diese Hardware mit Linux  laufen würde. Laufen ist in dem Fall übrigens glatte Untertreibung, Rennen wäre treffender, weil die NVME SSD in dem Setup 7 GB/s lesend schafft 😀

Da ich den PC für die Arbeit brauchte, war ein funktionierendes System an Tag 1 erst einmal wichtiger, als von der NVME SSD booten zu können, also wurde die HW nur zusammen gesteckt und die alte SATA SSD gebootet. Lief sofort ohne zu murren. Der Arbeitstag neigte sich dem Ende zu, also war es Zeit die SATA SSD auf die NVME SSD zu clonen und die Umstellung zu machen.

Nun ist mein Fedora System von 2014 und dessen Bootconfig weiß noch nichts von NVME. Also muß man das erst nachrüsten und ein Initramfs bauen, daß auch passende NVME Treiber hat. Dummerweise wusste ich das nicht, als die ich die SSD geclont habe 🙁 Ergebnis: „Geil, bootet von NVME .. ähhhhhh!?!?!“ Weil der Bootprozess vor dem Entschlüsseln der LUKS Paritionen einfach stehen blieb.

Zwei Möglichkeiten

Entweder VOR dem Clonen das neue Initramfs bauen, was deutlich einfacher ist, oder nochmal von der alten SSD Booten, Initramfs neubauen und die erzeugten Files von Hand rüberkopieren.

So, oder so, sieht der richtige Weg so aus:

  1. NVME-Treiber hinzufügen

    echo „add_drivers+= \“ nvme \““ > /etc/dracut.conf.d/nvme.conf
    # initramfs für aktiven Kernel neubauen
    dracut -f
  2. Disk Clonen

booten von einem Livestick
sudo su
dd if=/dev/quelle of=/dev/nvme0n1 bs=64M status=progress

Bei einer 1 TB SSD dauert das so 21-23 Minuten, da die SATA Geräte auf den meisten PCs mit 6 Gb/s angebunden sind, was ein theoretisches Maximum von 512 MB/s erlauben würde, aber 480 MB/s sind realistischer 😉

Wenn man die alte Platte nicht mehr benutzen will ist hier Schluß, die Platte muß dann aber auch gleich vom PC entfernt oder neu formatiert werden. Wieso, wird gleich klar werden.

Oder Ihr wollt mal wissen, was der Onkel Doktor machen müßte um die neue NVME SSD parallel zur alten SATA SSD booten zu können 🙂 Wir haben die Platte geclont und damit auch alle UUIDs zur identifizierung von Partitionen und Containern. UUIDs zeichnen sich durch eine gewisse EINMALIGKEIT aus, sprich, doppelte UUIDs produzieren lustige Fehler beim Bootprozess 😀

Gestern beim Linux am Dienstag kam die Frage auf, wieso ich nach dem Clonen nicht einfach die SATA SSD platt gemacht habe: Redundanz. Fällt die NVME SSD aus, habe ich noch ein System, das garantiert bootet.

Wie man die UUIDs von LUKS und EXTx ändert

Der Einfachheit

halber nehmen wir das „Gnome-Laufwerke“ Tool zur Hand um die alten UUIDs zuermitteln, da wir da visuell sehen können, ob das auch die richtige Partition ist. Man kann das auch in der Konsole ablesen, aber das kann leicht zu Verwechselungen führen:

$ lsblk -t -f
NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
nvme0n1 0 512 0 512 512 0 none 1023 128 0B 
├─nvme0n1p1 0 512 0 512 512 0 none 1023 128 0B ext4 1.0 Boot 4d2061ec-d538-4c88-aeb7-3fb0f3f4cd07 234,6M 46% /boot
├─nvme0n1p2 0 512 0 512 512 0 none 1023 128 0B crypto_LUKS 1 9d2595b2-a35c-48c1-a839-bb54c1a96597 
│ └─luks-9d2595b2-a35c-48c1-a839-bb54c1a96597 0 512 0 512 512 0 128 128 0B ext4 1.0 9d2595b2-a35c-48c1-a839-bb54c1a96597 659,9G 22% /
└─nvme0n1p3 0 512 0 512 512 0 none 1023 128 0B crypto_LUKS 1 ed009ed3-118c-465d-9b89-9b2a4f5cc3f3 
  └─luks-ed009ed3-118c-465d-9b89-9b2a4f5cc3f3 0 512 0 512 512 0 128 128 0B swap 1 46da0d80-21fb-45b7-8567-ba047de66cb6 [SWAP]

Einfacher ist das über das GNOME Laufwerke Tool:

LUKS

Filesystem in eine LUKS Container

Schritt 1 wäre jetzt auch erst einmal neue UUIDs zu erzeugen, was unter Fedora leicht mit dem Befehl „uuidgen“ gemacht werden kann. Andere Distro haben den Befehl nur als „uuid“ im Angebot.

WARNUNG:
Die hier gezeigten Anweisungen können in den falschen Händen Schaden an Ihrem System anrichten, deswegen erfolgt alles, was Sie jetzt machen auf eigene Gefahr!

WICHTIG: Bei Verwendung von LUKS darauf achten, daß die LUKS-Partition und die darin enthaltene Partition die gleiche UUID haben!

HINWEIS: der Befehl „replace“ wird von MYSQL/MARIADB zur Verfügung gestellt! Man kann die Anpassungen auch mit einem Texteditor machen, sollte man aber zwecks Reduzierung von Fehlerqellen nicht machen.

Alternativ könnte man sed -e „s/ALTE UUID/NEUE UUID/g“ < file >file.1; mv file.1 file machen, aber dann läuft man Gefahr die Rechte und Besitzer zu ändern.

Alles was wir jetzt machen, findet auf einer LIVE DISK statt, also im ungebooteten Zustand. Die Filesysteme sind alle EXT4, für abweichende Filesystem müßt Ihr Euch selbst was ausdenken 😉

Los geht’s :

A) Die Bootpartition

a) mit „Laufwerke“ das Gerät identifizieren: z.B. /dev/nvme0n1p1
b) ALTE UUID ermitteln ( wegkopieren in Texteditor ! )
c) tune2fs /dev/nvme0n1p1 -U „NEUE UUID“
d) BOOT + SYSTEM Partion der NVME anmelden
e) UUIDs ersetzen:
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/boot/grub2/grub*
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/boot/loader/entries/*
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/System/etc/fstab
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/System/etc/default/grub

*f) Partionen wieder abmelden

*) Das Abmelden ist natürlich optional, wenn Ihr mehrere Ersetzungen machen müßte, dann können die natürlich gemountet bleiben 😉

B) jede andere Partition

Jenachdem wieviele man hat, kann man das auch alles zusammen machen!

Wichtig: Jede Partition hat ihre eigene UUID, doppelte darf es nicht geben!

a) mit „Laufwerke“ das Gerät identifizieren: z.B. /dev/nvme0n1p2
b) ALTE UUID ermitteln ( wegkopieren in Texteditor ! )
c) tune2fs /dev/nvme0n1p2 -U „NEUE UUID“
d) BOOT + SYSTEM Partion der NVME anmelden
e) UUIDs ersetzen:
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/boot/grub2/grub*
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/boot/loader/entries/*
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/System/etc/fstab
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/System/etc/default/grub

f) Partionen wieder abmelden

Das waren die Filesysteme, kommen wir zu den LUKS Containern. Wer kein Luks hat, der ist jetzt natürlich fertig 🙂

Bei LUKS Partitionen ist das Vorgehen im Prinzip das Gleiche, nur die Befehle sind andere, weil LUKS kein Filesystem ist, aber eins zur Verfügung stellt nach dem Aufschliessen.

C) Für jede LUKS Partition

a) mit „Laufwerke“ das Gerät identifizieren: z.B. /dev/nvme0n1p2
b) ALTE UUID ermitteln ( wegkopieren in Texteditor ! )
c) cryptsetup luksUUID /dev/nvme0n1p2 –uuid „NEUE UUID“
d) BOOT + SYSTEM Partion der NVME anmelden
e) UUIDs ersetzen:
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/boot/grub2/grub*
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/boot/loader/entries/*
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/System/etc/fstab
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/System/etc/crypttab
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/System/etc/default/grub

f) Partionen wieder abmelden

Damit wären wir durch und so schlimm war es dann ja auch wieder nicht 🙂

Update: Es wurden Bilder zum Gnome-Laufwerke Tool eingebaut, powered by FlameShot – Ihrem Screenshottool