Massive Probleme beim Microsoft Januar Patchday

Diese Woche hatte ich massive Probleme nach dem Microsoft Januar Patchday am 11.01.2022. Die ausgelieferten Sicherheitsupdates haben auf den von mir betreuten Windowsservern einen Katastrophalen Schaden angerichtet. Dies scheint auch nicht nur mir so gegangen zu sein. Es gibt im Netz zahlreiche Berichte von anderen betroffenen und Günter Born hat einen Artikel bei Heise dazu geschrieben: Sicherheitsupdates vom Januar 2022 mit massiven Kollateralschäden in Windows. Gerade Installationen auf der Basis von Windows 2012R2 sind umfänglich betroffen.

Insbesondere von der Installation des Update KB5009624 auf Domain Controllern sollte man aktuell absehen. Es hat alle von mir betreuten Domain Controller in einee Boot-Loop (Boot-Schleife) geschickt und damit das gesamte Windowsnetzwerk lahmgelegt. Grund scheint ein Fehler im Modul lsass.exe zu sein. Auch darüber findet man weitere Details im Blog von Günter Born im Artikel Windows Server: Januar 2022-Sicherheitsupdates verursachen Boot-Schleife.

Nach der Deinstallation des Update KB5009624 auf den Domain Controllern funktionierten diese prinzipiell wieder, allerdings war einer der Domain Controller so beschädigt, dass er nicht mehr richtig funktionierte und sich auch standhaft weigerte mit den anderen zu replizieren. Alle Versuche diesen wieder zu reparieren blieben erfolglos. Erst als dieser von Hand gelöscht und komplett neu aufgesetzt wurde, nahm er wieder fehlerfrei seine Arbeit auf.

Nachdem alle Domain Controllern wieder einwandfrei arbeiteten, lief das Windowsnetzwerk prinzipiell wieder. Es gab aber haufenweise weitere Probleme im Windowsnetzwerk. Das gesamte IT Team war zwei Tage lang damit beschäftigt die Folgeprobelme und andere Fehlfunktionen des Microsoft Patchday zu lösen. Neben dem Boot-Loop auf Domain Controller traten bei uns auch noch folgenden Kollateralschäden durch den Microsoft Januar Patchday auf:

  • Nach dem Einspielen von KB5009624 und KB5009595 startete Hyper-V auf Windows 2012R2 nicht mehr. Informationen dazu findet man bei Microsoft im Artikel Virtual machines (VMs) in Hyper-V might fail to start
  • Nach dem ein Einspielen von KB5009624 auf den Windows 2012R2 Exchange Servern funktioniert ReFS nicht mehr. Sobald das Update deinstalliert wurde funktioniert dies zwar wieder. Mit Pech kann die Exchangeinstallation aber so beschädigt sein, dass man die Datensicherung zurückspielen muss.
  • Nach dem Einspielen der Updates funktionierte ein Cluster mit Windows 2012R2 Terminalservern nicht mehr. Selbst eine Deinstallation aller Updates und die anschließend komplette Neueinrichtung der Rollen konnte den Cluster nicht wieder richtig reparieren. Es gab andauernde nicht zu erklärende Fehlfunktionen. Deshalb wurde der Cluster von uns aufgegeben und die User auf einen neuen Cluster mit Windows 2019 Terminalservern migriert.

Ich habe Verständnis dafür, dass Hersteller wie Microsoft heute Sicherheitslücken sehr schnell schließen müssen, um die daraus resultierenden Gefahren für die Kunden schnell abzustellen. Ich finde die Informationspolitik zu den durch das Update verursachten Problemen von Microsoft jedoch völlig unzureichend. Warum gibt es nach wie vor keine offizielle Stellungnahme mit einer Auflistung der Probleme? Warum wurde auch drei Tage nach dem Erscheinen der Updates und den vielen Berichten über die Probleme die Update bis jetzt nur halbherzig zurückgezogen? Diese werden zwar aktuell nicht mehr automatisch ausgeliefert. Sie lassen sich im aber immer noch finden und ohne Warnung installieren. Siehe auch hier die Zusammenfassung von Günter Born Microsoft Patchday-Probleme Jan. 2022: Bugs bestätigt, Updates zurückgezogen?

Bis jetzt scheint es nur im Blog von Günter Born vernünftige Erklärungen, Zusammenfassungen und den aktuellsten Stand zu den massiven Problemen mit den Sicherheitsupdates des Microsoft Patchday vom 11.02.2022 zu geben. Vielen Dank von meiner Seite für diese gute Arbeit! Und der Weltkonzern Microsoft sollte sich fragen, warum das eigene Security Team so etwas nicht geschafft hat.

Sicherheitslücke Log4Shell CVE-2021-44228

Vor einer Woche hat das BSI zum ersten mal die Warnstufe Rot ausgerufen. Durch die Sicherheitslücke Log4Shell CVE-2021-44228 im weit verbreiteten Framework Log4J sind potenziell fast alle Java-Anwendungen angreifbar. Log4J ist der De-facto-Standard für das Loggen von Java-Anwendungen. Deshalb sind weltweit sehr viele Anwendungen betroffen.

Für mich bedeutete die Sicherheitslücke jetzt erst mal eine anstrengende Arbeitswoche. Es galt alle Java-Anwendungen zu identifizieren, für die ich verantwortlich bin und das ist eine große Menge. Danach musste ich rausfinden, ob die entsprechende Anwendung tatsächlich Log4J verwendet. Und zu guter letzt musste ein Update eingespielt werden, sofern dies der Fall war.

Inzwischen habe ich alle Anwendungen überprüft und kann beruhigt Weihnachten feiern. Dazu bin ich wie folgt vorgegangen.

Wie findet man raus, ob eine Software betroffen ist?

Informationen des Herstellers

Informationen des Herstellers oder Programmierers sind natürlich der einfachste und beste Weg, um die Anfälligkeit eines Programms für diese Sicherheitslücke zu überprüfen. Ich persönlich habe bei betroffenen Anwendungen die folgenden Webseiten der Hersteller dazu genutzt:

Liste der Betroffenen Anwendungen auf GitHub

Sollte man bei Hersteller oder Programmierer solche Informationen nicht direkt finden, gibt es eine weitere Möglichkeiten, um diese zu feinden. Der französische Sicherheitsspezialist SwitHak pflegt bei GitHub eine Liste mit Aussagen der Hersteller die betroffen sind. Sofern eigene Anwendungen auf dieser Liste aufgeführt sind kommt man über einen Link zu den jeweiligen Informationen.

log4j-detector

MergeBase hat auf gitlab das Programm log4j-detector veröffentlicht, mit dessen Hilfe man nach verwundbaren Versionen von Log4J innerhalb von Java-Anwendungen suchen kann. Wenn man dieses auf dem Server mit einer Anwendung laufen lässt, durchsucht es alle Java Classen und meldet einem, wenn es dort eine verwundbare Version von Log4J findet.

Netzwerkscann

Eine weitere Möglichkeit für das aufspüren von verwundbaren Log4J Lücken ist das Scannen der Serverdienste über das Netzwerk mittels eines Vulnerability Scanners. Einer der bekanntesten Vulnerability Scanners ist OpenVAS von Greenbone, welchen ich für diesen Scann verwendet habe. Wie man dem Forumsbeitrag Testing for CVE-2021-44228 (Log4j/Log4Shell vulnerability) entnehmen kann, kann diese die Log4J Lücke auch bereits finden.

Um OpenVAS von Greenbone zum scanne zu verwenden, habe ich mir diesen schnell auf einer virtuellen Maschine mit Kali Linux installiert. Wie dies geht schildert der Blogbeitrag OpenVAS on Kali GNU/Linux Part 1: How to install OpenVAS von Staf Wagemakers.

switchport mode trunk oder generel?

Heute habe ich einige neu gelieferte Dell EMC Networking-Switches der N-Serie mit der Modellbezeichnung N3224PX-ON für den Access Layer eingerichtet. An diese wurden vor allem Ubiquiti U6-LR und U6-Lite Wireless Access Points angeschlossen, die über einen switchport mode trunk mit 5 Virtual Local Area Network (VLAN) versorgt werden.

Zu meiner Überraschung stellte ich fest, dass die Accesspoints nicht funktionierten. Der freundliche Support von Dell gab mir den Tipp, das Interface im “switchport mode general” anstelle des “switchport mode trunk” zu betreiben. Dies führte auch zum Erfolg und die Wireless Access Points funktionierten anschließend. Dies war natürlich erstmal fantastisch, aber es stellte sich mir sofort die Frage nach dem Warum.

Was ist der Unterschied bei dem “switchport mode general” anstelle des “switchport mode trunk“? Der einzige Unterschied ist, dass bei ersterem mehrere VLANs ohne TAG übertragen werden können. Bei der klassischen und bei uns verwendeten Konfiguration für Wireless Access Points wird jedoch nur ein VLAN ohne TAG übertragen. Bei uns ist das das VLAN 31. Somit erklärt sich nicht, warum dies nicht auch mit dem “switchport mode trunk” funktioniert.

Nach einigen Tests habe ich dann entdeckt, dass es nicht reicht, mit “switchport trunk native 31” das VLAN auf dem Interface ohne TAG zu definieren. Es muss gleichzeitig auch mit “switchport trunk allowed vlan 31” auf dem Interface erlaubt werden. Falls man das nicht macht, bleibt das Interface einfach dabei, VLAN 1 ohne TAG auf dem Interface zu übertragen.

Wenn man wie oben beschrieben das richtige VLAN auf dem Interface sowohl erlaubt als auch als native zu übertragen gekennzeichnet hat, kann man die Wireless Access Points auch im “switchport mode trunk” betreiben.

Aruba Switch mit macOS 12 administrieren

Um von einem Rechner mit macOS 12 über die Konsole einen Aruba Switch zu konfigurieren oder die Firmware zu aktualisieren sind ein paar Kniffe notwendig. Wie zuvor schon für Geräte von Cisco, habe ich mir hier mal die wichtigsten aufgeschrieben. Vielleicht nützen diese ja noch mal jemand anderem, der sie hier findet.

Konfiguration des Aruba Switch über die Konsole

Man kann die meisten Geräte von Aruba über die Konsole konfigurieren. Diese funktioniert über ein mitgeliefertes USB-Kabel auch dann, wenn die Netzwerkkonfiguration nicht funktioniert oder noch nicht vorhanden ist.

Da man auf einem aktuellen Mac einen USB-C Anschluss hat und nur ein USB-A Kabel mitgeliefert wird, benötigt man in der Regel einen Adapter. Wenn man das USB-Kabel an diesem Adapter anschließt, taucht das Cisco Gerät als USB-Gerät im Ordner /dev auf. Mit dem folgenden Befehl kann man den Namen der USB-Gerätes identifizieren:

ls /dev/*usb*

Bei mir heißt das USB-Gerät z.B. “ /dev/tty.usbmodemE69491011611″. Um mit dem Terminal auf diese Konsole zu kommen, muss ich dann nur den folgenden Befehl eingeben:

screen /dev/tty.usbmodemE69491011611 -f 9600,cs8,-parenb,-cstopb,-hupcl

Kopieren von der running-config eines Aruba Switches auf einem Rechner mit macOS 12

Auf die meisten Geräten von Aruba wird das Protokoll sftp unterstützt. Um mit diesem das sftp Protokoll nutzen zu können, muss dieses zunächst ein ssh-key und der Filetransfer damit eingeschaltet werden. Dies geschieht mit den folgenden Befehlen:

crypto key generate ssh rsa
ip ssh filetransfer

Danach kann man die running-config mit dem folgenden Befehl im Terminal des Mac runterladen (wenn das Gerät die IP 192.168.45.61 hat und ein Benutzer admin auf diesem existiert):

scp admin@192.168.45.61:/cfg/running-config .

Kopieren einer Firmware von einem Rechner mit macOS 12 auf ein Aruba Switch

Um die Firmware über sftp zu installieren, muss wie oben beschriebe “ip ssh filetransfer” aktiviert sein. Sofern dies der Fall ist kann man die neuen Firmware mit dem Befehl scp vom Mac aus hochladen. Dazu sollte man zunächst das Secondary Image aktualisieren und booten (Aruba Switche haben in der Regel zwei Firmware Images). Falls das Image nicht funktionieren sollte, kann man dann immer noch das Primar Image booten und hat sich nicht ausgesperrt. Angenommen die Datei mit der Firmware heißt YA_16_11_0002.swi, der Switch hat die IP 192.168.45.61 und es gibt einen Benutzer admin auf diesem, geschieht das Update des Secondary Images mit dem folgenden Befehl:

scp YA_16_11_0002.swi admin@192.168.45.61:/os/secondary

Danach kann man mit dem Befehl “show flash” kontrollieren, ob dies geklappt hat:

Wenn das Update des Secondary Image geklappt hat, booten man dieses:

boot system flash secondary

Wenn sich das Secondary Image starten lässt, kann man dann auch noch das Primary Image aktualisieren. Dies geschieht analog zum vorherigen Update mit nachfolgendem Befehl:

scp YA_16_11_0002.swi admin@192.168.45.61:/os/primary

Auch den Erfolg dieses Kopiervorgangs kann man durch die erneute Eingabe von “show flash” kontrollieren. Danach booten man wieder das Primary Image und ist mit dem Update fertig:

boot system flash primary

Debian: Upgrade von 10 (Buster) auf 11 (Bullseye)

Am 14. August 2021 wurde Debian 11 (Bullseye) veröffentlicht. Dieser Artikel erläutert kurz, was zu tun ist, um ein Upgrade von Version 10 (Buster) auf Version 11 (Bullseye) bei einer bestehenden Installation durchzuführen. Im Prinzip ist das vorgehen dabei seit Jahren gleich. Schon bei dem Upgrade von Version 6.0 (Squeeze) auf Version 7.0 (Wheezy) war das Vorgehen nahezu identisch. Lediglich das aptitude wurde inzwischen durch apt ersetzt.

Datensicherung

Als erstes sollte das bestehende System mit einer Datensicherungssoftware gesichert werden. Dazu kommen eine ganze Reihe von Programmen wie cpio, tar, amanda oder rsnapshot infrage. Nähere Infos zu Backupsoftware unter Linux kann man in meinem Artikel Backup-Software für Linux nachlesen.

Danach sollte eine Liste der Installierten Software-Pakete erstellt werden, damit man im Notfall wieder ein System mit identischer Software installieren kann. Eine Anleitung dazu ist in meinem Artikel Ubuntu/Debian: Die gleiche Software auf einem neuen Computer installieren zu finden.

Einspielung aller Updates für das bestehende Debian

Bevor das eigentliche Upgrade auf die Version 11.0 gemacht wird sollten alle Updates für die alte Version eingespielt werden. Dazu muss zunächst die source-list aktualisiert werden:

sudo apt update

Danach können die Updates installiert werden:

sudo apt upgrade

Anpassen der sources-list

Damit die neuen Pakete gefunden werden, muss in der source-list das Wort buster gegen bullseye getauscht werden. Die source-list befindet sich in der Datei /etc/apt/sources.list. Die Datei sollte nach den Änderungen etwa wie folgt aussehen:

deb http://deb.debian.org/debian/ bullseye main contrib non-free
deb-src http://deb.debian.org/debian/ bullseye-updates main contrib non-free
deb http://security.debian.org/debian-security bullseye-security main
deb-src http://security.debian.org/debian-security bullseye-security main
deb http://ftp.debian.org/debian bullseye-backports main

Upgrade
Nun muss erneut die source-list aktualisiert werden:

sudo apt update

Zum Schluss wird dann der Rest der Pakete aktualisiert:

sudo apt full-upgrade

Während der Aktualisierung der einzelnen Software-Pakete wird dann ab und zu noch die ein oder andere Frage gestellt, bevor der abschließende Neustart fällig wird. Nach dem Neustart ist das Upgrade abgeschlossen.

ssh als SOCKS-Proxy verwenden

Eine geniale Funktion des ssh Protokolls ist der SOCKS-Proxy. Viele kennen und nutzen diese gar nicht. Dabei hilft einem diese enorm bei der Administration von Servern. Ich nutze diese Funktion z.B. sehr häufig, um mit einem Webbrowser aus einem andern Netzwerk zuzugreifen. Dies ist sehr praktisch, wenn man mit seinem Notebook gerade in einem andern IP-Netz hängt und deshalb mit dem Browser nicht durch eine Firewall kommt.

Wie geht sowas?

Um mit einem Webbrowser über den SOCKS-Proxy aus einem anderen Netzwerk zu kommen, sind die beiden folgenden Schritte notwendig.

1. Anmeldung per ssh an einem Server in dem gewünschten Netzwerk

Um aus einem andern Netzwerk zu kommen meldet man sich auf einem System das sich innerhalb des selben befindet mit ssh und dem Parameter -D <Port> an. Dieser Parameter aktiviert den SOCKS-Proxy auf dem angegebenen Port. Wenn man z.B. ein Open SSH, ein anderes System mit ssh-server und der IP-Adresse 10.10.10.10 hat und einen SOCKET auf Port 1080 verwenden möchte, gibt man in der Kommandozeile den folgenden Befehl ein:

ssh -D 1080 10.10.10.10

2. Einstellung des SOCKS-Proxy im Webbrowser

Danach stellt man in dem Webbrowser ein, dass man den SOCKS-Proxy auf dem entsprechenden Port verwenden möchte. Dazu sollte man natürlich einen Webbrowser verwenden, der dies auch kann. Bei dem Firefox Webbrowser geht dies z.B. Verbindungseinstellungen:

Im Anschluss surft man mit diesem Webbrowser von der IP-Adresse 10.10.10.10.

2FA bei einer Synology NAS mit TOTP

Immer wieder hört man von Ransomware (bzw. Krypto-Trojanern), welche Daten auf Servern und Storagesystemen verschlüsseln und Lösegeld erpressen. Umso wichtiger ist es somit seine NAS-Systeme (Network Attached Storage) gegen so etwas abzusichern. Oft wird dazu die sogenannte 2FA (Zwei-Faktor-Authentifizierung) verwendet.

Die Zwei-Faktor-Authentifizierung (2FA) ist eine Technik, um die Benutzerkonten vor unberechtigtem Zugriff zu schützen. Sie funktioniert durch zwei verschiedene Identitätsbeweise. Der erste Beweis ist etwas, das nur Ihr wisst: Euer Passwort. Der andere Beweis ist meistens ein PIN, der über eines eurer Geräte angezeigt wird und sich alle 30 Sekunden ändert. Dazu wird üblicher Weise der TOTP (Time-based One-time Password Algorithmus) Standard verwendet.

Seit Synology in diesem Sommer für seine NAS-Systeme den DSM (DiskStation Manager) in der Version 7 rausgebracht hat, wird 2FA unterstützt. Und es ist jedem anzuraten, diese auch zu verwenden. Falls Ihr noch die alte Version 6 verwenden sollten, habe ich in dem Artikel “Synology Diskstation Manager 7.0” beschrieben, wie man ein Upgrade durchführt.

Wenn man ein Smartphone hat, benötigt man für die Zwei-Faktor-Authentifizierung lediglich eine App die den TOTP (Time-based One-time Password Algorithmus) beherrscht. Ich selber nutze dazu aktuell 1Password. Es gibt aber auch diverse kostenlose Apps, welche diesen Standard beherrschen (z.B. Google Authenticator oder Microsoft Authenticator). Im folgenden Artikel werde ich erklären, wie man eine 2FA über TOTP für einen Benutzer im DSM einrichtet. Falls Ihr lieber ein Video mit einer Anleitung anschauen möchtet, verlinke ich hier auch ein Anleitungsvideo zu dem Thema, das ich auf YouTube hochgeladen habe.

Wie richtet man eine 2FA für einen Benutzer bei DSM ein?

Um die Zwei-Faktor-Authentifizierung bei einem Benutzer im DSM einzurichten, meldet man sich zunächst mit diesem an. Danach klickt man auf das Personen-Symbol oben rechte in der Ecke (siehe roter Kreis auf dem folgenden Screenshot).

In dem sich aufklappenden Menü wählt man dann den Menüpunkt “Persönlich” aus und es öffnet sich eine Seite mit den persönlichen Einstellungen des Benutzers. Etwas weiter unten auf dieser Seite gibt es dann den Abschnitt “Anmeldemethode”. Dadrunter gibt es einen Bereich mit der Überschrift “2-Faktor-Authentifizierung” (siehe blaues Viereck auf dem folgenden Screenshot). Wenn man auf diesen klickt, öffnet sich ein Einrichtungsdialog, der einen durch die Einrichtung der Zwei-Faktor-Authentifizierung führt.

In dem Dialog wird man zunächst nach der Methode gefragt. Synology bietet hier verschiedene an. Wie eingangs beschrieben wollen wir die Methode nach dem TOTP Standard verwenden. Deshalb wählen wir hier die Methode OTP aus (siehe blaues Viereck). Synology verzichtet in der Bezeichnung der Methode auf das “T” von “TOTP”. Das kann an dieser Stelle leicht verwirren.

Nach der Auswahl der Methode, wird man nach seinem Passwort gefragt. Nach erfolgreicher Eingabe von diesem, erscheint ein allgemeines Hinweisfenster mit Informationen zu 2FA. Mit dem “Weiter” Knopf gelang man im Anschluss zu einem Fenster mit Informationen zu der Installation der App “Synology Secure SignIn”. Wie bereits geschildert, kann man aber jede App verwenden, die den TOTP Standard unterstützt. Sofern man eine solche bereits installiert hat, benötigt man die App “Synology Secure SignIn” also nicht. In diesem Fall klickt man einfach wieder auf “Weiter” und ladet endlich in der eigentlichen Einrichtung von TOTP (siehe Screenshot).

Die konkrete Einrichtung von TOTP besteht jetzt aus zwei Schritten.

  • Scannen des angezeigten QR Codes mit der TOTP App.
  • Bestätigung des erfolgten Scanns durch Eingabe des richtigen PINs

Sobald man diese Schritte durchgeführt hat, ist die Zwei-Faktor-Authentifizierung aktiv. Sobald man sich mit einem neuen Gerät und seinem Benutzer an der Synology NAS anmeldet, wird man jetzt zusätzlich nach dem PIN gefragt. Erst nachdem man diesen mit Hilfe der TOTP App eingegeben hat, gelangt man auf den Desktop des DSM. Somit ist man zukünftig zusätzlich abgesichert, wenn einem das Passwort entwendet werden sollte.

Synology Diskstation Manager 7.0

Endlich ist die bereits sehnsüchtig erwartete Version 7.0 des DSM (DiskStation Manager) von der Firma Synology erschienen.

Für diejenigen von Euch die das DSM nicht kennen: Der DSM ist das Betriebsystem für die NAS Systeme der Firma Synology. Es beinhaltet eine Weboberfläche und diverse Anwendungen für die Verwaltung von Daten wie Dateien, Fotos, Videos, usw.

Bei der Version 7 verspricht der Hersteller das bislang größte Update für sein Betriebssystem. Dies war allerdings auch dringend nötig, da die Version 6.0 jetzt bereits vor mehr als 4 Jahren veröffentlicht wurde. Sie sollte eigentlich auch schon viel früher erscheinen. Synology hatte sich aber wiederholt entschieden, den Erscheinungstermin zu verschieben. Gerade bei einer Software für ein NAS (Network Attached Storage) ist dieses Vorgehen sicherlich auch sinnvoll, wenn die Software noch nicht wirklich stabil läuft. Schließlich kann eine Fehlfunktion hier auch immer gleich zu einem sehr unschönen Datenverlust führen.

Was sind die Neuerungen bei Version 7.0?

Das Motto des Launch-Events lautete “Smart. Simple. Reliable“. Damit unterstreicht Synology, dass neben diversen internen Erneuerungen und Verbesserungen auch die Oberfläche grundlegend überarbeitet und die Stabilität verbessert wurde. Die neue Benutzeroberfläche soll ein flüssigeres und intuitiveres Arbeiten ermöglichen. Zudem wurde auch der Speicher-Manager optisch aufgefrischt und hinsichtlich der Arbeitsgeschwindigkeit optimiert. Eine neue Live-Ansicht der Systemauslastung und das zentrales Analyse-Tool “Active Insight” liefern deutlich detaillierte Informationen und werden die Administration deutlich vereinfachen. Die vielen Apps für Fotos, Musik und Videos wurden zu zwei Apps zusammengefasst und um viele neue Funktionen wie automatische Zusammenstellung von Alben und Sortierung nach erkannten Personen erweitert.

Wie wird das Update eingespielt?

Der DSM 7.0 läuft auf allen Modellen ab dem Jahr 2015. Falls Ihr das Update installieren möchtet, findet Ihr unter folgendem Link auf der Synology Seite: DSM7. Zudem erkläre ich in dem folgenden Video im Detail, wie man seine Synology aktualisiert. Getestet habe ich das Update auf meiner bereits 2017 erworbenen DS416play, über die ich in diesem Blog in dem Artikel “Test einer Synology DS416play mit DSM 6.1” bereits berichtet hatte.

Einbinden einer neuen Festplatte bei Linux zur Laufzeit

In Zeiten zunehmender Virtualisierung (mit VMware vSphere, KVM, Citrix usw.) wird es immer häufiger notwendig Festplatten im laufenden Betrieb einzubinden, da diese ohne Neustart einfach zu einer virtuellen Maschine hinzufügen wurden. Bei Linux tauchen diese Platten ohne Neustart des Gastes aber nicht so einfach auf. Damit man diese auch im laufenden Betrieb zu Gesicht bekommt, muss der Kernel die Festplattenkonfiguration neu einlesen. Wie dies ohne Neustart geht, möchte ich in diesem Artikel dokumentieren.

Welche Speicher-Adapter kennt das System?

In dem Verzeichnis /sys/class/scsi_host befindensich die dem Kernel bekannten Speicher-Adapter des Systems. Der folgende Befehl zweigt die Adapter an.

ls /sys/class/scsi_host

Wie bringe ich die Speicher-Adapter dazu neue Festplatten zu erkennen?

Mit der folgenden Schleife, bringt man alle Speicher-Adapter des Systems dazu im laufenden Betrieb nach neuen Festplatten zu suchen.

for f in /sys/class/scsi_host/host*; do echo '- - -' > $f/scan; done

Wie bringe ich die Speicher-Adapter dazu Größenänderung bei Festplatten zu erkennen?

Wenn es sich nicht um eine neue neue Festplatte sondern nur um eine geänderte handelt, wird es noch etwas komplizierter. Dank ein bisschen Zauberei mit awk, kann man auch eine Schleife bauen, die bei allen Blockdevices nach Änderungen suchen lässt. Diese sieht dann so aus.

for d in $(lsblk -Sln | awk '{if ( $3 == "disk" ) print $1}'); do echo 1 > /sys/class/block/$d/device/rescan; done

Achtung: Fehlfunktion durch ablaufende Sicherheitszertifikate bei den Dell OS10 Switches

Dell hat gerade seine Kunden gerade per E-Mail angeschrieben und vor einem besonders heimtückischen Problem bei den OS10 Switches gewarnt. Bestimmte Versionen von OS10 (beginnend mit 10.4.1.4 bis 10.5.0.7 P3) enthalten ein Standardzertifikat, das für VLT Peer Establishment und die SFS-Cluster-Bildung verwendet wird. Und genau dieses Standardzertifikat läuft am 27. Juli 2021 ab. Dell beschreibt im Knowledge Artikel 000184027, wie man das Ablaufen des Zertifikates verhindern kann. In den meisten Konstellationen wird ein Update des OS10 auf eine aktuelle Version empfohlen. Ein Update von OS10 verursacht einen Netzwerkausfall. Deshalb sollten betroffenen diesen Artikel unbedingt zu Ende lesen.

Wenn das Zertifikat abläuft kann es zu massiven Fehlfunktionen bei betroffenen Switches kommen, sofern auf diesen VLT Peer Establishment und die SFS-Cluster-Bildung verwendet wird. Es könnte z.B. zu einem nachfolgenden Switch-Neustart, einer Link-Flap-Lösung, einer Operator-ausgelösten Konfigurationsänderung, VMotion und anderen Netzwerkereignissen kommen.

Aktualisierung von OS10 löst das Problem

Auf den von mir betreuten Switchen war die OS10 Version 10.5.0.1P1 installiert. Somit waren diese betroffen. Um das Problem zu lösen, empfiehlt Dell ein Update auf die aktuelle OS10 Version. Deshalb habe ich die Switche auf die OS10 Version 10.5.2.3 aktualisiert. Wie das im einzelnen geht, habe ich bereits in dem Blogartikel Dell OpenNetwork Switches mit OS10 beschrieben. Wer in der gleichen Situation wie ich ist, kann dort eine Anleitung für das Update der Switche finden.

Netzwerkausfall bei der Aktualisierung der Switche

Da Ich VLT Peer Establishment über jeweils zwei Switche verwende, wähnte ich mich vor einem Netzwerkausfall in Sicherheit. Genau dazu ist die VLT Technik ja schließlich gedacht. Wenn ein Switch ausfällt sollte der andere ohne Ausfall übernehmen. Dies war aber leider ein Trugschluss. Obwohl der Versionssprung von 10.5.0.1P1 auf 10.5.2.3 keine großen Änderungen suggeriert, wurde die Version des VLT Protokolls von Version 2.3 auf die Version 3.1 angehoben. Diese Versionen scheinen nicht kompatibel zu sein und es kommt nach dem Update des ersten Switches zu einer Netzwerkstörung, bis der zweite aktualisiert wurde.

Was sagt der Dell Support dazu?

Ich habe nach auftreten der Störung sofort den Support von Dell angerufen. Da kein Support-Mitarbeiter in deutscher Sprache verfügbar war, wurde zwar sofort aber auf englisch sehr freundlich beraten. Leider erhielt ich aber nur die Aussage, dass die Versionen der VLT Protokolle eben nicht kompatibel sind und man mit diesem Netzwerkausfall während dem Update eben leben müsse. Der Support versprach aber auch, dass sich nochmal ein Spezialist melden würde, der uns zu dem Update berät. Deshalb haben ich die Updates zunächst unterbrochen und werde noch mal ein paar Tage abwarten, ob sich jemand meldet. Vielleicht gibt es ja doch noch eine Lösung ohne Netzwerkausfall. Sofern dies der Fall sein sollte, werde ich den Blogeintrag hier entsprechend ergänzen.

Update: Peter gab mir in den Kommentaren den Tipp, das man den Upgradepfad beachten muss. Wenn man zwischenzeitlich auf die Version 10.5.0.6 und erst danach auf die Version 10.5.2.3 aktualisiert, soll es keinen Ausfall geben.

Persönliches Fazit

Wir hatten uns für die hochpreisigen Switche von Dell entschieden, um mit VLT genau solche Ausfälle zu vermeiden. Deshalb bin ich aktuell etwas enttäuscht. Nach gerade mal zwei Jahren, kommt es durch ein kurzfristig notwendiges Update zu genau einem solchen Ausfall. Ansonsten haben uns die Switche bis jetzt aber noch nicht im Stich gelassen und wir sind sehr zufrieden mit ihnen. Insofern hoffe ich, dass dies ein unglücklicher Einzelfall war, der sich so schnell nicht wiederholen wird.