Schlagwort-Archive: osbn

Tag OSBN

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

LinuxDay 2019 am 19. Okt. in Dornbirn

Update 20.10.2019: Nun ist der LInuxDay AT schon wieder vorbei und ich bin wohlbehalten in der Heimat angekommen. Vielen Dank an das Orga-Team für die tolle Organisation und den schönen Tag. Ebenfalls vielen Dank an die Hörer meines Vortrags, welche mir im Anschluss zahlreiche Rückmeldungen gaben. Bis nächstes Jahr.

Diesen 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

Dieser richtet sich vor allem an Anwender, die bisher nicht oder nur wenig mit Virtualisierung in Berührung gekommen sind und erfahren möchten, wie man mit dieser Technologie neue Betriebssysteme erkunden kann.

Natürlich freue ich mich auch darauf, bekannte Gesichter wiederzusehen und neue kennenzulernen. Also kommt vorbei. Wir sehen uns in Dornbirn.

DNS over HTTPS (DoH) — Was ändert sich für den Nutzer?

Mozilla und Google haben angekündigt, DoH in ihren Webbrowsern Firefox bzw. Chrome zu aktivieren. In diesem Artikel möchte ich allgemeinverständlich erklären, was sich dadurch für Nutzer dieser Programme ändern kann bzw. wird.

Dazu beschreibe ich zuerst in vereinfachender Weise, wie das heutige DNS-System funktioniert und was an diesem System kritisiert wird. Darauf folgt eine Beschreibung von DoH und der Kritik an diesem Protokoll. Der Artikel soll dem Leser helfen, sich eine eigene Meinung zu bilden.

Dieser Artikel richtet sich in erster Linie an (Privat-)Anwender und Nutzer der genannten Programme. Er soll ein grundlegendes Verständnis auch ohne vollständige Kenntnis der Fachterminologie ermöglichen. Den versierten Leser bitte ich daher zu entschuldigen, sollten einige Ausführungen fachlich nicht ganz exakt sein.

Das Domain Name System (DNS)

Das DNS ist einer der wichtigsten Dienste in vielen Netzwerken und quasi das Rückgrat des Internets. Denn es sorgt dafür, dass zu einer Eingabe im Webbrowser wie z.B. https://www.my-it-brain.de oder www.ubuntuusers.de der Server gefunden wird, welcher die entsprechende Seite ausliefern kann. Das DNS funktioniert dabei so ähnlich wie ein Telefonbuch bzw. eine Telefonauskunft.

Wie wird das DNS von (Privat-)Anwendern genutzt?

Um zu veranschaulichen, wie das DNS in den meisten Fällen genutzt wird, stelle man sich folgendes Heimnetzwerk vor, wie es vermutlich in vielen Haushalten existiert.

typical-soho-network
Darstellung eines typischen Heimnetzwerks mit Anbindung an das Internet über einen Internet Service Provider

Endgeräte wie Laptop, Smartphone, Tablet, PC, etc. sind via LAN oder WLAN an den heimischen (W)LAN-Router angebunden. Letzterer erhält vom Internet Service Provider (ISP) eine oder mehrere IP-Adressen mitgeteilt, über welche der Router — vom Internet aus gesehen — erreichbar ist. Darüber hinaus teilt der ISP noch die IP-Adressen seiner DNS-Server mit, welche ebenfalls im (W)LAN-Router gespeichert werden.

Der (W)LAN-Router wiederum weist jedem Endgerät eine IP-Adresse zu, unter welcher dieses Gerät im Heimnetzwerk erreicht werden kann. Darüber hinaus teilt er den Endgeräten eine sogenannte Gateway-Adresse mit. Diese Adresse stellt für die verbundenen Endgeräte quasi das Tor ins Internet dar. Gleichzeitig wird diese IP-Adresse meist auch als DNS-Serveradresse auf den Endgeräten konfiguriert. Erledigt wird dies alles in der Regel über das DHCP-Protokoll, um dem Nutzer die manuelle Konfiguration der beteiligten Komponenten zu ersparen.

Damit sind dann eigentlich auch schon alle Voraussetzungen geschaffen, um mit den Endgeräten im Internet surfen zu können.

Tippt nun ein Nutzer im Webbrowser seines PCs die Adresse https://www.my-it-brain.de ein, wird auf folgendem Weg die IP-Adresse des Servers ermittelt, welcher diesen Blog ausliefert. Das folgende Bild dient der Veranschaulichung der Schritte 1-5.

dns-request-answer-png
Darstellung der zur Namensauflösung durchlaufenden Schritte
  1. PC fragt den (W)LAN-Router nach der gesuchten IP-Adresse
  2. (W)LAN-Router fragt den bzw. die DNS-Server des ISP
  3. Der DNS-Server des ISP fragt ggf. weitere DNS-Server im Internet
  4. DNS-Server des ISP kennt die gesuchte IP-Adresse und teilt sie dem (W)LAN-Router mit
  5. Der (W)LAN-Router teilt die IP-Adresse dem PC mit

Der PC ist mit Kenntnis der IP-Adresse nun in der Lage, die gewünschte Seite beim Server anzufragen und im Webbrowser darzustellen.

Oftmals verfügen die in vorstehender Abbildung dargestellten Geräte über einen Zwischenspeicher für erfolgreich ausgeführte DNS-Abfragen, den sogenannten Cache. So muss bei einer wiederholten Anfrage einer bereits erfolgreich aufgelösten IP-Adresse nicht erneut die komplette Kette durchlaufen werden. Die Anfrage kann stattdessen aus dem Cache beantwortet und somit Zeit eingespart werden. Das folgende Code-Beispiel soll dies verdeutlichen. Dabei ist es nicht wichtig, jede einzelne Zeile interpretieren zu können. Der Befehl dig my-it-brain.de versucht den Namen ‚my-it-brain.de‘ in eine IP-Adresse aufzulösen. Die mit ‚Query time‘ beginnende Zeile gibt die Verarbeitungsdauer der Anfrage an.

user@X201:~$ dig my-it-brain.de

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> my-it-brain.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55873
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;my-it-brain.de.			IN	A

;; ANSWER SECTION:
my-it-brain.de.		3600	IN	A	136.243.44.163

;; Query time: 68 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Sep 26 15:45:15 CEST 2019
;; MSG SIZE  rcvd: 59

user@X201:~$ dig my-it-brain.de

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> my-it-brain.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55400
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;my-it-brain.de.			IN	A

;; ANSWER SECTION:
my-it-brain.de.		3590	IN	A	136.243.44.163

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Sep 26 15:45:24 CEST 2019
;; MSG SIZE  rcvd: 59

user@X201:~$

Die Beantwortung der ersten DNS-Abfrage dauerte noch 68 ms. Die zweite Anfrage konnte direkt aus dem Cache meines Laptops in 0 ms beantwortet werden. Dabei ist anzumerken, dass alle Anwendungen von diesem Cache profitieren können, sofern sie alle den Cache des Betriebssystems oder ggf. auch den des nachgelagerten (W)LAN-Routers nutzen können.

Kritik

Die Kommunikation über das DNS-Protokoll ist nicht verschlüsselt. Jeder Teilnehmer in einem Netzwerk, der eine DNS-Abfrage zu sehen bekommt, kann deren vollständigen Inhalt lesen. So kann z.B. der ISP sehen, welche Seiten wie oft von seinen Kunden aufgerufen werden. Wobei über die Häufigkeit wiederholter Seitenaufrufe keine genaue Aussage getroffen werden kann, wenn im Heimnetzwerk des Nutzers DNS-Caches verwendet werden.

Der DNS-Client, welcher einen Namen in eine IP-Adresse auflösen möchte, hat keinerlei Möglichkeit zu prüfen, ob die zurückgelieferte IP-Adresse wirklich dem Inhaber der gewünschten Seite gehört. Im Prinzip kann jeder, der eine DNS-Anfrage sieht, eine Antwort senden. Das Endgerät akzeptiert in der Regel die Antwort, die es als erstes erreicht als gültig.

Dadurch bestehen vielfältige Angriffsformen, welche meist das Ziel verfolgen, DNS-Teilnehmer durch Manipulation auf falsche Webseiten zu lenken, um anschließend Passwörter, PINs, Kreditkartennummern usw. zu ergaunern. Darüber hinaus können Manipulationen auch für Zwecke der Zensur verwendet werden.

Die erwähnten Gefahren für Angriffe bzw. Zensur möchte ich mit zwei kurzen Beispielen verdeutlichen.

Beispiel 1: Phishing mit Hilfe von Cache Poisoning

cache-poisoning
Skizzierte Darstellung eines Angriffs mittels Cache Poisoning

Beim Cache Poisoning wird der DNS-Cache des (W)LAN-Routers manipuliert. In der Folge werden Aufrufe von z.B. Gmail, Amazon, eBay oder Online-Banking-Webseiten auf sogenannte Phishing-Webseiten umgeleitet. Diese sehen den echten Seiten meist zum Verwechseln ähnlich und sollen den Nutzer dazu verleiten, seine Zugangsdaten zu diesen Diensten preiszugeben.

Als Anwender gibt es nicht viel, was man tun kann, um sich vor diesen Angriffen zu schützen. Es bleibt lediglich:

  • Verfügbare Sicherheitsupdates für alle vorhandenen Geräte zeitnah zu installieren
  • Beim Besuch von Webseiten skeptisch zu prüfen, ob es Anomalien gibt, die auf Phishing-Versuche hindeuten können

Beispiel 2: Zensur durch den ISP

Eure DNS-Anfragen müssen in jedem Fall bei eurem ISP vorbei. Entweder, weil ihr die DNS-Server eures ISP verwendet, oder weil sie dessen Netz auf dem Weg zu eurem DNS-Provider passieren. In jedem Fall kann euer ISP die Pakete identifizieren und ihren Inhalt lesen. Damit ist euer ISP auch in der Lage, die Anfrage bzw. Antwort zum Zwecke der Zensur zu manipulieren.

Das Risiko der Zensur ist je nach Land und verwendetem ISP bzw. DNS-Provider unterschiedlich zu bewerten. Als Nutzer könnt ihr der Zensur evtl. entgehen, indem man VPN-Tunnel nutzt, um mit vertrauenswürdigen DNS-Providern zu kommunizieren. Dies funktioniert jedoch nur, sofern die VPN-Protokolle vom ISP nicht identifiziert und ebenfalls blockiert werden können.

DNS over HTTPS (DoH)

DNS over HTTPS (DoH) ist ein Protokoll zur Durchführung einer DNS-Auflösung über das HTTPS-Protokoll. Das Ziel ist es, die Privatsphäre und Sicherheit der Benutzer zu erhöhen, indem das Abhören und Manipulieren von DNS-Daten durch Man-in-the-Middle-Angriffe verhindert wird.[1] Neben der Verbesserung der Sicherheit sind weitere Ziele von DNS über HTTPS, die Leistung zu verbessern und DNS-basierte Zensurmaßnahmen zu verhindern. DNS over HTTPS wurde am 19. Oktober 2018 als RFC 8484 standardisiert.[2]

https://de.wikipedia.org/wiki/DNS_over_HTTPS

Was ändert sich für (Privat-)Anwender?

Bei Verwendung dieses Protokolls wird zur Auflösung von Namen in IP-Adressen nicht mehr die Infrastruktur eures Heimnetzwerks oder die eures ISP genutzt. Anwendungen wie z.B. Mozilla Firefox oder Google Chrome implementieren vorkonfigurierte DNS-Server-Adressen, welche zukünftig die Namensauflösung übernehmen. Wie dies aussehen kann, wird in folgender Skizze dargestellt.

dns-over-https
Darstellung zweier DNS-over-HTTPS-Verbindungen

Die Skizze zeigt Verbindungen zwischen verschiedenen Anwendungen und verschiedenen DNS-Diensten im Internet. Die Kommunikation erfolgt über das HTTPS-Protokoll und ist damit verschlüsselt. Die Verschlüsselung der DNS-Kommunikation soll vor Manipulation schützen. Ganz nach dem Motto: „Was man nicht sieht, kann man nicht manipulieren bzw. blockieren.“

Der Anwender selbst hat nichts weiter zu tun. Sein Internet funktioniert weiterhin, ohne etwas ändern zu müssen. Die in den obigen Beispielen beschriebenen Probleme scheinen gelöst, oder? Ja, aber …

Kritik an DoH

DoH verhindert effektiv Zensur durch den ISP. Dieser kann die in HTTPS versteckten DNS-Anfragen nicht von anderem HTTPS-Datenverkehr unterscheiden. Einzig vorstellbare Gegenmaßnahme ist die Blockade sämtlichen HTTPS-Datenverkehrs.

Cache Poisoning sollte keinen Einfluss mehr auf die Anwendungen haben, da diese die vorhandene Infrastruktur nicht mehr nutzen und die Anwendungen (hoffentlich) nur Antworten von den konfigurierten DNS-Services akzeptieren.

Tatsächlich fallen mir noch einige weitere Angriffsvektoren wie z.B. DNS-/IP-Spoofing und Man-in-the-Middle-Angriffe auf HTTPS ein, doch mögen diese durch Maßnahmen auf Anwendungsseite mitigiert worden sein. Daher gehe ich hier nicht weiter darauf ein. Sollte ich neue Erkenntnisse hierzu gewinnen, werde ich diese in einem folgenden Artikel thematisieren.

Statt dem eigenen ISP bzw. dem selbst gewählten DNS-Server zu vertrauen, liegt das Vertrauen nun bei den in den Anwendungen konfigurierten DNS-Providern. Warum ich diesen mehr Vertrauen sollte als meinem ISP, erschließt sich mir persönlich nicht.

In einer Welt, in der Google als Datenkrake verschrien ist, gebe ich diesem Unternehmen nur ungern auch noch meine DNS-Anfragen und würde diese lieber bei meinem ISP belassen. Nun lebe ich in einem Land, wo die ISPs noch nicht negativ durch Zensur aufgefallen sind. Wer hier das kleinere Übel darstellt, muss jeder für sich selbst beurteilen.

Stand heute ist mir nicht bekannt, ob die zu verwendenden DNS-Server in den Anwendungen (wie z.B. Firefox und Chrome) konfiguriert werden können oder man mit den Voreinstellungen leben muss. Möchte man die Vorgabe ändern, hat man nun definitiv mehr Arbeit als früher. Beim klassischen DNS lässt man einfach neue DNS-Server-Adressen über DHCP an seine Endgeräte verteilen und ist fertig. Bei DoH ist diese Konfiguration pro Anwendung und pro Endgerät durchzuführen. Ich fände es schon ärgerlich, wenn zukünftig jede Anwendung mit ihrem eigenen DNS-Resolver daherkommt und einzeln angepasst werden muss.

DoH geht an den im Heimnetzwerk existierenden Caches vorbei. Dies bedeutet entweder langsamere DNS-Abfragen oder erhöhten Bedarf an Arbeitsspeicher auf den Endgeräten, wenn alle Anwendungen nun ihren eigenen Cache implementieren.

Und wenn nun ein oder zwei dieser großen Dienste, auf die alle DNS-Anfragen konzentriert werden, ausfällt? Dann müssen unter Umständen eine Vielzahl von Anwendungen einzeln umkonfiguriert werden, um einen anderen DNS-Provider zu nutzen. Und das auf jedem Endgerät!

Fazit

Das bisherige DNS ist nicht perfekt. Es hat Stärken und Schwächen. Die Schwächen wurden oben bereits benannt. Zu einer der Stärken zählt, dass das DNS hierarchisch aufgebaut ist und dezentral betrieben wird. So ist es recht unwahrscheinlich, dass das DNS als Ganzes ausfallen bzw. kontrolliert werden kann. Fällt das DNS des ISP oder des gewählten DNS-Providers aus, kann man mit verhältnismäßig geringem Aufwand einen anderen DNS-Server verwenden und den Dienst weiterhin nutzen.

Mir persönlich gefällt das Konzept von DoH aus den oben genannten Gründen nicht. Ich hoffe und wünsche mir, dass sich auch in zukünftigen Versionen der verschiedenen Anwendungen DoH deaktivieren und die vorhandenen DNS-Resolver des Betriebssystems bzw. des Heimnetzwerks nutzen lassen.

Auch wenn ich selbst von DoH nicht überzeugt, geschweige denn begeistert bin, wird die Marktmacht von Mozilla und Google sicher ausreichen, um das Protokoll dauerhaft zu etablieren. Hoffentlich lassen die Anwendungshersteller uns Anwendern die Freiheit, die Anwendung nach unseren Wünschen zu konfigurieren.

Doch nun genug der Schmähkritik. Ich möchte hier nicht mit einem negativen Ausblick schließen, bietet DoH doch auch Chancen. Steigt mit der Zeit die Anzahl der verfügbaren DoH-Endpunkte, hat der Anwender in Zukunft evtl. eine ebenso große Auswahl wie heute bei den DNS-Servern. Und vielleicht unterstützen zukünftig auch die Resolver des Betriebssystems und der heimischen (W)LAN-Router DoH und können wie heute von den jeweiligen Anwendungen genutzt werden. All dies bleibt abzuwarten. Bis dahin wird das Internet für den normalen Anwender wohl auch weiter funktionieren, nachdem Firefox und Chrome DoH aktiviert haben.

Ich hoffe, ich konnte euch das DNS und DoH etwas näherbringen. So dass ihr die Eingangsfrage für euch selbst beantworten könnt. Solltet ihr Fragen haben oder über die beiden hier besprochenen Protokolle diskutieren wollen, nutzt gern die Kommentarfunktion dazu.

Weiterführende Quellen und Links

Dieser Beitrag darf gerne geteilt werden.

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

Desktop-Linux – Wer die Wahl hat, hat die Qual

Vorwarnung: Dieser Artikel wird euch vermutlich nicht interessieren, wenn ihr nicht zufällig die gleichen Anforderungen an eine Linux-Distribution für den Desktop stellt wie ich. Mir selbst dient dieser Beitrag als Sammlung von Informationen und zum Vergleich von Distributionen, um schlussendlich eine neue Distribution für meinen Desktop-PC und meine beiden Notebooks auszuwählen. Falls euch langweilig ist oder ihr neugierig seid, dürft ihr natürlich gerne weiter lesen. ;-)

Umfeld

Auf meinen privaten Geräten läuft seit 2006 Ubuntu. Die Geräte haben dabei selten eine Neuinstallation erlebt, sondern wurden meist per Distribution-Upgrade auf eine neue Release aktualisiert. Leider klappt letzteres in jüngerer Vergangenheit zunehmend schlechter und unzuverlässiger. Eine Neuinstallation ist inzwischen einem Upgrade vorzuziehen, da sie meist schneller durchgeführt ist und weniger Nacharbeiten nach sich zieht.

Neben den zunehmenden Problemen mit dem Distribution-Upgrade hat mir Canonical in der jüngeren Vergangenheit ein wenig zu viel an meiner Lieblingsdistribution herumgepfuscht bzw. sie ver(schlimm)bessert. Dies ist der Auslöser, mir mal eine Alternative für den Desktop-Einsatz zu suchen.

Bei meinen Geräten handelt es sich um einen älteren Desktop-PC und zwei ThinkPads (T410 und X201). Dazu gesellt sich in der Peripherie noch ein Brother DCP-540CN, ein Synology DS213air. Alle Komponenten sind in das WLAN-Heimnetzwerk eingebunden. Die Hardware ist alt, doch funktioniert sie noch tadellos und erfüllt ihren Zweck. Daher möchte ich sie gerne noch einige Jahre weiter nutzen.

Anforderungen

Beruflich bin ich im BITS, dem Hochschulrechenzentrum der Uni Bielefeld, tätig und betreue dort diverse IT-Dienste und Themen. Da ich also bereits einen sehr großen Teil des Tages mit der Wartung, Pflege, Entstörung und (sofern noch Zeit ist) der Weiterentwicklung dieser Dienste verbringe, möchte ich mich daheim so wenig wie möglich mit diesen Tätigkeiten aufhalten. Die regelmäßige Installation von Sicherheits-Aktualisierungen ist obligatorisch, doch auf lange Fehlersuche und Behebung möchte ich daheim gerne verzichten.

Bei mir gilt Stabilität vor Bleeding Edge. Ich benötige nicht ständig neue Funktionen und die aktuellste Upstream-Version. Wenn eine Anwendung meine Anforderungen erfüllt und mit Sicherheits-Aktualisierungen versorgt wird, reicht mir das völlig aus.

Aktuell bieten mir die unter Ubuntu 16.04 LTS verfügbaren Anwendungen die Funktionalität, die ich benötige. Die auszuwählende Distribution sollte die entsprechenden Versionen in gleicher oder aktuellerer Version bereitstellen können. Sollte nur eine ältere Version einer Anwendung verfügbar sein, ist dies nicht automatisch ein Ausschlusskriterium. In diesem Fall ist die Anwendung zu testen, ob sie meinen Anforderungen genügt.

Ich wünsche mir einen möglichst großen Unterstützungszeitraum. Ubuntu bietet in den Versionen mit Long Term Support eine Unterstützung für 5 Jahre an. Damit bin ich bisher ganz gut gefahren und möchte mich deshalb in diesem Punkt nur ungern verschlechtern.

Bewertungskriterien

Wie ihr oben gelesen habt, habe ich keine knallharten und messbaren Anforderungen definiert, sondern lediglich Punkte genannt, die mir wichtig sind. In den folgenden Abschnitten werde ich mir eine Auswahl von Linux-Distributionen etwas näher ansehen und diese zuerst auf dem Papier und anhand meiner Erfahrungen miteinander vergleichen. Dabei bewerte ich folgende Kriterien:

  • Release-Zyklus
  • Support-/Life-Cycle
  • Paketverfügbarkeit und Versionsstand
  • Community

Für vorstehend genannte Kriterien vergebe ich Punkte nach folgender Tabelle. Dabei gehen alle Kriterien mit gleicher Gewichtung in das Endergebnis ein, sodass die Distribution mit den meisten Punkten am besten zu mir passen sollte.

Punkte
Beschreibung

0gefällt mir/funktioniert sehr schlecht
1gefällt mir/funktioniert schlecht
2Ist in Ordnung
3gefällt mir/funktioniert gut
4gefällt mir/funktioniert sehr gut

Als Referenz dient mir Xenial, für welches meine Bewertungstabelle wie folgt aussieht:

Ubuntu 16.04 LTS
NameWertBewertung
Unterstützungszeitraum5 Jahre bis April 20213
Release-ZyklusAlle 2 Jahre3
Communityubuntuusers.de4
Kernel4.42
systemd2292
gnome-shell3.18.42
Vim7.42
Firefox66.0.33
Thunderbird60.6.13
Evolution3.18.5.22
gThumb3.4.32
Evince3.18.22
Kile2.1.33
TeXlive20151
XSane0.9994
Summe38

Anmerkung: Bitte beachtet, dass dies hier eine sehr vereinfachte Form einer Bewertungstabelle für meinen privaten Zeitvertreib ist. Als Entscheidungstabelle für die Arbeit ist dieses Format ganz sicher nicht geeignet.

Ausgewählte Distributionen im Vergleich

Für den hier stattfindenden Vergleich habe ich mir folgende Distributionen angesehen (alphabetisch sortiert). Warum genau diese? Nun, entweder kenne ich sie schon oder sie wurden mir von Arbeitskollegen empfohlen.

  • Antergos
  • Arch Linux
  • CentOS
  • Debian
  • Fedora
  • Ubuntu

Antergos

Antergos basiert auf Arch Linux und folgt dem Rolling-Release-Prinzip. Ich möchte kein Rolling Release nutzen. Daher hört die Bewertung hier schon auf, da Antergos für mich nicht in Frage kommt.

Arch Linux

Arch Linux folgt ebenfalls dem Rolling-Release-Prinzip und scheidet daher ebenfalls von vornherein aus.

CentOS 7

CentOS wird aus den Quellen von Red Hat Enterprise Linux gebaut, zu welchem es binärkompatibel ist. CentOS ist nach eigenen Angaben ein Enterprise-Betriebssystem, welches mit langen Wartungszyklen aufwartet. So kann ein Release bis zu zehn Jahre genutzt werden, ohne dass Softwareversionen migriert werden müssen.

Zehn Jahre lang Ruhe. Das klingt verlockend. Grund genug, sich das aktuelle CentOS 7 auf dem Papier anzuschauen.

CentOS 7
NameWertBewertung
Unterstützungszeitraum10 Jahre bis Juni 20244
Release-ZyklusAlle 3-4 Jahre3
CommunityForum und Mailingliste2
Kernel3.10.02
systemd2192
gnome-shell3.28.33
Vim7.42
Firefox60.6.13
Thunderbird60.6.13
Evolution3.28.52
gThumb3.3.42
Evince3.28.22
Kile2.1.33
TeXlive20121
XSane0.9994
Summe38

Debian

Debian ist ein von der Gemeinschaft entwickeltes freies Betriebssystem und mein heimlicher Favorit. Mir gefällt die Idee, mich neben einer RPM-basierten Distribution auf der Arbeit,Ubuntu importiert den Großteil seiner Pakete aus Debian Unstable. Für einen Teil dieser Pakete übernimmt nach dem Debian Import Freeze die Firma Canonical die Pflege. Der größte Teil landet hingegen in der Komponente universe, wo er von den MOTU betreut wird (oder gar nicht). Die Folge dieses Vorgehens: Wenn Pakete in Debian Unstable während des Debian Import Freeze kaputt und unbenutzbar sind, werden sie in die Ubuntu-Paketquellen importiert und bleiben mit großer Wahrscheinlichkeit für die Lebensdauer des jeweiligen Releases daheim mit einer DEB-basierten Distribution zu beschäftigen, um in beiden Paketformatwelten auf dem Laufenden zu bleiben.

Debian Stable steht in dem Ruf rock solid zu sein, was meinem Wunsch nach einer sehr stabilen Distribution entgegen kommt. Die Softwarepakete in Debian Stable gelten gemeinhin als sehr gut abgehangen. Kritiker bezeichnen sie auch als hoffnungslos veraltet. So lange sie die von mir gewünschte Funktionalität bieten, ist mir das Alter egal. Falls ich mich für Debian entscheide, werde ich auf die Veröffentlichung von Buster warten, welche mit folgenden Werten aufwartet.

Debian 10 (Buster)
NameWertBewertung
Unterstützungszeitraum3 Jahre (+2 Jahre LTS)2
Release-ZyklusCa. alle 2 Jahre3
CommunitySee Support Page2
Kernel4.19.163
systemd2412
gnome-shell3.30.24
Vim8.13
Firefox60.6.13
Thunderbird60.6.13
Evolution3.30.52
gThumb3.6.22
Evince3.30.22
Kile2.9.922
TeXlive20183
XSane0.9994
Summe40

Fedora

Bei Fedora handelt es sich wiederum um eine RPM-basierte Distribution. Diese wartet mit recht aktuellen Softwarepaketen auf und gibt sich selbst als für Desktops, Workstations, Laptops und Server geeignet. Fedora wird auch gern als Testlabor für RHEL bezeichnet, da viele Entwicklungen, die sich hier etablieren konnten, später in RHEL übernommen werden.

Die Aktualität hat ihren Preis. So kommt Fedora mit recht kurzen Releasezyklen daher, was für mich ganz klar Punktabzug bedeutet.

Fedora Rawhide
NameWertBewertung
Unterstützungszeitraum13 Monate0
Release-ZyklusAlle 6 Monate0
Communityfedoraforum.de2
Kernel5.13
systemd2422
gnome-shell3.32.14
Vim8.13
Firefox66.0.33
Thunderbird60.6.13
Evolution3.33.12
gThumb3.7.13
Evince3.32.02
Kile2.9.922
TeXlive20183
XSane0.9994
Summe36

Ubuntu LTS

Basierend auf Debian laufen die Ubuntu LTS Releases seit Jahren auf meinen Rechnern. Da ich mit dieser Distribution die meiste Erfahrung habe und dadurch auch einige ihrer Macken kenne, fällt es mir schwer, bei einer Bewertung neutral zu bleiben. Doch werde ich mir Mühe geben.

Ubuntu importiert den Großteil seiner Pakete aus Debian Unstable. Für einen Teil dieser Pakete übernimmt nach dem Debian Import Freeze die Firma Canonical die Pflege. Der größte Teil landet hingegen in der Komponente universe, wo er von den MOTU betreut wird (oder gar nicht). Die Folge dieses Vorgehens: Wenn Pakete in Debian Unstable während des Debian Import Freeze kaputt und unbenutzbar sind, werden sie in die Ubuntu-Paketquellen importiert und bleiben mit großer Wahrscheinlichkeit für die Lebensdauer des jeweiligen Release kaputt und unbenutzbar. Dieses Vorgehen halte ich persönlich für ganz großen Schwachsinn.

Als einzigartig hingegen empfinde ich die deutschsprachige Community ubuntuusers.de. Auch wenn hier in einigen Themen auch mal die Fetzen fliegen, ist der Umgangston doch überwiegend freundlich. Hier fand ich in der Vergangenheit stets wertvolle Hilfe bei kleinen und auch großen Problemen

Ubuntu 18.04 LTS
NameWertBewertung
Unterstützungszeitraum5 Jahre bis April 20233
Release-ZyklusAlle 2 Jahre3
Communityubuntuusers.de4
Kernel4.153
systemd2372
gnome-shell3.28.32
Vim8.02
Firefox66.0.33
Thunderbird60.6.13
Evolution3.28.52
gThumb3.6.12
Evince3.18.42
Kile2.9.911
TeXlive20171
XSane0.9994
Summe37

Schlussfolgerung und selbstkritische Reflexion des Distributions-Vergleichs

Ubuntu 16.04 LTSCentOS 7Debian BusterFedora RawhideUbuntu 18.04 LTS
3838403637

Sieg nach Punkten für das hoffentlich bald erscheinende Debian Buster!

Dass mein heimlicher Favorit das Rennen gemacht hat, verwundert nicht. Nüchtern und bei Licht betrachtet muss ich gestehen, dass der oben stehende Vergleich Makulatur und nicht objektiv ist. So ist der Vergleich und die Bewertung von Software-/Paket-Versionen nicht geeignet, um zu bestimmen, wie gut meine funktionalen Anforderungen erfüllt werden. Dazu hätte es eines praktischen Tests der einzelnen Versionen bedurft.

So offenbarte ein praktischer Vergleich von kile in Version 2.9.91, dass mir dieses in der Benutzung deutlich schlechter gefällt, als die ältere Version 2.1.3. Und was für kile gilt, mag selbstverständlich auch für andere Anwendungen gelten.

Ein weiterer großer Schwachpunkt des Vergleichs ist der Punkt ‚Community‘. Aus persönlicher Erfahrung kenne ich nur die ubuntuusers.de wirklich gut, weil ich nur hier seit vielen Jahren selbst aktiv bin. Die Bewertung aller anderen Communities und Unterstützungsmöglichkeiten basiert auf deutlich weniger Erfahrungen und Teils sogar nur auf Hörensagen. Eine objektive Bewertung ist so natürlich nicht möglich.

Streng genommen handelt es sich bei dem angestellten Vergleich um Humbug und Mumpitz. Bitte nicht nachmachen!

Mir selbst reicht er jedoch als Indikator, dass das kommende Debian Buster meine Anforderungen daheim gut erfüllen könnte. Es wird daher nach der Veröffentlichung auf einem meiner Geräte installiert und in der Praxis erprobt.

Tja, wenn ich ehrlich bin, ist dieser Artikel wenig hilfreich. Zum Trost sei gesagt, dass er mir half, ein wenig die Zeit bis zum Release von Buster zu überbrücken.

Verzeichnis „/.well-known/“ überwachen

In einem bei heise online veröffentlichten Artikel ist zu lesen, dass das Verzeichnis „/.well-known/“ ein beliebtes Malware-Versteck auf gehackten Webservern ist. Der heise-Artikel empfiehlt Admins, den Inhalt von „/.well-known/“ und ggf. weiterer Unterverzeichnisse von Zeit zu Zeit zu prüfen. Um dies nicht manuell tun zu müssen, biete ich mit diesem Artikel ein Tutorial, das beschreibt, wie man diese Aufgabe mit Hilfe von systemd.path-Units automatisieren kann.

Ziel ist es, dass das System in dem Fall, dass sich der Verzeichnisinhalt von „/.well-known/“ oder eines darin enthaltenen Unterverzeichnisses ändert, eine E-Mail mit einem aktuellen Verzeichnis-Listing an eine konfigurierte E-Mail-Adresse sendet.

Update 2019-06-20: Neuen Abschnitt eingefügt

Voraussetzungen

Um diesem Tutorial folgen zu können, muss das betrachtete System

  • systemd als Init-System verwenden und
  • in der Lage sein, E-Mails zu versenden.

Darüber hinaus werden Kenntnisse in der Bearbeitung von Dateien mit einem Texteditor im Terminal vorausgesetzt.

Hinweis: Das Tutorial wurde mehrfach erfolgreich unter Ubuntu Bionic getestet. Der Leser Daniel hat versucht es unter Ubuntu Xenial nachzuvollziehen, was jedoch nicht geglückt ist. Details dazu finden sich in den Kommentaren zum Artikel.

Erstellung der Path-Unit

Im Verzeichnis /etc/systemd/system/ wird die Datei beispiel.path mit folgendem Inhalt erstellt. Der Dateiname kann selbstverständlich frei gewählt werden. Er muss lediglich auf .path enden.

[Unit]
Description="Meine '/.well-known/' Verzeichnisse auf Änderungen hin überwachen"

[Path]
PathModified=/var/www/site1/public/.well-known/
PathModified=/var/www/site1/public/.well-known/acme-challenge/
PathModified=/var/www/site2/public/.well-known/
PathModified=/var/www/site2/.well-known/acme-challenge/
PathModified=/var/www/site3/public/.well-known/
PathModified=/var/www/site3/public/.well-known/acme-challenge/
Unit=beispiel.service

[Install]
WantedBy=multi-user.target

In obigem Beispiel wird davon ausgegangen, dass der Webserver drei verschiedene Seiten ausliefert, die jeweils über ein eigenes „/.well-known/“-Verzeichnis mit jeweils einem Unterverzeichnis verfügen.

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

Erstellung der Service-Unit

Als nächstes wird die auszuführende Service-Unit erstellt. Diese sollte den gleichen Namen wie die Path-Unit haben, im Unterschied zu dieser jedoch auf .service enden. Die Datei beispiel.service wird ebenfalls im Verzeichnis /etc/systemd/system/ erstellt.

[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

In der Service-Unit wird definiert, was getan werden soll, wenn die dazugehörige Path-Unit ausgelöst wird. In diesem Beispiel soll das hinter ExecStart= angegebene Skript ausgeführt werden.

Erstellung des auszuführenden Skripts

Findet eine Änderung in einem der überwachten Verzeichnisse statt, wird folgendes Skript ausgeführt:

#!/bin/bash
MAIL_TEXT="/tmp/well-known"
MAIL_RCP="foo@example.com"
create_mail() {
cat >"${MAIL_TEXT}" <<EOF
Achtung, der Inhalt der '/.well-known/'-Verzeichnisse wurde verändert. Die Verzeichnisse haben aktuell folgenden Inhalt:

$(find /var/www/ -type d -name ".well-known" -exec ls -lRa {} \;)
EOF
}

send_mail() {
    /usr/bin/mailx -s 'Achtung: Inhalt von /.well-known/ geändert' ${MAIL_RCP} <"${MAIL_TEXT}"
}

create_mail
send_mail

Das obige Skript ist abends auf dem Sofa entstanden und erhebt nicht den Anspruch schön oder perfekt zu sein. Es erfüllt jedoch seinen Zweck und sendet eine E-Mail an eine angegebe Empfangsadresse. In der Mail werden alle „/.well-known/“-Verzeichnisse inkl. enthaltener Dateien und Unterverzeichnisse aufgelistet, welche sich innerhalb des Suchpfads /var/www befinden.

Die Überwachung scharf schalten

Um die Überwachung zu aktivieren, sind noch die folgenden Schritte mit root-Rechten auszuführen:

  1. Die Units zu aktivieren
  2. Die Path-Unit zu starten
sudo systemctl enable beispiel.path beispiel.service
sudo systemctl start beispiel.path

Zum Test kann man nun eine neue Datei oder ein Verzeichnis in einem der überwachten Pfade erstellen. Daraufhin, sollte man eine E-Mail erhalten, welche über die Änderung informiert.

Update 2019-06-20: Auffälliges Verhalten erkannt

In den letzten Tagen habe ich sporadisch eine E-Mail von meinem Server bekommen, welche mich über eine Änderung in den überwachten Verzeichnissen informieren sollte. Jedoch konnte ich im Inhalt der E-Mail keinerlei Änderung an den Verzeichnisinhalten erkennen. Diese waren wie erwartet leer.

Meine Hypothese warum ich dennoch eine E-Mail bekam war, dass die erfolgte Änderung umgehend rückgängig gemacht wurde. So dass die Verzeichnisse bereits wieder leer waren, als die Service-Unit ausgeführt wurde, welche mir die Verzeichnisinhalte per E-Mail sendet. Um diese Hypothese zu prüfen, habe ich folgendes Kommando ausgeführt:

# touch /var/www/site1/public/.well-known/test && rm /var/www/site1/public/.well-known/test

Der kurze Test bestätigte meine Hypothese. Es wurde wie erwartet eine Datei erstellt und direkt wieder entfernt. Die Path-Unit aktivierte die verknüpfte Service-Unit und ich erhielt eine E-Mail nach welcher der Inhalt von /var/www/site1/public/.well-known/ leer war.

Das beobachtete Verhalten empfinde ich als unschön, da ich so nicht mehr feststellen kann, was für eine Änderung stattgefunden hat und die E-Mail-Benachrichtigung damit nicht zum gewünschten Erkenntnisgewinn führt.

Noch ist unklar, ob dies einer fehlerhaften Konfiguration meinerseits, einem Bug, oder dem Design geschuldet ist. Falls jemand von euch einen besseren Einblick in diese Thematik besitzt, freue ich mich über euren Kommentar.

Ein Hinweis zum Schluss

Erwähnt werden muss, dass nur Änderungen signalisiert werden können, die vom Kernel ausgeführt werden. Führen andere Maschinen auf per Netzwerk eingebundenen Pfaden Änderungen durch, wird das nicht signalisiert.

https://www.my-it-brain.de/wordpress/unit-typ-systemd-path-kurz-vorgestellt/#comment-1624

Quellen und weiterführende Links

logo_clt2019

Zu Besuch bei den Chemnitzer Linux Tagen 2019

Auch in diesem Jahr haben die Chemnitzer Linux Tage wieder in das zentrale Hörsaal- und Seminar-Gebäude der Technischen Universität Chemnitz eingeladen. Das Motto lautete diesmal „Natürlich intelligent“ und so wundert es nicht, dass sich eine Vielzahl von Vorträgen den Themen Künstliche Intelligenz und Maschinelles Lernen widmeten. Darüber hinaus gab es interessante Vorträge zu den Themen IoT, Container, Sicherheit, Einsteiger, Datacenter, usw. Alles in allem wurde wie im letzten Jahr ein vielseitiges Programm geboten.

Anreise am Freitag

Wie im vergangenen Jahr bin ich auch dieses Mal wieder mit dem Auto angereist, denn 4,5 Std. Fahrt sind mir doch lieber, als 6-7 Std. Reisezeit mit der Bahn (laut Fahrplan). So kam ich Freitag Abend rechtzeitig an, um das Social Event im Turmbrauhaus zu besuchen. Es war ein schöner Abend mit freundlichen Menschen bei interessanten Gesprächen und natürlich 1..n Hopfenkaltschalen.

Ich habe mich gefreut, bekannte Gesichter von ubuntuusers.de wieder zu sehen und neue Gesichter hinter einigen Blogs kennen zu lernen, die ich regelmäßig lese.

Auftakt am Samstag

Punkt 7.00 Uhr Frühstück im Hotel, 8.00 Uhr Einlass bei den Chemnitzer Linux Tagen und ab 9.00 Uhr öffnete die Ausstellerfläche und das Vortragsprogramm startete. Ich selbst lernte an diesem Tag etwas über Präsentationen mit XeLaTeX (Beamer), NVMe, NVMe over Fabrics und erfuhr die ein und andere Neuigkeit im persönlichen Gespräch mit alten und neuen Bekannten. Mein persönliches Zitat des Tages stammt von D. Menzel und lautet: „NVMe over Fabric ist wie iSCSI auf Steroiden.“ :-D

Ausklang am Sonntag

Auch der Sonntag begann früh mit dem Frühstück um 7.00 Uhr. Um 9.00 Uhr war bereits alles für die Abreise gepackt und die Chemnitzer Linux Tage öffneten ihre Halle für den zweiten Veranstaltungstag. Dieser startete für mich mit einigen Standbesuchen, um Informationen über mögliche Schulungsangebote und Tipps für den Einsatz von Ansible einzusammeln, bevor es dann um 10.00 Uhr in den ersten Vortrag, den Samba Status Report, ging.

Laut dem zuvor genannten Vortrag tritt SMB2 an, um NFS zu töten. Naja, ich persönlich glaube, Totgesagte leben länger.

Der Storage Track endete mit einem Vortrag von Kai Wagner, welcher über die Neuigkeiten im neuen Ceph Release Nautilus berichtete. In hohem Tempo führte Kai durch eine Folienschlacht, um keine coole Neuerung zu vergessen. Bei den vielen lang erwarteten Neuerung kann ich gut verstehen, dass Kai keine davon unterschlagen wollte. Dennoch hat Kai hier einen tollen und unterhaltsamen Talk gehalten. Danke hierfür.

Der letzte Vortag für mich an diesem Tage war Open Source und Medizin, welcher einen interessanten Einblick in die Forschung mit Medizindaten bot.

Im Anschluss wurden die Vorträge noch in kleinen Gruppen diskutiert, bevor ich mich verabschiedete, um mich auf den Heimweg zu machen.

Es war mal wieder ein schönes Wochenende und tolle Chemnitzer Linux Tage 2019. Bis zum nächsten Jahr.

RHEL Spiegelserver für arme Admins

Es muss nicht immer gleich der Red Hat Sattelite Server sein, um einen lokalen Spiegelserver für die Installation von RPM-Paketen bereitzustellen.

Auf GitHub habe ich im Repository „Poor man’s RHEL mirror“ eine kleine Sammlung von Bash-Skripten zusammengestellt, mit denen sich ein Spiegelserver für RHEL-Repositories aufbauen lässt. Mit diesem können RHEL-Repositories, für welche man eine gültige Subskription besitzt, auf einen Host im lokalen Netzwerk synchronisiert und deren Pakete anderen RHEL-Servern im LAN zur Verfügung gestellt werden.

Neben der reinen Spiegelung können mit den auf GitHub bereitgestellten Skripten weitere lokale Stage-Repositories eingerichtet werden, mit denen sich die Verfügbarkeit von Paketen für einzelne Stages steuern lässt. Zusätzlich bietet das Projekt Skripte, um eigene YUM-Repositories zu erstellen, um zum Beispiel eigene Pakete darüber bereitstellen zu können. Des Weiteren wurde die Möglichkeit berücksichtigt, die Red Hat Errata Informationen in die lokalen RHEL-Repositories zu integrieren, um die --advisory Option für YUM auch auf Systemen nutzen zu können, die über keine eigene Verbindung zum Internet verfügen.

Warum ist dieses Projekt nützlich?

  • Es schont die eigene Internetverbindung, da Pakete nur einmal aus dem Internet heruntergeladen und anschließend im LAN zur Verfügung gestellt werden.
  • Es unterstützt bei der Erstellung eines YUM-Repositories zur Bereitstellung von RPM-Paketen.
  • Es unterstützt das Staging-Konzept, in dem es die Möglichkeit bietet, stage-spezifische Repositories bereitzustellen.
  • Es implementiert die Red Hat Errata Informationen in die gespiegelten RHEL-Repos, so dass diese von angebundenen Servern genutzt werden können, die über keine eigene Internetverbindung verfügen.
  • Es entstehen keine Zusatzkosten, da alle notwendigen Werkzeuge in den Repos einer RHEL-Standard-Subskription enthalten sind.

Wer kann dieses Projekt nutzen?

Das Projekt selbst steht unter der MIT-Lizenz und kann unter deren Bedingungen frei genutzt, modifiziert und weiter verteilt werden.

Für den Betrieb des Spiegelservers ist der Besitz einer gültigen RHEL-Subskription Voraussetzung. Denn es können nur jene Repos gespiegelt werden, für die eine gültige Subskription vorhanden ist. Auch alle an den Spiegelserver angeschlossenen Systeme müssen über eine entsprechende und gültige Subskription verfügen.

Bei Fragen zu Subskriptionen helfen die folgenden Seiten weiter:

Um mit diesem Projekt einen Spiegelserver aufsetzen und betreiben zu können, sind gewisse Kenntnisse erforderlich. Zu diesen zählen die Installation eine RHEL-Systems inkl. Registrierung, das Hinzufügen von Subskriptionen und die Installation von Paketen. Informationen hierzu bietet die Product Documentation for Red Hat Enterprise Linux 7.

Wie ist das GitHub-Repository zu diesem Projekt aufgebaut?

Das GitHub-Repository beinhaltet ein README, welches einen Überblick über das Projekt und eine Kurzbeschreibung der einzelnen Skripte in englischer Sprache beinhaltet. Im Master-Branch befindet sich die letzte stabile Version des Projekts. Weiterentwicklungen und Fehlerkorrekturen werden im Dev-Branch gepflegt und nach einer Testphase in den Master-Branch übernommen.

Sorgen, Nöte und Anträge sowie gefundene Fehler dürfen gern über die Issue-Funktion oder in den Kommentaren zu diesem Beitrag gemeldet werden.

An dieser Stelle folgt eine Beschreibung in deutscher Sprache, wie ein Spiegelserver mit diesem Projekt aufgebaut werden kann. Dabei handelt es sich um keine Schritt-für-Schritt-Anleitung und es werden grundlegende Kenntnisse über den Betrieb eines RHEL-Servers und die Installation sowie Konfiguration von Paketen vorausgesetzt.

Einrichtung eines Spiegelservers für arme Sysadmins

Um das Projekt nutzen zu können, benötigt man eine RHEL-Installation mit gültiger Subskription, auf welcher mindestens die folgenden Pakete installiert sein müssen:

  • reposync und createrepo, um RHEL-Repos synchronisieren und eigene Repos erstellen zu können
  • git zum Klonen des hier beschriebenen Projekts
  • Die Gruppe Basic Web Server oder einen anderen Webserver eurer Wahl, um die gespiegelten Repos über HTTP im LAN bereitstellen zu können

Zu Beginn sind die Dateien aus dem oben genannten GitHub-Repository in einem Verzeichnis auf dem lokalen Host bereitzustellen. Anschließend ist das Projekt zu konfigurieren. Die dazu notwendigen Schritte werden in den folgenden Abschnitten erläutert.

CONFIG.SAMPLE

Hierbei handelt es sich um die Hauptkonfigurationsdatei. Diese ist in CONFIG umzubenennen bzw. zu kopieren und zu editieren. In dieser Datei werden die Variablen gesetzt, die von den verschiedenen Shell-Skripten verwendet werden. Darunter sind z.B. Angaben, welche Repos gespiegelt werden und wo die Dateien gespeichert werden sollen.

Die Datei ist mit Kommentaren versehen und sollte weitgehend selbsterklärend sein (was für alle weiteren Dateien gilt).

create_yum_repo.sh

Dieses Skript kann genutzt werden, um ein eigenes YUM-Repository zu erstellen, über welches RPM-Pakete bereitgestellt werden können. Der Name des zu erstellenden Repos kann dem Skript als Parameter übergeben werden.

do_reposync.sh

Dies ist das Herzstück des Projekts. Es kümmert sich um die Spiegelung der RHEL-Repos. Die notwendigen Parameter werden in der Datei CONFIG konfiguriert.

Das Skript lädt nur die aktuellen Pakete aus den Repos herunter, löscht aus den Upstream-Repos entfernte Pakete jedoch nicht automatisch auf dem lokalen Host. Dies ist meinen persönlichen Anforderungen geschuldet. Es ist nicht ausgeschlossen, dass ich diese Parameter in Zukunft ebenfalls konfigurierbar gestalte.

Einen Überblick über den Speicherbedarf ausgewählter RHEL-Repos findet ihr hier: How much disk space do I need for reposync?

Um die heruntergeladenen Pakete im LAN zur Verfügung zu stellen, muss das BASEDIR (siehe CONFIG) über einen Webserver zugreifbar gemacht werden.

refresh_repo.sh

Werden einem Repo neue RPM-Dateien hinzugefügt, muss die Metadaten-Datenbank aktualisiert werden, damit Klienten die neuen Pakete auch finden können. Um diese Aktualisierung kümmert sich eben dieses Skript.

rsync_repo.sh

Mit diesem Skript lassen sich Repos auf dem lokalen System synchronisieren. Dabei werden die Dateien jedoch nicht 1:1 kopiert, sondern Hardlinks erstellt. Dies spart bei der Verwendung mehrerer Repos für unterschiedliche Stages Speicherplatz.

Neben dem kompletten Sync eines Repos ist es auch möglich, dem Skript eine Datei zu übergeben, welche die Namen der Pakete enthält, welche in ein weiteres Repo „transportiert“ werden sollen.

Wrapper-Scripts

In meiner Umgebung arbeiten wir mit bis zu vier verschiedenen Stages (E, I, Q und P). Für jede dieser Stages wird ein eigenes Stage-Repo des Upstream rhel-7-server-rpms erzeugt. Um diese Stage-Repos zu aktualisieren, werden die folgenden Skripte verwendet:

  • update_rhel-e-stage.sh
  • update_rhel-i-stage.sh
  • update_rhel-q-stage.sh
  • update_rhel-p-stage.sh

Jede Stage wird mit den Paketen aus der vorhergehenden aktualisiert. So ruft z.B. update_rhel-e-stage.sh das Skript rsync_repo.sh, um die Pakete aus dem lokalen Spiegel des Upstreams rhel-7-server-rpms zu importieren. update_rhel-i-stage.sh verwendet dementsprechend die rhel-e-stage als Quelle usw.

Diese Konfiguration ist für meinen Anwendungsfall optimiert. Die Verwendung der Skripte ist optional. Der Spiegelserver funktioniert auch ohne diese Wrapper-Scripts.

update_mirror_packages_and_erratas.sh

Dieses Skript aktualisiert die Pakete in den Repos des lokalen Spiegelservers inkl. der Red Hat Errata Informationen. Letztere ermöglichen es, die Erratas (RHSA, RHBA und RHEA) auch Systemen verfügbar zu machen, welche über keine Verbindung zum Internet verfügen.

Das Skript ist in der Standardeinstellung auf meinen Anwendungsfall optimiert und aktualisiert am Ende alle vorhandenen RHEL-Stage-Repos. Wer diese Funktion nicht benötigt, kann sie durch Auskommentieren der Zeilen 45 und 46 im Skript deaktivieren.

Anschließend kann ein Cronjob erstellt werden, welcher das Skript ausführt, um den Spiegelserver regelmäßig gemäß der eigenen Anforderungen zu aktualisieren.

Die gespiegelten Repos verfügbar machen

Hat man die Repos seiner Wahl gespiegelt, ergibt sich je nach Konfiguration eine Verzeichnisstruktur ähnlich der folgenden.

$ tree -L 2
.
├──  rhel-7-test-mirror
│   ├── rhel-7-server-extras-rpms
│   ├── rhel-7-server-optional-rpms
│   ├── rhel-7-server-rpms
│   ├── rhel-7-server-supplementary-rpms
│   ├── rhel-e-stage
│   ├── rhel-e-stage.repo
│   ├── rhel-i-stage
│   ├── rhel-p-stage
│   ├── rhel-q-stage
│   └── rhel-server-rhscl-7-rpms

Das Verzeichnis rhel-7-test-mirror aus obigen Beispiel enthält die gespiegelten Repos als Unterverzeichnisse. Dieses Verzeichnis sollte über einen Webserver zugreifbar gemacht werden, um die Pakete den Clients im lokalen Netzwerk verfügbar zu machen.

Im obigen Listing ist eine Datei namens rhel-e-stage.repo zu sehen. Dabei handelt es sich um eine Repo-Datei, welche heruntergeladen und im Verzeichnis /etc/yum.repos.d/ platziert werden kann, um wie in diesem Beispiel das Repo rhel-e-stage zu aktivieren.

Aufbau einer Repo-Datei

Das folgende Listing zeigt die kommentierte Repo-Datei aus dem vorstehenden Abschnitt. Sie kann als Muster für weitere eigene Repo-Dateien dienen.

[rhel-e-stage] # Repo ID
baseurl = http://example.com/rhel-7-test-mirror/rhel-e-stage/
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
name = Repo for rhel-7-server-rpms (Test)

Fragen, Sorgen, Nöte und Anträge

Das Projekt und die enthaltene Software werden so wie sie sind unter der angegebenen Lizenz zur Verfügung gestellt.

Fragen, Sorgen, Nöte und Anträge können sowohl hier in den Kommentaren zum Artikel, als auch auf Github hinterlassen werden.

Ich hoffe, dass dieses Projekt euch (weiterhin) nützlich ist und freue mich über Rückmeldungen, wie es euch gefällt.