VMware: Fehler beim Upgrade des HP MicroServer Gen8 von ESXi 5.5U1 auf 5.5U2


Durch die Umstrukturierung meiner privaten IT-Umgebung Zuhause wollte ich zugleich meine vorhandene VMware ESXi-Installation auf meinem HP MicroServer Gen8 aktualisieren: Nämlich von der Version 5.5 Update 1 auf 5.5 Update 2. Als Installationsmedium kam die von HP angebotene ESXi-ISO mit den dazupassenden Treibern zum Einsatz, welche auf der HP-Webseite zum Download bereit steht. Die Firmware der Hardware und vom iLO befand sich auf dem Stand des “HP Service Pack For ProLiant” vom Mai 2015.

Also, nun einen USB-Stick aus meinen unendlich tiefen Schrank voller IT-Zeug geholt, mit Hilfe von Rufus die vorhin heruntergeladene ISO auf einen USB-Stick gepackt und die HP-Kiste davon gebootet. Nach der Auswahl der richtigen Festplatte mit der ESXi-Installation und der Angabe, dass ein “Upgrade” gewünscht ist, wird nun das “System gescannt“… Aber genau hier war nun auch Schluss. Nach wenigen Sekunden tauchte dann folgende Fehlermeldung auf:

ValueError: Cannot merge VIBs Mellanox_bootbank_net-mst_2.0.0.0-1OEM.550.0.0.472560, Mellanox_bootbank_net-mst_2.0.0.0-1OEM.550.0.0.472560 with unequal payloads attributes ([net-mst: 8.250 KB], [net-mst: 8.242 KB])

Fehlermeldung im VMware ESXi-Installer

Es scheinen sich anscheinend zwei VIBs mit denselben Versionen auf dem vorhandenen ESXi und der 5.5U2-ISO zu befinden, welche unterschiedlich groß sind. Dadurch scheint der ESXi-Installer etwas verwirrt zu sein. Das war dann natürlich nicht so erfreulich. Aber zum Glück gibt es ja die Freund und Helfer: Die Suchmaschinen. Meist gibt es dann auch andere Personen aus der IT-Welt, die ein ähnliches oder gar das selbe Problem hatten und bei meiner Problemstellung, war das glücklicherweise der Fall…Read full article »

[QuickTipp] Zertifikatsdatei .pfx aus Zertifikat und Key erstellen (und umgekehrt)


Noch ein kleiner Tipp für Zwischendurch: Falls man mal eine Zertifikatsdatei .pfx benötigen sollte, aber nur das Zertifikat (.cer, .crt) und den Key (.key) besitzen sollte, kann man sich mit einem einfachen Befehl mit dem Tool openssl die Zertifikatsdatei erstellen:

openssl pkcs12 -export -out domain.pfx -inkey domain.key -in domain.crt

Update 21.01.2015: Thomas aus den Kommentaren wies mich darauf hin, wie das nun umgekehrt möglich ist: Natürlich gibt es auch hierfür Situationen, wo das durchaus hilfreich sein könnte. Das Extrahieren klappt auch hier mit zwei Befehlen:

Key aus .PFX exportieren: (Achtung: Der Key wird verschlüsselt exportiert!)
openssl pkcs12 -in domain.pfx -nocerts -out domain.key

Zertifikat aus .PFX exportieren:
openssl pkcs12 -in domain.pfx -clcerts -nokeys -out domain.crt

Das Passwort der Key-Datei kann man mit einem Befehl entfernen – falls man das überhaupt möchte. Man wird zur Bestätigung nach dem Passwort des Zertifikates gefragt.
openssl rsa -in domain.key -out domain_decrypted.key

Quelle #1: stackoverflow.com
Quelle #2: markbrilman.nl

[QuickTipp] -bash: /bin/rm: Argument list too long


Vor mehreren Wochen stand ich vor dem Problem, das temporäre Verzeichnis /tmp zu leeren: Beim Ausführen kam lediglich die wenig zufriedenstellende Rückmeldung /bin/rm: Argument list too long. Der Fehler scheint aufzutauchen, wenn das Argument mit der Liste der zu löschenden Dateien größer als 128 Kilobyte ist – welche sicherlich eine stolze Liste an Dateien ist… Zum Glück gibt es auch hierfür ausreichend Workarounds, die vielen Dateien dennoch auf einmal löschen zu können.

Zwei Möglichkeiten hierfür sind:
for i in *; do rm $i; done
…oder…
find -type f -print0 | xargs -0 rm

Abschließend bedanke ich mich bei dem Autor des Artikels unter sysadminslife.com für die Lösung!

[QuickTipp] Speedtest via CLI


Ein kleiner Tipp für Zwischendurch, womit man ganz simpel die Internetanbindung über die allbekannte Seite Speedtest.net über die Command Line testen kann. Die Installation sowie die Ausführung ist schnell erledigt und lässt sich auch sehr leicht durchführen.

Installation von python-pip via apt

apt-get install python-pip

Installation von speedtest-cli

$ pip install speedtest-cli
Downloading/unpacking speedtest-cli
  Downloading speedtest-cli-0.3.1.tar.gz
  Running setup.py egg_info for package speedtest-cli

Installing collected packages: speedtest-cli
  Running setup.py install for speedtest-cli

    Installing speedtest script to /usr/local/bin
    Installing speedtest-cli script to /usr/local/bin
Successfully installed speedtest-cli
Cleaning up...

Fertig ist die Installation.

Die Ausführung
Der eigentliche Test wird mit speedtest-cli ausgeführt, was dann zum Beispiel so aussehen kann:

$ speedtest-cli --share
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Server Block (144.76.38.130)...
Selecting best server based on ping...
Hosted by Vodafone DE (Frankfurt) [100.73 km]: 7.709 ms
Testing download speed........................................
Download: 297.61 Mbits/s
Testing upload speed..................................................
Upload: 71.29 Mbits/s
Share results: http://www.speedtest.net/result/3734126179.png

Tipp: Wenn man sich nur für die Endergebnisse interessiert, kann man einfach den Parameter “–share” weg lassen. Dabei wird dann nur der Test ausgeführt und die Ergebnisse werden nicht veröffentlicht.

via github.com/sivel/speedtest-cli

ext4 – Neue Partition belegt bereits Speicherplatz


ext4

ext4 und der reservierte Speicherplatz

Das Problem
Vor einigen Monaten stand ein Freund und ich vor dem Rätsel, warum eine neu erstelle Partition mit dem Dateisystem ext4 bereits eine Menge an Speicherplatz belegt hat – komplett jungfräulich, ohne jegliche Daten. Bei einer 4 TB Festplatte waren so bereits satte 186 GB in Verwendung…

Wie sich später herausstellte, reserviert sich ext4 automatisch 5% des Speicherplatzes für Notfälle. Sollte also die Festplatte aus irgendwelchen Gründen voll laufen, würde das sehr wahrscheinlich katastrophal enden und im schlimmsten Fall würde das System danach nicht mehr (ordentlich) hochfahren (natürlich vorausgesetzt es handelt sich hierbei um die Systempartition). Aus diesem Grund wird bereits ein prozentualer Speicherplatz für den root-Nutzer des Systems reserviert: Dadurch sollte das System selbst weiterhin in der Lage sein, hochfahren können, um dann selbst wieder freien Platz schaffen zu können.
Anwendungen, welche nicht unter dem Administratorkonto laufen, haben keinen Anspruch auf den reservierten Speicherbereich und würden wahrscheinlich beim Versuch, Daten auf die Festplatte zu schreiben, abstürzen.

Ich würde empfehlen, bei Partitionen, worauf sich ein Betriebssystem befindet, den reservierten Speicherbereich zu belassen – just in case. Bei reinen Datenplatten macht dies natürlich weniger Sinn und kann deshalb auch reduziert oder gar komplett abgeschaltet werden.

Die Lösung
Mit dem Werkzeug, welches bereits auf den meisten Linux-Systemen vorinstalliert ist, lässt sich der prozentual reservierte Bereich problemlos während des Betriebes ändern:

tune2fs -m 0 /dev/sda1

Erklärung: Der Parameter “-m” definiert hierbei die prozentuale Reservierung der angegebenen Partition. 0% deaktiviert die Reservierung.

via ubuntu-forum.de