Blog

Überraschung! Microsoft hat vor wenigen Tagen die von der Windows-Welt allbekannte PowerShell für Linux- und macOS Systeme öffentlich freigegeben. Und zwar steht nun das Projekt auf GitHub unter der MIT-Lizenz – also OpenSource – für jeden frei zur Verfügung. Es gab bereits vor einigen Wochen einige Spekulationen und mehrfache inoffizielle Aussagen, dass Microsofts Shell OpenSource auch für andere Systemen erscheinen soll. Diese haben sich hiermit nun bestätigt…

Wie bereits in einem vorherigen Blog-Artikel genauer erläutert, hat Veeam eine neue kostenfreie Software mit dem Namen “Veeam Backup Agent for Linux” veröffentlicht. Aktuell noch in der Beta-Phase. Damit ist die Sicherung von Linux-Systemen – auch ganz ohne grafische Desktop-Umgebungen – über die CLI möglich. Die Konfiguration läuft mit Hilfe einer beigelieferten GUI über das Terminal ab. In diesem Artikel möchte ich nun genauer auf die erste Konfiguration des ersten Backup-Jobs eingehen. Zur Installation des Backup Agents bin ich bereits in einem vorherigen Artikel genauer eingegangen – dieser ist im ersten Absatz verlinkt.

Veeam bietet seit längerer Zeit eine kostenlose Lösung zum Sichern von einzelnen Windows-Maschinen an: Die Software hört auf dem Namen Veeam Endpoint Backup Free und hat selbst mir schon mehrmals aus der Klemme geholfen. Wer sich genauer über das Tool informieren möchte, kann sich auf der offiziellen Webseite umsehen. Wie bereits vor einigen Monaten berichtet, gab man die Entwicklung einer kostenlosen Sicherungslösung für Linux-basierende Betriebssysteme bekannt. Nach einigen Monaten Verspätung, wurde schließlich am 21. Juni 2016 die erste Beta-Version des Veeam Backup Agents für Linux veröffentlicht. Ich habe mir einen ersten Eindruck verschafft und möchte euch diesen nun mitteilen…

Kurz notiert: Die maximale Gültigkeitsdauer eines Zertifikates ist standardmäßig seitens der Windows Zertifikatsstelle (“Certification Authority“) auf 2 Jahre beschränkt. Wird eine Zertifikatsanforderung (“Certificate Signing Request“) mit einer längeren Gültigkeitsdauer eingereicht, beschwert sich die Windows CA aufgrund der zu langen Dauer. Das Zertifikat wird zwar dennoch erfolgreich ausgestellt, jedoch beschränkt sich die Gültigkeit dieses Zertifikates dann auf die maximal zulässige Dauer. Ein Grund für eine längere Gültigkeitsdauer ist unter anderem, dass die Zertifikate weniger oft auf den Zielsystemen gewechselt werden müssen. Spart natürlich ein wenig Arbeit ein. Jedoch sollte man vorab die Pro und Kontras diesbezüglich abwägen, bevor es zur Umsetzung geht – natürlich kommt es auch stark auf den geplanten Einsatzzweck an. Nicht vergessen: Die Dauer des Zertifikates kann nicht die Dauer des Root-Zertifikates übersteigen! Die Antwort seitens der Certificate Authority von certreq fällt wie folgt aus: Certificate retrieved(Issued) Issued The certificate validity period will be shorter than the WebServerSec5y Certificate Template specifies, because the template validity period is longer than the maximum certificate validity period allowed by the CA. Consider renewing the CA certificate, reducing the template validity period, or increasing the registry validity period. (“WebServerSec5y” ist hierbei ein von mir selbst erstelltes CA-Template mit einer Gültigkeitsdauer von 5 Jahren) Doch was wäre, wenn man dennoch länger gültige Zertifikate haben möchte?

Standardmäßig kann die Bash-Shell der VMware vCenter Server Appliance 6.0 nur für maximal 86400 Sekunden – also 24 Stunden – aktiviert werden. Nach dem Ablauf wird die Bash-Shell wieder deaktiviert und die eingebaute limitierte “ApplianceSh”-Shell verwendet. In älteren VCSA 6.0-Versionen gab es hier einen Trick, indem man das Timeout einfach auf den Maximalwert einstellte, welcher etwa 68 Jahre entsprach. Dieser funktioniert in den neueren Versionen leider nicht mehr:

Aktuell findet in Las Vegas die VeeamON 2015 statt, wo sich Experten, Partner und Kunden von Veeam aus aller Welt treffen, sich gegenseitig austauschen, an Konferenzen teilnehmen und das sicherlich großzügige Buffet genießen werden. Zudem stehen Präsentationen zu neuen Produktvorstellungen und Technologien von Veeam an. Soweit nun kurz die VeeamON erklärt, kommen wir nun zum Kernthema, worüber ich eigentlich schreiben wollte: Veeam hatte auf der besagten Veranstaltung ein neues Produkt angekündigt, was mich ehrlich gesagt sehr begeistert und worauf ich schon sehr gespannt bin. Um euch nun nicht noch weiter auf die Folter zu spannen: Es wurde das Produkt “Veeam Backup For Linux” angekündigt.

Veeam Backup & Replication ist eine sehr tolle und umfangreiche Software zum Sichern von Hypervisors wie VMware ESXi oder Microsoft Hyper-V. In den vergangenen Wochen hat mich Veeam jedoch mit einem Problem ratlos gemacht: Veeam konnte meine zwei Microsoft SQL Server 2014 Service Pack 1 in einer Always-On-Gruppe einfach nicht sichern, obwohl diese offiziell von Veeam unterstützt werden. In der Verwaltungsoberfläche trat immer folgender Fehler auf: “VSSControl: Failed to freeze guest, wait timeout” (siehe ebenfalls im Screenshot 1) Zur groben Übersicht, so sah die minimalistische Umgebung aus: 1x VMware ESXi 5.5 U2 1x VMware vCenter 5.5 U2 1x Veeam Backup and Replication v8 (v8.0.0.20121) 2x Microsoft SQL Server 2014 SP1 in zwei eigenen virtuellen Maschinen beide Nodes in einer Always-On-Gruppe AOG erreichbar unter DNS “sqlcl-vcenter.domain.local” Woran das nun liegen könnte?

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]) 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…

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…

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…