Archiv des Autors: Jörg Kastning

Konzept zum Deployment meines Blogs mit Ansible

An dieser Stelle möchte ich ein Konzept erarbeiten, um meinen Blog mit Hilfe von Ansible1 2 auf einem Ubuntu-Server ausbringen zu können.

Dabei hoffe ich auch ein wenig auf eure Unterstützung. Habt ihr Anregungen, konkrete Verbesserungsvorschläge oder auch Fragen, freue ich mich über eure Kommentare. Denn ich selbst bin kein Ansible-Experte und führe dieses Projekt zum Selbststudium und zu Übungszwecken durch.

Die Testumgebung

Die Testumgebung besteht aus der Ansible Control Machine, basierend auf RHEL 73 und dem Zielsystem, basierend auf Ubuntu Bionic Beaver4. Zum Zeitpunkt der Erstellung dieses Artikels nutze ich Ansible in Version 2.4.2.

Zwar wurde bereits die Ansible-Version 2.5 veröffentlicht, in den RHEL-7-Paketquellen ist jedoch noch die Version 2.4.2 enthalten. Ich verwende diese Version auch auf der Arbeit und erhoffe mir so, Erkenntnisse aus diesem Projekt in meine dienstliche Tätigkeit einfließen lassen zu können.

Auf dem Zielsystem existiert ein Benutzer, welcher über volle sudo-Berechtigung verfügt. Dieser Benutzer muss sich mit seinem Passwort authentisieren, wenn er sudo verwendet.

Auf der Ansible Control Machine wird ein SSH-Schlüsselpaar5 generiert, dessen privater Schlüssel nicht mit einer Passphrase geschützt ist. Der öffentliche Schlüssel wird auf dem Zielsystem abgelegt. Damit wird sichergestellt, dass die Ansible Control Machine SSH-Zugriff auf das Zielsystem hat.

Die Konfiguration von Ansible (/etc/ansible/ansible.cfg) wird so angepasst, dass standardmäßig das oben erzeugte SSH-Private-Key-File beim Verbindungsaufbau genutzt wird.

Die Installation der benötigten Betriebssysteme und Ansible sind nicht Gegenstand dieses Artikels.

Geplante Vorgehensweise

Um eine Vorgehensweise zu erarbeiten, orientiere ich mich an dem Artikel Testinstanz für einen WordPress-Blog erstellen. In diesem habe ich bereits beschrieben, wie ein Blog auf einem weiteren System als Testsystem aufgesetzt werden kann. Die Vorgehensweise ist ähnlich, mit dem Unterschied, dass sämtliche Schritte nun durch Ansible orchestriert werden sollen.

Danach ergibt sich folgende (vorläufige) Reihenfolge:

  1. Vom Produktivsystem benötigte Dateien holen
  2. Sicherstellen, das alle benötigten Pakete auf dem Zielsystem installiert sind
  3. VirtualHost erstellen
  4. DocumentRoot aus Backup-Datei erstellen
  5. Datei-Attribute und Zugriffsrechte korrekt setzen
  6. Eine .httpasswd-Datei erzeugen/ausbringen
  7. Datenbank aus Backup wiederherstellen
  8. Datenbankbenutzer erstellen
  9. Troubleshooting

Mit hoher Wahrscheinlichkeit ist die obige Liste noch nicht vollständig. Daher werde ich diese im Laufe des Projekts anpassen, sobald weitere Erkenntnisse vorliegen.

Als Quelldaten für den Blog liegen das DocumentRoot meines Blogs als Tarball6 vor. Von der Datenbank wurde ein logisches Backup7 erstellt. Auf diese Datensicherung wird zurückgegriffen, um den Blog auf einem neuen Ubuntu-Server auszubringen bzw. wiederherzustellen.

Der erste Versuch

Im ersten Anlauf habe ich eine Ansible-Rolle8 mit folgendem Aufbau erstellt:

/etc/ansible/roles/
└── deploy-my-blog
    ├── files
    │   ├── backup-documentroot.tar.bz2
    │   ├── dh_params.pem
    │   ├── db_dump.sql.bz2
    │   ├── my-it-brain.vhost
    │   └── php-fpm-pool.conf
    ├── handlers
    │   └── main.yml
    ├── tasks
    │   └── main.yml
    └── vars
        └── main.yml

5 directories, 8 files

Unterhalb von files wurden Dateien abgelegt, welche vom aktuellen Produktivsystem stammen und für das Deployment auf einem neuen Server benötigt werden.

Im folgenden werde ich zuerst auf die eingesetzten Module eingehen und anschließend das Playbook zum Deployment des Blogs vorstellen.

Verwendete Module

ModulStatusVerwendung
aptstableinterfaceVerwaltet APT-Pakete
unarchivepreviewEntpackt Archiv-Dateien und kopiert sie ggf. vorher auf das Zielsystem
copystableinterfaceKopiert Dateien auf entfernte Rechner
filestableinterfaceErstellt Dateien, Verzeichnisse, symbolische Links und setzt deren Attribute
mysql_dbpreviewHinzufügen von MySQL-Datenbanken (aus Backup)
mysql_userpreviewHinzufügen (und Entfernen) von Benutzern in MySQL-Datenbanken

Die in der Spalte Status angegebenen Werte stableinterface und preview lassen Rückschlüsse auf die Stabilität der Schnittstellen eines Moduls zu.

So garantieren die Entwickler bei einem stableinterface, dass es in Zukunft keine Änderungen geben wird, die nicht abwärtskompatibel sind. Auch wenn sich keine explizite Angabe findet, wie lange diese Garantie gilt, kann man davon ausgehen, dass man seine Playbooks bei Verwendung dieser Module nicht so schnell aufgrund von Updates anpassen muss. Für Module mit dem Status preview wird genau dies hingegen nicht garantiert. Hier kann es von Version zu Version Änderungen geben, welche Anpassungen an Playbooks erforderlich machen, welche diese Module verwenden. Dadurch entsteht ggf. ein erhöhter Testaufwand, bevor man seine Ansible-Installation aktualisieren kann.

Das Playbook

Den Inhalt der Datei /etc/ansible/roles/deploy-my-blog/tasks/main.yml habe ich unter dem Namen deploy-blog-playbook.yml als Gist veröffentlicht. Um es in diesem Artikel anzeigen zu können, müsst ihr JavaScript in eurem Webbrowser aktiveren.

Die Zeilen 2-11 sorgen dafür, dass die benötigten Pakete auf dem Zielsystem installiert werden. Da es sich dabei um einen Ubuntu-Server handelt, verwende ich das Modul apt.

Die Zeilen 13-16 stellen das DocumentRoot und die SSL-Zertifikate aus dem Dateibackup auf dem Zielsystem wieder her.

In meiner aktuellen Konfiguration verwende ich PHP-FPM mit einem eigenen Pool, welcher in meinem VirtualHost referenziert wird. Um diese Konstellation auch auf dem neuen System nutzen zu können, stelle ich entsprechende Konfiguration mit den Zeilen 18-47 her. Vermutlich können die Zeilen 39-47 entfallen, da PHP-FPM das Logfile automatisch erstellt. Weitere Tests müssen dies noch zeigen. Ich habe diese Zeilen während des Troubleshootings eingefügt. Ursache für den Fehler wird vermutlich das fehlende Log-Verzeichnis gewesen sein, welches ich in den Zeilen 29-37 erzeuge.

Der NGINX auf meinem Produktivsystem verwendet die Datei dh_params.pem, welche ich in den Zeilen 49-57 auch auf den neuen Host kopiere. Anschließend wird in den Zeilen 59-66 die vHost-Datei auf das Zielsystem kopiert und durch die Zeilen 68-77 verlinkt und damit aktiviert.

Die letzten Zeilen kümmern sich um die Einrichtung der Datenbank. Zuerst wird die Dump-Datei auf das Zielsystem kopiert und dort anschließend in die neue Datenbank db_my_it_brain eingespielt. Zum Schluss wird noch der benötigte Datenbank-Benutzer erstellt.

In Zeile 94 und 95 habe ich Variablen eingesetzt, welche in vars/main.yml definiert wurden. Dort habe ich auch eine Variable für den Namen der Datenbank definiert, welche ich gern in Zeile 96 genutzt hätte. Leider ist es mir nicht gelungen, da sowohl priv: '"{{ DBNAME }}".*:ALL' als auch priv: "{{ DBNAME }}".*:ALL zu Fehlern führten. Falls hier jemand eine Idee hat, freue ich mich, wenn ihr mir die korrekte Syntax mitteilt.

Erstes Fazit

Das ging leichter als gedacht. Die benötigten Module waren schnell gefunden und ihre Anwendung aufgrund der hinreichend guten Dokumentation nicht schwierig.

Da die aktuell genutzten Variablen sensible Informationen beinhalten, möchte ich diese zukünftig mit Ansible Vault schützen.

Stand heute bin ich jedoch erstmal in der Lage meinen Blog aus der Datensicherung heraus erneut deployen zu können.

Chemnitzer Linux-Tage 2018 — Jeder fängt mal an.

Am 10. und 11. März 2018 finden fanden die Chemnitzer Linux-Tage (#clt2018) statt. Das Motto lautet in diesem Jahr lautete: „Jeder fängt mal an.“


Auch an dieser Stelle nocheinmal vielen Dank an die Veranstalter der #CLT2018 und die Hörer meines Vortrags „Webseiten mit HTTPS bereitstellen und mit HSTS sichern“. Die Folien zum Vortrag findet ihr auf der Seite Artikel und Vorträge sowie hinter diesem Direktlink.

Zum Ende meines Vortrags habe ich auf weitere Maßnahmen hingewiesen, mit denen sich die Angriffsfläche auf HTTPS verkleinern lässt. Weitere Informationen dazu findet ihr auf dieser Seite im Artikel „Über Pinning (HPKP), CAA und Certificate Transparency“.


Die Besucher erwartet in diesem Jahr erneut ein prall gefülltes Vortragsprogramm mit bis zu sieben parallel laufenden Tracks. War ich im vergangenen Jahr als Besucher zu Gast, steuere ich in diesem Jahr den Vortrag „Webseiten mit HTTPS bereitstellen und mit HSTS sichern“ bei. In diesem führe ich in das Thema HTTPS und die Internet-PKI ein und weise auf einige Stolpersteine hin, die auf dem Weg lauern.

Neben vielen interessanten Vorträgen werden an beiden Tagen jeweils sechs Workshops zum Lernen und Mitmachen angeboten. Für die Teilnahme ist eine Anmeldung erforderlich und es sind 5 Euro Teilnahmegebühr zu entrichten. Beeilt euch bei Interesse mit der Anmeldung, denn die Plätze sind begrenzt.

Darüber hinaus erwarten euch auf den CLT2018:

Die Praxis Dr. Tux bietet in ihrer Sprechstunde bei allen Problemen Hilfestellung, die der Anwender nicht alleine lösen kann.

Im Business Forum stellen sich bis zu 15 Open-Source-Firmen kurz vor. Hört entspannt zu, was diese Firmen genau tun, stellt Fragen und beteiligt euch an der Diskussion.

Auf der PGP-Party könnt ihr eure öffentlichen Schlüssel-Dateien signieren lassen. Weitere Informationen zur Vorbereitung und Durchführung findet ihr unter vorstehendem Link.

Retro Gaming wird während der Chemnitzer Linux-Nacht geboten. Ab 19:30 Uhr könnt ihr auf der Atari 2600 zeigen, aus welchem Holz ihr geschnitzt seid!

In der Projektküche präsentieren 15 Personen in jeweils fünf Minuten ihre Open-Source-Projekte. Möchtet ihr selbst euer Projekt vorstellen? Dann Beeilung, Anmeldeschluss ist der 1. März 2018.

Es wird also wieder viel geboten. Und neben den spannenden und interessanten Vorträgen freue ich mich natürlich auch, bekannte Gesichter wiederzusehen und abends über alte Zeiten zu plaudern. Bis neulich.

Ansible: Playbook nur auf Nodes laufen lassen, die gewissen Kriterien genügen

Manchmal möchte man ein Playbook bzw. Plays nur auf Hosts laufen lassen, welche gewissen Kriterien entsprechen. In diesem Beitrag möchte ich zwei Beispiele geben, wie sich dies umsetzen lässt.

Playbook nur auf Hosts mit Red Hat Betriebssystem ausführen

Das Modul group_by [1] wird genutzt, um während des Laufs eines Playbooks dynamisch Gruppen von Hosts zu erstellen, auf welche man später weitere Plays anwendet.

---
- hosts: all

  tasks:
    - name: Group by OS

      group_by: key=os_{{ ansible_distribution }}
      changed_when: False

- hosts: os_RedHat
  roles:
    - common

Zu Beginn eines Playbook-Laufs wird das Modul setup [2] ausgeführt, um Variablen mit nützlichen Informationen über die Nodes zu belegen. Die Variable ansible_distribution enthält dabei ein Schlüsselwort für eine bestimmte Distribution.

In obigen Beispiel wird dabei die Gruppe os_RedHat erstellt. Im Folgenden werden dann alle Nodes dieser Gruppe der Rolle common zugeordnet.

Dieses Verfahren lässt sich natürlich auch für weitere Variablen anwenden. Möchte man sehen, welche Variablen belegt werden und genutzt werden können, kann sich die Rückgabe von setup in der Standardausgabe ansehen, wenn man das Modul manuell auf einigen Nodes ausführt.

Plays nur auf bestimmten Nodes ausführen

Ein weiteres Beispiel habe ich auf ITrig [4] gefunden:

---
- name: install open-vm-tools
  hosts: vmwareclients
  gather_facts: True
  become: true
  become_user: root
  tasks:
- name: debian install open-vm-tools
  apt: name=open-vm-tools state=present
  when: ansible_os_family == "Debian" and ansible_virtualization_type == "VMware"

- name: centos install open-vm-tools
  yum: name=open-vm-tools state=present
  when: ansible_os_family == "RedHat" or ansible_distribution == 'CentOS' and ansible_virtualization_type == "VMware"

Hier werden Ansible Conditionals [3] verwendet, um zu bestimmen, auf welchen Nodes ein Play ausgeführt wird. Auch hier werden wieder Variablen ausgewertet, welche durch das Modul setup [2] belegt wurden.

In obigen Beispiel wird dies genutzt, um die open-vm-tools mit einem Playbook sowohl auf Debian und RedHat/CentOS Systemen zu installieren.

Quellen

  1. group_by – Create Ansible groups based on facts {en}
  2. setup – Gathers facts about remote hosts {en}
  3. Conditionals {en}
  4. Ansible Playbooks auf Servern mit SSH Key Authentifizierung verwenden {de}

Unit-Typ systemd.path kurz vorgestellt

Mit systemd.path lassen sich Dateien und Verzeichnisse auf bestimmte Ereignisse hin überwachen. Tritt ein spezifiziertes Ereignis ein, wird eine Service-Unit ausgeführt, welche üblicherweise den gleichen Namen, wie die Path-Unit trägt.

Wie dies funktioniert, möchte ich an einem sehr einfachen Beispiel zeigen. Das Ziel ist, die Datei testfile auf Änderungen hin zu überwachen. Immer wenn die Datei nach einem Schreibvorgang geschlossen wird, soll ein bestimmtes Skript gestartet werden.

beispiel.path

Im Verzeichnis /etc/systemd/system/ wird die Datei beispiel.path mit folgendem Inhalt erstellt:

[Unit]
Description=Datei auf Änderungen hin überwachen

[Path]
PathChanged=/home/oglattermann/testfile
Unit=beispiel.service

[Install]
WantedBy=multi-user.target

In der Sektion [Path] wird mit PathChanged= der absolute Pfad zu der zu überwachenden Datei spezifiziert, während Unit= angibt, welche Service-Unit ausgeführt werden soll, wenn sich die Datei ändert. Diese Unit soll gestartet werden, wenn sich das System im Multi-User-Mode befindet.

beispiel.service

Wird die Datei testfile geändert (genau: geschrieben und geschlossen), wird folgende Service-Unit aufgerufen, um das darin spezifizierte Skript auszuführen:

[Unit]
Description=Führt Skript aus, wenn eine Datei sich geändert hat.

[Service]
Type=simple
ExecStart=/home/oglattermann/skript.sh

[Install]
WantedBy=multi-user.target

Das Skript skript.sh enthält dabei in diesem Beispiel lediglich folgenden Code:

#!/bin/bash
echo "Datei geändert" >/home/oglattermann/Output.txt

Für einen Test müssen die beiden soeben erstellten Units noch aktiviert werden:

sudo systemctl enable beispiel.path beispiel.service
sudo systemctl start beispiel.path

Schreibt man nun die Datei testfile neu bzw. wird eine Schreiboperation auf diese Datei abgeschlossen, wird die entsprechende Service-Unit ausgeführt und man findet die Datei Output.txt vor.

Anwendungsbeispiele

Die folgende, unvollständige und nicht abschließende Liste führt einige Anwendungsbeispiele auf, wo sich systemd.path sinnvoll nutzen lässt.

  • Ereignisgesteuerte Datenverarbeitung starten
  • Dateien unter /etc überwachen und bei Änderungen Benachrichtigung versenden
  • Import-Ordner auf neue Dateien hin überwachen und Verarbeitung starten

Quellen und weiterführende Links

Wie kann man mit tcpdump HTTP-Traffic eines bestimmten Hosts sniffen?

Diese Frage wurde bereits von Scott in seinem englischsprachigen Blog beantwortet. Ich gebe sie an dieser Stelle wieder, um nicht immer wieder danach suchen zu müssen.

Das Kommando lautet:

tcpdump -c 20 -s 0 -i eth1 -A host 192.168.1.1 and tcp port http

Die Parameter bedeuten:

  • -c 20: Beendet den Vorgang, nachdem 20 Pakete aufgezeichnet wurden.
  • -s 0: Die mitgeschnittenen Nutzdaten sollen ungekürzt wiedergegeben werden.
  • -i eth1: Zeichne nur Pakete an der Netzwerkschnittstelle eth1 auf.
  • -A: Gebe alle Pakete in ASCII aus.
  • host 192.168.1.1: Zeichne nur Pakete auf, die von Host 192.168.1.1 kommen.
  • and tcp port http: Zeichne nur HTTP-Pakete auf.

Ergänzt man den Befehl noch um -w DATEINAME wird die Aufzeichnung in eine Datei statt auf die Standardausgabe geschrieben.

sht21andrasppi

Raspi-SHT21 Version 2 BETA veröffentlicht

Zwei Jahre sind seit dem letzten Release vergangen. Letztes Wochenende fand ich nun endlich die Zeit, mich wieder mit dem Projekt Raspi-SHT21 zu befassen. Herausgekommen ist die BETA der Version 2.

Alle Informationen zur neuen Version gibt es in den Versionsinformationen auf GitHub und in der README-Datei des Projekts.

Bei mir daheim läuft die neue Version bisher stabil. Da ausführliche Tests fehlen, habe ich sie als BETA markiert. Falls ihr Fehler findet, Fragen habt oder der Meinung seid, dass noch etwas fehlt (Code, Doku, Spendenbutton), eröffnet bitte einen GitHub-Issue oder hinterlasst mir hier einen Kommentar.

In Zukunft soll das Projekt um Remote-Messstationen erweitert werden. Der Raspberry Pi dient dabei als Zentrale zur Speicherung und Visualisierung der Messdaten. Diese werden zukünftig nicht mehr nur ausschließlich vom direkt angeschlossenen SHT21-Sensor geliefert, sondern auch von weiteren Sensoren, die ihre Daten per WLAN übertragen. Sobald es etwas zu zeigen gibt, werde ich in diesem Blog darüber berichten.

Verwandte Artikel

  1. Überwachung von Temperatur und Luftfeuchtigkeit mit dem SHT21
  2. Visualisierung von Umweltdaten

Synology NAS: Einzelnen Ordner neu indizieren

Synology Diskstations stellen Anwendungen bereit, um Bilder, Musik und Videos verwalten zu können. Dies sind im einzelnen

  • die Photo Station,
  • die Audio Station und
  • die Video Station.

Damit die Medien in den jeweiligen Anwendungen angezeigt werden können, müssen diese zuvor indiziert werden. Die Indizierung erfolgt automatisch, wenn Medien über die entsprechende Anwendung hinzugefügt werden. Fügt man sie jedoch auf anderem Wege hinzu, z.B. durch rsync, startet die Medienindizierung nicht und die Medien können in der jeweiligen Anwendung nicht wiedergegeben werden.

Die Benutzeroberfläche „DSM“ bietet lediglich die Möglichkeit, ganz allgemein eine Medienindizierung zu starten. Dabei werden jedoch sämtliche Medien neu indiziert und nicht nur die neu hinzugefügten. Je nach Umfang dauert die Indizierung mehrere Stunden bis Tage. Es gibt jedoch eine Möglichkeit, die Indizierung manuell zu starten und dabei auf ein einzelnes Verzeichnis zu beschränken.

Dazu meldet man sich per SSH an der Diskstation an und führt folgendes Kommando aus:
/usr/syno/bin/synoindex -R /Pfad/zum/Verzeichnis/

Damit lässt sich eine Menge (Rechen-)Zeit sparen.

Kommentar: VMware vSphere Web Client – Welch ein Fluch

Es war einmal vor langer Zeit, als einzig und allein der vSphere Client für Windows existierte, um einen ESX-Host bzw. einen vSphere Cluster zu verwalten. Und die vSphere-Admins waren glücklich und froh.

In dieser guten und glücklichen Zeit war der einzige Wermutstropfen, dass der vSphere Client nur für Microsoft Windows existierte und man als Linux-Liebhaber darauf angewiesen war, für die Administration der vSphere-Umgebung ein anderes Betriebssystem zu booten. Doch konnte dies die Freude nicht mindern. Und alle freuten sich und waren froh.

Doch in dieser Welt des Frohsinns und der Glückseligkeit gab es einen Dämon, dem dies alles gar nicht gefiel. Und dieser Dämon beeinflusste die guten Software-Engineers bei VMware und veranlasste sie dazu, den vSphere Web Client auf Basis von Flash zu entwickeln. Dies war der Beginn von dunklen Zeiten, welche bis in die Gegenwart anhalten.

Wer den vSphere Client kennt und sich den Web-Client ansieht, fragt sich vermutlich: „Warum? Warum investiert man Zeit, um so einen Mist zu entwickeln?“

Der vSphere Web Client ist langsam, kann nichts besser als der Fat-Client, bietet keine neuen Funktionen und basiert auf Flash. Letzteres sorgt dafür, dass es für Linux weiterhin keinen nutzbaren Client gibt. Doch den Göttern sei Dank, wir konnten weiterhin den althergebrachten Fat-Client nutzen und das Flash-Gespenst links liegen lassen. Und nachdem wir uns alle von dem Schreck erholten hatten, waren wir wieder glücklich und froh.

Dies gefiel dem Dämon nicht und so lies er verkünden, dass die Entwicklung des guten etablierten vSphere Client eingestellt wird, da man sich in Zukunft auf den Web-Client konzentrieren will. Dachte man anfangs noch an einen Aprilscherz, so wurden die Zeiten nun richtig finster. Denn der vSphere Web Client war immer noch mies und unbenutzbar. Der Unmut vieler Nutzer entlädt sich seit April 2014 in diesem Thread, welcher bis in die aktuelle Zeit Updates erfährt. Denn das Grundproblem ist immer noch nicht gelöst. Der vSphere Web Client ist immer noch nicht zu gebrauchen.

Um es noch einmal zusammenzufassen, der vSphere Web Client:

  • Ist so langsam, dass ich meinen Bart wachsen höre
  • Zwingt mich Flash auf meiner Admin-Workstation zu installieren, um ihn überhaupt nutzen zu können
  • Funktioniert nicht in allen Browsern
  • Funktioniert mal in dem einen, mal in dem anderen Browser (scheint mit der Mondphase zu wechseln)
  • Benötigt für volle Funktionalität das Client Integration Plugin (CIP), welches noch bescheidener funktioniert, als der Rest des Clients

Dieser Drecks-Web-Client raubt mir den letzten Nerv. Warum beschäftige ich mich überhaupt damit? Weil Client-Probleme im Web-Client reproduziert werden müssen, damit der VMware-Support helfen kann. Dies zieht einen Service Request nicht selten in die Länge, da man mit dem Support erstmal den Web-Client zum Laufen bringen muss, bevor man das eigentliche Problem analysieren kann. Eine echte Lösung gab es für den Client nie. Ein Workaround folgte dem Nächsten.

Unter uns, die Arbeit im VMware-Support kann doch auch keinen Spaß machen, wenn man so ein Drecks-Werkzeug supporten muss. Die Aussage eines Supporters dazu: „Ich gehe groß feiern, wenn der HTML5-Client endlich fertig ist.“

Der neue vSphere Client (HTML5) verspricht Licht am Ende des Tunnels. Die Kritik am verhassten vSphere Web Client scheint VMware erreicht zu haben. Doch offensichtlich muss es erst noch einmal schlechter werden, bevor es besser werden kann. Denn mit vSphere 6.5 hat uns VMware eine Version spendiert, in der sich der ausgereifte vSphere Client nicht mehr verwenden lässt, der vSphere Web Client immer noch totaler Mist ist und der vSphere Client (HTML5) noch nicht voll funktionsfähig ist. Super. Ganz toll. Statt eines gut funktionierenden Clients gibt es jetzt einen gammeligen und einen erst teilweise fertiggestellten.

Was bleibt ist die Hoffnung, dass der HTML5-Client in der nächsten vSphere-Version voll funktionsfähig ist und ein würdiger Nachfolger des guten alten Clients wird, welchen VMware so lieblos sterben lies. Und vielleicht kommt das VMware-Marketing auf der Suche nach Innovationen dann ja auf die Idee, einen schnellen, stabilen Fat-Client zu entwickeln. Und damit sind wir Admins wieder glücklich und zufrieden, bis ans Ende unserer (Arbeits-)Tage.

TLDR;

VMware vSphere ist ein gutes Produkt. Auch im Fall von Störungen in der IT-Infrastruktur lässt einen diese Lösung nur selten im Stich. Virtuelle Maschinen werden bis zuletzt korrekt ausgeführt, während der sie umgebene Rest schon am Boden liegt.

Warum das Unternehmen die Admins über die letzten Jahre mit einem vSphere Web Client straft, der einem jeglichen Spaß an der Arbeit nimmt, wird vielleicht für immer ein Rätsel bleiben.

Hoffentlich bekommt das Unternehmen mit dem neuen vSphere Client (HTML5) endlich die Kurve. Denn die Mitbewerber haben bereits aufgeschlossen und sind einen Blick wert, wenn einem bei Nutzung der Client-Anwendung übel wird.

Nun, wo der Frust einmal raus ist, geht es mir schon besser und ich wünsche euch ein schönes und erholsames Wochenende.

Ordnung in die Fotosammlung bringen

In diesem Beitrag möchte ich festhalten, wie ich mit dem ExifTool von Phil Harvey [1] ein wenig Ordnung in meine Fotosammlung brachte.

Meine Frau und ich verwenden verschiedene Geräte wie z.B. Smartphones, Tablets und Digitalkameras, um Fotos aufzunehmen. Dabei speichern diese Geräte die aufgenommenen Bilder nach folgenden Namensmustern:

  • IMG_1234.JPG
  • IMG_<YYYYMMDD>_<hhmmss>.jpg

Die so benannten Bilder landen nach Themen sortiert in Verzeichnissen auf einem NAS. Um sie in eine chronologische Reihenfolge zu bringen, möchte ich sie einheitlich nach folgendem Muster benennen:

  • <YYYY-MM-DD>T<hhmmss>_img.jpg

Dazu lese ich das Aufnahmedatum mit dem ExifTool aus den EXIF-Daten [2] der Fotos aus und verwende dies, um die Dateien nach dem gewünschten Muster umzubenennen. Der dazu genutzt Befehl sieht wie folgt aus:

exiftool '-filename<DateTimeOriginal' -d "/Pfad/zum/Zielverzeichnis/%Y-%m-%dT%H%M%S_img%%-c.jpg" Quellverzeichnis/

Mit dem obigen Kommando werden die Dateien aus dem Quellverzeichnis wie gewünscht umbenannt und in das Zielverzeichnis verschoben. Sollte dort bereits eine Datei mit gleichem Namen existieren, wird durch die Option „%%-c“ ein Index angehängt und hochgezählt.

[1] ExifTool by Phil Harvey {en}
[2] Exchangeable Image File Format {de}

Zertifikatsanfrage (CSR) mit OpenSSL erstellen

Dieses Tutorial beschreibt, wie eine Zertifikatsanfrage (engl. Certificate Signing Request, kurz CSR) erstellt werden kann. Dabei wird die Erstellung von Anfragen für Zertifikate mit einem und mehreren enthaltenen Hostnamen behandelt. Die nach diesem Tutorial erstellten Zertifikatsanfragen können dann genutzt werden, um sie an eine Zertifizierungsstelle (engl. Certificate Authority, kurz CA) zu übermitteln.

Voraussetzung, um diesem Tutorial zu folgen, ist eine funktionsfähige Installation von OpenSSL. Die Installation von OpenSSL ist nicht Gegenstand dieses Tutorials.

Die folgende Tabelle gibt Auskunft über die Konfigurationen, mit denen dieses Tutorial getestet wurde.

BetriebssystemOpenSSL Version
Ubuntu 16.04 LTSOpenSSL 1.0.2g
CentOS/RHEL 7OpenSSL 1.0.2k-fips
Fedora 26OpenSSL 1.1.0f-fips

Keyfile und CSR in einem Schritt erstellen

Die Dateien für den privaten Schlüssel und den CSR können auf der Kommandozeile mit dem folgenden Befehl erstellt werden. Dabei werden die benötigten Informationen interaktiv abgefragt.

/tmp$ openssl req -newkey rsa:2048 -sha256 -keyout test.key -out test.csr
Generating a 2048 bit RSA private key
..............................................................................................+++
........................................................................................................................+++
writing new private key to 'test.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:NRW
Locality Name (eg, city) []:.        
Organization Name (eg, company) [Internet Widgits Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:test.example.com
Email Address []:.

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:.
An optional company name []:.

Die einzelnen Argumente des Befehls sind wie folgt zu erklären:

openssl req ruft das Kommando zur Generierung eines PKCS#10 CSR auf [1]. Das Argument -newkey rsa:2048 gibt an, dass ein neuer RSA-Key mit einer Schlüssellänge von 2048 Bit generiert werden soll. Dieser Schlüssel wird anschließend verwendet, um den CSR zu erzeugen. Mit dem Argument -sha256 wird angegeben, dass das beantragte Zertifikat mit dem SHA256-Algorhytmus signiert werden soll. Man beachte, dass dies von der Zertifizierungsstelle überschrieben werden kann. Mit -keyout test.key wird der Dateiname angegeben, unter dem die Private-Key-Datei (test.key) im aktuellen Verzeichnis gespeichert werden soll. Dementsprechend gibt -out test.csr an, wo die CSR-Datei (test.csr) gespeichert werden soll. Im oben dargestellten Beispiel geschieht dies ebenfalls im aktuellen Verzeichnis.

Das Kommando erzeugt den privaten Schlüssel und fragt interaktiv nach einer Passphrase, mit welcher die Private-Key-Datei verschlüsselt wird. Anschließend werden die Informationen abgefragt, welche in den CSR aufgenommen werden sollen. Mit einem „.“ gibt man an, dass der Standardwert aus den eckigen Klammern in den CSR übernommen werden soll. Auf die Angabe einer E-Mail-Adresse und eines Challenge-Passworts kann guten Gewissens verzichtet werden, da diese Angaben von den meisten Zertifizierungsstellen ignoriert werden.

CSR für mehrere Hostnamen erstellen

Um einen CSR für mehrere Hostnamen zu erstellen, bedient man sich am einfachsten einer Konfigurationsdatei. Die im Folgenden verwendete Konfigurationsdatei kann unter [2] heruntergeladen und unter einem beliebigen Namen (z.B. csr_config.cnf) gespeichert werden. Ausführliche Informationen zum Aufbau der Konfigurationsdatei finden sich in Kapitel 3.3 des unter [2] verlinkten TLS-Kochbuchs. Beachten Sie, dass hinter dem Parameter subjectAltName neben den weiteren Host-/Domain-Namen auch der commonName mit aufgeführt werden muss.

[ req ]
default_bits = 2048
default_keyfile = test_privatekey.pem
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:test.example.com, DNS:*.test.example.com

[ req_distinguished_name ]
countryName = DE
stateOrProvinceName = Nordrhein-Westfalen
localityName = MeinOrt
0.organizationName = MeineFirma
organizationalUnitName = MeineAbteilung
commonName = test.example.com

Die obige Konfigurationsdatei kann nun genutzt werden, um einen CSR für den Hostnamen test.example.com und alle möglichen Hostnamen unterhalb der Domain .test.example.com zu erstellen:

/tmp$ openssl req -batch -sha256 -new -config csr_config.cnf -out test2.csr

Mit der Option -batch wird der interaktive Modus deaktiviert. Die Option -new gibt an, dass ein neuer CSR generiert werden soll. Dabei wird ein Private-Key nach den Vorgaben in der Konfigurationsdatei, welche mit -config csr_config.cnf angegeben wird, erzeugt.

Abschließende Bemerkungen

Die beiden gezeigten Methoden zur Erzeugung einer Zertifikatsanfrage stellen nur einen kleinen Ausschnitt aus dem großen Werkzeugkasten namens OpenSSL dar. Doch sind sie dazu geeignet, in einfacher Weise einen CSR zu erstellen, den man zur Signatur an eine CA seines Vertrauens senden kann.

  1. PKCS #10: Certification Request Syntax Specification
  2. TLS/SSL-Kochbuch – Rezepte für die Verwendung von OpenSSL