Archiv des Autors: Jörg Kastning

Der GNU/LinuxDay in Vorarlberg – am 19. Okt. 2019 in Dornbirn

LinuxDay 2019 am 19. Okt. in Dornbirn

Nächsten Monat ist es wieder soweit. Die LUG Vorarlberg lädt zum LinuxDay AT in die HTL Dornbirn ein. Mit bis zu 500 Besuchern ist dies die größte Veranstaltung zu Linux und Freier Software in der Bodenseeregion.
Der Eintritt ist frei! Das Programm wartet auch in diesem Jahr wieder mit spannenden Vorträgen auf. Mit dabei auch ein Vortrag von mir zum Thema: Mehr Spaß beim Ausprobieren dank Virtualisierung
Natürlich freue ich mich auch darauf, bekannte Gesichter wiederzusehen und neue kennenzulernen. Also kommt vorbei. Wir sehen uns in Dornbirn.
rh-accelerators-badge-2019-rgb-red-250x250

Red Hat Accelerator and the Enable Sysadmin Community

Dies ist ein Post in eigener Sache.

Ich bin Mitglied der Red Hat Accelerators Community.

Als aktives Mitglied dieser Gemeinschaft ist es mir eine Freude mein Wissen und meine Erfahrungen mit euch zu teilen.

Ich bin kein Repräsentant oder Mitarbeiter von Red Hat. Die hier veröffentlichten Ansichten sind meine eigenen. Sie können mit denen von Red Hat übereinstimmen, müssen es jedoch nicht. Falls ihr mehr über das  Red Hat Accelerators Programm lernen wollt, lest unter folgendem Link weiter: https://access.redhat.com/accelerators

Enable Sysadmin

Enable Sysadmin ist eine Red Hat Community, in der englischsprachige Artikel von Sysadmins für Sysadmins veröffentlicht werden. Es finden sich hier Artikel zu Themen wie: Einführung in bestehende und neue Technologien, Software und Anwendungen, Sysadmin Horror Stories, Scripting und Programmiersprachen für Sysadmins.

In unregelmäßigen Abständen werden dort auch Artikel aus meiner Feder (oder eher Tastatur) veröffentlicht. Eine Übersicht meiner bisher dort erschienen Artikel findet ihr auf der Seite Artikel und Vorträge oder auf der Seite About me bei Enable Sysadmin.

Wenn ihr ebenfalls Interesse habt für Enable Sysadmin zu schreiben und eure Erfahrungen dort mit euren Kameraden im Leid zu teilen, schreibt einfach eine E-Mail an enable-sysadmin@redhat.com. Ich bin sicher, auch ihr werden freundlich aufgenommen und bei eurer ersten Publikation unterstützt.

Ansible kontrolliert /etc/chrony.conf

Damit neue Linux-VMs die richtige Zeit finden, habe ich mir eine kleine Ansible-Rolle namens chrony erstellt, welche ich im Folgenden vorstellen möchte.

# tree chrony/
chrony/
├── handlers
│   └── main.yml
├── tasks
│   └── main.yml
└── templates
    └── chrony.conf.j2

Die Rolle kommt sehr minimalistisch daher und umfasst nur die zwingend erforderlichen Verzeichnisse und Dateien. Sie ähnelt sehr stark der Rolle resolv.conf, welche ich bereits in diesem Beitrag beschrieben habe.

tasks/main.yml

---
- name: make sure chronyd is installed
  yum:
    name: chrony
    state: latest
    update_cache: yes

- name: deploy chrony.conf template
  template:
    src: /data/ansible/roles/chrony/templates/chrony.conf.j2
    dest: /etc/chrony.conf
    owner: root
    group: root
    mode: 0644
    backup: yes
  notify:
  - restart chronyd

Im ersten Task nutze ich das Modul yum, um sicherzustellen, dass das chrony-Paket auch installiert ist, um dieses im zweiten Schritt zu konfigurieren.

Der zweite Task nutzt das Modul template, um aus der Datei unter roles/chrony/templates/chrony.conf.j2 die Zielkonfiguration in der Datei /etc/chrony.conf auf dem Zielsystem zu erstellen. Aktuell enthält mein Template statischen Text und ich hätte genauso gut das Modul copy nutzen können, um diese Datei auf das Zielsystem zu bringen. Ich verwende jedoch das template-Modul, um mir die Möglichkeit offen zu halten, durch Verwendung von Variablen den Inhalt dynamisch erstellen zu lassen.

Am Ende des zweiten Tasks wird ein Handler namens ‚restart chronyd‘ aufgerufen. Die Funktionsweise von Handlern habe ich bereits in DNS-Konfiguration mit Ansible beschrieben. Bitte lest für weitere Informationen dort nach.

VMDK-Dateien mit Hilfe der PowerCLI vergrößern

In diesem Tutorial möchte ich an einem Minimal-Beispiel zeigen, wie mit Hilfe der PowerCLI ausgewählte VMDK-Dateien spezifischer VMs vergrößert werden können.

Dies bietet sich z.B. immer dann an, wenn so viele VMs betroffen sind, dass der Aufwand der manuellen Vergrößerung über den vSphere-(Web)-Client zu groß erscheint.

Betrachtet wird hier lediglich die Vergrößerung der VMDK-Datei. Die anschließend ebenfalls notwendige Vergrößerung von Partition und Dateisystem innerhalb des Gast-Betriebssystems ist nicht Bestandteil dieses Tutorials.

Zielstellung

Für das Minimalbeispiel sollen aus einer Gruppe VMs die jeweils zweite und dritte Festplatte von VM-Test-5 und VM-Test-6 vergrößert werden. Die jeweilige zweite Festplatte ist von 250 GB auf 500 GB zu vergrößern und die jeweilige dritte Festplatte soll von 400 GB auf 800 GB vergrößert werden.

Voraussetzungen

Eine funktionsfähige Installation der VMware PowerCLI und die Möglichkeit den vCenter Server über diese ansprechen zu können, ist Voraussetzung, um diesem Tutorial zu folgen.

Ablauf

Im folgenden Code-Block wird dargestellt, wie wir die notwendigen Informationen über die zu bearbeitenden VMs auslesen.

PowerCLI C:\Scripts> Get-VM | Where-Object {$_ | Select-String -pattern "VM-Test-\d"}

Name                 PowerState Num CPUs MemoryGB
----                 ---------- -------- --------
VM-Test-5        PoweredOn  4        24.000
VM-Test-7        PoweredOn  4        16.000
VM-Test-6        PoweredOn  4        24.000


PowerCLI C:\Scripts> Get-VM | Where-Object {$_ | Select-String -pattern "VM-Test-[5,6]{1}"}

Name                 PowerState Num CPUs MemoryGB
----                 ---------- -------- --------
VM-Test-5        PoweredOn  4        24.000
VM-Test-6        PoweredOn  4        24.000


PowerCLI C:\Scripts> $VM = Get-VM | Where-Object {$_ | Select-String -pattern "VM-Test-[5,6]{1}"}
PowerCLI C:\Scripts> Get-VM $VM | Get-HardDisk | FT Parent, Name, CapacityGB -AutoSize

Parent        Name        CapacityGB
------        ----        ----------
VM-Test-5 Hard disk 1         40
VM-Test-5 Hard disk 2        250
VM-Test-5 Hard disk 3        400
VM-Test-5 Hard disk 4         80
VM-Test-6 Hard disk 1         40
VM-Test-6 Hard disk 2        250
VM-Test-6 Hard disk 3        400
VM-Test-6 Hard disk 4         80

Aus der obigen Ausgabe ist zu erkennen, dass wir die VMDK-Dateien, welche als „Hard disk 2“ bzw. „Hard disk 3“ bezeichnet werden, vergrößern möchten.

In dem nun folgenden Code-Block definiere ich zuerst ein paar Variablen, welche ich für den Verarbeitungslauf benötige, anschließend prüfe ich noch einmal, ob ich die richtigen VMDK-Dateien für die Operation auswähle und vergrößere sie anschließend.

PowerCLI C:\Scripts> $HardDisk = 2
PowerCLI C:\Scripts> $HardDisk = "Hard disk " + $HardDisk
PowerCLI C:\Scripts> $HardDiskSize = 500
PowerCLI C:\Scripts> Get-HardDisk -vm $VM | where {$_.Name -eq $HardDisk}

CapacityGB      Persistence                                                    Filename
----------      -----------                                                    --------
250.000         IndependentPersis... ...STD-2.9T-02] VM-Test-5/VM-Test-5_1.vmdk
250.000         IndependentPersis... ...STD-2.9T-01] VM-Test-6/VM-Test-6_1.vmdk


PowerCLI C:\Scripts> Get-HardDisk -vm $VM | where {$_.Name -eq $HardDisk} | Set-HardDisk -CapacityGB $HardDiskSize -Conf
irm:$false

CapacityGB      Persistence                                                    Filename
----------      -----------                                                    --------
500.000         IndependentPersis... ...STD-2.9T-02] VM-Test-5/VM-Test-5_1.vmdk
500.000         IndependentPersis... ...STD-2.9T-01] VM-Test-6/VM-Test-6_1.vmdk


PowerCLI C:\Scripts> Get-VM $VM | Get-HardDisk | FT Parent, Name, CapacityGB -AutoSize

Parent        Name        CapacityGB
------        ----        ----------
VM-Test-5 Hard disk 1         40
VM-Test-5 Hard disk 2        500
VM-Test-5 Hard disk 3        400
VM-Test-5 Hard disk 4         80
VM-Test-6 Hard disk 1         40
VM-Test-6 Hard disk 2        500
VM-Test-6 Hard disk 3        400
VM-Test-6 Hard disk 4         80


PowerCLI C:\Scripts> $HardDisk = 3
PowerCLI C:\Scripts> $HardDisk = "Hard disk " + $HardDisk
PowerCLI C:\Scripts> $HardDiskSize = 800
PowerCLI C:\Scripts> Get-HardDisk -vm $VM | where {$_.Name -eq $HardDisk}

CapacityGB      Persistence                                                    Filename
----------      -----------                                                    --------
400.000         IndependentPersis... ...STD-2.9T-02] VM-Test-5/VM-Test-5_2.vmdk
400.000         IndependentPersis... ...STD-2.9T-01] VM-Test-6/VM-Test-6_2.vmdk


PowerCLI C:\Scripts> Get-HardDisk -vm $VM | where {$_.Name -eq $HardDisk} | Set-HardDisk -CapacityGB $HardDiskSize -Conf
irm:$false

CapacityGB      Persistence                                                    Filename
----------      -----------                                                    --------
800.000         IndependentPersis... ...STD-2.9T-02] VM-Test-5/VM-Test-5_2.vmdk
800.000         IndependentPersis... ...STD-2.9T-01] VM-Test-6/VM-Test-6_2.vmdk


PowerCLI C:\Scripts>

Falls der obige Code-Block nicht selbsterklärend ist, stellt eure Fragen dazu gern in den Kommentaren. Ich versuche das Tutorial dann zeitnah zu ergänzen.

DNS-Konfiguration mit Ansible

Um neue Linux-VMs mit einer funktionierenden und zu unserer Umgebung passenden DNS-Konfiguration zu provisionieren, habe ich mir eine kleine Ansible-Rolle namens resolv.conf erstellt, welche ich im Folgenden vorstellen möchte.

Die Rolle resolv.conf

# tree roles/resolv.conf
roles/resolv.conf
├── handlers
│   └── main.yml
├── tasks
│   └── main.yml
└── templates
    └── resolv.conf.j2

Die Rolle kommt sehr minimalistisch daher und umfasst nur die zwingend erforderlichen Verzeichnisse und Dateien.

tasks/main.yml

---
- name: make sure line 'dns=none' is set in /etc/NetworkManager/NetworkManager.conf
  ini_file:
    path: /etc/NetworkManager/NetworkManager.conf
    state: present
    no_extra_spaces: yes
    section: main
    option: dns
    value: none
    owner: root
    group: root
    mode: 0644
    backup: yes
  notify:
  - reload NetworkManager

- name: deploy resolv.conf template
  template:
    src: roles/resolv.conf/templates/resolv.conf.j2
    dest: /etc/resolv.conf
    owner: root
    group: root
    mode: 0644
    backup: yes
  notify:
  - reload NetworkManager

Um die Datei /etc/resolv.conf mit Ansible verwalten zu können, habe ich zuerst dem NetworkManager abgewöhnt, diese Datei zu anzufassen. Dazu habe ich das Ansible-Modul ini_file verwendet, welche die benötigte Option dns=none in der Sektion [main] setzt.

Der zweite Task nutzt das Modul template, um aus der Datei unter roles/resolv.conf/templates/resolv.conf.j2 die Zielkonfiguration in der Datei /etc/resolv.conf auf dem Zielsystem zu erstellen. Aktuell enthält mein Template statischen Text und ich hätte auch das Modul copy nutzen können, um diese Datei auf das Zielsystem zu bringen. Ich verwende jedoch das template-Modul, um mir die Möglichkeit offen zu halten, durch Verwendung von Variablen den Inhalt dynamisch erstellen zu lassen.

Mit dem Parameter notify: wird an zwei Stellen ein Handler namens ‚reload NetworkManager‘ benachrichtigt. Auf diesen gehe ich im nächsten Abschnitt ein.

handlers/main.yml

Mit den Ansible Handlers lassen sich Aktionen auslösen, welche nur dann ausgeführt werden sollen, wenn durch einen Task Änderungen auf dem Zielsystem durchgeführt wurden. Die Handler werden erst am Ende eines Playbooks abgearbeitet und nur einmal ausgeführt, auch wenn Sie von mehreren Tasks über Änderungen benachrichtigt wurden.

# cat resolv.conf/handlers/main.yml 
---
  - name: reload NetworkManager
    service:
      name: NetworkManager
      state: reloaded

Bei dem in diesem Text beschriebenen Beispiel führt der Handler mit dem Namen ‚reload NetworkManager‘ den darunter definierten Task aus. Jedoch nur dann wenn einer der beiden Tasks (oder beide) aus tasks/main.yml zu einer Änderung auf dem Zielsystem geführt hat.

Es gilt zu beachten, dass Handler erst dann ausgeführt werden, wenn alle Tasks erfolgreich ausgeführt wurden. Dies kann in einigen Fällen die Fehlersuche etwas erschweren. Ich habe dazu ein Beispiel in Ansible: Up and Running von Rene Moser und Lorin Hochstein gefunden, welches ich hier gerne wiedergeben möchte. Stellt euch vor, euer Playbook hat folgenden Ablauf:

  1. Ihr führt ein Playbook aus
  2. Einer der Tasks verwendet notify bei Änderungen
  3. In einem folgenden Tasks tritt ein Fehler auf, welcher zum Abbruch der Verarbeitung führt
  4. Ihr behebt das Problem und führt das Playbook erneut aus

Der Task aus Schritt 2 hat seine Änderungen bereits erfolgreich durchgeführt. Bei der erneuten Ausführung des Playbooks wird sein Status daher OK und nicht CHANGED sein. Der Handler wurde jedoch nicht ausgeführt, da die Verarbeitung zuvor abgebrochen wurde. Auch bei der erneuten Ausführung des Playbooks wird der Handler nicht mehr ausgeführt, da der dazu erforderliche Task zu keiner Änderung im Zielsystem mehr führt.

Hochstein schreibt, dass Handler meist genutzt werden, um Dienste neuzustarten oder deren Konfiguration neu zu laden. Dies kann selbstverständlich auch erreicht werden, wenn man auf den Einsatz von Handlern verzichtet und einen Dienst am Ende des Playbooks explizit neustartet. Welches der bessere Weg ist, möge jeder für sich selbst entscheiden.

Fazit

Dies war eine meiner ersten Ansible-Rollen überhaupt. Ob dies der geschickteste Weg ist, die DNS-Konfiguration herzustellen, oder ob es noch elegantere Ansätze gibt, mag ich nicht abschließend beurteilen. Zumindest scheint auch diese Lösung robust zu sein und hat mich bisher nicht im Stich gelassen.

Falls ihr Fragen oder Anregungen habt, hinterlasst gern einen Kommentar. Ich freue mich stets neue Lösungswege kennen zu lernen.

RHEL-System registrieren und Subskription hinzufügen

Ein früher Schritt in unserem Bereitstellungsprozess für RHEL-Systeme umfasst die Registrierung des Systems im Red Hat Customer Portal und das Hinzufügen einer geeigneten Subskription. Um diese beiden Schritte zu automatisieren, nutze ich eine Ansible-Rolle, welche ich euch im Folgenden vorstellen möchte.

Umfeld

RHEL läuft bei uns vorwiegend innerhalb verschiedener Virtualisierungs-Cluster und vereinzelt auf dedizierten Servern (Blech). Wir nutzen für die Entwicklung und den Betrieb folgende Subskriptionen:

  • Red Hat Developer Subscription
  • Red Hat Enterprise Linux Server, Standard (Physical or Virtual Nodes)
  • Red Hat Enterprise Linux for Virtual Datacenters, Standard

Die Rolle ‚register-rhel-subscription‘

Meine Rolle kommt minimalistisch daher und besitzt folgende Strukur:

# tree roles/register-rhel-subscription               
roles/register-rhel-subscription
|-- defaults
|   `-- main.yml
|-- tasks
|   `-- main.yml

tasks/main.yml

---
# tasks file for register-rhel-subscription
# Register System and add Subcription
 - name: Register system and add subscription
   redhat_subscription:
     activationkey: "{{ org_activationkey }}"
     org_id: 1234567
     state: present

redhat_subscription ist ein Ansible-Modul, welches das Kommando subscription-manager verwendet, um Registrierung und Subskription eines Systems zu verwalten.

Dem Parameter activationkey wird ein Aktivierungsschlüssel übergeben, welcher zuvor im Customer Portal erstellt werden muss. Dieser Schlüssel ermöglicht eine Registrierung, ohne interaktive Eingabe von Benutzername und Kennwort. In obigem Code wird dem Parameter der Inhalt der Variable org_activationkey übergeben. Wie und wo diese Variable definiert wird, werde ich im nächsten Abschnitt erklären.

Die ebenfalls erforderliche org_id kann man mit dem folgenden Kommando in Erfahrung bringen: sudo subscription-manager identity

Durch state: present wird der gewünschte Zielzustand deklariert. In diesem Fall soll das System also registriert werden. Ändert man diesen Parameter zu state: absent wird das System entsprechend de-registriert.

defaults/main.yml

In dieser Datei wird der Standard-Wert für die Variable org_activationkey definiert.

---
# defaults file for register-rhel-subscription
org_activationkey: "my-datacenter-sub"

Der in dieser Datei spezifizierte Wert kann je nach Bedarf z.B. in host_vars und group_vars überschrieben werden (Siehe dazu: Using Variables). So kann bspw. über die Gruppenzugehörigkeiten im Inventory gesteuert werden, welche Subskription einem Host bzw. einer Gruppe von Hosts zugewiesen werden soll.

Beispiel-Playbook

---
- hosts: all
  tasks:
    - name: Group by OS
      group_by: key=os_{{ ansible_distribution }}
      changed_when: False

- hosts: os_RedHat
  roles:
    - register-rhel-subscription

Fazit

Diesen Text zu schreiben hat deutlich länger gedauert, als die eigentliche Aufgabe umzusetzen. Bisher macht diese Lösung einen robusten Eindruck.

Falls ihr Fragen oder Anregungen habt, sind diese in den Kommentaren herzlich willkommen.

Gefahrlos eine Zip-Bombe testen

In der jüngeren Vergangenheit berichteten verschiedene Online-Medien (siehe [0] und [1]) über eine neuartige sehr effiziente Zip-Bombe [2], welche der Entwickler David Fitfield entwickelt und zusammen mit einer detaillierten Beschreibung veröffentlicht [3] hat.

Es reizte mich, diese Zip-Bombe auszuprobieren. Im folgenden beschreibe ich, wie ich eine Disk-Image-Datei [4] und ein Loop-Device [5] verwendet habe, um dies gefahlos tun zu können, ohne mir mein komplettes Dateisystem vollzuschreiben.

Die Prozedur besteht aus den folgenden Schritten:

  1. Disk-Image-Datei mit definierter Größe erzeugen
  2. Dateisystem in erstellter Disk-Image-Datei erzeugen
  3. Einhängepunkt erzeugen und Disk-Image-Datei einhängen

Die einzelnen Schritte werden im Detail im folgenden Code-Block dargestellt:

[root@example.com ~]# fallocate -l 1G /tmp/zipbomb.img
[root@example.com ~]# mkfs.ext4 -F /tmp/zipbomb.img
mke2fs 1.42.9 (28-Dec-2013)
Discarding device blocks: done                            
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
65536 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=268435456
8 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

[root@example.com ~]# mount -o loop /tmp/zipbomb.img /mnt
[root@example.com ~]# mount | grep /mnt
/tmp/zipbomb.img on /mnt type ext4 (rw,relatime,seclabel,data=ordered)
[root@example.com ~]#

Nun hängt in /mnt ein Dateisytem von 1 GB Größe, welches von der Zip-Bombe vollgeschrieben werden kann. Viel Spaß beim Ausprobieren.

Und wie probiere ich nun die Zip-Bombe aus?

Na ganz einfach:

[root@example.com ~]# cd /mnt
[root@example.com ~]# wget https://www.bamsoftware.com/hacks/zipbomb/zbsm.zip
[root@example.com ~]# unzip zbsm.zip

Es dauert auch nicht lange, bis euer Dateisystem unter /mnt voll ist.

Quellen und weiterführende Links

[0] DerStandard: Verstopfte Festplatte: „ZIP-Bombe“ verwandelt 46 Megabyte in 4,5 Petabyte
[1] Golem.de: Malware: Zip-Bombe entpackt 46 MByte zu 4,5 Petabyte
[2] Wikipedia: Archivbombe
[3] David Filield: A better zip bomb
[4] Wikipedia (en): IMG (file format)
[5] Wikipedia: Loop device

Die Rolle von Ansible in unserem Linux-Betriebskonzept

Seit 2016 betreiben wir im BITS Red Hat Enterprise Linux als drittes Server-Betriebssystem neben Solaris und Microsoft Windows Server. Nachdem wir nun erste Betriebserfahrung mit der für uns neuen Distribution gesammelt haben, möchte ich in diesem Jahr unser Betriebskonzept überarbeiten, um die Erkenntnisse aus dem bisherigen Betrieb einfließen zu lassen und (hoffentlich) Verbesserungen für den zukünftigen Betrieb herbei zu führen.

Ansible wird in diesem Konzept eine wesentliche Rolle einnehmen. Als Konfigurations-Management-Werkzeug wird es für Teile des Betriebssystems und für das zentrale RHEL-Patchmanagement zum Einsatz kommen.

Die zu bewältigenden Konfigurationsaufgaben unterscheiden wir dabei in:

  • Parameter die im Bereitstellungsprozess initialisiert werden und anschließend in der Hoheit des jeweiligen Systembetreibers liegen sowie
  • Parameter welche dauerhaft durch das Konfigurations-Management verwaltet werden; diese gliedern sich wiederum in die
    • Zeilenbasierte Verwaltung von Konfigurationsdateien und
    • Dateibasierte Verwaltung von Konfigurationsdateien

In diesem Beitrag führe ich die einzelnen Parameter und Optionen auf, welche zukünftig von Ansible verwaltet werden. Von diesen wird zukünftig auf weitere Beiträge verlinkt, welche die konkrete Umsetzung mit Ansible beschreiben und dokumentieren. Es mag sich also lohnen von Zeit zu Zeit wieder hier vorbei zu schauen.

Initialisierte Parameter

Hierunter sind Parameter und Optionen zu verstehen, die zu Beginn im Bereitstellungsprozess konfiguriert werden, um sicherzustellen, dass sich das neue System optimal in unsere Infrastruktur einfügt. Diese werden initial und einmalig gesetzt und gehen nach der Übergabe des Systems in die Hoheit des jeweiligen Systembetreuers über. Der Systembetreuer ist bei uns die Person, welche den spezifischen Server administriert und Dienste auf diesem betreibt.

Zu den initial konfigurierten Parametern zählen im Einzelnen:

Dauerhaft verwaltete Parameter

Diese Parameter/Optionen werden bei lokalen Änderungen auf dem System durch Ansible überschrieben. Dabei handelt es sich um

  • Die Stage-Zuordnung über das Ansible-Inventory
  • Das Anlegen und verwalten eines Benutzers zur Anbindung an das BMC-Monitoring
  • Die Verwaltung spezifischer lokaler Benutzerkonten
  • Die Steuerung des SSH-Servers, der authorized_keys Dateien und die Verwaltung der öffentlichen SSH-Schlüssel der Benutzer
  • Steuerung des RHEL-Patchmanagements

Ansible Automates Frankfurt 2019

Am 25. Juni 2019 fand in Frankfurt am Main das Red Hat Event Ansible Automates statt. Da der Einsatz von Ansible einen kleinen Teil meiner Arbeit darstellt, folgten ein Kollege und ich der Einladung zu diesem kostenlosen Marketing-Event. Es folgt ein kurzer Erfahrungsbericht.

Die Veranstaltung wurde im 6. Stock (direkt unter dem Flachdach) des Fleming’s Hotel nahe des Mainufers durchgeführt. Die Klimaanlage gab ihr bestes, den Raum für die ca. 140 Teilnehmer auf einer angenehmen Temperatur zu halten und das Team von Red Hat gab sich große Mühe spannende Vorträge und Demonstrationen für die Hörer zu bieten.

Die Agenda umfasste nach einer Begrüßung Vorträge u.a. zu Themen wie Automation Culture, Network Automation, Best Practices und SAP HANA – Standardization with Ansible.

Die Organisation war gut, die Teilnehmer wurden mit ausreichend kalten und warmen Getränken sowie einem kleinen Mittagessen versorgt. Die einzelnen Vorträge dauerten zwischen 30 und 40 Minuten. Die Technik arbeite reibungslos und man konnte den Vortragenden gut folgen. Zum Ende eines jeden Vortrags gab es eine kurze Frage&Antwort-Runde, bei der die Teilnehmer die Gelegenheit nutzten nachzuhaken und durchaus auch Kritik zu äußern. Dies verlieh der Veranstaltung einen interaktiven Charakter.

In den Pausen und beim abschließenden Apéro bot sich zudem die Gelegenheit zum Gespräch mit den Teilnehmern und Vertretern von Red Hat.

Eindrücke von der Veranstaltung

Red Hat präsentierte im Rahmen dieser Veranstaltung zwei Fallstudien von der Nutzung von Ansible zum Deployment komplexer Umgebungen bei Kunden aus Deutschland. Ein Highlight war die Präsentation eines kompletten SAP HANA Deployments mit Alexa und Ansible in der AWS Cloud.

Als Systemadministrator viel mir bei diesen Präsentationen auf, dass sich diese primär um das Deployment drehten. Auf Fragen des anschließenden Betriebs und Aufgaben wie Wartung, Aktualisierung, etc. gingen die Beiträge nicht ein. Auf Nachfrage erfuhr man, dass hierzu keine Erfahrungen vorliegen oder noch an entsprechenden Lösungen gearbeitet wird. Schade. Sind doch gerade dies die Aufgaben, die meine tägliche Arbeit bestimmen und das SysAdmin-Leben teilweise sehr schwer machen. So muss ich sagen, da wo es für uns interessant wird, hörten die Vorträge meist auf.

Teilnehmer aus der Finanzbranche äußerten Kritik, dass Ansible, Ansible Tower und einige weitere der noch jungen Produkte, die gewünschte Enterprise-Qualität vermissen lassen, welche man von der Basis-Distribution gewohnt ist und die man auch für die übrigen Produkte erwartet. Das Team von Red Hat nahm die Kritik an und versprach diese mitzunehmen und bei der weiteren Entwicklung zu berücksichtigen. Ich werde die Entwicklung weiter beobachten und prüfen, ob sich einige der genannten Punkte wiederfinden lassen.

Einer der am häufigsten genannten Kritikpunkte, welcher auch mir sehr am Herzen liegt, sind die Update-Mechanismen. So halte ich Syntax-Änderungen bei Minor-Updates von Ansible für ein Unding. Können diese doch leicht dafür sorgen, dass meine Playbooks und Rollen nicht mehr funktionieren. Zum Glück ist die Zahl meiner Playbooks und Rollen heute noch sehr überschaubar und das Problem nicht groß. Für Kunden mit vielen hundert Playbooks stellt dies jedoch ein großes Ärgernis dar. Dies ist leicht nachvollziehbar, werden dadurch die Kosten auf Seiten des Kunden in die Höhe getrieben.

Keith Tenzer zeigte in seinem Vortrag, wie man mit Hilfe des Ansible Tower, GitHub und einer OpenStack Cloud eine CI/CD-Umgebung aufbauen und nutzen kann. Sein Fazit lautete, dass man heute nicht mehr auf die Qualität genutzter Softwarekomponenten oder Herstellerprodukte vertrauen kann, sondern alle Komponenten eigenen Tests unterziehen muss. Diese Ansicht teilten nicht alle Teilnehmer. So wurde der Einwand geäußert, dass man als Kunde für Enterprise-Qualität bezahle und diese auch erwarte. Schließlich zahle man Geld, um eigene Aufwände zu reduzieren und nicht zu steigern.

Ich schließe mich der geäußerten Kritik in Teilen an. Zwar halte ich umfassende eigene Tests für wichtig, richtig und unausweichlich, doch ist der Aufbau einer CI/CD-Umgebung zum Teil hochkomplex und mit einem nicht zu unterschätzenden Wartungsaufwand verbunden. So ist eine CI/CD-Landschaft für ein Hello-World-Programm sicher leichter zu gestalten, als z.B. für eine CampusManagement-Software.

Nun sehe ich CI/CD auch durch die SysAdmin-Brille. Für Entwickler und ihre Development-Workflows bietet CI/CD unbestreitbare Vorteile. Mir stellt sich bei der Betrachtung jedoch auch die Frage:

  • Wer betreibt die Cloud? Wieviel Aufwand bringt dies mit sich?
  • Wer betreibt und aktualisiert die Werkzeuge wie Ansible Tower, GitHub, etc. pp. und wie gut skalieren diese Werkzeuge?
  • Habe ich mit CI/CD wirklich weniger Aufwände und Kosten oder verlagern sich diese nur?

Es wird wohl keine pauschalen Antworten auf diese Fragen geben, hängen sie doch zu sehr von organisationsspezifischen Faktoren ab.

Persönliches Fazit

Insgesamt war es eine gelungene Veranstaltung, von der ich einige neue Eindrücke mitgenommen habe.

Es wurde deutlich, dass auch Ansible nicht die heilige Handgranate ist, welche alle IT-Herausforderungen im Handumdrehen bewältigt. Doch hat dies glaube ich auch kaum jemand erwartet.

Mir persönlich hat der Vortrag von Günter Herold über Automation Culture besonders gut gefallen. Er machte deutlich, dass Automatisierung keine Aufgabe von einzelnen Abteilungen oder Teams ist sondern nur Abteilungs- und Plattformübergreifend das volle Potenzial entfalten kann. Dies leuchtet ein, sind an einem Dienst bzw. Geschäftsprozess doch häufig mehrere komplexe Systeme beteiligt, welche erst im Zusammenwirken einen Mehrwert für die Organisation erbringen.

Fraglich bleibt, ob und wie wir in unserer Einrichtung von den Entwicklungen profitieren können. Sind wir doch eher klassisch organisiert und von DevOps noch weit entfernt. Doch müssen wir uns ja auch nicht komplett an Idealen ausrichten, sondern finden vielleicht einen guten und effizienten Mittelweg.

Lesezeichen: LaTeX-Schriftartenkatalog

Heute habe ich auf dem Blog vNotes einen Beitrag über den LaTeX-Schriftartenkatalog der TeX User Group aus Dänemark gelesen. In diesem Katalog finden sich diverse Schriftarten, welche bereits in der Distribution TeX Live enthalten sind. Neben der Vorschau der einzelnen Schriften werden auch konkrete Informationen zur Einbindung in eigene Dokumente gegeben.

Ich folge Viktors Empfehlung und setze hier ein Lesezeichen.

http://www.tug.dk/FontCatalogue/