VMWare ESXi 5.x – SSH aktivieren

VMWare ESXi basiert intern auf einem Unix-artigen System, entsprechend kann ab und an ein kleiner Schubs auf der Konsole recht hilfreich wirken. Zwar ist im System von Haus aus ein SSH-Server vorhanden, jedoch üblicherweise deaktiviert.

Um einen SSH-Zugang zu aktivieren klickt man im vSphere-Manager den Host an und wählt rechts den Tab “Konfiguration” aus. In der linken Seite befindet sich unter “Software” der Menüpunkt “Sicherheitsprofil”. Unter Dienste ist SSH bereits geführt, jedoch nicht gestartet – dies kann man über den kleinen Link “Einstellungen” an der rechten Seite ändern. Unter SSH->Optionen lässt sich der Dienst dauerhaft aktivieren oder auch nur für einen kurzen Eingriff manuell starten.

SSH @ ESXi 5.x

Der zugehörige Artikel bei VMware wäre 2004746

BitNotice #47 – CableSharing: 2xEthernet aus einem Kabel

“Cabel Sharing” ermöglicht es über ein normales Netzwerkkabel gleich 2 Anschlüsse zu übertragen. 10 oder 100MBit/s Ethernet nutzt 4 Adern, übliche Netzwerkkabel bieten 8. Die freien Adern können daher für einen zweiten Anschluss herangezogen werden. Nicht Standardgemäß, nicht für 1GBit/s-Ethernet oder PoE und kann zu Störungen führen, wenns schnell gehen muss aber ein hilfreicher Trick.

BitBastelei #105 – LiPo-Basteleien (TP4056,18650)

Lithium-Ionen und Lithium-Polymer-Akkus sind heute kaum weg zu denken – Grund genug sich das Ganze genauer an zu schauen. Ausgerüstet mit einem TP4056 Lade-IC werden “kaputte” Laptop-Akkus wiederbelebt, ein Arduino dient zum Akkutest.

00:12 – TP4056 Lade-IC
02:50 – Aufbau Laptop-Akkupack
11:02 – TP4056: Erste Nutzung
14:31 – TP4056 + Zelle aus Laptop-Pack
18:03 – Arduino als Entladetest
22:35 – NiCd-Lader zu LiPo-Lader umbauen
26:16 – Zweiter Laptop-Akku

Lade-IC: www.ebay.de/itm/251537822465

CURL & OpenSSL – Zertifikatsfehler

In den letzten Tagen hatte ich einige seltsame Ergebnisse bei CURL – einige URLs wurden wegen eines fehlerhaften Zertifikatsunterschrift abgelehnt:

Cannot connect to URL : Peer certificate cannot be authenticated with known CA certificates: SSL certificate problem, verify that the CA cert is OK. Details:
[…]routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Seltsamerweise ist manuell sowohl Zertifikat als auch CA fehlerfrei, letztere ist auch in /etc/ssl/certs/ korrekt hinterlegt. Laut diversen Posts handelt es sich wohl um einen Fehler in OpenSSL – um vorerst Ruhe zu bekommen habe ich curl nun unter Gentoo mit CURL_SSL=”gnutls” oder CURL_SSL=”polarssl” installiert und bisher keine Probleme mehr. Für Ubuntu wäre libcurl4-gnutls-dev der richtige Startpunkt.

Warning: Nerd inside