Am Mittwoch den 15.03.2023 wurden am Nachmittag Wartungsarbeiten an unserer Infrastruktur im Z-Bau durchgeführt.

Extra Fernwartung für tor3 #

tor3, einer unserer drei Tor Exit Server, wachte nach einem Stromausfall nicht selbstständig wieder auf. Daher musste der Server manuell gestartet werden. Die passende BIOS-Einstellung dazu wurde angepasst. Der Resetknopf von tor3 war bisher noch nicht ferngesteuert schaltbar, dies wurde bei der Gelegenheit nachgerüstet. Damit hängen jetzt alle Tor Nodes an einem Raspberry Pi, der die Resetleitungen per Optokoppler schließen kann. Sobald das neue System für den Raspberry Pi installiert ist können die Server für kleinere Probleme aus der Ferne neugestartet werden.

Raspberry Pi als Fernzugriff für den Resetknopf

NVMe für vmhost1 #

Die eigentliche Mission bestand allerdings darin die in vmhost1 verbaute SSD zu wechseln. Diese war ursprünglich nur als Zwischenlösung installiert und zeigte so langsam erste Schwächen. Als zeitgemäßen Ersatz wurden daher 2 NVMe SSDs besorgt.

vmhost1 beherbergt einiges unserer Infrastruktur. Dazu gehören Services wie DNS, unser Community Matrix Server, der SNI Proxy, aber vor allem auch die Layer 3 Peering VM ff1 und eine Reihe an VMs, die Backupgateways für viele V2 Hoods stellen.

Für den Wechsel war eigentlich alles relativ detailliert geplant, um die Ausfälle der Services klein zu halten und um unnötig lange Last auf der restlichen Infrastruktur zu vermeiden.

Einbau der NVMe SSDs

Die NVMe SSDs waren schnell eingebaut und wurden auch vom bisherigem System erkannt. In einem Livesystem konnte also dann der Inhalt der System Platte in ein frisches Btrfs RAID1 umgezogen werden. Über die IPMI Konsole war das etwas mühsam, da das Tastaturlayout von Laptop und Server nicht zusammen passen. Die minutenlangen Bootzeiten von Serverhardware waren ebenfalls wenig hilfreich.

Bis zu diesem Punkt ging auch alles nach Plan. Um das EFI nicht zusätzlich zu verwirren und um wirklich sicher zu sein, dass von den neuen Speichern gebootet wird, wurde die alte Systemplatte ausgebaut. Dann wieder anschalten und … nix.

Also wieder zurück ins Livesystem und den Bootloader überprüfen. Neustarten. Ni̸x̶.̶ Liv̷e̴s̴t̴system̷.̴ ̵B̵o̶o̸t̵l̵o̸ader umstrukț̸̂u̴̖͊r̴̳͗ḭ̶͝ȇ̵̱r̷̡̆e̴͖̕n. Nix̵̜̺̌.̵͍͐̃̀͘ ̶̀͋͜2̴̺͚̼̩̮̎͂̏͘ ̴̤͍͕̼̦̎̓̆S̶͎͔̗̳̀͆̅̑̄͝ẗ̶̬́̄̔̾̄͘u̵̡̢̟̾n̵͔̻̝̍̐͘den sp̵͖̗̜̦̫̑̈́͛̓͝ä̵̰͔̿t̵̗͈̺̭̲͗͊r. Laptop Akk̴̗̻̗̭͎̟͝ų̴̞̼͔́̊͆͊ ̴̰̻̔̂̏̈͗w̴̟͔͌i̸̖͒̌̈́̌r̸͈͎̀ḑ̵̩̥͉͌̓ ̸͖͇̱̼̭̝͋l̸̝̳͌͌́̈́̈e̸̜̳̣̩̱͇̽̔͋͘e̸̪̿͒̚ṟ̶͔̘̱̘͖͐͗͊̾̏̆. K̸͕̩͆e̴̹̾í̵̢n̶͕̊ ̶̘̿͊N̶͕͕͘e̴̻̅͐t̷̠͗̈́z̸̮̊͠t̷͇͔͒͒ĕ̸̗i̶͙̼̒̾l̵̨̛̰.̷͕̔. A̶n̷d̷e̵r̶e̸r̴ ̴L̴a̷p̵t̷o̸p̵.̶ V̷̡̹̜̫̥̏̉E̶̡̯̒̐R̵̢̛̩̹̮͔̠̝̍̏̄̋̄D̴̡̜̻̫̤̒̽͆A̶̜̠̼͕̦̽M̶̞̲͚̹͆M̵̪̫̣͎̠͚̰̀̄͑́T̶͓̹͈̤̎̓̈̚͝!̶̘̭̜̤͉̱̈́̓̓͋̕͠

…

Eigentlich waren sogar für diesen Fall Vorbereitungen getroffen worden. Um potentielle Probleme der Mainboard Firmware zu umgehen wurde zusätzlich zu den NVMe SSDs ein USB Stick im internen Port für die EFI-Systempartition (ESP) installiert. Allerdings bringt das dort abgelegte grub2 Bootloader EFI Binary nicht alles für den Zugriff auf das NVMe Protokoll mit. Es genügt auch nicht, alle Module, die grub2 noch nachladen muss, auch mit auf den USB Stick zu legen. grub2 benötigt ein NVMe-fähiges UEFI um den Linux-Kernel von dort laden zu können.

Erst nachdem der komplette /boot Inhalt auf dem USB Stick ausgelagert war, grub2 daher auch den Linux Kernel ohne NVMe finden und booten konnte, startete das System wieder wie gedacht und mit einiger Verzögerung konnte der Rest wieder in Betrieb genommen werden.

Fazit #

Alles in Allem war der Umbau ein etwas größeres Erlebnis als zunächst angenommen und es gab wieder viel Neues zu lernen. Zum einen war natürlich die Firmware und Bootloadergeschichte etwas ungewöhnlich und interessant, aber auch, dass im Freifunk Franken manch redundant ausgelegt Infrastruktur etwas weniger redundant ist als gewünscht :)

An dieser Stelle gilt ein besonderer Dank dem Z-Bau und seinen verständnisvollen Mitarbeitern!