Schlagwort-Archive: Server

BitNotice #115 – SATA, SAS und Speichervoodoo

Den S-ATA-Stecker kennt vermutlich jeder PC-Bastler, aber wusstet Ihr auch, dass über den selben Stecker auch SAS funktioniert? Und dass man 4 dieser Datenkanäle auf ein Kabel bündeln kann? Ein kurzer Blick auf die SATA/SAS-Stecker und Protokolle, welche bei mir so herumfliegen.

Korrektur: SFF-8482 ist nur S-ATA-kompatibel, nicht 100% identisch

BitBastelei #174 – XMPP-Server mit Prosody

XMPP hatten wir ja schon mal – ein Instant Messaging Dienst wie viele ihn tagtäglich nutzen. Der Vorteil: Das Protokoll ist offen – jeder kann sich seinen Client – für welches Endgerät auch immer – aussuchen, selber welche entwickeln oder gar eigene Server betreiben. Um letzteres soll es dieses mal gehen: Mit Pros?dy lässt sich ein solcher in wenigen Minuten installieren.

XMPP-Logo: copyright (c) 1999 – 2011 by the XMPP Standards Foundation (XSF). https://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/#legal
Prosody-Logo: © https://prosody.im

Q’n’D Windows-Shutdown-Daemon in PHP

Alles in Deckung, ich mache wieder unschönes Zeugs. Ich hatte ja bereits erklärt wie man über RPC/Samba einen Windows-PC von Linux herunterfahren kann. Leider ist die Installation von Samba aus Embedded-Systemen eine eher ungünstige Sache und ist in meinem Fall wegen Speichermangel nicht drin. Allerdings ist sowohl auf dem Embedded-System als auch dem betroffenen Rechner PHP verfügbar. I aim to misbehave.

Auf dem herunterzufahrenden Windows-Rechner wird per PHP ein TCP-Socket geöffnet. Dieser Code basiert auf einem Beispiel von Michael Kliewe. Um Scriptkiddies nicht direkt Zugang zu geben ist etwas (sehr schlechte) Challenge-Response-Authentifizierung drin – nunja, ist kein kritisches System. Wird der Client bestätigt folgt ein simples Shutdown per exec. Nicht viel, aber schnell Fertig und funktioniert:

Der Client bastelt sich eine passende Authentifizierung und spielt Zündknopf:

Hoffen wir, dass es läuft und ich nie wieder drauf schauen muss, denn irgendwo tut sowas selbst mir weh ;)

UEFI – wir verschlimmbessern?

Was war das doch früher einfach: Ins CMOS-Setup, ein paar wenige Einstellungen anpassen und meist konnte man danach sein System starten – auch, wenn der nötige “Treiber” erst per Option-ROM hinterher kam. Heute läuft das anders: Vor das ohnehin schon in einen Hypervisor verfrachtete OS hängt man einen weiteren Systemlayer: UEFI. Ganz toll mit ganz vielen Modulen und ganz vielen Möglichkeiten (die sicher auch Sicherheitstechnisch in Zukunft einigen Spaß machen dürften). Soweit die Theorie. Inzwischen hatte ich das große Vergnügen mehrere UEFI-Systeme vorgesetzt zu bekommen. Nummer eins war ein kleines AMD-Fusion-Board, welches recht pflegeleicht war. Das neue Setup glänzt mit Mausunsterstützung und selbsterklärender GUI, an vernünftige Einstellungen gelangt man über einen Expertenmodus. Das System startet flott und zeigt keine Fehler, zwar “no Points so far”, dann auch ältere PCs mit BIOS hatten zum Teil schon grafische Menüs, aber ich sah auch keine Nachteile für mach, also “macht wenn ihr euch besser fühlt” – die 2TB-Grenze des alten BIOS dürfte demnächst ja erreicht sein. Die weiteren Rechner waren IBM xServer und hierzu kann ich nur eins sagen: You are doing it wrong. IBM war ja noch nie für durchdachte Menüs oder Konzepte im BIOS zu haben, aber was sie bei diesen Kisten geritten hat wissen sie wohl selbst nicht – je nach PCI-Karten benötigen die Kisten über 20 Minuten um den BIOS-Nachfolger zu durchlaufen und mit dem OS zu beginnen. Das Booten einer internen RAID-Karte wird zur Geduldsprobe: Diese versteckt sich hinter kryptischen PCI-IDs, welche erst in eine Bootwarteschlange eingefügt und in einem weiteren Schritt entsprechend priorisiert werden müssen. Selbst dann booten ältere Systeme nicht, denn ohne ein höher priorisiertes “Legacy Devices”, welches als Dummy-Boot-Device dient und beim Booten diverse Einstellungen ändert, werden nur EFI-fähige Betriebssysteme unterstützt. “Mal schnell” etwas machen fällt hier definitiv aus. Aus den UEFI-Zielen der einfacheren Bedienbarkeit und schnelleren Bootzeiten wurde hier eher das exakte Gegenteil. Ich habe jetzt nach 2 Stunden jedenfalls das nicht (ganz planmäßig abgesägte) OS wieder am laufen – wie der letzte Nutzer es gebootet hatte wird wohl ein Geheimnis bleiben.