- Auch nachdem sich Server auf universelle Hardware ähnlich wie PCs zubewegt haben, bleibt Out-of-Band-Management für Ausfälle, Bootvorgänge und Remote-Installationen eine Schlüsselfunktion, die Clients und Server voneinander unterscheidet
- IPMI ist kein Produktname, sondern eine Spezifikation; herstellerspezifische Management-Systeme wie HP iLO und Dell DRAC überschneiden sich mit IPMI, haben aber jeweils eine eigene Geschichte und erweiterte Funktionen
- IPMI läuft auf dem BMC und bietet sowohl Out-of-Band-Schnittstellen auf Netzwerk- oder serieller Basis als auch In-Band-Schnittstellen über Betriebssystemtreiber
- Reale Implementierungen bieten Web-UI, SSH, VNC, Befehle über UDP 623, Remote-Konsole, virtuelle Medien sowie Steuerung von Sensoren, Stromversorgung, Lüftern und Watchdog, sind aber besonders anfällig für Sicherheitsrisiken
- Intel ME und Intel AMT sind ähnliche Technologien auf der Client-PC-Seite, aber wegen der Anforderungen von AMT und vPro ist die verbreitete Annahme, auf gewöhnlichen Verbrauchergeräten sei Sideband-Netzwerkzugriff möglich, meist nicht zutreffend
Bis Server zu „großen Computern“ wurden
- Client-Server-Computing entstand aus der Weiterentwicklung des Time-Sharing-Computing, bei dem mehrere Terminals mit einem Computer verbunden waren
- Terminals mussten nicht dieselbe Architektur wie der Computer haben, und dieses Verständnis setzte sich auch in frühen Client-Server-Systemen fort
- Die PC-Revolution Mitte der 1990er schuf auf der Client-Seite eine einheitliche WinTel-Kultur, doch bis in die 2000er war es bei Servern üblich, separate Betriebssysteme und Architekturen zu verwenden
- Die Kombination aus SPARC und Solaris war auf Servern weit verbreitet
- Auch IBMs Minicomputer-Architektur und mehrere Betriebssysteme waren wichtige Server-Plattformen
- Java trug zu Enterprise-Anwendungen bei, indem es Code-Wiederverwendung zwischen Solaris/SPARC-Backends und Windows/x86-Clients ermöglichte
- Mit der Zeit gerieten spezialisierte Server-Architekturen im Kosten-Leistungs-Wettbewerb gegenüber PC-Architekturen zunehmend ins Hintertreffen
- Auch Server-Software verlagerte sich von vertikaler Skalierung und hoher Verfügbarkeit hin zu horizontaler Skalierung und gelockerten Zuverlässigkeitsanforderungen, wodurch die Vorteile von Enterprise-Computern abnahmen
- Heute liegen die Unterscheidungsmerkmale von Servern vor allem in Multi-Socket-SMP und NUMA, komplexen Storage-Controllern und -Topologien sowie Out-of-Band-Management-Funktionen
Was Out-of-Band-Management löst
- Out-of-Band-Management ermöglicht den Zugriff auf einen Server über einen separaten Verwaltungsrechner, selbst wenn das Betriebssystem oder allgemeine Komponenten nicht korrekt funktionieren
- SSH ist ein typisches Beispiel für In-Band-Management, das von Software oberhalb des Betriebssystems bereitgestellt wird
- Out-of-Band-Management wird von einem separaten Hardware- und Software-Stack übernommen und erforderte traditionell keine Mitwirkung des Betriebssystems oder der CPU
- Heute zeigt sich diese Funktion am deutlichsten in der Remote-Konsole eines Servers
- Sie funktioniert wie ein integriertes IP-KVM, sodass sich der Server bedienen lässt, als wären lokaler Monitor und Tastatur angeschlossen
- Die Funktion „virtuelle Medien“ kann ISO-Dateien hochladen und sie wie physische Geräte erscheinen lassen, was für die Installation von Betriebssystemen nützlich ist
- Diese Funktionen sind kein neues Konzept; ähnliche Fähigkeiten finden sich in der gesamten Geschichte des Business-Computing
- In vergleichsweise modernen Servern waren meist mehrere Management-Ebenen gleichzeitig vorhanden
- Lokale Bedienoberflächen wie LCDs oder LEDs, die den Hardwarezustand anzeigen
- Serielle Konsolen für den Zugriff auf frühe Bootloader und dauerhaft verfügbare Low-Level-Management-Systeme
- Höherstufige Management-Systeme zur Remote-Verwaltung der Maschinen-Workloads
- Auch heute gibt es noch Störungsanzeigen auf der Frontblende und serielle Management-Funktionen, aber der Umfang hot-swap-fähiger redundanter Komponenten ist geringer als früher
Die Beziehung zwischen IPMI und BMC
- IPMI ist kein bestimmtes Produkt, sondern die Intel-IPMI-Spezifikation
- Große Server-Hersteller haben in der Regel eigene IPMI-Implementierungen und verwenden Namen wie HP iLO und Dell DRAC
- Solche Systeme existierten teils schon vor IPMI, weshalb es nicht ganz korrekt ist, sie einfach „IPMI“ zu nennen
- Neuere Hersteller übernehmen oft die Standardlösung von Firmware-Anbietern unverändert und nennen sie dann IPMI
- Die IPMI-Software läuft normalerweise auf einem Prozessor, der BMC (Baseboard Management Controller) genannt wird
- Die Begriffe IPMI und BMC werden manchmal austauschbar verwendet
- LOM (Lights-Out Management) ist im Allgemeinen ein älterer Begriff, lebt aber weiter, weil HP(E) den Namen Integrated Lights-Out weiterhin nutzt
- Der BMC ist vom SMC (System Management Controller) in Client-Computern zu unterscheiden, der Aufgaben wie die Lüftersteuerung übernimmt
- Historisch sind die beiden Komponenten verwandt
- In Servern übernimmt der BMC die meisten dieser Funktionen
- IPMI spezifiziert zwei Zugriffsarten
- Out-of-Band-Schnittstellen über Netzwerk oder serielle Verbindung
- In-Band-Schnittstellen, auf die das Betriebssystem über Treiber zugreift
- Dank des In-Band-Zugriffs können Werkzeuge wie
ipmitoolunter Linux mit IPMI aus einem laufenden Betriebssystem heraus interagieren - IPMI ist zugleich ein eigenständiges Management-System und bietet dem Betriebssystem aus praktischen Gründen eine lokale Schnittstelle; wer diese Struktur versteht, verwechselt die Begriffe seltener
Wie IPMI in der Praxis genutzt wird und welche Sicherheitsgrenzen es gibt
- IPMI-Produkte bieten ihre Funktionen zunehmend in Form von Webanwendungen an
- Es gibt weiterhin viele Produkte mit dedizierter Client-Software, aber der Trend geht dahin, Funktionen in integrierte Web-Apps zu verlagern
- Die Qualität der Web-Oberflächen unterscheidet sich stark je nach Implementierung und ist im Allgemeinen eher schlecht
- Die meisten Server haben eine dedizierte Ethernet-Schnittstelle, die als IPMI oder management gekennzeichnet ist
- Aus Sicherheits- und Zuverlässigkeitsgründen ist es am sinnvollsten, die IPMI-Management-Schnittstelle in ein eigenes physisches Netzwerk zu legen
- Auch wenn es im Hauptnetzwerk Leistungs- oder Stabilitätsprobleme gibt, sollte IPMI weiterhin erreichbar bleiben
- Ein eigenes physisches Netzwerk kostet Zeit, Platz und Geld
- Als Kompromiss wird das Management-Netzwerk oft als VLAN auf gewöhnlicher Netzwerkinfrastruktur aufgebaut
- Es verhält sich wie ein unabhängiges privates Netz, nutzt aber tatsächlich gemeinsame Hardware
- Die Isolation wird in Software umgesetzt
- Um zusätzliche Kabel zu vermeiden, bietet IPMI auch Sideband-Networking
- Der BMC kommuniziert dabei direkt über dieselbe NIC, die auch das Betriebssystem verwendet
- Die NIC lässt es wie zwei verschiedene Schnittstellen erscheinen; IPMI-Verkehr wird im selben Paketstrom wie Host-Verkehr mitgeführt, nutzt aber eine andere MAC-Adresse
- Die Trennung zwischen IPMI- und Anwendungsverkehr wird schwächer, was Sicherheitsüberlegungen erforderlich macht
- Viele IPMI-Implementierungen haben schwerwiegende Sicherheitsprobleme gezeigt und sollten niemals für nicht vertrauenswürdige Benutzer erreichbar sein
- Die Netzwerkfunktionen unterscheiden sich je nach Implementierung, gemeinsam ist aber eine Standardschnittstelle über UDP 623 für Erkennung und Basisbefehle
- SSH und Web-Oberflächen sind verbreitet, und für Remote-Konsolen wird häufig auch VNC verwendet
- Zu den grundlegenden Funktionen, die sich per IPMI ausführen lassen, gehören:
- Anzeigen der Liste von Hardwaremodulen auf FRU-Ebene oder anhand herstellerspezifischer Teilenummern
- Steuern grundlegender Hardwarefunktionen wie Sensoren, Stromzustand und Lüfter
- Nutzung eines standardisierten Watchdog-Timers
- In Kombination mit Software oberhalb des Betriebssystems kann der Watchdog-Timer dafür sorgen, dass ein Server zurückgesetzt wird, wenn eine Anwendung in einen fehlerhaften Zustand gerät
- Das Timeout des Watchdogs sollte lang genug gewählt werden, um dem System während des Bootens und nach der Anmeldung Zeit zum Deaktivieren zu geben
Intel ME, AMD ST, AMT und die Ausnahmen bei Client-PCs
- IPMI ist in Enterprise-Servern verbreitet, aber auf gewöhnlichen Client-Computern sowie kleinen oder stromsparenden Systemen selten
- Intel ME und AMD ST sind bemerkenswerte Ausnahmen, die einem OOB-Management-Controller ähneln und in fast allen Intel- und AMD-Prozessoren vorhanden sind
- Intel ME ist die Komponente, die Intel AMT (Active Management Technology) ermöglicht
- AMT war ein Versuch, Out-of-Band-Management auf Client-Maschinen zu verbreiten, und bietet die meisten Funktionen, die IPMI ähneln
- AMT war kein großer Erfolg; ein Hauptgrund war, dass Intel die meisten AMT-Funktionen auf die Nutzung mit teuren Enterprise-Management-Plattformen beschränkte
- Es gibt Open-Source-AMT-Clients, aber das Problem, tatsächlich Maschinen zu finden, auf denen sich AMT nutzen lässt, bleibt bestehen
- Das Sideband-Management von AMT sorgte in der Sicherheits-Community für Besorgnis, tatsächlich ist es aber nur möglich, wenn alle folgenden Bedingungen erfüllt sind
- Der Prozessor muss AMT-fähig sein
- Der Mainboard-Chipsatz muss AMT-fähig sein
- Die NIC muss AMT-fähig sein
- Alle drei Geräte sind auf Intel-Produkte mit vPro-Label beschränkt
- Schon die Tatsache, dass Intel-NICs in Verbrauchergeräten nicht besonders beliebt sind, macht Sideband-Zugriff selten
- vPro ist auf vergleichsweise höherwertige Prozessoren und Chipsätze beschränkt
- Die weitverbreitete „Tatsache“, Intel ME sei auf Verbrauchergeräten über Sideband-Networking erreichbar, stimmt meist nicht; der Grund ist nicht nur Intels Softwarelizenzierung
- Intel ME selbst hat ohne AMT kaum Out-of-Band-Management-Funktionen, scheint aber als praktische Grundlage zum Hosten und Verwalten von Trusted-Execution-Komponenten wie Secure Boot und DRM zu dienen
- Intel ME kann von Dritten nicht auditiert werden und hat in der Vergangenheit schwerwiegende Sicherheitslücken enthalten
- Moderne ARM-SoCs für Verbraucher verfügen über ähnliche Fähigkeiten, sodass dies kein Problem ist, das sich nur auf einen bestimmten x86-Anbieter beschränkt
1 Kommentare
Meinungen auf Hacker News
Einige Punkte weichen etwas vom aktuellen Stand ab. Intel ist bei CPUs/GPUs insgesamt hinter AMD zurückgefallen, und es stechen nur Ausnahmen hervor, die wie die N100-Serie gut für Low-Power- und lüfterlose Einsatzzwecke geeignet sind.
Deshalb kaufen Organisationen Intel-CPUs meist dann, wenn sie eine bestehende Umgebung mit CPUs desselben Herstellers erneuern müssen, etwa wenn man wie bei EVC in vSphere neue Prozessoren dazu bringt, sich wie ältere Modelle desselben Herstellers zu verhalten, um Hot Migration zwischen CPU-Architekturen zu ermöglichen und Unterbrechungen beim Hardwaretausch zu minimieren.
Ansonsten geht die Stimmung fast überall zu AMD-CPUs, die gemessen an der Rechenleistung besser und günstiger sind. Intel-NICs sind insgesamt ordentlich und werden auch in Consumer-Geräten immer häufiger. Eine Ausnahme ist allerdings der X710, der zwar auf „Enterprise“-Kompatibilitätslisten etwa von VMware stand, aber über mehr als ein Jahr hinweg wegen Treiberproblemen stille Netzwerkausfälle oder Crashes verursachte.
Für Organisationen, die Server kaufen, kann Supermicro im Allgemeinen eine gute Wahl sein. Es ist günstiger und flexibler bei Formfaktoren, Gehäusen, Komponenten und Zahl der Slots und in der Regel zuverlässig, aber der Support ist weniger verlässlich als der theoretische Support von Dell/HPE, sodass es am besten in redundanten Konfigurationen passt.
Außerdem wird die IPMI-Spezifikation gerade durch Redfish ersetzt, das vollständigere, sicherere, standardisierte und vernünftige APIs bietet. Bei Mainstream-Servern aus den letzten Jahren ist die Wahrscheinlichkeit hoch, dass sie neben IPMI auch Redfish haben.
Vor Kurzem hat die Shortseller-Research-Firma Hindenburg einen Bericht veröffentlicht, der fragwürdige Aspekte bei Supermicro aufdeckt, aber die Hardware selbst ist weiterhin erstklassig und wird auch von großen Cloud-Anbietern eingesetzt: https://hindenburgresearch.com/smci/
Keine Unterstützung für ACPI-Energiesparmodi, mangelhafte Unterstützung für 4-Pin-/3-Pin-Lüfter, sodass 3-Pin-Lüfter immer mit 100 % laufen, ein IPMI-Webinterface wie unverändert aus den 2010ern, NVMe-Platzierung, die den Einsatz von Kühlkörpern verhindert, und jede Menge undurchsichtige Jumper ohne Board-Beschriftung.
Das vergleichbare ASRock-Rack-Board war dagegen um Welten besser.
https://arstechnica.com/security/2024/07/secure-boot-is-comp...
Je kleiner die Fertigungsprozesse werden, desto zwangsläufiger werden Lebensdauerprobleme größer, daher ist das nicht besonders überraschend. Probleme wie Elektromigration können leichter zu ernsthaftem Trouble werden. Es heißt, die Microcode-Problematik habe Mainboards zu überhöhten Spannungen veranlasst, und das stimmt auch, aber ebenso stimmt, dass Chips empfindlicher auf Umgebungsänderungen reagieren.
Früher mochte ich die Performance und Linux-Kompatibilität von Intel-NICs, und auch Intel-SSDs mochte ich. Allerdings musste man herauslesen, dass ihre Performance im P95- bis P99-Bereich etwas besser war als bei günstiger Konkurrenz, und genau P95 bis P99 sind die Momente, in denen sich ein Computer langsam anfühlt und nervt. Einer der Gründe, warum ich Anandtech zugleich mochte und nicht mochte, war, dass sie solche Kernpunkte häufig verpassten.
Wäre es Open Source, könnte man es einfach bauen.
https://www.supermicro.com/en/solutions/management-software/...
Allein für Upload und Austausch von Zertifikaten, etwa Zertifikatsnamen und Encoding, habe ich ein Bündel von Python-Modulen, um die merkwürdigen Unterschiede der einzelnen Vendors zu behandeln. Eigentlich sollten ein paar standardisierte PUT-Requests reichen, die überall funktionieren, und die Redfish-API-Dokumentation lässt einen das auch glauben, aber die Realität sieht anders aus.
Daher fällt es mir schwer zuzustimmen, dass es standardisiert oder benutzbar sei; es ist genauso nervig wie damals, als man direkt im Webinterface herumklicken musste.
Eine Möglichkeit für die Aussage, dass man ohne IPMI leben müsse, wenn man auf kompakte oder stromsparende Computer besteht, ist ein Atom-basiertes Supermicro-MicroATX-Board mit IPMI in einem kurzen 1U-Gehäuse, das von kleinen Noctua-Lüftern leise gekühlt wird.
Ich nutze zu Hause ein älteres Modell, und weil es leise und klein ist, fand ich es deutlich attraktiver als die Dell-R2x0-Modelle, die ich gesehen hatte. Mit Server-Features wie IPMI und ECC-RAM war es besser als ein Mini-PC und stabiler als ein wackeliger RasPi.
Persönlich würde ich den IPMI-Port nicht ins Haupt-LAN stecken, aber getrennt davon war er ziemlich nützlich und machte auch Spaß zum Herumspielen.
In meinem Board steckt ein 5950X, aber eine Zeit lang lief es auch mit einem 5600G gut. Da es mATX/ATX ist, passt es in normale Gehäuse und an normale Netzteile, und man braucht kein Rack.
Wenn man Geräten ohne IPMI Remote-Zugriffsfunktionen hinzufügen möchte, kann man so etwas wie den 30-Dollar-RISC-V-NanoKVM ausprobieren
Er bietet HDMI-Capture und -Encoding, Ethernet/Wi-Fi sowie ATX-Stromsteuerung und führt eine normale Linux-Distribution aus
https://www.aliexpress.com/item/1005007369816019.html
https://github.com/sipeed/NanoKVM
Es arbeitet als USB-Tastatur, USB-Maus, USB-Flash-Laufwerk zum Speichern eines Boot-ISO für Installation und Recovery sowie als ziemlich guter USB-NIC
Diesen USB-NIC kann man auf dem PC nutzen, um nur einen Verwaltungs-SSH-Port offenzulegen, sodass sich der PC anfühlt, als hätte er eine Art dediziertes IPMI-Interface. In der aktuellen Software ist auch Unterstützung für WireGuard und Tailscale enthalten, sodass man sich direkt per VPN verbinden kann
Es gibt noch kleinere Probleme, aber die Entwickler beheben sie schnell
Man könnte es wohl selbst bauen, aber USB-C-Stecker zu löten ist wirklich unangenehm
Noch ein nicht vertrauenswürdiges KVM
Ende der 1990er habe ich mehrere von Intel gebaute Server installiert. Intel lieferte Referenzplattformen als „Barebone“-Computer aus, RAM und Storage wurden vom Integrator eingebaut, und das Lights-out-Management lief über LANDesk Server Manager Pro und eine „Emergency Management Card“ (EMC)
Das waren Geräte aus der Pentium-Pro- bis frühen Pentium-II-Ära wie AP450GX, BB440FX und RC440FX
Wenn man bedenkt, dass Referenzcode von x86-Plattformen nicht stirbt, habe ich mich oft gefragt, wie viel der heutigen IPMI-Strukturen auf diese Hardware und Software zurückgeht. Das Standardpasswort der Intel LANDesk Emergency Management Card war „calvin“, und wenn man frühe Dell iDRACs benutzt hat, dürfte einem dieses Passwort bekannt vorkommen. Ich glaube nicht, dass das Zufall ist
Nebenbei: Ein Intel-Mitarbeiter sagte mir, der Codename der EMC sei „Hobbes“ gewesen, aber ich konnte dazu keine Dokumentation finden
EMC-Versionen tauchen gelegentlich bei eBay auf, es gab sowohl ISA- als auch PCI-Versionen. Es war ein x86-PC auf einer Karte, und einige oder alle hatten eine integrierte UPS. Es gab einen PCMCIA-Slot für Out-of-Band-Management und ein externes Netzteil; die Karte war über ihr Host-Bus-Interface und proprietäre Steckverbinder mit dem Server-Mainboard verbunden
Ich habe Firmware einiger EMC-Versionen heruntergeladen und angeschaut; manche wirkten wie Embedded-DOS-Maschinen. Das ist noch ein Spielzeugprojekt, das ich irgendwann angehen will, daher habe ich den Code noch nicht reverse-engineert oder in qemu laufen lassen, würde es aber gern tun
Drittanbieter wie Unisys, Fujitsu, ALR/Gateway und NCR, die Intel-Referenzplattformen verkauften, boten diese Karte ebenfalls an. Wenn man sie in Verkaufsangeboten sieht, ist das ein guter Hinweis auf eine Intel-Referenzplattform, ebenso Verweise auf „LDSM“
Wenn jemand diese Abstammung kennt, wäre das wirklich interessant
https://www.intel.com/pressroom/archive/releases/1998/ld1030...
https://web.archive.org/web/20240903131630/https://www.ebay....
Intel ME und AMD PSP tragen wesentlich dazu bei, die CPU in einen Zustand wie bei einem x86-PC zu bringen, in dem Host-Firmware tatsächlich ausgeführt werden kann
Die Initialisierungskomplexität ist so hoch geworden, dass es mehr Sinn ergibt, sie in Software auf einem gesitteten separaten Embedded-Core zu erledigen, der in C programmierbar ist, statt die gesamte Logik in seltsam eingeschränktem Assembly wie beim traditionellen frühen BIOS-Startcode zu schreiben
Bei einigen HPE ProLiant scheint iLO tatsächlich Teile dieser Low-Level-Initialisierung zu übernehmen. In dieser Bootphase steuert iLO auch direkt den Framebuffer; bei G10 erscheint kurz eine Meldung in der Art, dass die „Konsole an den Host übergeben“ wird, danach wird das Display neu initialisiert und die Hinweise zu den Funktionstasten erscheinen
Dell dürfte etwas Ähnliches tun, aber in der frühen Phase sieht man nur „Please wait“ und eine große Ladeanzeige, ohne Fortschrittsstatus
IPMI und andere Lösungen sind gut, aber was ich immer haben möchte, ist ein standardisiertes serielles Interface zu einer ständig laufenden UEFI-Shell. Wie ich auf diesen seriellen Port zugreife, ist dann mein Problem
ExitBootServices()aufgerufen hatDer Code wird buchstäblich aus dem RAM entfernt und der entsprechende Bereich an das Betriebssystem zurückgegeben, daher ist die Umsetzung nicht einfach
BIOS/UEFI-Remote-Konsolen waren immer heikel, und ob sie funktionierten, war sehr wechselhaft. Um Ein- und Ausgabe passend hinzubekommen, musste man oft an GRUB- oder Kernel-Konfigurationen drehen
IPMI ist nützlich, zeigt aber sehr deutlich, dass man kommerziellen Unternehmen nicht vertrauen kann, Hardware langfristig ordentlich zu unterstützen
Das Betriebssystem, das auf IPMI läuft, ist meistens relativ sicher, solange das System neu ist. Sobald aber ein neuer CPU-Sockel erscheint, verlieren die Hersteller zunehmend das Interesse an Updates für ältere Systeme. Das gilt selbst dann, wenn dieselbe IPMI-Hardware sowohl auf alten als auch auf neuen Boards sitzt.
Wenn man auf der IPMI-Hardware ein eigenes Betriebssystem installieren könnte, wäre sie deutlich nützlicher. Dann könnte man sie auch sicher direkt mit dem Internet verbinden. Derzeit braucht man Sideband-Kommunikation wie VPN, SSH-Port-Forwarding oder ein separates Netzwerksegment, wodurch für die Unterstützung von IPMI viel zusätzliche Hardware und Konfiguration anfällt.
Bei großen Installationen verteilen sich die Zusatzkosten gut, bei kleinen Installationen sind sie aber eine ziemlich große Belastung. Wenn man nur ein einzelnes Gerät in Colocation betreibt, lohnt es sich kaum.
Weil man IPMI nicht sicher direkt ins Internet stellen kann, hängt am Ende an jedem Gerät irgendeine Form von Pi. Damit ist es genauso einfach, den seriellen Port zu verwenden, wenn nicht sogar einfacher. Letztlich kehrt man damit zur Standardsteuerung über serielle Ports zurück, die es schon zu VAX-, Sun- und Alpha-Zeiten gab – und je länger man darüber nachdenkt, desto sinnvoller ist das im Vergleich zu einer unsicheren Netzwerkschnittstelle.
Für kleinere Deployments, etwa in der Größenordnung von rund 10.000 Cores, würde ich über einen Integrator selbst aufbauen
Mit Gigabyte/ASRock-Rack-Mainboards, Epyc-9003-Serie, 384 GB RAM und einer üblichen redundanten Netzteilkonfiguration liegt man bei etwa 7.000 Dollar pro Node, und die Energieeffizienz kann ziemlich gut sein.
Das integrierte IPMI ist ebenfalls recht ordentlich, funktioniert gut mit
ipmitoolund enthält normalerweise auch einen gewissen Umfang an Redfish-Funktionen.Ich mag IPMI wirklich sehr, aber im Homelab stört mich daran, dass es im Idle etwa 5 W zusätzlich verbraucht
Die Kombination aus Gigabyte-MC12-LE0-Board und Ryzen Pro 5650 wirkt für einen Homeserver für etwa 50 Dollar wie eine naheliegende Wahl, aber der höhere Stromverbrauch gefällt mir nicht ganz.
Ältere Geräte wie Dell T20/T30 haben Intel AMT; das ist funktional deutlich schwächer und hat auch Sicherheitsmängel, bietet zusammen mit MeshCommander aber immerhin eine Möglichkeit zur Fernverwaltung. MeshCommander wurde leider eingestellt und die Releases sind hier und da verschwunden, aber glücklicherweise habe ich die MSI- und Node-Pakete auf einem Server gespeichert.
Ich plane, PiKVM V2 mit einem Raspberry 4 und einer einfachen USB-HDMI-Capture-Karte für 8 Dollar auszuprobieren: https://docs.pikvm.org/v2/
Abgesehen davon, dass einige Funktionen fehlen, wirkt es vielversprechend, weil es sich universeller auch für Geräte einsetzen lässt, die überhaupt keine Fernverwaltung unterstützen.
Ich bezweifle, dass ein BMC – manchmal ein in die NIC integrierter BMC – wirklich so viel Strom frisst. Außerdem dürfte PiKVM mit einem Raspberry 4 über 5 W liegen.
https://github.com/sipeed/NanoKVM
Ich habe es nicht ausprobiert, aber als Nachfolger scheint https://meshcentral.com/ vorgesehen zu sein.
Die große Frage bei IPMI ist, was der Standardschlüssel ist
Wenn irgendwo in der Lieferkette jemand zusätzliche IPMI-Schlüssel installiert oder es einen Standardschlüssel gibt, kann diese Person den Computer aus der Ferne verwalten.
https://www.rapid7.com/blog/post/2013/07/02/a-penetration-te...
Bei IPMI ist die maximale Passwortlänge außerdem auf 20 Zeichen begrenzt. In der Praxis sollte man davon ausgehen, dass der Hash höchstens gegenüber bekannten Pentestern geheim bleibt, die innerhalb eines begrenzten Vertragszeitraums arbeiten – nicht aber gegenüber echten Angreifern mit unbegrenzter Zeit.
Diesen Punkt sehe ich äußerst kritisch. Er steht seit 20 Jahren in der Spezifikation. Ist nicht gerade der Vorteil von Software, dass sie sich leichter ändern lässt als Hardware? Es ist leicht zu sagen: „Das muss in ein VLAN.“ Wenn man aber Audits macht, hängt IPMI fast immer am Büronetz.
Wenn man dumme Dinge in die Defaults packt, verbreitet sich weltweit eine dumme Konfiguration – einschließlich in jedem Unternehmen ohne sachkundige Security-Admins in dem Moment, in dem es „einen Server kauft“.