Dies ist der Beginn meines zweiten Container-Projekts. Nach Kanboard im Container möchte ich diesmal eine Nextcloud-Instanz als Container, zusammen mit einem Datenbank-Container, in einem Podman-Pod betreiben.

Da ein einzelner Artikel vermutlich zu lang wird, teile ich das Projekt in mehrere Artikel auf. Wie viele es genau werden, kann ich jetzt noch nicht sagen. Am Ende der Reihe werde ich hier eine Übersicht einführen und die einzelnen Teilen entsprechend miteinander verbinden.

In diesem ersten Teil geht es um meine Motivation, das eigentliche Ziel und den groben Plan.

Was Leser dieser Reihe erwartet

Ihr könnt mich durch diese Reihe begleiten und euch von meinen Erlebnissen und Erkenntnissen unterhalten lassen. Dabei dürft ihr nicht annehmen, dass es sich bei dem von mir beschriebenen Vorgehen um eine gute Praxis handelt. Hier gilt eher: Der Weg ist das Ziel.

Ihr seid herzlich eingeladen, die Artikel zu kommentieren und über das Vorgehen und Alternativen dazu zu diskutieren. Gern in der Kommentarsektion unter den jeweiligen Beiträgen oder als Artikel in euren eigenen Blogs.

Ich plane die Artikel im Wochenrhythmus, wenigstens monatlich, zu veröffentlichen. Bitte verzeiht, wenn es etwas unregelmäßig wird. Dies ist ein Hobby, dem nur begrenzt Zeit zur Verfügung steht.

Motivation

Bei Linux-Containern handelt es sich um eine Technologie, die gekommen ist, um zu bleiben. Sie hat bereits in vielen Branchen Fuß gefasst und immer mehr Projekte bieten ihre Anwendungen zusätzlich oder ausschließlich in Form von Containern an.

Als Sysadmin mittleren Alters werden mich Linux-Container sicher noch viele Jahre begleiten. Um praktische Erfahrungen mit dem Betrieb zu sammeln, möchte ich einige private Projekte in Containern betreiben.

Beruflich arbeite ich überwiegend mit RHEL. Red Hat engagiert sich stark in den Projekten Ansible und Podman, welche ich auch unter anderen Distributionen, wie z.B. Debian, einsetze. Ich möchte das Projekt als Chance nutzen, mein Wissen auch in diesen Werkzeugen zu festigen und auszubauen.

Ich spiele schon seit einiger Zeit mit dem Gedanken, wieder eine eigene Nextcloud-Instanz zu betreiben. Da auf dem zur Verfügung stehenden Server bereits eine Nextcloud-Instanz läuft und ich meine Anwendung von der bestehenden Instanz getrennt und möglichst losgelöst vom Betriebssystem betreiben möchte, habe ich mich entschieden, Nextcloud im Container zu betreiben.

Ziele

Ziel dieses Projekts sind das Deployment und der Betrieb einer Nextcloud-Instanz als Podman-Pod. Im Einzelnen sollen folgende Ziele erreicht werden:

1. Entwicklung eines wiederverwendbaren Verfahrens zum Deployment einer Nextcloud im Container
2. Persistente Speicherung von Konfigurations- und inhaltlichen Daten im Dateisystem des Hosts
3. Konfiguration eines Reverse-Proxies (NGINX) für den Zugriff auf die Nextcloud-Instanz
4. Konfiguration von Backup und Restore für Konfiguration und Inhalte der Nextcloud-Instanz
5. Konfiguration und Test automatischer durch Ansible gesteuerter Updates

Umgebung

Für die Umsetzung des Projekts steht mir ein Virtual Private Server (VPS) mit genügend Ressourcen zur Verfügung. Dieser wird in einem Rechenzentrum in Deutschland betrieben. Auf diesem sind Debian Bullseye, NGINX, ein OpenSSH-Server, Podman 3.0.1 (rootless) und Python 3.9.2 installiert. Damit erfüllt dieses System die Voraussetzungen, um mit Ansible konfiguriert zu werden und Container ausführen zu können.

Ansible selbst läuft in meiner privaten Arbeitsumgebung auf meinem Debian-PC und einem Fedora-35-Notebook.

Methodik und verwendete Werkzeuge

Zu Beginn habe ich mich etwas in der Nextcloud-Dokumentation und den verfügbaren Nextcloud-Images belesen. Besagte Dokumentation sowie die der verwendeten Werkzeuge sind im folgenden Abschnitt verlinkt.

Um die oben formulierten Ziele zu erreichen, werde ich in einem Python Virtual Environment eine Ansible-Version installieren, mit der ich die Collection containers.podman nutzen kann. Hiermit werde ich eine Ansible-Rolle entwickeln, die ich wiederverwenden kann, um Nextcloud-Instanzen in einer rootless-Podman-Umgebung zu deployen. Die Ansible-Rolle wird anschließend auf meinem GitHub-Account veröffentlicht.

Die Konfiguration von NGINX und acme.sh für die TLS-Zertifikate erfolgt manuell.

Quellen und weiterführende Links

In diesem Abschnitt liste ich Links zu Artikeln und Dokumentationen auf, welche ich im Vorfeld gelesen habe und deren Kenntnis ich für die Umsetzung als nützlich erachte. Zur besseren Übersicht gliedere ich diese in die Unterabschnitte Hintergrundwissen, Dokumentation und Eigene Artikel.

Die weiteren Artikel dieser Reihe

• Nextcloud im Container – Teil 2: Die Ansible-Rolle
• Nextcloud im Container — Teil 3: Mit Reverse-Proxy
• Nextcloud im Container — Teil 4: Hier und da klemmt es
• Nextcloud im Container – Teil 5: Backup und Restore
• Nextcloud im Container – Teil 6: Updates

Hintergrundwissen

• Architecting Containers Part 1: Why Understanding User Space vs. Kernel Space Matters; Scott McCarty (fatherlinux); July 29, 2015
• Architecting Containers Part 2: Why the User Space Matters; Scott McCarty (fatherlinux); September 17, 2015
• Architecting Containers Part 3: How the User Space Affects Your Application; Scott McCarty (fatherlinux); November 10, 2015
• A Practical Introduction to Container Terminology; Scott McCarty (fatherlinux); February 22, 2018
• Podman: Managing pods and containers in a local container runtime; Brent Baude; January 15, 2019
• Installing Nextcloud 20 on Fedora Linux with Podman; fedora MAGAZINE; DSchier; February 15, 2021
• How to set up and use Python virtual environments for Ansible; Enable Sysadmin; Gineesh Madapparambath; 2021-08-18
• https://de.wikipedia.org/wiki/Ansible
• https://de.wikipedia.org/wiki/Nextcloud
• https://de.wikipedia.org/wiki/Containervirtualisierung

Dokumentation

• https://docs.ansible.com/
• https://docs.nextcloud.com/
• https://hub.docker.com/_/nextcloud
• https://github.com/docker-library/docs/blob/master/nextcloud/README.md

Eigene Artikel

• Kanboard im Container…
• Reverse-Proxy für Kanboard im Container
• Backup und Restore im Kanboard-Container-Land
• Aktualisierung eines Kanboard-Pods

In Teil 1 dieser Artikelserie habe ich mein Ansinnen ausführlich beschrieben. Dieser Teil widmet sich der Entwicklung einer Ansible-Rolle zum Deployment des Nextcloud-Apache-Container-Images.

In den folgenden Abschnitten beschreibe ich die Einrichtung eines Python Virtual Environments, die Installation von Ansible in dem zuvor erstellten Environment und die Installation der Ansible-Collection containers.podman, bevor ich mich abschließend der eigentlichen Ansible-Rolle widme.

Python Virtual Environments für Ansible

Zur Einrichtung habe ich mich an den englischsprachigen Artikel „How to set up and use Python virtual environments for Ansible“ von Gineesh Madapparambath gehalten. Die notwendigen Schritte werden hier kurz und bündig dokumentiert.

[t14s ~]$ python3 --version
Python 3.9.7

[t14s ~]$ mkdir python-venv
[t14s ~]$ cd !$
cd python-venv

[t14s python-venv]$ python3 -m venv ansible-core2.x
[t14s python-venv]$ source ansible-core2.x/bin/activate
(ansible-core2.x) [jkastning@t14s python-venv]$ python3 -m pip install --upgrade pip
Requirement already satisfied: pip in ./ansible-core2.x/lib/python3.9/site-packages (21.0.1)
Collecting pip
  Downloading pip-21.3.1-py3-none-any.whl (1.7 MB)
     |████████████████████████████████| 1.7 MB 2.3 MB/s 
Installing collected packages: pip
  Attempting uninstall: pip
    Found existing installation: pip 21.0.1
    Uninstalling pip-21.0.1:
      Successfully uninstalled pip-21.0.1
Successfully installed pip-21.3.1

(ansible-core2.x) [t14s python-venv]$ python3 -m pip install ansible-core
Collecting ansible-core
[...]

(ansible-core2.x) [t14s python-venv]$ ansible --version
ansible [core 2.11.6] 
  config file = None
  configured module search path = ['/home/tronde/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/tronde/python-venv/ansible-core2.x/lib64/python3.9/site-packages/ansible
  ansible collection location = /home/tronde/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/tronde/python-venv/ansible-core2.x/bin/ansible
  python version = 3.9.7 (default, Aug 30 2021, 00:00:00) [GCC 11.2.1 20210728 (Red Hat 11.2.1-1)]
  jinja version = 3.0.2
  libyaml = True

Damit ist die Installation von ansible-core abgeschlossen. Im folgenden Code-Block wird geprüft, ob Ansible sich grundsätzlich mit dem Zielsystem verbinden und dort einen Python-Interpreter identifizieren kann.

(ansible-core2.x) [t14s python-venv]$ ansible -i hosts --private-key ~/.ssh/ansible_id_rsa -m ping example.com
example.com | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

Installation der Ansible-Collection containers.podman

Um Podman auf dem Zielsystem konfigurieren zu können, wird die genannte Ansible-Collection benötigt, welche mit folgendem Befehl installiert werden kann. Der Code-Block zeigt zusätzlich die Ausgabe während der Installation.

(ansible-core2.x) [t14s ansible-core2.x]$ ansible-galaxy collection install containers.podman
Starting galaxy collection install process
Process install dependency map
Starting collection install process
Downloading https://galaxy.ansible.com/download/containers-podman-1.8.2.tar.gz to /home/tronde/.ansible/tmp/ansible-local-8729oh0om8w3/tmp7tv2yrae/containers-podman-1.8.2-9rw3fd1y
Installing 'containers.podman:1.8.2' to '/home/tronde/.ansible/collections/ansible_collections/containers/podman'
containers.podman:1.8.2 was installed successfully

Ansible-Rolle: Deployment von Nextcloud und MariaDB als Pod

Nextcloud benötigt für den Betrieb eine Datenbank. Hierfür könnte man eine integrierte SQLite nutzen. Dies wird jedoch nur für kleine Umgebungen empfohlen. Während der Entstehung dieses Artikels wird MariaDB als Datenbank-Backend vom Nextlcoud-Projekt empfohlen. Daher habe ich mich entschieden, das Nextcloud-Image zusammen mit einem MariaDB-Container zu deployen. Dazu greife ich auf die beiden folgenden Container-Repositorien zurück:

• Nextcloud (Official Image) — https://hub.docker.com/_/nextcloud
• MariaDB (Official Image) — https://hub.docker.com/_/mariadb

Das Grundgerüst bzw. die Verzeichnisstruktur für die Ansible-Rolle wurde erstellt mit:

$ ansible-galaxy role init --offline ansible_role_deploy_nextcloud_with_mariadb_pod

Die aktuelle Version der Ansible-Rolle ist auf GitHub zu finden. Ich werde ihre Bestandteile hier im Einzelnen vorstellen.

Die Variablen in defaults/main.yml

In der Datei defaults/main.yml habe ich Standardwerte für Variablen definiert, die geeignet sind, eine funktionsfähige Nextcloud-Instanz zu initialisieren. Die Bezeichner der Variablen sind dabei der Dokumentation der verwendeten Container-Repositorien entnommen.

In Zeile 4-7 und 10 werden die Namen für Podman-Volumes definiert, welche die persistent zu speichernden Daten aufnehmen werden.

     1	---
     2	# defaults file for ansible_role_deploy_nextcloud_with_mariadb_pod
     3	# Podman volumes for Nextcloud
     4	NC_HTML: nc_html
     5	NC_APPS: nc_apps
     6	NC_CONFIG: nc_config
     7	NC_DATA: nc_data
     8	
     9	# Podman volume for MariaDB
    10	MYSQL_DATA: mysql_data

Die Zeilen 13-17 definieren Variablen für die MariaDB-Instanz, wie z.B. Namen der Datenbank, Benutzername und Passwörter für diese Datenbank und den DB-Host. Diese werden neben dem MariaDB-Container auch von dem Nextcloud-Container benötigt, um eine Verbindung zur Datenbank herstellen zu können.

    12	# MySQL/MariaDB vars
    13	MYSQL_DATABASE: nc_db
    14	MYSQL_USER: nextcloud
    15	MYSQL_PASSWORD: ToPSeCrEt2021!
    16	MYSQL_ROOT_PASSWORD: ToPSeCrEt2021!
    17	MYSQL_HOST: 127.0.0.1
    18	
    19	# Vars for MariaDB container
    20	MARIADB_CONMON_PIDFILE: /tmp/mariadb_conmon.pid
    21	MARIADB_IMAGE: docker.io/library/mariadb:10.5.7
    22	MARIADB_NAME: nc_mariadb

Zeile 20-22 definiert Variablen, die für den MariaDB-Container benötigt werden. Hier wird z.B. die Version des Container-Images (MARIADB_IMAGE) und ein Name für die Container-Instanz (MARIADB_NAME) festgelegt.

Die folgenden Zeilen widmen sich den Variablen für den Nextcloud-Container. Dort werden in den Zeilen 25 u. 26 Benutzername und Passwort für den Nextcloud-Admin definiert, gefolgt von einigen Variablen, welche bei Nutzung eines Reverse-Proxy benötigt werden und SMTP-Variablen, welche der Nextcloud den Mailversand ermöglichen.

    24	# Nextcloud vars
    25	NEXTCLOUD_ADMIN_USER: nc_admin
    26	NEXTCLOUD_ADMIN_PASSWORD: VSnfD2021!
    27	NEXTCLOUD_OVERWRITEPROTOCOL: ""
    28	NEXTCLOUD_OVERWRITECLIURL: ""
    29	NEXTCLOUD_TRUSTED_DOMAINS: ""
    30	
    31	# SMTP vars
    32	SMTP_HOST: smtp.example.com
    33	SMTP_SECURE: tls # ssl to use SSL, or tls zu use STARTTLS
    34	SMTP_PORT: 587 # (25, 465 for SSL, 587 for STARTTLS)
    35	SMTP_AUTHTYPE: LOGIN
    36	SMTP_NAME: bob@example.com
    37	SMTP_PASSWORD: MailSecret1!
    38	MAIL_FROM_ADDRESS: no-reply@example.com
    39	MAIL_DOMAIN: "@example.com"

Bei den SMTP-Variablen handelt es sich um Beispiel-Werte. Diese müssen an die konkrete Umgebung angepasst werden.

Es folgen nun noch ein paar Variablen, welche dem Pod und dem Nextcloud-Container einen Namen geben, sowie die Version des zu verwendenden Nextcloud-Container-Images festlegen.

    41	# Vars for podman-pod(1)
    42	POD_NAME: nc_pod
    43	POD_PORT: 127.0.0.1:40231:80
    44	POD_INFRA_CONMON_PIDFILE: /tmp/nc_pod_infra.pid
    45	
    46	# Vars for Nextcloud container
    47	NC_CONMON_PIDFILE: /tmp/nc_conmon.pid
    48	NC_IMAGE: docker.io/library/nextcloud:23-apache
    49	NC_NAME: nextcloud

Durch POD_PORT: 127.0.0.1:40231:80 wird definiert, dass der Port 40231 an das Loopback-Interface gebunden und mit Port 80 des Pods verknüpft wird. Mit dieser Einstellung ist die Nextcloud-Instanz nur von dem Host aus erreichbar, auf dem sie ausgebracht wurde. Möchte man sie auch von anderen Hosts aus erreichbar machen, kann man entweder den Teil mit 127.0.0.1: weglassen oder einen Reverse-Proxy wie z.B. NGINX verwenden. Ich empfehle an dieser Stelle letzteres.

Hinweis: In defauts/main.yml stehen Passwörter im Klartext. Diese sind mit der Veröffentlichung der Ansible-Rolle allgemein bekannt und sollten gegen solche ersetzt werden, die geheimgehalten werden. Dies kann z.B. geschehen, in dem man die entsprechenden Variablen in vars/main.yml oder host_vars/hostname neu definiert. Es bietet sich an, diese zusätzlich mit Ansible-Vault zu verschlüsseln.

Die Tasks in tasks/main.yml

Im vorstehenden Abschnitt wurden die Variablen definiert, welche für die nun folgenden Tasks benötigt werden. Diese sind in tasks/main.yml definiert und werden im folgenden wieder abschnittsweise erläutert.

     1	---
     2	# tasks file for ansible_role_deploy_nextcloud_with_mariadb_pod
     3	- name: Main folder, needed for updating
     4	  containers.podman.podman_volume:
     5	    state: present
     6	    name: "{{ NC_HTML }}"
     7	    recreate: no
     8	    debug: no
     9	
    10	- name: Volume for installed/modified apps
    11	  containers.podman.podman_volume:
    12	    state: present
    13	    name: "{{ NC_APPS }}"
    14	    recreate: no
    15	    debug: no
    16	
    17	- name: Volume for local configuration
    18	  containers.podman.podman_volume:
    19	    state: present
    20	    name: "{{ NC_CONFIG }}"
    21	    recreate: no
    22	    debug: no
    23	
    24	- name: Volume for the actual data of Nextcloud
    25	  containers.podman.podman_volume:
    26	    state: present
    27	    name: "{{ NC_DATA }}"
    28	    recreate: no
    29	    debug: no
    30	
    31	- name: Volume for the MySQL data files
    32	  containers.podman.podman_volume:
    33	    state: present
    34	    name: "{{ MYSQL_DATA }}"
    35	    recreate: no
    36	    debug: no

Die ersten Zeilen enthalten Tasks, durch welche die Podman-Volumes zur persistenten Datenspeicherung auf dem Zielsystem erstellt werden. Diese Tasks sind, wie für Ansible üblich, deklarativ und idempotent. Existiert ein Volume bereits, liefert der entsprechende Task ein ‚OK‘ zurück, da keine Aktionen erforderlich sind.

Die folgenden Zeilen erstellen den Podman-Pod und fügen ihm einen Nextcloud- sowie einen MariaDB-Container hinzu. Die Dokumentation der verwendeten Module findet sich in Punkt 5 und 6 im Abschnitt Quellen und weiterführende Links.

    38	- name: Create the podman-pod(1)
    39	  containers.podman.podman_pod:
    40	    debug: no
    41	    infra: yes
    42	    infra_conmon_pidfile: "{{ POD_INFRA_CONMON_PIDFILE }}"
    43	    publish: "{{ POD_PORT }}"
    44	    name: "{{ POD_NAME }}"
    45	    state: started
    46	
    47	- name: Create MariaDB container
    48	  containers.podman.podman_container:
    49	    debug: yes
    50	    conmon_pidfile: "{{ MARIADB_CONMON_PIDFILE }}"
    51	    image: "{{ MARIADB_IMAGE }}"
    52	    image_strict: yes
    53	    pod: "{{ POD_NAME }}"
    54	    recreate: yes
    55	    state: started
    56	    name: "{{ MARIADB_NAME }}"
    57	    env:
    58	      MYSQL_USER: "{{ MYSQL_USER }}"
    59	      MYSQL_PASSWORD: "{{ MYSQL_PASSWORD }}"
    60	      MYSQL_ROOT_PASSWORD: "{{ MYSQL_ROOT_PASSWORD }}"
    61	      MYSQL_DATABASE: "{{ MYSQL_DATABASE }}"
    62	    volume: "{{ MYSQL_DATA }}:/var/lib/mysql:Z"
    63	
    64	- name: Wait for DB to initilize
    65	  wait_for:
    66	    timeout: 20
    67	
    68	- name: Create Nextcloud container
    69	  containers.podman.podman_container:
    70	    debug: no 
    71	    conmon_pidfile: "{{ NC_CONMON_PIDFILE }}"
    72	    image: "{{ NC_IMAGE }}"
    73	    image_strict: yes
    74	    pod: "{{ POD_NAME }}"
    75	    recreate: yes
    76	    state: started
    77	    name: "{{ NC_NAME }}"
    78	    env:
    79	      MYSQL_DATABASE: "{{ MYSQL_DATABASE }}"
    80	      MYSQL_USER: "{{ MYSQL_USER }}"
    81	      MYSQL_PASSWORD: "{{ MYSQL_PASSWORD }}"
    82	      MYSQL_HOST: "{{ MYSQL_HOST }}"
    83	      NEXTCLOUD_ADMIN_USER: "{{ NEXTCLOUD_ADMIN_USER }}"
    84	      NEXTCLOUD_ADMIN_PASSWORD: "{{ NEXTCLOUD_ADMIN_PASSWORD }}"
    85	      NEXTCLOUD_TRUSTED_DOMAINS: "{{ NEXTCLOUD_TRUSTED_DOMAINS }}"
    86	      SMTP_HOST: "{{ SMTP_HOST }}"
    87	      SMTP_SECURE: "{{ SMTP_SECURE }}"
    88	      SMTP_PORT: "{{ SMTP_PORT }}"
    89	      SMTP_AUTHTYPE: "{{ SMTP_AUTHTYPE }}"
    90	      SMTP_NAME: "{{ SMTP_NAME }}"
    91	      SMTP_PASSWORD: "{{ SMTP_PASSWORD }}"
    92	      MAIL_FROM_ADDRESS: "{{ MAIL_FROM_ADDRESS }}"
    93	      MAIL_DOMAIN: "{{ MAIL_DOMAIN }}"
    94	      OVERWRITEPROTOCOL: "{{ NEXTCLOUD_OVERWRITEPROTOCOL }}"
    95	      OVERWRITECLIURL: "{{ NEXTCLOUD_OVERWRITECLIURL }}"
    96	    volume:
    97	      - "{{ NC_HTML }}:/var/www/html:Z"
    98	      - "{{ NC_APPS }}:/var/www/html/custom_apps:Z"
    99	      - "{{ NC_CONFIG }}:/var/www/html/config:Z"
   100	      - "{{ NC_DATA }}:/var/www/html/data:Z"

In Zeile 64-66 habe ich einen Task definiert, der einfach nur 20 Sekunden wartet. Dies wurde erforderlich, da ich Laufzeitprobleme feststellen konnte, wenn der Nextcloud-Container startet, bevor die Datenbank im MariaDB-Container initialisiert war. Dieses Konstrukt ist nicht schön und ich bin für Verbesserungsvorschläge offen.

Zwischenfazit

Die Erstellung der Ansible-Rolle hat länger gedauert, als angenommen. Dies liegt nur zum Teil in meiner spärlichen Freizeit begründet. Einen größeren Einfluss darauf hatte die Dokumentation zum Nextcloud-Repository. Diese geht davon aus, dass man ein Dockerfile bzw. Docker-Compose verwendet. So war noch etwas Internet-Recherche erforderlich, um den Pod letztendlich ans Laufen zu bringen.

Dieser Artikel beschäftigte sich mit den Tag-1-Aufgaben, an deren Ende eine Nextcloud-Instanz ausgebracht wurde, welche an einen Reverse-Proxy angebunden werden kann.

Im nächsten Artikel gehe ich auf die Konfiguration des NGINX-Reverse-Proxy ein. Hierbei habe ich einige Überraschungen erlebt, welche mich an der Reife des Projekts [2] zweifeln lassen.

Quellen und weiterführende Links

1. Nextcloud System Requirements — https://docs.nextcloud.com/server/latest/admin_manual/installation/system_requirements.html
2. Nextcloud (Official Image) — https://hub.docker.com/_/nextcloud
3. MariaDB (Official Image) — https://hub.docker.com/_/mariadb
4. GitHub Tronde/ansible_role_deploy_nextcloud_with_mariadb_pod
5. podman_pod – Manage Podman pods
6. podman_container – Manage podman containers

Herzlich Willkommen zu Teil 4 meines Wochenend-Projekts „Nextcloud im Container“. Diesem gingen die folgenden Teile voraus:

1. Der Plan
2. Die Ansible-Rolle
3. NGINX als Reverse-Proxy

Nach Teil 3 habe ich die Zwei-Faktor-Authentisierung über TOTP für meine Nutzerkonten aktiviert, die Bookmark-, Calendar- und Contact-App installiert bzw. aktiviert, ein paar Kalendertermine erstellt und ein paar Dateien hochgeladen. Nichts Wichtiges. Lediglich ein paar Daten, die ich nach einem Backup zerstören kann, um anschließend den Restore-Prozess zu testen. Zuvor möchte ich aber noch ein paar Dinge festhalten, die mir bisher aufgefallen sind.

Background jobs: Cron does not run

In den Grundeinstellungen der Nextcloud werden Hintergrund-Aufgaben konfiguriert. Diese sind laut des dortigen Hinweises wichtig, um die optimale Geschwindigkeit zu erreichen:

Um die optimale Geschwindigkeit zu erreichen ist es wichtig, dass die Hintergrund-Aktivitäten richtig konfiguriert sind. Für größere Installationen ist ‚Cron‘ die empfohlene Einstellung. Weitere Informationen findest Du in der Dokumentation.

Grundeinstellungen in den Nextcloud-Einstellungen

Die Überschrift ist der Titel des GitHub-Issues #1695. Dieser beschäftigt sich damit, dass Cron in der Container-Instanz nicht läuft. Halt genau so, wie Cron dies bei mir auch nicht tut.

Der Benutzer beryl03, welcher den Issue eröffnet hat, beschreibt, dass Cron in der Container-Instanz nicht verfügbar ist und er in der Dokumentation keinen Hinweis darauf gefunden hat. Um das Problem zu mitigieren hat beryl03 einen Cronjob auf seinem Container-Host konfiguriert, welcher sich mit der Container-Instanz verbindet und darin die Datei cron.php ausführt. Welch elender Workaround. Aber immerhin gibt es einen. Denn die Hintergrund-Aufgaben mit AJAX auszuführen, scheitert leider ebenfalls. Schade, so habe ich mir das tatsächlich nicht vorgestellt.

Im Verlauf von Issue #1695 wird darauf hingewiesen, dass zur Verwendung von Cron ein weiterer Container benötigt wird (siehe [3]). Dies wird in den Beispielen zu den Compose-Dateien beschrieben (siehe [4]). Da ich Podman und Ansible statt Docker-Compose verwende, habe ich mir diese Beispiele natürlich nicht angesehen. Das ist dem Projekt nicht anzulasten, da ich mich ja bewusst für einen anderen Weg entschieden habe. Doch denke ich, dass man das Thema Hintergrund-Aufgaben innerhalb der Projekt-Dokumentation als auch in der Nextcloud-Dokumentation etwas ausführlicher behandeln könnte und sollte. Doch wie gehe ich nun mit dem Problem um, dass meine Hintergrund-Aufgaben nicht ausgeführt werden?

Docker-Compose mit Podman nutzen

Tatsächlich habe ich einen Artikel gefunden, welcher beschreibt, wie man Docker-Compose ab Podman 3.0 nutzen kann. Allerdings bietet dieser nur eine Lösung für den Fall, dass man Podman als User root bzw. mit Root-Rechten ausführt. Da Podman bei mir rootless läuft, kommt die Lösung für mich nicht in Frage.

Nach etwas weiterer Recherche habe ich einen RFE gefunden, welcher diese Funktionalität auch für rootless-Podman fordert. Die gute Nachricht lautet, dass diese Funktion mit Podman 3.2 veröffentlicht wurde. Pech für mich, dass unter Debian stable lediglich Podman 3.0.1 in den Quellen verfügbar ist.

Ein Workaround ist besser als gar keine Lösung

Tatsächlich erscheint mir aktuell der Workaround von beryl03 (siehe [1]) der beste Weg zu sein, um die Hintergrund-Aufgaben ausführen zu lassen. Dazu führe ich auf meinem Container-Host folgenden Befehl aus:

$ podman exec -u 33 -t nextcloud php -f /var/www/html/cron.php

Damit wird das Skript cron.php innerhalb der Container-Instanz mit der Nextcloud ausgeführt. Mit -u 33 wird die UID von www-data innerhalb der Container-Instanz angegeben. Für eine genaue Erklärung des Befehls und seiner Optionen siehe podman-exec(1).

Da ich nicht gern lange Befehle in die Crontab schreibe, erstelle ich ein kurzes Skript namens nextcloud_cron.sh, welches obigen Befehl aufnimmt und welches ich alle 5 Minuten von Cron ausführen lasse. Damit werde ich sich noch sehr lange arbeiten, denn nicht umsonst sagen manche: „Nichts hält so lange, wie ein gutes Improvisorium.“

Fazit von Teil 4

Ich hoffe, die Artikelserie hat euch bis hierhin ein wenig unterhalten. Wer nach einer einfachen Lösung gesucht hat, bei der man ein bis zwei Container-Images aus dem Regal nimmt, ein paar Variablen mit Werten füllt, sie auf einen Container-Host provisioniert, ausführt und fertig ist, wird sicher gemerkt haben, dass er diese Lösung in dieser Artikelreihe nicht findet.

Auch ich habe mir zu Beginn nicht vorgestellt, dass es so hakelig werden würde. Schließlich soll mit Containern doch alles einfacher werden, nicht wahr? Warum mache ich also weiter und lasse das ganze Wochenend-Projekt nicht einfach fallen? Neugier, Sturheit, eine nutzbare Nextcloud-Instanz und auch ein bisschen Spaß bilden die Antwort auf vorstehende Frage. Und deshalb mache ich auch weiter. In Teil 5 wird es um Backup und Restore gehen.

Wie betreibt ihr eure Nextcloud? Mit Container oder ohne? Unter Docker, K3s, K8s, Podman, OpenShift oder einer noch ganz anderen Lösung? Lasst es mich gern in den Kommentaren wissen. Habt ihr über eure Erfahrungen in eurem eigenen Blog geschrieben, lasst mir gern einen Link hier. Macht es gut, bis nächste Woche.

Quellen und weiterführende Links

1. Background jobs: Cron does not run #1695
2. AJAX Background Jobs Fail After a Period of Inactivity #1442
3. https://github.com/nextcloud/docker/issues/1695#issuecomment-1042602441
4. https://github.com/nextcloud/docker/blob/master/.examples/docker-compose/insecure/mariadb/apache/docker-compose.yml
5. Using Podman and Docker Compose. Podman 3.0 now supports Docker Compose to orchestrate containers. Enable Sysadmin. 2021-01-07.
6. [RFE]Make docker-compose work with rootless podman #9169

Diese Frage habe ich mir selbst schon mehrmals gestellt. Und mindestens genauso oft wurde sie mir schon von anderen gestellt. Als Antwort kommen hier meist zuerst telnet oder netcat (nc) in den Sinn. Doch in einer RHEL-Minimal-Installation sind diese beiden Programme nicht enthalten und müssen erst nachinstalliert werden. Was tut man in diesem Fall (ohne den Paketmanager zu starten)?

Ich möchte in diesem Artikel mehrere Antworten auf die Eingangsfrage festhalten. Dabei beginne ich mit denen, die ich auf stackoverflow gefunden habe.

Bash und timeout

Von RHEL 6 aufwärts sollte das Programm timeout in der Minimal-Installation enthalten sein. In Fedora 35 und Debian 11 ist es ebenfalls enthalten. Es stammt aus dem Paket coreutils, in dem es meines Wissens spätestens seit Version 8.22 enthalten ist.

Kommando

$ timeout $TIMEOUT_SECONDS bash -c "</dev/tcp/${HOST}/${PORT}"; echo $?

Beispiele

Erfolgreicher Verbindungstest

$ HOST=beispiel.de
$ PORT=443
$ timeout 5 bash -c "</dev/tcp/${HOST}/${PORT}"; echo $?
0

Selbstverständlich funktioniert auch folgender Befehl:

$ timeout 5 bash -c "</dev/tcp/beispiel.de/443"; echo $?
0

Fehlgeschlagener Verbindungstest

Jetzt nutze ich einen Port, der nicht erreichbar ist:

$ timeout 5 bash -c "</dev/tcp/beispiel.de/4433"; echo $?
124

Nutzung von nc

Sollte nc bereits installiert sein, kann man auch dieses Programm für einen Verbindungstest nutzen:

Kommando

$ nc -w $TIMEOUT_SECONDS -v $HOST $PORT </dev/null; echo $?

Beispiele

Erfolgreicher Verbindungstest

$ HOST=beispiel.de
$ PORT=443
$ nc -w 2 -v $HOST $PORT </dev/null; echo $?
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 23.21.157.88:443.
Ncat: 0 bytes sent, 0 bytes received in 0.54 seconds.
0

Fehlgeschlagener Verbindungstest

$ nc -w 2 -v beispiel.de 4433 </dev/null; echo $?
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: TIMEOUT.
1

Zusammenfassung

Mit timeout und nc habe ich meine beiden Favoriten festgehalten. Mit beiden lässt sich die Erreichbarkeit von entfernten TCP-Ports testen (die von lokalen TCP-Ports übrigens auch).

Falls ihr noch weitere Möglichkeiten kennt, mit Bordmitteln, die in der Minimal-Installation einer Distribution enthalten sind, um einen Verbindungstest durchzuführen, schreibt sie mir gern in die Kommentare. Ich nehme sie dann gern mit in den Artikel auf.

Den allermeisten IT-Systemadministratoren werden die Programme dig, host und nslookup aus dem Paket bind-utils bekannt sein. Sie dienen der Auflösung von Hostnamen. Mir sind jedoch wiederholt Systeme begegnet, auf denen diese Programme nicht zur Verfügung stehen. Dies führte mich zur Eingangsfrage, wie ich Hostnamen auflösen kann, ohne das Paket bind-utils nachinstallieren zu müssen.

Die Antwort liefert der folgende Codeblock. Das Programm getent(1) stammt aus der glibc, welche auf jedem Linux-System vorhanden ist. Voraussetzung ist lediglich, dass das System für die Nutzung von DNS-Resolvern konfiguriert ist (z.B. /etc/resolv.conf).

$ getent hosts beispiel.de
23.21.157.88    beispiel.de

$ getent ahosts my-it-brain.de
2a02:c207:3005:4920::1 STREAM my-it-brain.de
2a02:c207:3005:4920::1 DGRAM  
2a02:c207:3005:4920::1 RAW    
144.91.83.52    STREAM 
144.91.83.52    DGRAM  
144.91.83.52    RAW

Für weitere Abfragemöglichkeiten verweise ich auf die Manpage getent(1).

Herzlich willkommen zu Teil 6 meiner Reihe Nextcloud im Container. Dieser Teil behandelt das Thema Updates. Zum Verständnis empfehle ich, zuerst Teil 1 und Teil 2 zu lesen.

Nun wünsche ich euch viel Spaß beim Lesen und gute Unterhaltung.

Gedanken zum Update

Meine Nextcloud-Instanz läuft in einem Podman-Pod. Das sieht im Terminal wie folgt aus:

$ podman pod ps
POD ID        NAME    STATUS   CREATED       INFRA ID      # OF CONTAINERS
e84bec6108d1  nc_pod  Running  2 months ago  5e52555c5060  3

Dieser Pod besteht aus den folgenden drei Container-Instanzen:

$ podman ps
CONTAINER ID  IMAGE                                  COMMAND               CREATED       STATUS         PORTS                    NAMES
5e52555c5060  k8s.gcr.io/pause:3.2                                         2 months ago  Up 7 days ago  127.0.0.1:40671->80/tcp  e84bec6108d1-infra
c6571aa338ce  docker.io/library/mariadb:10.5.7       mysqld                2 months ago  Up 7 days ago  127.0.0.1:40671->80/tcp  nc_mariadb
21739d36eef1  docker.io/library/nextcloud:23-apache  apache2-foregroun...  2 months ago  Up 7 days ago  127.0.0.1:40671->80/tcp  nextcloud

Diese Container-Instanzen sind zustandslos und ephemeral (engl. für kurzlebig, vergänglich oder flüchtig). Persistent zu speichernde Daten werden außerhalb der Container-Instanzen gespeichert. Diese Eigenschaften erlauben es, Container einfach entfernen und durch neue Instanzen ersetzen zu können.

Um die Nextcloud zu aktualisieren, wird in dieser Umgebung also nicht die Anwendung innerhalb des Containers aktualisiert. Stattdessen werden die Container-Instanzen entfernt und Container-Images mit aktuelleren Versionen der Anwendung und Datenbank instanziiert.

Der Update-Prozess

Die aktuell laufenden Versionen von Nextcloud und MariaDB sind obigen Codeblock zu entnehmen. Diese Images wurden durch die beiden folgenden Zeilen in der Datei {role_path}/defaults/main.yml definiert:

MARIADB_IMAGE: docker.io/library/mariadb:10.5.7
NC_IMAGE: docker.io/library/nextcloud:23-apache

Hier kann man nun die gewünschten Versionen der zu verwendenden Container-Images eintragen. Alternativ kann man die Default-Werte auch durch entsprechende Einträge in {role_path}/vars/main.yml überschreiben. Die Einträge sehen dann bspw. wie folgt aus:

MARIADB_IMAGE: docker.io/library/mariadb:10.5.9
NC_IMAGE: docker.io/library/nextcloud:23.0.3-apache

Nun kann das Playbook mit der Ansible-Rolle aus Teil 2 dieser Reihe erneut ausgeführt werden:

$ ansible-playbook -i hosts deploy_nextcloud.yml --ask-vault-pass                                                 
Vault password:                                                                                                   
                                                                                                                  
PLAY [localhost] **************************************************************************************************
                                                                                                                  
TASK [Gathering Facts] *******************************************************************************************
ok: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Main folder, needed for updating] *************************
ok: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Volume for installed/modified apps] ***********************
ok: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Volume for local configuration] ***************************
ok: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Volume for the actual data of Nextcloud] ******************
ok: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Volume for the MySQL data files] **************************
ok: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Create the podman-pod(1)] *********************************
changed: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Create MariaDB container] *********************************
changed: [localhost]                                                                                               
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Wait for DB to initilize] *********************************
ok: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Create Nextcloud container] *******************************
changed: [localhost]                                                                                               
                                                                                                                  
PLAY RECAP *******************************************************************************************************
localhost                   : ok=10   changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Nun kann man sich auf dem Zielsystem davon überzeugen, dass die neuen Container-Images zur Instanziierung verwendet wurden:

$ podman ps
CONTAINER ID  IMAGE                                      COMMAND               CREATED         STATUS             PORTS                    NAMES
5e52555c5060  k8s.gcr.io/pause:3.2                                             2 months ago    Up 7 days ago      127.0.0.1:40671->80/tcp  e84bec6108d1-infra
248f87e1135b  docker.io/library/mariadb:10.5.9           mysqld                35 seconds ago  Up 36 seconds ago  127.0.0.1:40671->80/tcp  nc_mariadb
59ac1aad168c  docker.io/library/nextcloud:23.0.3-apache  apache2-foregroun...  10 seconds ago  Up 11 seconds ago  127.0.0.1:40671->80/tcp  nextcloud

Fertig. Schon kann Nextcloud in Version 23.0.3 mit einer MariaDB 10.5.9 genutzt werden.

Fazit

Mit diesem Artikel habe ich das letzte noch offene Ziel Nr. 5 „Konfiguration und Test automatischer durch Ansible gesteuerter Updates“ erreicht. Der Update-Prozess folgte dem Container-Paradigma, die Container komplett zu ersetzen und nicht die Anwendung innerhalb der Container zu aktualisieren.

Es handelte sich im dokumentierten Fall um Updates auf ein neues Patch-Release, bei denen das Risiko für Fehler ohnehin sehr gering ist. Ob das Update auch bei Minor- bzw. Major-Releases so gut funktioniert, muss sich noch zeigen. Ich werde diesen Artikel aktualisieren, wenn es Erkenntnisse dazu gibt.

Mit diesem Artikel endet meine Reihe „Nextcloud im Container“. Ich hoffe, ich habe euch damit ein wenig unterhalten und konnte euer Wissen durch die ein oder andere Information erweitern.

Quellen und weiterführende Links

1. Nextcloud im Container – Teil 1: Der Plan
2. Nextcloud im Container – Teil 2: Die Ansible-Rolle
3. Nextcloud im Container — Teil 3: Mit Reverse-Proxy
4. Nextcloud im Container — Teil 4: Hier und da klemmt es
5. Nextcloud im Container – Teil 5: Backup und Restore
6. ansible_role_deploy_nextcloud_with_mariadb_pod auf GitHub
7. Semantic Versioning 2.0.0

In diesem Artikel möchte ich einen Blick auf die Linux Distributionen AlmaLinux und Rocky Linux werfen und sie ihrem Upstream-Projekt Red Hat Enterprise Linux (RHEL) gegenüber stellen. Dabei interessieren mich insbesondere die folgenden Punkte:

1. Wer betreibt das Projekt bzw. steht hinter dem Projekt?
2. Wie finanziert sich das Projekt? Gibt es ein funktionierendes Geschäftsmodell?
3. Welchen Eindruck hinterlässt die Dokumentation?
4. Wie lange wird ein Major-Release unterstützt?
5. Wie viele Tage liegen zwischen einem RHEL-Release und den Releases der beiden Projekte?
6. Wie handhaben die Projekte Sicherheits-Updates?

Aus Gründen der Transparenz weise ich darauf hin, dass ich Mitglied der Red Hat Accelerators Community und System-Administrator diverser RHEL-Server bin. Dieser Text gibt ausschließlich meine persönlichen Ansichten und nicht die von Red Hat oder die meines Arbeitgebers wieder. Zwar können diese in einzelnen Punkten übereinstimmen, müssen es aber nicht.

Was haben beide Projekte gemeinsam?

Sowohl AlmaLinux als auch Rocky Linux sind nach eigener Aussage:

• Produktionsreife Betriebssysteme
• Binärkompatibel zu RHEL
• Werden aus den RHEL-Quelltexten übersetzt
• Für den Nutzer kostenlos
• Bieten 10 Jahre Unterstützung für ein Major-Release

Auch Red Hat bietet 10 Jahre Support auf seine RHEL-Major-Releases (Login erforderlich), an die sich eine Extended Life Phase anschließen kann. Selbstverständlich ist auch RHEL nach eigener Aussage reif für den produktiven Einsatz. Im Unterschied zu AlmaLinux und Rocky Linux kann RHEL jedoch nur zusammen mit einer kostenpflichtigen Subskription sinnvoll betrieben werden. Je nach Größe der Umgebung und Anzahl RHEL-Instanzen können hier beträchtliche Kosten anfallen.

Wer steht hinter den Distributionen?

Bei AlmaLinux handelt es sich um ein Community-Projekt, welches von der Firma CloudLinux Inc. gestartet wurde, welche das Projekt auch mit 1 Mio. USD pro Jahr unterstützt. Entwickelt und gesteuert wird das Projekt durch die Community, zu deren Unterstützung die gemeinnützige AlmaLinux OS Foundation gegründet wurde.

Neben der jährlichen Zuwendung von CloudLinux finanziert sich das Projekt durch diverse Sponsoren.

Die Firma CloudLinux Inc. verfügt selbst über mehr als 10 Jahre Erfahrung in der Pflege eines RHEL-Klons sowie den Betrieb der dazu notwendigen Infrastruktur. Nach eigener Aussage möchte CloudLinux Inc. durch die Unterstützung des Projekts den eigenen Bekanntheitsgrad steigern und hofft auf neue Kunden für das kommerzielle CloudLinux OS und KernelCare.

RHEL wird von der Firma Red Hat entwickelt, welches eines der weltweit erfolgreichsten Open Source Unternehmen ist. Haupteinnahmequelle des Unternehmens ist der Vertrieb von Subskriptionen für RHEL und weitere Produkte aus dem Portfolio. Eine Subskription berechtigt zum Bezug von Software-Aktualisierungen und umfasst kommerziellen Support.

Rocky Linux ist ein Community-Projekt, welches vom CentOS-Mitbegründer Gregory Kurtzer gegründet wurde. Das Projekt verfolgt die gleichen Ziele wie das ursprüngliche CentOS, welches zugunsten von CentOS Stream aufgegeben wurde.

Ähnlich wie AlmaLinux finanziert sich das Projekt durch verschiedene Sponsoren. Wie die Webseite Linuxnews am 16. Mai 2022 berichtete, konnte sich Rocky Linux eine Finanzierung in Höhe von 26 Mio. USD von Google sichern.

Hilfe, Unterstützung und Dokumentation

Wie oben bereits beschrieben haben alle Distributionen ein Unterstützungszeitraum von 10 Jahren. Das heißt, dass ein Major-Release wie AlmaLinux/RHEL/Rocky Linux 8 für einen Zeitraum von 10 Jahren Aktualisierungen in Form von Bug-/Security-Fixes und ausgewählter Verbesserungen erhält. AlmaLinux und Rocky Linux profitieren hier von der Vorarbeit, welche Red Hat für RHEL geleistet hat.

Hilfe für individuelle Probleme, Sorgen, Nöte und Anträge erhält man bei AlmaLinux und Rocky Linux in Foren, Chats und auf Mailinglisten. Darüber hinaus kann man kommerziellen Support für AlmaLinux bei TuxCare einkaufen. Rocky Linux listet CIQ und OpenLogic by Perforce als Support-Anbieter. Red Hat unterhält mit der Red Hat Customer Portal Community ebenfalls einen Bereich mit Disussions-Forum. Darüber hinaus bietet Red Hat im Rahmen seiner Subskriptionen Support direkt vom Hersteller.

Für alle drei Distributionen gibt es also sowohl freie/kostenlose Support-Angebote, als auch kommerzielle Support-Verträge, entweder direkt vom Hersteller oder durch Drittanbieter.

Ob man kommerziellen Support benötigt oder der Community-Support ausreicht, hängt von verschiedenen Faktoren wie z.B. den eigenen Fähigkeiten und nicht zuletzt von der eigenen Risikofreudigkeit ab. Ich persönlich habe die Erfahrung gemacht, dass in Enterprise- bzw. Provider-Umgebungen Probleme auftreten können, die im Hobbykeller, im Verein oder im SoHo ausbleiben und völlig unbekannt sind. In diesen Fällen darf man sich nicht wundern, wenn sich in den Community-Foren niemand findet, der helfen kann. Hier kann ein kommerzieller Support vorteilhaft sein, der auf diese Umgebungen ausgerichtet ist und über mehr Erfahrung in diesem Bereich verfügt.

Ich persönlich bin mit dem Red Hat Support für RHEL zufrieden. Er hat mir schon einige Male bei Problemen und Fragestellungen geholfen, wo ich im Forum vermutlich ohne Antwort geblieben wäre. Die Support-Qualität bei AlmaLinux und Rocky Linux kann ich mangels Erfahrung nicht beurteilen.

Softwareunterstützung

Alle drei betrachteten Distributionen sind zueinander binärkompatibel. Das bedeutet, dass Anwendungen, die unter RHEL ausgeführt werden können, in aller Regel auch unter AlmaLinux und Rocky Linux ausgeführt werden können und umgekehrt.

Software-Hersteller führen in ihren Systemvoraussetzungen häufig unterstützte Betriebssysteme auf. Hier finden sich manchmal nur die kommerziellen Enterprise-Betriebssysteme wie RHEL oder SuSE Linux Enterprise Server (SLES). In solch einem Fall kann es passieren, dass der Software-Hersteller den Support ablehnt, wenn man seine Anwendung auf einem RHEL-Klon ausführt statt auf dem Original. Evtl. verlangt der Hersteller auch nur, dass das Problem unter einem offiziell unterstützten Betriebssystem nachgestellt wird. Dieser Punkte sollte bei der Auswahl einer Distribution mit bedacht werden.

Dokumentation

Red Hat bietet für RHEL eine ausführliche Produkt-Dokumentation und eine umfassende Wissensdatenbank. Zwar ist auch hier nicht alles perfekt, doch hat man dies auch schon deutlich schlechter gesehen. Um die Dokumentation kontinuierlich zu verbessern, bietet Red Hat allen Kunden und Nutzern die Möglichkeit, Dokumentations-Feedback direkt in der Dokumentation zu geben. Aus eigener Erfahrung kann ich berichten, dass gefundene Fehler meist innerhalb weniger Tage behoben werden.

Bei AlmaLinux habe in hinsichtlich Dokumentation auf den ersten Blick nur ein Wiki gefunden, welches auf mich hinsichtlich Gliederung und Umfang einen enttäuschenden Eindruck macht.

Rocky Linux hat ebenfalls ein Wiki und einen gesonderten Bereich für Dokumentation. Auch hier lässt mich die Gliederung etwas verstört und hilflos zurück. Zwar finden sich auf den ersten Blick mehr Anleitungen als bei AlmaLinux, an die RHEL-Dokumentation reicht sie jedoch keinesfalls heran.

Die schwache bis mangelhafte Dokumentation bei AlmaLinux bzw. Rocky Linux mag nicht so sehr ins Gewicht fallen, da man in vielen Fällen einfach die RHEL-Doku zurate ziehen kann. Auch hier profitieren die beiden Projekte wieder von der Vorarbeit des Originals.

Release-Zyklen

Seit RHEL 8 hat sich Red Hat feste Release-Zyklen auferlegt, welche alle 6 Monate ein Minor- bzw. Point-Release und alle 3 Jahre ein Major-Release vorsehen. Da AlmaLinux und Rocky Linux als Downstream-Projekte aus den RHEL-Quelltexten gebaut werden, erscheinen deren Releases stets nach der Veröffentlichung eines RHEL-Release. Die folgende Tabelle gibt einen kleinen Überblick, wann welche Distribution ein Minor-Release veröffentlicht hat.

Release	AlmaLinux	RHEL	Rocky Linux
8.4	2021-05-26	2021-05-18	2021-06-21
8.5	2021-11-12	2021-11-09	2021-11-15
8.6	2022-05-12	2022-05-10	2022-05-16
9 beta	2022-04-19	2021-11-03	N/A
9.0 GA	2022-05-26	2022-05-18	2022-07-14

Bisher folgen die Releases von AlmaLinux und Rocky Linux in der Regel wenige Tage auf das RHEL-Release. Beim Major-Release 9 hing RockyLinux ca. 1,5 Monate hinterher.

Bereitstellung von Sicherheits-Updates

Alle drei Projekte stellen Produkt-Errata im Internet bereit:

• AlmaLinux Product Errata – https://errata.almalinux.org/
• Red Hat Product Errata – https://access.redhat.com/errata
• Rocky Linux Product Errata – https://errata.rockylinux.org/

Dabei werden Errata in Bugfix-, Enhancement- und Security-Advisory unterschieden.

Während Bugs und fehlende Funktionalität störend und ärgerlich sein können, stellt die schnelle Verfügbarkeit von Sicherheits-Updates einen kritischen Faktor dar, um Sicherheitslücken zeitnah schließen zu können. Nach Aussage von AlmaLinux werden Errata bei AlmaLinux und Rocky Linux mit einem Geschäftstag Verzögerung in Bezug auf das RHEL-Errata-Release veröffentlicht. Ob beide Projekte dies durchhalten können, werde ich in der Zukunft stichprobenartig kontrollieren.

Mein Open-Source-Projekt Ansible: Patch-Management für Red Hat Systeme nutzt die Red Hat Security Advisories, um sogenannte Patch-Sets zu definieren, welche zu bestimmten Stichtagen installiert werden. Es ist darauf angewiesen, dass Errata-Informationen als Meta-Informationen in den Paket-Repositorien verfügbar sind. Bei CentOS fehlten diese, sodass mein Patch-Management für CentOS nicht nutzbar ist.

Daher bin ich sehr erfreut, dass AlmaLinux und Rocky Linux diese Meta-Informationen ebenfalls in ihren Repositorien bereitstellen. Prinzipiell sollte mein Patch-Management auch mit diesen beiden Distributionen funktionieren. Ein Test steht jedoch noch aus.

Zusammenfassung

Mit AlmaLinux und Rocky Linux gibt es zwei von einer Gemeinschaft entwickelte binärkompatible RHEL-Klone, welche von unterschiedlichen Unternehmen unterstützt und gesponsort werden. Erste Unternehmen bieten kommerziellen Support für diese Distributionen an.

Mir fällt positiv auf, dass beide Projekte in ihren Repos Errata-Informationen wie z.B. ALSA oder RLSA bereitstellen. Dies erleichtert die gezielte Installation von sicherheitsrelevanten Aktualisierungen. Hier bieten beide Projekte mehr, als es CentOS in der Vergangenheit tat.

Die Dokumentation scheint bei beiden Projekten keine große Rolle zu spielen. Ich empfinde sie als unübersichtlich und lückenhaft. Hier kann man jedoch vermutlich auf die Dokumentation des Originals (RHEL) zurückgreifen, welche sich mit sehr geringer Transferleistung auch für AlmaLinux und Rocky Linux nutzen lässt.

Auf den ersten Blick scheint es sich sowohl bei AlmaLinux als auch bei Rocky Linux um zwei solide Distributionen für alle jene zu handeln, die sich RHEL nicht leisten können oder wollen.

Wer Red Hat Enterprise Linux (RHEL) betreiben möchte, benötigte dazu eine sogenannte Subskription, im Folgenden RHEL-Sub genannt. Die Kosten für eine RHEL-Sub ergeben sich aus der Art der RHEL-Sub und dem damit verbundenen Service-Level. Der schon etwas ältere Artikel Support-Subskriptionen von SUSE und Red Hat gibt hierzu einen kleinen Einblick.

Da RHEL-Klone wie AlmaLinux und Rocky Linux kostenlos verfügbar sind, kommt schnell die Frage auf: „Warum soll ich für RHEL soviel Geld bezahlen, wenn ich quasi das gleiche OS unter anderem Namen kostenlos nutzen kann?“

Um bei der Beantwortung dieser Frage zu helfen, stelle ich in diesem Artikel einige potenzielle Mehrwerte vor, die man mit dem Erwerb einer RHEL-Sub erhält.

Aus Gründen der Transparenz weise ich darauf hin, dass ich Mitglied der Red Hat Accelerators Community und System-Administrator diverser RHEL-Server bin. Dieser Text gibt ausschließlich meine persönlichen Ansichten und nicht die von Red Hat oder die meines Arbeitgebers wieder. Zwar können diese in einzelnen Punkten übereinstimmen, müssen es aber nicht.

Kostenlose RHEL-Subs

Nicht alle RHEL-Subs kosten Geld. Es gibt auch zwei Subskriptionen, mit denen sich RHEL und bestimmten Rahmenbedingungen kostenlos betreiben lässt.

Red Hat Developer Subscription for Individuals

Ein jeder kann über das Red Hat Developers Program (engl.) kostenlos eine persönliche RHEL Developer Subscription (engl.) erhalten. Mit dieser Sub erhält der Besitzer das Recht, bis zu 16 Systeme (physisch oder virtuell) zu betreiben; auch in Produktion.

Die Subskription muss jedes Jahr verlängert werden. Die Verlängerung ist ebenfalls kostenlos.

Die Subskription beinhaltet keinen kommerziellen Support. Man hat lediglich Zugriff auf die Wissensdatenbank und die Customer Portal Community. Die SaaS-Dienste Red Hat Insights und Image Builder können auch mit dieser Subskription genutzt werden.

Red Hat Developer Subscription for Teams

Im Unterschied zur oben vorgestellten individuellen Subskription dürfen Systeme mit der RHEL-Sub-for-Teams nicht in Produktion betrieben werden. Sie dient ausschließlich der Entwicklung, dem Test und der Qualitätssicherung. Dafür dürfen mit dieser Sub eine sehr große Anzahl RHEL-Systeme provisioniert werden.

Ich bin mir nicht sicher, ob ich eine genaue Zahl nennen darf. Darum glaubt mir bitte, wenn ich euch sage: „Es sind wirklich eine Menge Berechtigungen für physische und virtuelle Systeme enthalten.“

Diese Subskription erhaltet ihr nur über euer Red Hat Account Management. Falls ihr dieses (noch) nicht kennt, wendet euch im Zweifel an die Firma, wo ihr eure RHEL-Subs kauft.

Mich selbst hat es einige Mühen gekostet, an diese Sub zu kommen. Laut Aussage meines Account-Managers war ich der erste Kunde in Deutschland, der diese Sub kannte und haben wollte. Dank der Red Hat Accelerators und meines Account-Managers, der nicht aufgegeben hat, hat es schlussendlich geklappt. Falls ihr Probleme habt, diese Sub zu bekommen, schreibt mich einfach an. Vielleicht habe ich noch einen Tipp für euch.

Für den Support, Zugriff auf Red Hat Insights und Image Builder gelten die gleichen Bedingungen wie für die RHEL Developer Subscription for Individuals.

Support

Support meint an dieser Stelle nicht die Hilfe und Unterstützung, die man auf Mailinglisten, in Foren oder Chats erhalten kann. Gemeint ist ausschließlich der kommerzielle Support der Firma Red Hat, welchen man per Telefon, E-Mail oder das Customer Portal erreichen kann.

Über den Support hat man Kontakt zu den Menschen, die sich vermutlich am besten mit dem Produkt auskennen. Hier sitzen Menschen, die dafür bezahlt werden, uns Kunden bestmöglich zu unterstützen. Dabei mag es von Fall zu Fall Schwankungen in der Reaktionszeit und/oder der Qualität geben.

Mir persönlich hat der Support schon in etlichen Fragestellungen und bei einigen hartnäckigen Problemen weiterhelfen können. Dabei waren so schöne Dinge wie Kernel Panic bei Zugriff auf eine eingehängte DFS-Ressource, deren Shares in einer HNAS-Speicher-Infrastruktur liegen. Ich glaube, sowas haben die wenigsten Menschen bei sich daheim im Keller stehen. Und die Chance, bei diesem Problem Hilfe in einem Forum oder Chat zu finden, dürfte dementsprechend gering sein. Der Support stellte in diesem Fall Kontakt zu einem Engineer her, der über eine hervorragende Kenntnis der beteiligten Protokolle und Protokollversionen verfügte und beim Debugging unterstützte. Am Ende erhielten wir einen angepassten Kernel, der das Problem löste und den wir nutzen konnten, bis das Problem auch Upstream und im regulären RHEL-Kernel gefixt wurde.

Nicht zuletzt ist kommerzieller Support ein guter Verbündeter, wenn man selbst nicht weiterweiß und sich Druck aufbaut. Nach dem Motto: „Wenn selbst der Hersteller nicht weiter weiß, woher soll ich dann wissen, warum es nicht geht?“ Es ist nie schön, wenn es soweit kommt. Noch hässlicher wird es, wenn man dann nicht auf jemand anderen zeigen kann.

Red Hat Insights

Zu Red Hat Insights (engl.) habe ich in der Vergangenheit bereits eine eigene Serie geschrieben, auf die ich an dieser Stelle verweise:

1. Einführung in Red Hat Insights
2. Erkundung von Red Hat Insights — Advisor
3. Schwachstellen-Management mit Red Hat Insights
4. Red Hat Insights – Compliance
5. Red Hat Insights – Patch and Drift
6. Persönliche Bewertung von Red Hat Insights

Dieser Dienst steht auch mit den kostenlosen Developer-Subs zur Verfügung. Vorausgesetzt, die Nutzung ist unter geltendem Recht möglich, stellt dieser Dienst einen echten Mehrwert dar. Ein vergleichbarer Dienst existiert für AlmaLinux und Rocky Linux nicht.

Image Builder (SaaS)

In größeren Umgebungen (IHMO >2 Systeme) werden Server meist nicht mehr individuell installiert, sondern von sogenannten Images oder Templates provisioniert. Diese sind initial zu erstellen und fortlaufend zu pflegen.

Image Builder ist ein SaaS-Dienst in Red Hat Insights, welcher bei der Erstellung solcher Templates unterstützt. Dabei können Images direkt für die Cloud Anbieter Amazon Web Services, Google Cloud Platform, Microsoft Azure, VMware vSphere, KVM/QEMU (.qcow2) und Bare Metal erstellt werden.

Es handelt sich dabei um einen noch recht jungen Dienst, der einige Einschränkungen hat. So ist das einzige derzeit unterstützte Dateisystem für Images XFS. Ein RFE, um Ext4 als unterstütztes Dateisystem hinzuzufügen, ist gestellt.

Auch lassen sich aktuell über diesen Dienst noch keine User oder SSH-Public-Keys in die Images integrieren. Für diese Funktionalität habe ich ebenfalls bereits RFEs geschrieben.

Ich bin gespannt, wie Red Hat diesen Dienst weiterentwickelt. In meinen Augen hat er das Potenzial, zu einem nützlichen Werkzeug zu reifen.

Diesen Dienst kann man ebenfalls mit den kostenlosen Developer-Subs nutzen, während ein vergleichbarer Dienst meines Wissens für AlmaLinux und Rocky Linux nicht existiert.

Fazit

Ob die genannten Mehrwerte tatsächlich zum Tragen kommen, muss jeder für sich und seine Organisation selbst beurteilen. Sie sollten jedoch vor einer Entscheidung in die Überlegungen mit einbezogen werden.

Die Nutzung von Red Hat Insights ist in unserem Rechtsraum schwierig, bis nahezu unmöglich. Dort wo der Dienst genutzt werden kann, stellt er ein gutes Werkzeug dar, welches dem Admin die tägliche Arbeit erleichtert.

Ich werde ein kleines Heimlabor aus RHEL-Servern aufbauen und diese in Red Hat Insights integrieren. Vielleicht gewinne ich dadurch Erkenntnisse, die sich auch auf den Betrieb im Rechenzentrum übertragen lassen.

Der Image Builder ist als SaaS in seiner jetzigen Form nur von geringem Nutzen für mich. Ich hoffe, dass meine RFEs akzeptiert und umgesetzt werden, um diesen Service und dessen Nutzen weiter auszubauen.

Ein Freund bat mich kürzlich um meine Meinung zum Thema Software-Verteilung und Dokumentation des Installations- bzw. Bereitstellungsprozesses. Die Gedanken, die ich mir dazu gemacht habe, möchte ich an dieser Stelle mit euch teilen. Dabei schreibe ich aus dem Blickwinkel eines Systemintegrators, der von Dritten erstellte Software integrieren und betreiben muss.

Den Anwendungsentwicklern, Software-Architekten und Produkt-Managern unter euch soll dieser Text als Information dienen, was ich und ggf. weitere Personen meiner Zunft von einer Dokumentation erwarten bzw. wie wir uns Software-Verteilungsprozesse vorstellen.

Als Leser seid ihr alle eingeladen, eure Gedanken ebenfalls zu teilen und eine Diskussion zu diesem Thema zu führen.

Das Szenario

Ich habe bei meinen Gedanken ein Szenario im Kopf, in dem ein Anwendungsentwickler eine Anwendung in einer Sprache seiner Wahl schreibt. Diese Anwendung soll später über ein Web-Frontend erreichbar und nutzbar sein. Die Anwendung benötigt eine Datenbank, um Informationen darin abzulegen. Binärdateien werden ggf. außerhalb der Datenbank in einem Dateisystem gespeichert.

Die Anwendungsentwickler freuen sich, wenn ihre Software einen hohen Verbreitungsgrad erreicht. Dazu muss die dazugehörige Dokumentation folgende Informationen bieten.

Werkzeuge zum Erstellen und Ausführen der Anwendung

• Welcher Compiler ab welcher Version wird benötigt?
• Welche Bibliotheken werden ab welcher Version benötigt?
• Sind abweichende Versionen möglich oder funktioniert nur genau eine?
• Welche Laufzeitumgebung wird benötigt?
• Was ist in welcher Reihenfolge zu tun, um vom Quelltext zu einem ausführbaren Programm zu kommen?

Voraussetzungen zur Integration der Anwendung

• Wird eine Datenbank benötigt?
• Welche Datenbank-Management-Systeme werden unterstützt?
• Ab welcher Version?
• Über welche Rechte muss ein DB-User mindestens verfügen, damit der Anwendungs-Installer die notwendigen Tabellen, Views, etc. erstellen kann?
• Welche Webserver werden unterstützt?
• Welche Protokolle, Parameter bzw. Optionen sind für die Kommunikation mit der Anwendung notwendig?

Ich bin immer enttäuscht, wenn hier auf ein einziges System eingeschränkt wird. Dies limitiert unnötig den Nutzerkreis.

• Wird ein Snakeoil-Zertifikat mitgeliefert oder hat der Systemintegrator dieses beizustellen? Eigene Zertifikate auf Wunsch verwenden zu können ist obligatorisch.

Die bis jetzt genannten Informationen müssen so umfassend sein, dass Paketbetreuer bzw. Software-Paketierer daraus Debian-, Flatpak-, RPM-, Snap-Pakete, Container-Images und Windows-Installer bauen können.

Nehmen die Anwendungsentwickler in Personalunion die Rolle von Software-Paketierern wahr, scheint es dennoch unrealistisch, dass sie allein alle Formate unterstützen können. Sie sollten sich für einige wenige Formate entscheiden, die auf möglichst vielen Plattformen lauffähig sind. In dem von mir gedachten Szenario sind dies OCI-kompatible Container-Images.

Bei einer GUI-Anwendung würde ich mich vermutlich für Flatpak entscheiden. Die Paketierung als DEB oder RPM würde ich auf jeden Fall den Paketbetreuern der jeweiligen Distributionen überlassen.

Systemintegration

Für den Systemintegrator, welcher den Webserver, die Anwendung und die Datenbank zusammenbringt (integriert), muss klar beschrieben werden:

• Gibt es ein fertiges Container-Image? Wo bekommt man es her?
• Optional: Wie erstellt man das Container-Image selbst?
• Welche (Umgebungs-)Variablen gehören zum Image? Welche Werte können diese annehmen?
• Ein Kommunikationsdiagramm, damit der Sysadmin weiß, was wann mit wem spricht und welche Firewall-Regeln evtl. benötigt werden.

Referenzimplementierungen sind ebenfalls schön. Diese sollten für Docker, Docker-Compose, Kube-YAML (K8s) und Podman bereitstehen. Die Doku zum Container-Image muss jedoch so ausgestaltet sein, dass auch ohne Referenzimplementierung die Instanziierung mit den verschiedenen Engines und Orchestrierern gelingen kann.

Was Sysadmins (wie ich) nicht mögen

Ich mag es nicht, wenn in den Abhängigkeiten ein Webserver (Apache, NGINX, lighttpd) oder ein Datenbank-Management-System unnötig hart verdrahtet ist. Gleiches gilt für die Festlegung der zu verwendenden Container-Registries. Ich will dem Installer sagen können, wo er die Images findet und nicht auf den Dockerhub festgelegt werden.

Und ja, mir ist bewusst, dass eine gute Dokumentation genauso viel Aufwand und Pflege bedeutet wie der Quelltext einer Anwendung selbst. Aber ist es eine Alternative, wenn Systemintegratoren die Anwendung nach dem ersten Installationsversuch hassen?

Eure Meinung ist willkommen

Wie steht ihr als Entwickler zum Thema Dokumentation? Was erwartet ihr als Sysadmin und User von ihr?

Stimmt ihr mit mir überein oder habt ihr ganz andere Ansichten dazu? Nutzt gern die Kommentarfunktion und lasst es mich wissen.

Der folgende Text dient mir als Dokumentation. Ich halte darin fest, wie ich LVs von einer VG in eine andere VG verschiebe und die Partitionstabelle der Festplatte mit der Quell-VG bearbeite. Der Verschiebe-Vorgang setzt sich dabei aus den zwei Vorgängen Kopieren und Löschen zusammen.

Der Text mag euch unterhalten und ggf. könnt ihr darauf zurückgreifen, wenn ihr ähnliche Arbeiten an euren Linux-Dateisystemen plant. Euch erwartet jedoch kein Tutorial, das in einzelne Themen oder Programme einführt. Falls ihr von hieran weiterlest, wünsche ich euch viel Spaß mit dem Text.

Ausgangslage

Es geht um meinen Desktop-PC. Dieser besitzt neben einer Geschichte auch einige Altlasten. Nun ist mir meine /boot-Partition zu klein. Da der Platz hinter der Partition jedoch von einer LUKS-verschlüsselten Partition mit LVM belegt ist, muss ich hier erst Platz schaffen, um die /boot-Partition vergrößern zu können.

Folgender Code-Block gibt einen Überblick über die Block-Geräte meines PCs, die darauf befindlichen Partitionen sowie deren Einhängepunkte in /etc/fstab und /etc/crypttab. Identifizierende Merkmale wie UUIDs wurden gekürzt, verändert oder Platzhalter an ihrer Stelle verwendet.

$ lsblk
NAME                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                             8:0    0 931,5G  0 disk  
└─sdb_crypt                   253:4    0 931,5G  0 crypt 
  └─tower--pc--vg2-lv--images 253:5    0   360G  0 lvm   /var/lib/libvirt/images
sdb                             8:16   0 238,5G  0 disk  
├─sdb1                          8:17   0   243M  0 part  /boot
├─sdb2                          8:18   0     1K  0 part  
└─sdb5                          8:21   0 238,2G  0 part  
  └─sda5_crypt                253:0    0 238,2G  0 crypt 
    ├─tower--pc--vg-root      253:1    0  27,9G  0 lvm   /
    ├─tower--pc--vg-swap_1    253:2    0     4G  0 lvm   [SWAP]
    └─tower--pc--vg-home      253:3    0 204,3G  0 lvm   /home
sr0

$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/tower--pc--vg-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda1 during installation
UUID=a3809eb1-fc3d191e2ae9 /boot           ext2    defaults        0       2
/dev/mapper/tower--pc--vg-home /home           ext4    defaults        0       2
/dev/mapper/tower--pc--vg-swap_1 none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

# 1 TB SSD SANDisk
/dev/mapper/tower--pc--vg2-lv--images	/var/lib/libvirt/images	ext4	defaults	0	0

$ cat /etc/crypttab 
sda5_crypt UUID=07f0d6c5-257591190166 none luks,discard
sdb_crypt UUID="e605980c-307daf28b717" none luks,discard

$ sudo blkid
/dev/sdb1: UUID="a3809eb1-fc3d191e2ae9" BLOCK_SIZE="1024" TYPE="ext2" PARTUUID="6ee39e6a-01"
/dev/sdb5: UUID="07f0d6c5-257591190166" TYPE="crypto_LUKS" PARTUUID="6ee39e6a-05"
/dev/sda: UUID="e605980c-307daf28b717" TYPE="crypto_LUKS"
/dev/mapper/sda5_crypt: UUID="AZKTuQ-rVeB5S" TYPE="LVM2_member"
/dev/mapper/tower--pc--vg-root: UUID="be0ff8fd-7aee7ce75f3b" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/tower--pc--vg-swap_1: UUID="90823267-b6828aeca9b9" TYPE="swap"
/dev/mapper/tower--pc--vg-home: UUID="d410241d-04214b690522" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/sdb_crypt: UUID="Ff4Lt0-RKJrGd" TYPE="LVM2_member"
/dev/mapper/tower--pc--vg2-lv--images: UUID="3af3b461-cdd7b2bc9710" BLOCK_SIZE="4096" TYPE="ext4"

Ziel

Mein Ziel ist, die /boot-Partition auf 2 GB zu vergrößern, ohne das System neuinstallieren zu müssen oder die Daten in den vorhandenen Partitionen zu verlieren.

Mögliche Vorgehensweisen

Bei meiner Internet-Recherche bin ich auf folgende Lösungsmöglichkeiten gestoßen:

• Move a logical volume from one volume group to another (StackExchange)
• How to move / copy logical volume (lv) to another volume group (vg)? (askUbuntu)
• Resizing LVGrub NeukonfigurierenM-on-LUKS (ArchWiki)

Wenn man diese Diskussionen und den Wiki-Artikel liest, erkennt man, dass es mehrere Wege zum Ziel gibt. Ich habe mich für folgendes Vorgehen entschieden, da es auf mich den Eindruck macht, unkompliziert zu sein und nur ein geringes Risiko für Datenverlust birgt:

1. Datensicherung
2. LUKS-Devices umbenennen
3. LV und Dateisystem der /home-Partition verkleinern
4. Neue LVs in zweiter VG erstellen
5. Partitionen mit partclone kopieren
6. Grub Neukonfigurieren (2x)

Schritt 1: Datensicherung durchführen

Bevor ich irgendwelche Änderungen an der Partitionstabelle von /dev/sdb durchführe, erstelle ich eine Datensicherung. Dazu verwende ich die freie Software Clonezilla, um die Partitionen von /dev/sdb in eine Image-Datei auf einer externen Festplatte zu sichern.

Das Programm ist einfach in der Bedienung und ermöglicht mir im Fehlerfall, die Partitionen der zu bearbeitenden Festplatte wiederherzustellen.

Schritt 2: LUKS-Devices umbenennen

Im IST-Zustand befindet sich das LUKS-Device sdb_crypt auf dem Gerät /dev/sda, während sich sda5_crypt auf dev/sdb5 befindet. Dies ist unschön und lässt sich wie folgt ändern:

root:~# dmsetup rename sda5_crypt sd_temp
root:~# dmsetup rename sdb_crypt sda5_crypt
root:~# dmsetup rename sd_temp sdb_crypt

Nun wird die Datei /etc/crypttab entsprechend angepasst (vgl. mit IST-Zustand):

root:~# cat /etc/crypttab 
sdb_crypt UUID=07f0d6c5-257591190166 none luks,discard
sda5_crypt UUID="e605980c-307daf28b717" none luks,discard

Damit die Partitionen beim Start des Rechners korrekt entschlüsselt und eingebunden werden, wird abschließend initramfs aktualisiert:

root:~# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-5.10.0-15-amd64
update-initramfs: Generating /boot/initrd.img-5.10.0-13-amd64

Nach einem Neustart ergibt sich das gewünschte Bild:

$ lsblk
NAME                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                             8:0    0 931,5G  0 disk  
└─sda5_crypt                  253:4    0 931,5G  0 crypt 
  └─tower--pc--vg2-lv--images 253:5    0   360G  0 lvm   /var/lib/libvirt/images
sdb                             8:16   0 238,5G  0 disk  
├─sdb1                          8:17   0   243M  0 part  /boot
├─sdb2                          8:18   0     1K  0 part  
└─sdb5                          8:21   0 238,2G  0 part  
  └─sdb_crypt                 253:0    0 238,2G  0 crypt 
    ├─tower--pc--vg-root      253:1    0  27,9G  0 lvm   /
    ├─tower--pc--vg-swap_1    253:2    0     4G  0 lvm   [SWAP]
    └─tower--pc--vg-home      253:3    0 204,3G  0 lvm   /home

Schritt 3: LV und Dateisystem der /home-Partition verkleinern

Meine /home-Partition ist mir mit 204 GB etwas groß geraten. Daher möchte ich sie um 100 GB verkleinern. Um das Dateisystem verkleinern zu können, darf die Partition nicht eingehängt sein. Um die folgenden Schritte durchzuführen, nutze ich diesmal das Linux-System System Rescue. Dabei handelt es sich um ein Live-System, mit jeder Menge Werkzeugen, um einen (beschädigten) Rechner zu bearbeiten.

Der folgende Code-Block zeigt, wie zuerst das verschlüsselte LUKS-Device geöffnet und anschließend das LV der /home-Partition verkleinert wird. Der dabei verwendete Befehl führt die Verkleinerung des Dateisystems und des LV in einem Schritt aus:

# LUKS-Device öffnen
# cryptsetup open <device> <name> --type <device_type> see cryptsetup(8)

root@sysrescue ~]# cryptsetup open /dev/sda5 crypt_disk --type luks2
Enter passphrase for /dev/sda5: 
[root@sysrescue ~]# lsblk
NAME                       MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
loop0                        7:0    0 647.7M  1 loop  /run/archiso/sfs/airootfs
sda                          8:0    0 238.5G  0 disk  
├─sda1                       8:1    0   243M  0 part  
├─sda2                       8:2    0     1K  0 part  
└─sda5                       8:5    0 238.2G  0 part  
  └─crypt_disk             254:0    0 238.2G  0 crypt 
    ├─tower--pc--vg-root   254:1    0  27.9G  0 lvm   
    ├─tower--pc--vg-swap_1 254:2    0     4G  0 lvm   
    └─tower--pc--vg-home   254:3    0 204.3G  0 lvm   
sdb                          8:16   0 931.5G  0 disk

# Dateisystem und LV in einem Schritt verkleinern
# Aufgrund der gewählten Größe dauert dieser Vorgang einige Minuten
# lvresize --size [+|-]Size[m|UNIT] --resizefs <lv name> see lvresize(8)

[root@sysrescue ~]# lvresize --size -100G --resizefs /dev/tower-pc-vg/home 
fsck from util-linux 2.38
/dev/mapper/tower--pc--vg-home: Inode 393223 extent tree (at level 1) could be narrower.  IGNORED.
/dev/mapper/tower--pc--vg-home: Inode 12847282 extent tree (at level 1) could be narrower.  IGNORED.
/dev/mapper/tower--pc--vg-home: 20959/13393920 files (1.2% non-contiguous), 14367863/53551104 blocks
resize2fs 1.46.5 (30-Dec-2021)
Resizing the filesystem on /dev/mapper/tower--pc--vg-home to 27336704 (4k) blocks.
The filesystem on /dev/mapper/tower--pc--vg-home is now 27336704 (4k) blocks long.

  Size of logical volume tower-pc-vg/home changed from 204.28 GiB (52296 extents) to 104.28 GiB (26696 extents).
  Logical volume tower-pc-vg/home successfully resized.

[root@sysrescue ~]# lsblk
NAME                       MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
loop0                        7:0    0 647.7M  1 loop  /run/archiso/sfs/airootfs
sda                          8:0    0 238.5G  0 disk  
├─sda1                       8:1    0   243M  0 part  
├─sda2                       8:2    0     1K  0 part  
└─sda5                       8:5    0 238.2G  0 part  
  └─crypt_disk             254:0    0 238.2G  0 crypt 
    ├─tower--pc--vg-root   254:1    0  27.9G  0 lvm   
    ├─tower--pc--vg-swap_1 254:2    0     4G  0 lvm   
    └─tower--pc--vg-home   254:3    0 104.3G  0 lvm   
sdb                          8:16   0 931.5G  0 disk

Zur Sicherheit führe ich noch eine Dateisystemüberprüfung aus:

[root@sysrescue ~]# fsck -t ext4 /dev/mapper/tower--pc--vg-home
fsck from util-linux 2.38
e2fsck 1.46.5 (30-Dec-2021)
/dev/mapper/tower--pc--vg-home: clean, 20959/6840320 files, 13956503/27336704 blocks

Da alles in Ordnung ist, fahre ich mit dem nächsten Schritt fort. Dazu nutze ich weiterhin die System Rescue Umgebung.

Schritt 4: LVs in zweiter VG erstellen

Da ich für die folgenden Vorgänge Zugriff auf die zweite VG benötige, öffne ich zuerst das LUKS-Device, in dem sich diese befindet:

[root@sysrescue ~]# cryptsetup open /dev/sdb crypt_disk2 --type luks2

Nun erstelle ich drei neue LVs, welche den Inhalt der existierenden LVs root, swap_1 und home aufnehmen sollen. Die Ziel-LVs müssen dazu mindestens gleich groß oder größer als die Quell-LVs sein. Um die erforderliche Größe zu ermitteln, lasse ich mir die Größe der Quell-LVs in Byte anzeigen. Ich wähle bewusst die Einheit Byte, da die Ausgabe bei größeren Einheiten auf zwei Nachkommastellen gerundet wird und ich mir keine Probleme durch die Rundung einhandeln möchte.

# Es werden nur die relevanten Informationen wiedergegeben
root:~# lvdisplay --unit b
LV Path                /dev/tower-pc-vg/root
LV Name                root
VG Name                tower-pc-vg
...
LV Size                29997662208 B
-----
LV Path                /dev/tower-pc-vg/swap_1
LV Name                swap_1
VG Name                tower-pc-vg
...
LV Size                4290772992 B
-----
LV Path                /dev/tower-pc-vg/home
LV Name                home
VG Name                tower-pc-vg
...
LV Size                111971139584 B

Mit diesen Informationen erstelle ich die neuen LVs in der zweiten VG:

:~# lvcreate --size 29997662208B /dev/tower-pc-vg2 --name root
  Logical volume "root" created.
:~# lvcreate --size 4290772992B /dev/tower-pc-vg2 --name swap_1
  Logical volume "swap_1" created.
:~# lvcreate --size 111971139584B /dev/tower-pc-vg2 --name home
  Logical volume "home" created.

Schritt 5: Partitionen mit partclone kopieren

Für diesen Schritt nutze ich die freie Anwendung Partclone. Da meine LVs weiterhin ausgehängt sind, muss ich mir um Schreib-Zugriffe anderer Prozesse während des Kopiervorgangs keine Sorgen machen:

# Manpage partclone(8)
# partclone.<fs_type> --dev-to-dev --source <Quelle> --output <Ziel>

[root@sysrescue ~]# partclone.ext4 --dev-to-dev --source /dev/tower-pc-vg/root --output /dev/tower-pc-vg2/root 
Partclone v0.3.20 http://partclone.org
Starting to back up device(/dev/tower-pc-vg/root) to device(/dev/tower-pc-vg2/root)
Elapsed: 00:00:01, Remaining: 00:00:00, Completed: 100.00%                      
Total Time: 00:00:01, 100.00% completed!
done!
File system:  EXTFS
Device size:   30.0 GB = 7323648 Blocks
Space in use:  20.8 GB = 5078551 Blocks
Free Space:     9.2 GB = 2245097 Blocks
Block size:   4096 Byte
Elapsed: 00:03:16, Remaining: 00:00:00, Completed: 100.00%, Rate:   6.37GB/min, 
current block:    7323648, total block:    7323648, Complete: 100.00%           
Total Time: 00:03:16, Ave. Rate:    6.4GB/min, 100.00% completed!
Syncing... OK!
Partclone successfully cloned the device (/dev/tower-pc-vg/root) to the device (/dev/tower-pc-vg2/root)
Cloned successfully.

[root@sysrescue ~]# partclone.ext4 --dev-to-dev --source /dev/tower-pc-vg/home --output /dev/tower-pc-vg2/home 
Partclone v0.3.20 http://partclone.org
Starting to back up device(/dev/tower-pc-vg/home) to device(/dev/tower-pc-vg2/home)
Elapsed: 00:00:01, Remaining: 00:00:00, Completed: 100.00%                      
Total Time: 00:00:01, 100.00% completed!
done!
File system:  EXTFS
Device size:  112.0 GB = 27336704 Blocks
Space in use:  57.2 GB = 13956503 Blocks
Free Space:    54.8 GB = 13380201 Blocks
Block size:   4096 Byte
Elapsed: 00:12:22, Remaining: 00:00:00, Completed: 100.00%, Rate:   4.62GB/min, 
current block:   27336704, total block:   27336704, Complete: 100.00%           
Total Time: 00:12:22, Ave. Rate:    4.6GB/min, 100.00% completed!
Syncing... OK!
Partclone successfully cloned the device (/dev/tower-pc-vg/home) to the device (/dev/tower-pc-vg2/home)
Cloned successfully.

Die SWAP-Partition enthält keine Daten, die kopiert werden müssen. Hier formatiere ich das neue LV einfach als SWAP-Partition:

[root@sysrescue ~]# mkswap /dev/tower-pc-vg2/swap_1
Setting up swapspace version 1, size = 4 GiB (4290768896 bytes)
no label, UUID=f9181521-a06da5b8ade5

Schritt 6: Grub neukonfigurieren (2x)

An diesem Punkt habe ich meinen Rechner normal gestartet, um zu überprüfen, dass er wie gewohnt hochfährt. Die gute Nachricht lautet: „Er ist wie gewohnt gestartet.“

Nun verfüge ich über ein Clonezilla-Image der ersten Festplatte, dessen Wiederherstellbarkeit ich noch nicht durch Restore validiert habe und über die Kopien meiner Partitionen in der zweiten VG. Starten tut mein Rechner jedoch immer noch von den altbekannten Partitionen, da ich der Grub-Konfiguration noch nicht mitgeteilt habe, dass ein Wurzeldateisystem aus einer anderen Partition zu verwenden ist.

Leider habe ich es versäumt, mir während der Nutzung der System-Rescue-Umgebung Notizen zu machen. Daher kann ich die verwendeten Befehle an dieser Stelle nur unvollständig wiedergeben. Es ist mir jedoch gelungen, vom Wurzeldateisystem in /dev/tower-pc-vg2/root zu starten. Dies sieht man z.B. in der Ausgabe von lsblk:

:~$ lsblk
NAME                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                             8:0    0 931,5G  0 disk  
└─sda5_crypt                  253:0    0 931,5G  0 crypt 
  ├─tower--pc--vg2-lv--images 253:1    0   360G  0 lvm   /var/lib/libvirt/images
  ├─tower--pc--vg2-root       253:2    0  27,9G  0 lvm   /
  ├─tower--pc--vg2-swap_1     253:3    0     4G  0 lvm   [SWAP]
  └─tower--pc--vg2-home       253:4    0 104,3G  0 lvm   /home
sdb                             8:16   0 238,5G  0 disk  
├─sdb1                          8:17   0     2G  0 part  /boot
├─sdb2                          8:18   0     1K  0 part  
└─sdb5                          8:21   0 234,2G  0 part  
  └─sdb_crypt                 253:5    0 234,2G  0 crypt 
    ├─tower--pc--vg-root      253:6    0  27,9G  0 lvm   
    ├─tower--pc--vg-swap_1    253:7    0     4G  0 lvm   
    └─tower--pc--vg-home      253:8    0 104,3G  0 lvm   
sr0

Wer den Code-Block genau studiert hat, wird festgestellt haben, dass meine /boot-Partition gegenüber dem Eingangs erwähnten IST-Zustand auf 2 GB angewachsen ist. Ich habe die Partitionstabelle zwischenzeitlich mit GParted bearbeitet, welches in der System-Rescue-Umgebung enthalten ist.

Damit habe ich mein Ziel erreicht. Der Artikel könnte an dieser Stelle enden. Ich möchte jedoch zukünftig wieder die Partitionen von /dev/sdb verwenden. Dazu muss ich nochmals Grub neukonfigurieren, welches ich diesmal in folgendem Code-Block zeige:

root@tower-pc:~# mount /dev/tower-pc-vg/root /mnt

# Die separate /boot-Partition muss ebenfalls mit eingehängt werden
root@tower-pc:~# mount /dev/sdb1 /mnt/boot

root@tower-pc:~# for DEVICE in /dev /dev/pts /proc /sys; do mount --bind $DEVICE /mnt$DEVICE; done
root@tower-pc:~# mount /dev/tower-pc-vg2/lv-images /mnt/var/lib/libvirt/images

# ID der Partition mit dem Wurzeldateisystem ermitteln
root@tower-pc:~# ls -l /dev/tower-pc-vg/root 
lrwxrwxrwx 1 root root 7 18. Jun 20:13 /dev/tower-pc-vg/root -> ../dm-6
root@tower-pc:~# ls -l /dev/disk/by-id/ | grep dm-6
lrwxrwxrwx 1 root root 10 18. Jun 20:13 dm-name-tower--pc--vg-root -> ../../dm-6

# In eine chroot-Umgebung wechseln
root@tower-pc:~# chroot /mnt
root@tower-pc:/# pwd
/

In der chroot-Umgebung wird die Datei /etc/default/grub mit einem Editor geöffnet und die Zeile GRUB_CMDLINE_LINUX_DEFAULT= bearbeitet. Dort trage ich die ID der Partition meines Wurzeldateisystems ein. Die Zeile sieht anschließend wie folgt aus:

GRUB_CMDLINE_LINUX_DEFAULT="root=/dev/disk/by-id/dm-name-tower--pc--vg-root iommu='soft' quiet"

Der folgende Code-Block stellt die Befehle dar, mit denen Grub neukonfiguriert und installiert sowie initramfs aktualisiert wird.

root@tower-pc:/# grub-mkconfig -o /boot/grub/grub.cfg 
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-5.10.0-15-amd64
Found initrd image: /boot/initrd.img-5.10.0-15-amd64
Found linux image: /boot/vmlinuz-5.10.0-13-amd64
Found initrd image: /boot/initrd.img-5.10.0-13-amd64
Found Debian GNU/Linux 11 (bullseye) on /dev/mapper/tower--pc--vg2-root
done

root@tower-pc:/# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-5.10.0-15-amd64
update-initramfs: Generating /boot/initrd.img-5.10.0-13-amd64
root@tower-pc:/# exit
exit
root@tower-pc:~# reboot NOW

Nach dem Neustart habe ich noch überprüft, dass der Rechner wirklich die ursprünglichen Partitionen eingehängt hat:

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931,5G 0 disk
└─sda5_crypt 253:4 0 931,5G 0 crypt
├─tower--pc--vg2-lv--images 253:5 0 360G 0 lvm /var/lib/libvirt/images
├─tower--pc--vg2-root 253:6 0 27,9G 0 lvm
├─tower--pc--vg2-swap_1 253:7 0 4G 0 lvm
└─tower--pc--vg2-home 253:8 0 104,3G 0 lvm
sdb 8:16 0 238,5G 0 disk
├─sdb1 8:17 0 2G 0 part /boot
├─sdb2 8:18 0 1K 0 part
└─sdb5 8:21 0 234,2G 0 part
└─sdb_crypt 253:0 0 234,2G 0 crypt
├─tower--pc--vg-root 253:1 0 27,9G 0 lvm /
├─tower--pc--vg-swap_1 253:2 0 4G 0 lvm [SWAP]
└─tower--pc--vg-home 253:3 0 104,3G 0 lvm /home
sr0 11:0 1 1024M 0 rom

Ende gut alles gut

Operation gelungen. Patient rechnet noch.

Mein Ziel habe ich erreicht und als Bonus Grub so konfiguriert, dass wieder meine ursprünglichen Partitionen verwendet werden. Die LVs in VG2 behalte ich vorerst. Sie stören nicht und ich kann die dortige Installation ebenfalls booten. Diese kann ich evtl. noch für zukünftige Experimente hernehmen.

Mir gefällt, dass ich frei verfügbare Informationen und Werkzeuge benutzen konnte, um alle notwendigen Aufgaben zu erledigen. So habe ich wieder einiges dazugelernt. Dies ist einer der Gründe, weshalb mir Freie Software und Open Source so gut gefallen.

Nun werde ich diesen Text noch verschlagworten, damit ich ihn in einer fernen Zukunft auch wiederfinde.

In diesem Artikel stelle ich euch meine Ansible-Rolle vsphere_provision_lab vor. Mit dieser ist es möglich, vordefinierte Labor-Umgebungen, bestehend aus virtuellen Maschinen (VMs), in einem VMware vSphere Cluster zu provisionieren.

Um dem Text folgen zu können, ist es hilfreich zu wissen, was eine Ansible-Rolle (engl.) ist und worum es sich bei VMware vSphere handelt.

Anwendungsfall

Zum Test von Ansible-Modulen, -Playbooks und -Rollen sowie neuer Shell-Skripte und Konfigurationsparameter benötige ich wiederholt Test- bzw. Labor-Umgebungen. Diese bestehen aus VMs, welche im Vergleich zum Provisionierungszeitpunkt möglichst wenig Änderungen aufweisen sollten.

Da die Konfiguration der Gast-Betriebssysteme durch einen Testlauf verändert wird, soll eine solche Labor-Umgebung nach einem Test möglichst schnell dekommissioniert und neu-provisioniert werden können.

Der Vorgang der Provisionierung und Dekommissionierung soll automatisiert erfolgen.

Voraussetzungen

Um die Ansible-Rolle vsphere_provision_lab nutzen zu können, benötigt man:

• Einen Ansible Control Node mit einer Ansible-Version >= 2.9
• Eine vCenter Server Appliance oder einen vCenter Server; getestet habe ich die Rolle mit Version 6.7 U3

Die Ansible-Rolle verwendet die Module vmware_guest und vmware_guest_disk aus der Collection community.vmware. Um diese nutzen zu können, muss auf dem Ansible Control Node Python in einer Version >= 2.6 und PyVmomi installiert sein.

Da die Rolle neue VMs aus Templates erstellt, müssen entsprechende vSphere Templates vorhanden sein.

Variablen

In diesem Abschnitt werden die Variablen dokumentiert, welche mit Werten zu belegen sind. Diese sind in defaults/main.yml definiert und können entsprechend der Variablen-Präzedenz überschrieben werden.

vCenter-Variablen

• vsphere_provision_lab_vc_hostname – Der FQDN für die vCenter Server Appliance.
• vsphere_provision_lab_vc_username – Ein Benutzeraccount mit der Berechtigung, neue VMs zu erstellen.
• vsphere_provision_lab_vc_password – Spezifiziert das Benutzer-Passwort.
• vsphere_provision_lab_vc_datacenter – Name des vSphere Datacenter in der Bestandsliste, das verwendet werden soll.
• vsphere_provision_lab_vc_cluster – Der zu verwendende vSphere Cluster aus der Bestandsliste.
• vsphere_provision_lab_vc_datastore – Name des Datenspeichers, in dem die VMDK-Datei(n) erstellt wird/werden.
• vsphere_provision_lab_vc_folder – Der vSphere Folder Name, in dem die VM erstellt wird. Der Wert kann zuvor mit dem Playbook find_vmware_guest_folder.yml ermittelt werden.

Ich empfehle, sensible Informationen wie z.B. Benutzername und Passwort in einer verschlüsselten Ansible-Vault-Datei zu speichern.

Dictionary zur Spezifikation der VMs

Namen und Parameter der zu erstellenden VMs werden in einem YAML-Dictionary gespeichert. Der folgende Code-Block zeigt ein Beispiel für ein solches Dictionary mit einem Eintrag:

  vm1:
    vm_template: rhel8-en
    vm_ram_mb: 1024
    vm_vcpu: 2
    vm_net: VLAN123
    vm_ip: 192.168.0.5
    vm_netmask: 255.255.255.0
    vm_gateway: 192.168.0.254
    vm_domain: sub.example.com
    vm_hostname: host2
    vm_dns_servers:
      - 192.168.0.2
      - 192.168.0.3
    vm_dns_suffix:
      - sub.example.com
      - sub2.example.com
      - sub3.example.com
    vm_second_hdd: true
    vm_second_hdd_size_gb: "10"
    vm_second_hdd_type: "thin"
    vm_second_hdd_datastore: "DS1"
    vm_scsi_controller: "1"
    vm_unit_number: "1"
    vm_scsi_type: 'paravirtual'

Aus dem obigen Dictionary wird eine VM mit den folgenden Parametern erstellt:

• vSphere-Template ‚rhel8-en‘ wird als Vorlage verwendet.
• Der VM werden 1 vCPU und 512 MB RAM zugewiesen.
• Die vNIC an das VM-Netz ‚VLAN123‘ angeschlossen.
• Die VM wird mit der IP 192.168.0.1/24 und dem Standardgateway 192.168.0.254 konfiguriert.
• Im Gast-Betriebssystem wird der Hostname ‚host1‘ konfiguriert.
• Es werden DNS-Server und DNS-Suffixe konfiguriert.
• Es wird eine zweite Festplatte für die VM erstellt.

Diesen Block kann man nun für weitere VMs wiederholen. Wird keine zweite HDD benötigt, setzt man vm_second_hdd auf false.

Beispiel-Playbook

---
- hosts: localhost
  connection: local
  gather_facts: no
  vars_files:
    - /path/to/vault-with-vcenter-creds.vars
    - roles/vsphere_provision_lab/vars/rhel-lab.yml
 
  roles:
    - vsphere_provision_lab

In diesem Beispiel werden die Variablen aus zwei Dateien geladen.

• /path/to/vault-with-vcenter-creds.vars ist eine Ansible-Vault-Datei, welche die Anmeldeinformationen für den vCenter Server beinhaltet.
• roles/vsphere_provision_lab/vars/rhel-lab.yml enthält das Dictionary mit den zu erstellenden VMs.

Wie kann man diese Rolle nutzen?

Die Rolle steht unter der Lizenz GPLv2-or-later und kann aus dem GitLab-Repo vsphere_provision_lab heruntergeladen bzw. das Repo geklont werden. Sie ist im Role Path der Ansible-Installation zu speichern. Anschließend kann man sich an folgendem Ablaufplan orientieren:

1. Im Vorfeld sollten IP-Adressen und FQDNs für die zu erstellenden VMs registriert werden. Dieser Punkt ist spezifisch für eure jeweilige Umgebung.
2. Die Variablen sind mit gültigen Werten zu belegen.
3. Die Rolle ist in ein Playbook einzubinden.
4. Und schon kann das Playbook ausgeführt werden.

Fazit

Die Ansible-Rolle vsphere_provision_lab ermöglicht es, Labor-Umgebungen, bestehend aus VMs, als YAML-Dictionary zu definieren und auf einem VMware vSphere Cluster zu provisionieren.

Damit eignet sie sich, um wiederholt eine Umgebung mit gleichen Ausgangsbedingungen zu schaffen. Gleichzeitig wird die Zeit für die Provisionierung verkürzt, da manuelle Schritte entfallen.

So richtig idempotent arbeitet das Modul vmware_guest allerdings nicht. Führe ich das Playbook ein zweites Mal aus, wird der Status „Changed“ zurückgegeben, obwohl die VMs bereits existieren. Die VMs selbst überstehen den zweiten Lauf auch unbeschadet, jedoch zeigt der vSphere Client, dass sie rekonfiguriert wurden. Das könnte ich mir noch genauer ansehen, um der Ursache auf die Schliche zu kommen.

Was haltet ihr davon? Findet ihr diese Role nützlich, oder bevorzugt ihr andere Wege zur Provisionierung eurer VMs auf vSphere?

Links meint in diesem Artikel insbesondere Lesezeichen (engl. Bookmarks), wie sie häufig im Webbrowser gespeichert werden. Und Shaarli (engl.) ist eine simple und schnelle Anwendung, um diese zu speichern, verwalten und teilen zu können.

In der Vergangenheit habe ich wiederholt Lösungen gesucht, um meine Lesezeichen im Webbrowser auf verschiedenen Geräten synchron zu halten. Bisher habe ich mich stets an einem oder mehreren der folgenden Punkte gestört:

• Die Lösungen funktionierten nur mit einem Browser (z.B. Firefox oder Chrome)
• Die Lösungen waren cloud-basiert. Ich möchte meine Links aber nach Möglichkeit nicht in einem Cloud-Dienst speichern.
• Es mussten Browser-Plugins installiert werden, die mit der nächsten Browserversion nicht mehr funktionierten oder nach ein paar Monaten eingestellt wurden.
• Man musste dazu Dienste hosten, von denen man 90 % der Funktionalität nicht genutzt hat.
• Es funktionierte nie auf allen meinen Geräten.

Dabei ist es mir gar nicht wichtig, dass die Links synchronisiert werden. Ich möchte nur von all meinen Geräten auf die gleiche Sammlung zugreifen können. Eine umfangreiche und wachsende Linksammlung hier im Blog zu pflegen skaliert jedoch auch nicht. Und hier kommt Shaarli ins Spiel.

Nach eigener Darstellung kann Shaarli (engl.) genutzt werden, um:

• interessante Links zu speichern, kommentieren und zu teilen.
• von verschiedenen Computern und mobilen Geräten auf diese Links zuzugreifen.
• als Microblog zu dienen.
• als ToDo-Liste oder lese-ich-später-Liste zu fungieren.
• eine Wissensdatenbank mit Notizen und Code-Schnipseln zu erstellen.
• etc.

Ich selbst nutze Shaarli aktuell vorwiegend zum Speichen von Links, welche ich mit Titel, Beschreibung und Tags versehen und organisieren kann. Zusätzlich können Links als privat markiert werden, wodurch sie erst nach einem Login abrufbar sind.

Mir gefällt die einfache und schnelle Erfassung neuer Links. Die folgenden drei Screenshots veranschaulichen dies.

Die Projektdokumentation ist brauchbar und die Anwendung lässt sich ohne großen Aufwand auch selbst betreiben. Bei mir läuft sie unter Debian in einem rootless-Podman-Container (engl.).

Fazit

Schnelle und einfache Einrichtung der Anwendung sowie Erfassung von Links machen dieses Projekt zu einem nützlichen Werkzeug in meinem Alltag. And of course, it’s Open Source.

Da bleibt mir nur noch zu sagen: „Danke Dirk für den Tipp.“

Referenzen

• Shaarli Documentation (engl.)
• GitHub Project Page (engl.)
• My-Shaarli – Meine persönliche Shaarli-Instanz

Um die Paketquellen von Red Hat für Red Hat Enterprise Linux (RHEL) nutzen zu können, wird eine sogenannte Software-Subskription benötigt. Diese bestimmt, auf welche Paketquellen ein System zugreifen und deren Inhalt konsumieren kann.

Das System der Subskriptionen befindet sich im Umbruch (siehe [1]). In diesem Artikel beschreibe ich, wie es bisher war, was sich durch die Aktivierung von Simple Content Access (SCA) [2] ändert und wie ich aktuell meine RHEL-Systeme registriere und deren System Purpose konfiguriere.

Der Text vermittelt dabei Wissen zum Red Hat Subscription Management (RHSM), Simple Content Access (SCA), Subscription Watch (SWatch), dem System Purpose und verlinkt relevante Quellen.

Aus Transparenz-Gründen möchte ich an dieser Stelle darauf hinweisen, dass ich Mitglied der Red Hat Accelerators bin (vgl. hier). Dieser Text spiegelt ausschließlich meine persönliche Meinung wider.

Subskriptions-Verwaltung ohne SCA

Eine Subskription berechtigt zur Nutzung bestimmter Paketquellen von Red Hat. Sie umfasst in der Regel eine gewisse Menge sogenannter Entitlements. Diese bestimmen, wie viele Systeme von einer Subskription abgedeckt werden.

Ein Beispiel: Eine Subskription für „Red Hat Enterprise Linux Server, Standard (Physical or Virtual Nodes)“ beinhaltet zwei Entitlements. Damit lassen sich ein physischer Server mit bis zu zwei CPU-Sockeln oder zwei virtuelle Maschinen (mit einer beliebigen Anzahl CPUs) zur Nutzung der Paketquellen berechtigen.

In der Regel werden RHEL-Systeme über den subscription-manager beim Red Hat Subscription Management (RHSM) oder einem Satellite Server registriert. Anschließend werden sie mit einer Subskription verknüpft. Wie man dies lösen kann, habe ich 2019 in dem Artikel RHEL-System registrieren und Subskription hinzufügen beschrieben.

Vorteile des RHSM

Das RHSM im Customer Portal bietet eine gute Übersicht über die vorhandenen Verträge, die Subskriptionen, deren Laufzeiten und verknüpfte Systeme. Man sieht hier auf einen Blick, ob man ausreichend Subskription hat, um all seine Systeme damit abdecken zu können.

Nachteile des RHSM

Um ein System beim RHSM zu registrieren und mit einer Subskription zu verknüpfen, muss das System eine Verbindung ins Internet zum RHSM-Dienst aufbauen. Dies ist im Datacenter häufig nicht erwünscht. Für Systeme ohne Zugang zum Internet gibt es die optionale Offline-Registrierung [3], welche jedoch etwas umständlich ist und bei vielen Offline-Systemen nicht skaliert.

Registriert man die Systeme nicht, ist man dennoch zu einer ordentlichen Buchführung verpflichtet, um sicherzustellen, dass man nicht dauerhaft mehr Systeme einsetzt, als durch vorhandene Subskriptionen abgedeckt sind.

Läuft ein Subskriptionsvertrag ab, werden die Entitlements ungültig. Die damit verknüpften Systeme fangen an, sich beim Update-Versuch darüber zu beschweren und verweigern den Zugriff auf die Paketquellen. Das ist besonders ärgerlich, weil es nach meiner Erfahrung bei jeder Vertragsverlängerung passiert. Denn tatsächlich wird der Vertrag nicht verlängert. Es gibt einen neuen Vertrag mit der entsprechenden Anzahl Subskriptionen. Diese müssen dann manuell neu verknüpft werden, was jedes Mal manuellen Pflegeaufwand bedeutet.

Vermutlich um dem zuvor genannten Ärgernis entgegenzuwirken hat Red Hat die Funktion auto-attach entwickelt. Wird die mit einem registrierten System verknüpfte Subskription ungültig sucht auto-attach automatisch nach einer geeigneten freien Subskription und verknüpft diese mit dem jeweiligen System. Nun mag sich manch einer Fragen, wie auto-attach wohl entscheidet, wenn es mehrere Subskriptionen gibt, die prinzipiell geeignet sind. Nach meiner Erfahrung wählt auto-attach mit einer Wahrscheinlichkeit von >95 % die am wenigsten geeignete Subskription aus. In meinen Augen nervt es mehr, als das es hilft.

Das Verknüpfen von Subskriptionen ist für die Buchführung praktisch, für den Betrieb eher nervig. Teilweise stört es sogar Betriebsabläufe, wenn z.B. Updates vorübergehend nicht installiert werden können. Um dem zu begegnen, hat Red Hat Simple Content Access (SCA) [2] geschaffen.

Was ändert sich durch SCA?

Wird SCA im RHSM aktiviert, müssen Subskriptionen nicht mehr mit Systemen verknüpft werden. RHEL-Systeme, die im RHSM registriert sind, erkennen dies und setzen für den Zugriff auf die Paketquellen kein Entitlement mehr voraus.

Vorteile

Der Betrieb wird vereinfacht. Ein System muss nur noch registriert werden und kann sofort auf Inhalte der diversen Paketquellen zugreifen.

Unterbrechungen im Betriebsablauf bei Ablauf einer Subskription gehören der Vergangenheit an.

Auch auto-attach bereitet nun keinen Ärger mehr.

Nachteile

Die Buchführung wird aufwändiger, da RHSM mit aktivierten SCA nur noch begrenzt dafür taugt. Man muss sich nun einen anderen Weg überlegen, wie man den Überblick behält.

Subscription Watch

Subscription Watch [4, 5] ist ein SaaS-Dienst in der Hybrid Cloud Console [6], welcher den Kunden dabei unterstützen soll, im Blick zu behalten, wie viele Subskriptionen er besitzt und wie viele er konsumiert. Dabei ist es möglich, mehr zu konsumieren, als man besitzt. Wird dies angezeigt, kann man handeln und fehlende Subskriptionen nachkaufen.

Leider hat die Sache einen Haken. Es funktioniert nicht richtig. In meinem Fall kommt eine Mischung aus kostenpflichtigen Subskriptionen und der Developer Subscription for Teams zum Einsatz. Im Subscription Watch gibt es einen Bug, durch den mir angezeigt wird, ich würde mehr Subskriptionen nutzen, als ich im Bestand habe, obwohl dies nicht der Fall ist.

Ich habe zu dem Fall ein Support-Ticket, in dem das Verhalten reproduziert werden konnte und der Fehler bestätigt wurde. Nur eine Lösung gibt es noch nicht. Leider ist Subscription Watch im aktuellen Status damit nutzlos für mich.

System Purpose

Was der System Purpose ist, wird im Detail in [1] und [7] beschrieben. Red Hat empfiehlt den System Purpose zu pflegen, um u.a. Subscription Watch dabei zu helfen, die konsumierten Inhalte korrekt zu zählen. Das hat folgenden Hintergrund.

Sowohl mit der „Red Hat Enterprise Linux Server, Standard (Physical or Virtual Nodes)“ Subskription als auch mit der „Developer Subscription for Teams“ darf man das RHEL-8-BaseOS-Repo nutzen. Gezählt werden soll in Subscription Watch jedoch nur die kostenpflichtige Subskription (Erstgenannte). Mit Hilfe des System Purpose gibt man an, ob es sich um ein Produktionssystem oder ein Test-/Entwicklungs-System handelt und steuert darüber, ob ein System in Subscription Watch gezählt wird.

Funktionieren tut das Ganze leider (noch) nicht. Unter anderem ist der zuvor erwähnte Bug dafür verantwortlich. Ich pflege den System Purpose jedoch trotzdem, in der Hoffnung, dass es in der Zukunft funktionieren wird.

Wie registriere ich meine Systeme heute?

Ich habe dazu eine kleine Ansible-Rolle erstellt, welche folgende Struktur besitzt:

roles/register_syspurpose/
├── defaults
│   └── main.yml
├── README.md
└── tasks
    └── main.yml

Das Readme.md enthält eine Beschreibung der notwendigen Variablen und ein Beispiel-Playbook, wie man diese Rolle nutzt:

register_syspurpose
===================

Register host to RHSM and set System Purpose.

Requirements
------------

 * [community.general collection](https://galaxy.ansible.com/community/general)

You might already have installed this collection if you are using Ansible Engine 2.9 or the `ansible` package. It is not included in `ansible-core`. To check whether it is installed, run `ansible-galaxy collection list`.

To install it, use: `ansible-galaxy collection install community.general`.

To use it in a playbook, specify: `community.general.redhat_subscription`.

Role Variables
--------------

```yaml
register_syspurpose_activationkey: register-syspurpose # activationkey for access.redhat.com or Satellite
register_syspurpose_org_id: 123456 # Org ID on access.redhat.com or Satellite
register_syspurpose_role: "Red Hat Enterprise Linux Server"
# possible values are:
# Red Hat Enterprise Linux Server
# Red Hat Enterprise Linux Workstation
# Red Hat Enterprise Linux Compute Node

register_syspurpose_sla: "Self-Support"
# possible values are:
# Premium
# Standard
# Self-Support

register_syspurpose_usage: "Development/Test"
# possible values are:
# Development/Test
# Disaster Recovery
# Production
```

I got these values from the KB [syspurpose_usage: "Development/Test"](https://access.redhat.com/articles/5713081).
There might be other possible values out there. In case you know some valid
addtional values please sent a PR to add them to this documentation.

Dependencies
------------

None.

Example Playbook
----------------

Including an example of how to use your role (for instance, with variables passed in as parameters) is always nice for users too:

~~~
- hosts: all
  gather_facts: no
  roles:
    - register_syspurpose
~~~

License
-------

MIT.

Author Information
------------------

Joerg Kastning - "joerg (dot) kastning '@' uni-bielefeld (dot) de"

Auch die Tasks-Datei ist sehr übersichtlich:

---
# tasks file for register_syspurpose
- name: Register system to RHSM and set syspurpose attributes
  redhat_subscription:
    state: present
    activationkey: "{{ register_syspurpose_activationkey }}"
    org_id: "{{ register_syspurpose_org_id }}"
    syspurpose:
      role: "{{ register_syspurpose_role }}"
      service_level_agreement: "{{ register_syspurpose_sla }}"
      usage: "{{ register_syspurpose_usage }}"
      sync: true

Um die Variablen mit Werten zu belegen, nutze ich group_vars. Ich verwende ein statisches Inventory, in dem ich Gruppen für die möglichen Kombinationen aus role, sla und usage definiert habe. So wird jeder neue Host der entsprechenden Gruppe hinzugefügt und anschließend bei der Provisionierung direkt registriert und korrekt konfiguriert. Detaillierte Informationen zum verwendeten Modul redhat_subscription bietet die Dokumentation unter [8].

Ihr seht, es steckt keine Magie in der Rolle. But I like to Keep It Simple, Stupid.

Fazit

Das Red Hat Subscription Management ist kompliziert, hat seine Macken, eine Geschichte und etliche Altlasten. Ein Team um Rich Jerrido hat es sich zur Aufgabe gemacht, das Subskriptions-System zu überarbeiten und alte Zöpfe abzuschneiden. Ich beneide das Team nicht um diese Aufgabe.

Das System befindet sich aktuell im Übergang (siehe [1]). Damit gehen Herausforderungen sowohl für Red Hat als auch dessen Kunden einher.

Das Red Hat die technischen Abhängigkeiten zwischen Betriebssystem und RHSM mit SCA abschafft, weiß ich zu schätzen. Schade, dass die Unterstützung bei der Buchführung dabei auf der Strecke bleibt.

Subscription Watch bietet mir auch in der nahen Zukunft keinen Nutzen. Um meinen Pflichten aus [9] nachzukommen, werde ich mir Red Hat Discovery näher ansehen. Meine Erfahrungen werde ich anschließend hier im Blog niederschreiben.

Quellen und weiterführende Links

1. Transition of Red Hat’s subhttps://access.redhat.com/documentation/en-us/red_hat_subscription_management/2022scriptions 5ervices to console.redhat.com
2. Simple Content Access (SCA)
3. How to register and subscribe a system offline to the Red Hat Customer Portal?
4. Subscription Watch
5. Chapter 1. What is subscription watch?
6. Red Hat Hybrid Cloud Console
7. RHEL 8 Documentation: Chapter 12. Configuring System Purpose
8. community.general.redhat_subscription module – Manage registration and subscriptions to RHSM using the subscription-manager command
9. Red Hat Enterprise Linux subscription guide

Im Artikel „Wie kann man Hostnamen ohne Programme aus dem Paket bind-utils auflösen?“ hatte ich getent bereits genutzt, um Hostnamen auflösen zu können, wenn kein Programm aus dem Paket bind-utils installiert ist. In diesem Artikel möchte ich getent einmal ganz allgemein vorstellen.

Das Kommando getent steht auf so gut wie jedem Linux- und UNIX-System zur Verfügung. Es steht für get entries und tut genau das. Es ruft Einträge aus Textdateien ab (in diesem Kontext auch Datenbanken genannt), die auf eurem System vorhanden sind. Genau genommen kann es alle Datenbanken abfragen, die in der Datei /etc/nsswitch.conf (siehe nsswitch.conf(5)) konfiguriert sind. Damit lässt sich auf reichhaltige Informationen zugreifen, ohne eine Internet-Suchmaschine zu bemühen. Es funktioniert sogar auf Systemen ohne Internetkonnektivität (ja auch heutzutage gibt es solche Systeme noch).

Ich möchte hier allerdings nicht die Manpage getent(1) widergeben, sondern euch ein paar Anwendungsbeispiele zeigen, bei denen ich getent hilfreich finde.

Informationen zu Ports, Services und Protokollnummern

Nehmen wir mal an, in einem Firewall-Log fallen uns die Ports 5432 und 11371auf und wir können uns gerade nicht daran erinnern, für welche Services diese üblicherweise verwendet werden. So hilft uns folgende Abfrage auf unserem Linux-/UNIX-System weiter:

$ getent services 5432 11371
postgresql            5432/tcp postgres
hkp                   11371/tcp

Die Ports gehören also zu PostgreSQL und zu OpenPGP-HTTP-Keyservern.

Umgekehrt funktioniert das natürlich auch. Mal angenommen, ihr habt die Standard-Ports für NTP und MySQL vergessen:

$ getent services ntp mysql
ntp                   123/udp
mysql                 3306/tcp

Der Befehl getent services ohne weitere Argumente gibt euch den gesamten Inhalt der Datenbank aus.

Auf dem gleichen Weg lassen sich auch die Protokollnummern gängiger Protokolle ermitteln:

$ getent protocols tcp udp rdp icmp
tcp 6 TCP
udp 17 UDP
rdp 27 RDP
icmp 1 ICMP

Informationen über User und Gruppen

Selbstverständlich kann man diese Informationen auch mit `grep <Suchmuster> /etc/{groups,passwd} erhalten. Es geht aber auch wie folgt:

$ getent passwd root
root:x:0:0:root:/root:/bin/bash
$ getent group root
root:x:0:
$ getent group sudo
sudo:x:27:alice

Ein Beispiel für Hostnamen findet sich bereits hier.

Fazit

Ich finde, getent ist ein einfach zu bedienendes und nützliches Programm. Seid ihr neugierig geworden? Dann schaut doch mal in die Manpage getent(1) für weitere Hinweise, wie und wofür ihr es nutzen könnt.

In diesem Artikel möchte ich euch das Förderprogramm Media Tech Lab des Media Lab Bayern vorstellen.

Wie dem Titel bereits zu entnehmen ist, werden Open Source Projekte mit bis zu 50.000 EUR pro Projekt gefördert. Das Geld dafür kommt aus der Bayerischen Staatskanzlei. Doch der Reihe nach.

Vor einiger Zeit schrieb mich Jessica vom Media Lab Bayern an, um mich auf das Programm aufmerksam zu machen. Sie fragte, ob ich nicht Interesse habe, mich mit ihr und Erkan Kasap (CTO) über das Programm zu unterhalten, um ggf. darüber zu berichten und so dessen Bekanntheitsgrad zu steigern. Der Zufall sorgte dafür, dass Erkan und ich uns auf der FrOSCon 2022 an der Hochschule Bonn-Rhein-Sieg in Sankt Augustin begegnet sind, wo wir uns gemeinsam mit Dirk über das Programm ausgetauscht haben. Erkan strahlte dabei eine Leidenschaft und ein Commitment aus, welche mir den Eindruck vermittelten, dass er für dieses Projekt brennt.

Um was für Projekte geht es?

Das Programm sucht innovative Projektideen zu Themen aus den Bereichen:

• Infrastruktur & Web-Technologie
• UX-Design & User Experience
• Machine Learning & Natural Language Processing
• Web3 & Blockchain
• Augumented & Mixed Reality

Ihr arbeitet bereits an entsprechenden Projekten oder strebt dies an? Ihr seid dabei auf eine Anschubfinanzierung angewiesen oder braucht Unterstützung bei der Projektplanung? Dann könnt ihr euch mit eurer Idee hier bewerben.

Ihr habt noch keine konkrete Idee, würdet aber gern mal an einem Open Source Proejekt arbeiten, welches das Potenzial hat, die Medienbranche zu verändern? Dann schaut in die Projektideen und lasst euch inspirieren.

Wen sucht Erkan?

Erkan ist auf der Suche nach:

• Open Source-Entwickler:innen und
• Software-Freelancer:innen

die Lust auf ein cooles Forschungs- und Entwicklungsprojekt in und für die Medienbranche haben. Wichtig dabei ist, dass nur Einzelpersonen oder Teams aus Einzelpersonen gefördert werden können, jedoch keine Unternehmen.

Seid ihr z.B. Entwickler, die über ein Sabbatical nachdenken, um mal an einem richtig coolen Projekt zu arbeiten, aber in dieser Zeit auch Einkommen erzielen müssen, dann ist dieses Programm für euch.

Ihr seid jung, sprudelt vor innovativen Ideen, die ihr unbedingt umsetzen wollt? Doch es fehlt das Geld und ein wenig Unterstützung darin, wie man ein Projekt erfolgreich durchführt? Dann nehmt Kontakt zu Erkan auf. Vielleicht ist euer Projekt dann schon bald dabei und wird Realität.

Welche Projekte haben keine Chance?

Euer Projekt muss innovativ sein. Nicht innovativ sind z.B.:

• Noch eine Rechtschreib- und Grammatikkorrektur für Office-Programme
• Peer-Review-Portale
• Sync&Share-Lösungen

Halt alles was es prinzipiell schon gibt. Damit sind jedoch nicht bereits existierende Projekte gemeint, denen es vielleicht noch an Funktionalität fehlt, um produktiv eingesetzt zu werden.

TL;DR: Wenn ihr alten Wein in neuen Schläuchen verkaufen wollt, seid ihr bei Erkan an der falschen Adresse.

Die harten Fakten

Wenn dein/euer Projekt angenommen wird, arbeitet ihr bis zu sechs Monate an eurem Projekt. Dies geht remote oder beim Media Lab im Open Space in München. Der Arbeit am Projekt wird dabei die größte Zeit des Tages eingeräumt. Der Verwaltungs-Overhead wird auf ein Minimum reduziert. Die Messung und Kontrolle des Fortschritts gehört jedoch zu jedem ordentlichen Projekt dazu. So gibt es selbstverständlich auch hier Check-ins mit dem Media Lab Team, Tech-Experten auf CTO/Senior Level und Produkt Experten (Medienexperten). Mit diesen könnt ihr Fragen zum Tech-Setup diskutieren, die Nutzerperspektive kennenlernen und erhaltet Feedback zu eurem Projekt.

Ihr erhaltet alle zwei Monate ab Beginn des Projekts eine Auszahlung. An das Projektteam (nicht jedes Projektmitglied) werden so max. 45.000 EUR ausbezahlt, die ihr frei einsetzen könnt. Weitere 5.000 EUR sind zweckgebunden und können für Coaching und Mentoring eingesetzt werden. So könnt ihr euch bspw. Experten-Rat zu Themen wie Community-Management oder wie verwalte ich Contributer für mein Projekt einkaufen.

Was gibt es noch nicht?

Auf der FrOSCon kam unser Gespräch darauf, was mit den Projekten passiert, wenn sie fertig und abgenommen sind. Stichwort: Maintenance.

Dieser Punkt ist noch nicht abschließend geklärt. Erkan äußerte die Idee, dass Medienhäuser, die ein Open Source Projekt einsetzen und zu einem Bestandteil ihrer Geschäftsprozesse machen, als Paten auftreten können, um die Pflege und Wartung des Codes zu finanzieren. Dem Gemeinschaftsgedanken folgend, können sich mehrere Unternehmen auf diesem Weg die Kosten für die Software-Pflege teilen.

Eine interessante Idee, bei der allerdings noch offen ist, ob und in welchem Umfang sich Medienhäuser darauf einlassen.

Mein Eindruck

Ich persönlich finde es schon bemerkenswert, dass in Deutschland ein Förderprogramm aufgelegt wird, welches die Entwicklung von Open Source Projekten in diesem Umfang fördert. Etwas Vergleichbares war mir bis dato nicht bekannt.

Erkan hat auf mich den Eindruck hinterlassen, mit viel Herzblut und bis in die Bartspitzen motiviert hinter diesen Programm zu stehen.

In meinen Augen bietet das Programm eine gute Chance, um Open Source Projekten zu einem erfolgreichen Verlauf zu verhelfen. Auch wenn die Finanzierung der Maintenance-Phase nach Projektende noch nicht geklärt ist.

Im September habe ich über das Förderprogramm Media Tech Lab berichtet. Heute möchte ich euch auf den Prototype Fund hinweisen, welcher Open-Source-Projektideen mit bis zu max. 47.500 Euro unterstützt.

Danke an @Kampfradler (Twitter-Link), welcher mich auf dieses Förderprogramm hingewiesen hat.

Der Prototype Fund ist ein Projekt der Open Knowledge Foundation Deutschland, gefördert durch das Bundesministerium für Bildung und Forschung (BMBF). Er existiert seit 2016 und damit schon etwas länger als Media Tech Lab. Seither wurden nach Angabe des Projekts 12,3 Mio. Euro an Fördergeldern bewilligt, mit denen 293 Projekte gefördert wurden.

Bezüglich der Rahmenbedingungen ähneln sich Media Tech Lab und der Prototype Fund auffällig. Hier die wichtigsten Eckdaten:

• Einzelpersonen und kleine (interdisziplinäre) Teams können eine finanzielle und ideelle Unterstützung für die Erprobung von Ideen sowie die Entwicklung von Open-Source-Anwendungen in den Bereichen Civic Tech, Data Literacy, IT-Sicherheit und Software-Infrastruktur (siehe FAQ) erhalten.
• Die Förderung beträgt bis zu 47.500€ über 6 Monate.
• Es gibt Unterstützung durch Mentor*innen und Coaching in den Bereichen User Centered Design, Projektmanagement, Security und Business.
• Es werden ausschließlich Open-Source-Projekte gefördert.

Der Prototype Fund ist bestrebt, Teams und Teilnehmer*innen mit weiteren Geldgeber*innen und potenziellen Partner*innen zu vernetzen. Ziel ist es, Teilnehmer*innen so gut wie möglich bei der Weiterführung ihrer „Produkte“ nach Projektende zu unterstützen.

Projekt und Förderung enden nach sechs Monaten mit der Vorstellung des Prototypen. Damit es danach weitergeht, braucht es Spender, Investoren und ein Geschäftsmodell. Diese Weiterentwicklungen sind jedoch nicht durch die Prototype-Fund-Förderung abgedeckt (Media Tech Lab hat aktuell auch noch kein Konzept für die Maintenance-Phase).

Die Projektseite biete eine gute FAQ, welche die wichtigsten Fragen zu den Rahmenbedingungen und zum Bewerbungsprozess beantwortet. Wenn ihr Interesse an einer Förderung habt, schaut hier hinein.

Ich freue mich, dass es offenbar doch mehr als ein Förderprogramm für Open-Source-Projekte in Deutschland gibt. Falls ihr noch weitere Förderprogramme für Open-Source-Projekte kennt, hinterlasst doch bitte einen Hinweis mit URL auf deren Webseite in den Kommentaren. Ich freue mich, wenn ich hier zukünftig weitere Open-Source-Förderprogramme vorstellen kann.

Ihr betreibt ein Projekt, dass durch den Prototype Fund gefördert wurde und möchtet gerne darüber berichten? Meldet euch gerne bei mir. Gern könnt ihr mir einen Entwurf für einen Erfahrungsbericht senden oder wir führen ein kurzes Interview und ich berichte anschließend von euren Erfahrungen. Because sharing is caring.

Das Jahr neigt sich dem Ende zu und ich möchte zurückblicken und mich erinnern, wie es in diesem Jahr für meinen Blog verlaufen ist.

In diesem Jahr wurden auf My-IT-Brain insgesamt 29 Artikel veröffentlicht. Dies sind zwei weniger als in 2021. Dafür habe ich jeden Monat mindestens einen Artikel veröffentlichen können.

Während ich mich im Januar mit verschiedenen Themen beschäftigt habe, konzentrierte ich mich im Februar und März auf eine sechsteilige Serie zum Thema Nextcloud im Container. Die daraus entstandene Nextcloud-Instanz läuft immer noch und wurde im Laufe des Jahres mehrmals aktualisiert. Sie ist allerdings ein Wochenendprojekt geblieben. Außer zum Teilen größerer Dateien nutze ich sie nicht aktiv.

Da ich immer mal wieder Systeme für verschiedene Test benötige, habe ich mir zwei Ansible-Rollen geschrieben, welche mir die Erstellung definierter Labor-Umgebungen erleichtern. Dokumentiert habe ich diese in:

• Labor-Umgebung mit Ansible in KVM erstellen
• Labor-Umgebungen auf VMware vSphere erstellen mit der Ansible-Rolle vsphere_provision_lab

Zur Jahresmitte habe ich einen Blick auf AlmaLinux, RHEL und Rocky Linux geworfen und mich gefragt, welche potenziellen Mehrwerte eine RHEL-Subskription bietet.

Nach meiner ersten FrOSCon habe ich entdeckt, dass es doch tatsächlich einige Förderprogramme für Open-Source-Projekte gibt und habe diese in kurzen Artikeln vorgestellt:

• Stipendien bis zu 50.000 EUR für Open Source Projekte
• Der Prototype Fund fördert eure Open-Source-Projektidee
• Der Sovereign Tech Fund öffnet Antragsverfahren 2023

Leider ist es mir aus zeitlichen Gründen nicht gelungen, Kontakt zu den bereits geförderten Projekten aufzunehmen, um über die Erfahrungen zu berichten, welche die Projekte mit den jeweiligen Förderprogrammen gemacht haben. Falls ihr ein Projekt habt, welches durch eines der genannten Programme gefördert wurde und gern darüber berichten möchtet, meldet euch doch gern bei mir. Ich schreibe eure Geschichte gern auf und veröffentliche sie hier.

Zum Jahresende wurde es dann wieder etwas ruhiger hier. Ich arbeite aktuell an einer kleinen Artikelserie, die ich mit dem Beginn des neuen Jahres veröffentlichen möchte. Worum es geht wird an dieser Stelle noch nicht verraten.

Ich freue mich, wenn ihr auch im nächsten Jahr meine Artikel lest, kommentiert, evtl. etwas daraus lern und sie unterhaltsam findet. Ich wünsche euch allen fröhliche Weihnachten und einen guten Rutsch ins Jahr 2023.

In diesem Artikel führe ich auf, was ich 2022 für bzw. mit FLOSS getan habe. FLOSS steht dabei für Free/Libre Open Source Software. Es geht dabei nicht um weltbewegende Projekte oder große Beiträge. Es ist mehr eine Sammlung von Kleinigkeiten. Dennoch möchte ich diese öffentlich machen, um zu zeigen, was man mit FLOSS tun und wie man sich beteiligen kann.

Ansible-Rolle zum Deployment von Nextcloud und MariaDB in einem Podman Pod

Dieses kleine Projekt ist etwas verrückt und für den Einsatz in Produktion vermutlich nicht geeignet. Doch konnte ich mich gleich mit zwei Themen intensiv beschäftigen, die mich interessieren, Ansible und Podman. Mein Ziel war es, die Anwendungen Nextcloud und MariaDB zur Bereitstellung einer privaten Cloud in einem rootless Podman Pod zu provisionieren. Die ganze Geschichte kann in der kleinen Serie Nextcloud im Container nachgelesen werden.

Die Quellen der Ansible-Rolle gibt es auf:

• Github: https://github.com/Tronde/ansible_role_deploy_nextcloud_with_mariadb_pod
• Galaxy: https://galaxy.ansible.com/Tronde/deploy_nextcloud_with_mariadb_pod

RHEL-Patchmanagement

Seit 2016 entwickle und pflege ich ein Patch-Management für Red Hat Enterprise Linux Systeme. Dieses Jahr habe ich Release 3.3.0 und 3.3.1 veröffentlicht.

Mit diesem Projekt habe ich ein Patch-Management gebaut, welches sehr gut die Anforderungen meines Arbeitgebers abdeckt und sich ohne Zusatz-Subskriptionen wie das Smart-Management-Addon für RHEL-Subskriptionen realisieren lässt. Seit 2018 läuft es vollautomatisch und stellt sicher, dass verfügbare Sicherheits-Updates mindestens einmal pro Monat installiert werden.

Es erfreut sich auch außerhalb unserer Organisation einiger Beliebtheit:

• Github: https://github.com/Tronde/ansible-role-rhel-patchmanagement/
• Galaxy: https://galaxy.ansible.com/Tronde/ansible_role_rhel_patchmanagement

Drei Ansible-Rollen dank Open Source

Häufig haben Unternehmen/Organisationen sehr individuelle Anforderungen, für die keine fertigen Lösungen von der Stange existieren. Open Source schafft die Möglichkeit, sich selbst helfen zu können. So habe ich ohne großen Aufwand Ansible-Rollen geschrieben, um Proxy-Einstellungen für den subscription-manager und YUM bzw. DNF zu konfigurieren sowie um Red Hat Enterprise Linux registrieren und den System Purpose konfigurieren zu können.

Quellen:

• Github: https://github.com/Tronde/set_proxy4yum_dnf
• Galaxy: https://galaxy.ansible.com/Tronde/set_proxy4yum_dnf
• Github: https://github.com/Tronde/set_proxy4rhsm
• Galaxy: https://galaxy.ansible.com/Tronde/set_proxy4rhsm
• Github: https://github.com/Tronde/register_syspurpose
• Galaxy: https://galaxy.ansible.com/Tronde/register_syspurpose

Meine erste Linux System Role

Die Linux System Roles sind eine Sammlung von Ansible-Rollen zur Konfiguration diverser Betriebssystem-Komponenten von Linux. Ziel der Sammlung ist es, Ansible-Rollen zur einfachen Nutzung durch Systemadministratoren bereitzustellen.

Ich habe viel über den Entwicklungsprozess von Ansible-Rollen gelernt, bis meine erste Rolle pam_pwd aufgenommen wurde. Mit dieser Rolle kann PAM konfiguriert werden, um eine Passwort-Richtlinie zu etablieren.

Sie befindet sich noch in einem sehr frühen Stadium. Nutzt sie auf eigene Gefahr. Der Lerneffekt für mich war jedoch sehr groß, so dass sich die Arbeit in meinen Augen gelohnt hat.

Quelle:

• Github: https://github.com/linux-system-roles/pam_pwd

Mit Ansible Labor-Umgebungen in KVM und vSphere provisionieren

Ich benötige immer mal wieder Labor-Umgebungen mit frischen Betriebssystem-Installationen für verschiedene Versuche und Tests. Um die Provisionierung dieser Laborumgebung zu vereinfachen und zu beschleunigen, habe ich zwei Ansible-Rollen erstellt, mit denen sich diese Labor-Umgebungen auf KVM- und vSphere-Hypervisoren provisionieren lassen:

• Labor-Umgebung mit Ansible in KVM erstellen
• Labor-Umgebungen auf VMware vSphere erstellen mit der Ansible-Rolle vsphere_provision_lab

Blogs, Issue-Reports Pull-Requests

Man kann FLOSS auch dadurch unterstützen, indem man darüber spricht bzw. schreibt. Letzteres tue ich in diesem Blog. Der My-IT-Brain Jahresrückblick 2022 gibt einen Überblick darüber.

Hinzu kommen kleine Beiträge in Form von Issue-Reports und Pull-Requests. Details kann man meiner Contribution Activity auf Github entnehmen.

Spenden

Viele FLOSS-Projekte werden ohne funktionierendes Geschäftsmodell von Menschen in deren Freizeit entwickelt und gewartet. Diese Projekte sind auf Spenden angewiesen.

Ich setze mir jedes Jahr ein persönliches Budget, aus dem ich an die Projekte spende, deren Anwendungen ich häufig benutze oder die mir besonders sympathisch sind. Das ist nicht immer ganz einfach. Ich persönlich bevorzuge eine Banküberweisung oder eine Einmalzahlung per Kreditkarte. Mich erst bei einem Zahlungsdienstleister anzumelden stellt für mich meist eine zu hohe Hürde dar.

Fazit

Es muss nicht das eine große Projekt sein. Auch mit der Summe kleiner Teile kann man eine Menge erreichen.

FLOSS hat mir geholfen, viele meiner Anforderungen zu erfüllen. Für mich ist es selbstverständlich, die Ergebnisse dieser Arbeit ebenfalls wieder unter einer freien Lizenz zu veröffentlichen, um auf diesem Weg etwas an die FLOSS-Gemeinschaft zurückzugeben. Doch denkt immer daran: „Nutzung auf eigene Gefahr.“

Hallo liebe Leserinnen und Leser,

in diesem Beitrag möchte ich um eure Meinungen und Gedanken zur Distribution IPFire 2.x und einer dafür erhältlichen Hardware-Appliance bitten.

IST-Zustand

Es existiert ein einfaches Heimnetzwerk, welches über eine Vodafone ConnectBox mit dem Internet verbunden ist. Die Firewall der ConnectBox ist aktiviert und es sind aktuell keinerlei eingehende Verbindungen zugelassen.

Im LAN existieren eine Vielzahl unterschiedlicher Geräte, wie z.B. Access-Points, Pi-Hole, PCs, Laptops, PV-Anlage, Netzwerkdrucker, etc. pp.

SOLL-Zustand

Das bestehende Heimnetzwerk soll in verschiedene Netzwerkzonen unterteilt werden können, welche durch eine Firewall voneinander getrennt sind. Es soll eine Möglichkeit zur VPN-Einwahl geschaffen werden, um von außerhalb des Netzwerks auf Dienste im Heimnetzwerk zugreifen zu können. Der vorhandene Kabelrouter soll nicht ersetzt werden.

Bei der Internet-Recherche bin ich auf IPFire gestoßen, für welche ich als ehemaliger IPCop-Nutzer eine gewisse Sympathie hege. Zudem habe ich mit der IPFire Mini Appliance (EU) ein Gerät im Blick, welches am Aufstellungsort eine gute Figur machen sollte. Mir ist dabei wichtig, dass das Gerät möglichst sparsam bei der Energieaufnahme ist und passiv gekühlt wird, damit im Betrieb keine Geräusche verursacht werden.

Ich möchte die IPFire als Paketfilter, OpenVPN-Gateway und ggf. IPS nutzen.

Ihr seid gefragt

Bevor ich nun ca. 450 Euro investiere, möchte ich die Chance nutzen und nach euren Erfahrungen mit IPFire und den verfügbaren Appliances fragen.

Habt ihr IPFire genutzt oder nutzt sie noch? Seid ihr damit zufrieden, oder würdet ihr zu einer Alternative raten? Wenn Alternative, welche und warum?

Worauf betreibt ihr IPFire? Auf einer Appliance wie der oben verlinkten, einem Raspberry Pi, in einer VM oder auf etwas ganz anderem? Lasst es mich gerne wissen, warum ihr euch für welche Lösung entschieden habt.

Falls ihr jetzt die Hände über dem Kopf zusammenschlagt und ruft: „Nein alles, nur das nicht!“ Dann bin ich natürlich umso mehr an eurer Erfahrung interessiert.

Bitte nutzt die Kommentare oder schreibt mir an „ipfire (aett) my-it-brain (Punkt) de“, wenn ihr eure Gedanken mit mir teilen möchtet.

Quellen und weiterführende Links

• Wikipedia-Artikel zu IPFire: https://de.wikipedia.org/wiki/IPFire
• Projekt-Webseite: https://www.ipfire.org/
• IPFire Mini Appliance im IPFire-Wiki: https://wiki.ipfire.org/hardware/lightningwirelabs/mini
• IPFire Mini Appliance im Online-Shop: https://store.lightningwirelabs.com/products/IPFIRE-MINI-EU-R1

Dies ist ein Update des Artikels aus dem letzten Jahr.

Smartphone

Mein Sony Xperia XZ2 Compact musste aufgrund mehrerer Macken ersetzt werden. Mein neuer Begleiter ist nun ein Samsung Galaxy S22. Zwar habe ich mir auch ein Fairphone angesehen, doch ist mir dieses einfach viel zu groß. Nutzungsänderungen ergaben sich lediglich bei den Messenger-Diensten und den sozialen Netzwerken:

• Für Chat und Kurznachrichten mit Matrix über Element (dienstlich)/neu: FluffyChat (privat), SMS und Threema (bevorzugt).
• Nutzung diverser sozialer Netzwerkwerke wie Facebook, LinkedIn, Mastodon, Twitter und XING; meine Accounts in den gestrichenen Netzwerken habe ich gelöscht.

Tablet

Hier hat sich gegenüber dem Vorjahr nichts verändert.

Laptop

Hier gab es lediglich ein Upgrade auf Fedora 37 und Rambox ist hamsket gewichen.

Desktop-/Server-PC

Auch hier gibt es keine Änderungen gegenüber dem Vorjahr.

Sonstige Geräte im Netzwerk

Unverwüstlich verrichtet mein Brother DCP-540CN weiterhin zuverlässig seinen Dienst. Meine FHEM-Installation hingegen habe ich eingestampft und meinen Pi-Hole auf den Raspberry Pi 1 Rev. B migriert. Damit habe ich wieder einen Pi für neue Basteleien frei.

Zusammenfassung

Viel hat sich hier nicht verändert und ich bin mit dem aktuellen Setup zufrieden. Ob es im Jahr 2023 etwas mehr Veränderungen geben wird, wird sich zeigen.

Ich entschuldige mich direkt für den reißerischen Titel. Ich persönlich glaube nicht, dass sich in dieser Hinsicht 2023 viel verändern wird.

Ich möchte an dieser Stelle lediglich darauf hinweisen, dass ihr meinen aktuellen GnuPG-Public-Key an dieser Stelle zum Download und per Web Key Directory findet.

Im März ist es endlich wieder soweit. Die Chemnitzer Linux-Tage laden am 11. und 12. März in das Hörsaal- und Seminar-Gebäude der Technischen Universität Chemnitz ein.

Nach den Online-Konferenzen der letzten Jahre, mit denen ich nicht wirklich warm geworden bin, freue ich mich sehr darauf, Open Source begeisterte Menschen wieder vor Ort treffen zu können.

Das Programm bietet dieses Jahr 90 Vorträge in sechs parallelen Tracks, neun Workshops und ein spezielles Junior-Programm.

Ich selbst bin dieses Jahr mit zwei Vorträgen am Sonntag vertreten. Dirk, Sujeevan und ich werden euch gemeinsam bewusst machen „Warum man nicht in der IT arbeiten sollte und warum wir es trotzdem tun.“ In meinem Vortrag „Einstieg in die Automatisierung mit Ansible“ geht es darum, dass Konzepte wie Automatisierung und Konfigurationsmanagement nicht nur in die Werkzeugkästen für Hyperscaler gehören, sondern wie sie jedem Sysadmin die tägliche Arbeit erleichtern und der gesamten Organisation von Nutzen sein können.

Als passionierter Autofahrer setze ich dieses Jahr mein Vertrauen in die Bahn, welche mich am Freitag nach Chemnitz und am Sonntag wieder heim bringen soll. Ihr werdet in meinem Konferenzbericht lesen, wie mir diese Erfahrung gefallen haben wird.

So alles klappt, sehen wir uns in Karl-Marx-Stadt.

In diesem dritten Teil meiner Serie über RHEL System Roles nutze ich die Rolle timesync, um die NTP-Pool-Zone de.pool.ntp.org für meine Hosts zu konfigurieren.

Ich möchte mit diesem Artikel zeigen, wie einfach die Nutzung der RHEL System Roles ist, um eine Gruppe von RHEL-Servern zu konfigurieren. Dabei muss ich mich nicht um Details wie die Frage kümmern, ob auf meinen Zielhosts ntpd oder chronyd für die Zeitsynchronisierung genutzt wird. Diese Aufgabe löst die Ansible-Rolle für mich.

Bevor ich fortfahre, habe ich eine Warnung: Diese Rolle ersetzt die Konfiguration auf den Zielsystemen. Alle zuvor dort getroffenen Einstellungen werden verloren gehen.

Man muss sich also entscheiden, ob man die Zeitsynchronisation komplett über diese Rolle steuern möchte oder gar nicht.

Voraussetzungen

Auf dem Ansible-Controller müssen die Pakete ansible-core und rhel-system-roles installiert sein.

Das Playbook

Ich möchte mehrere NTP-Server konfigurieren. Für diesen Anwendungsfall liefert die Rolle timesync bereits ein Beispiel mit, welches ich mittels Copy-Paste-and-Modify in mein Playbook übernehme.

[root@ansible-ctrl ]# cp /usr/share/doc/rhel-system-roles/timesync/example-multiple-ntp-servers-playbook.yml ansible/use_de_ntp_servers.yml

Das Playbook sieht nach der Anpassung wie folgt aus:

- hosts: all
  vars:
    timesync_ntp_servers:
      - hostname: 0.de.pool.ntp.org
        iburst: yes
      - hostname: 1.de.pool.ntp.org
        iburst: yes
      - hostname: 2.de.pool.ntp.org
        iburst: yes
      - hostname: 3.de.pool.ntp.org
        iburst: yes
  roles:
    - rhel-system-roles.timesync

Testlauf in Labor-Umgebung

Um zu sehen, wie die Datei /etc/chrony.conf vor und nach dem Playbook-Lauf aussieht, lasse ich das Playbook zuerst mit den Optionen -C (aktiviert Check-Mode) und -D (zeigt die Änderungen an) laufen. So kann ich vorab prüfen, welche Änderungen vorgenommen werden, bevor es ernst wird. Die Ausgabe ist über 500 Zeilen lang. Ich habe sie auf Gist gepostet und hier eingebunden. Wer sich für die Ausgabe nicht interessiert, kann direkt zur Zusammenfassung springen.

Anschließend habe ich das Playbook ohne die Optionen -C und -D ausgeführt und meine Hosts wie gewünscht konfiguriert.

Zusammenfassung

Mit der RHEL System Role timesync kann die Zeitsynchronisation verschiedener RHEL-Releases schnell und einfach konfiguriert werden, ohne Kenntnis über die konkrete Implementierung auf den Zielsystemen zu besitzen.

Gleichzeitig kann ein Blick in die Struktur der Rolle und den Inhalt der dazugehörigen Dateien Aufschluss darüber geben, wie Ansible-Rollen für mehrere RHEL-Major-Releases erstellt werden können. Man kann dies für die Erstellung eigener Rollen mit ein wenig Transferleistung wiederverwenden.

Weiterführende Quellen und Links

1. Red Hat Enterprise Linux (RHEL) System Roles {en}
2. Ansible Documentation: Role Directory Structure {en}
3. Red Hat Software and Download Center {en}
4. Die Vorteile einer Red Hat Subskription
5. RHEL System Roles: selinux
6. RHEL System Roles: sshd
7. RHEL System Roles: firewall

In Teil 4 meiner losen Reihe über die RHEL System Roles stelle ich die Ansible-Rolle sshd vor. Diese dient der Konfiguration des OpenSSH-Servers, einem der wichtigsten Dienste in Linux- und UNIX-Systemen.

Wer die ersten Teile dieser Reihe gelesen hat, ist inzwischen mit der grundsätzlichen Anwendung dieser Ansible-Rollen vertraut. Die Rolle sshd bildet hier keine Ausnahme. Wendet man die Rolle ohne weitere Konfiguration auf Ziel-Systeme an, konfiguriert sie den OpenSSH-Server entsprechend der Standard-Konfiguration des jeweiligen Betriebssystems. Es werden alle Optionen der sshd_config(5) unterstützt.

Ein Wort der Warnung: Mit dieser Rolle konfiguriert ihr den SSH-Dienst der Zielsysteme. Wenn dabei ein Fehler passiert, könnt ihr euch und euren Ansible-Controller aussperren und verliert ggf. den Zugriff auf die Systeme. Behaltet dies bitte im Hinterkopf und sorgt ggf. für alternative Zugänge, wie z.B. über eine lokale Konsole.

Bei der Konfiguration meiner Server ist mir persönlich wichtig, dass

• der Benutzer root sich nur mittels SSH-Public-Key-Verfahren anmelden kann,
• die Public-Key-Authentifizierung aktiviert ist,
• die Passwort-Authentifizierung deaktiviert ist und
• in der Datei .ssh/authorized_keys des jeweiligen Benutzers nach dem SSH-Public-Key gesucht wird.

Darüber hinaus möchte ich alle Git-bezogenen Umgebungsvariablen (GIT_*) nutzen. Die übrigen Einstellungen möchte ich auf den Standard-Werten des jeweiligen Betriebssystems belassen.

Im Folgenden beschreibe ich, wie sich diese mit der RHEL System Role sshd umsetzen lässt.

Voraussetzungen

Wie bei allen RHEL System Roles müssen auch hier die Pakete ansible-core und rhel-system-roles inkl. ihrer Abhängigkeiten auf dem Ansible-Controller installiert sein. Der Ansible-Controller muss die Ziel-Hosts über SSH erreichen können und über einen Benutzer mit sudo-Berechtigungen verfügen.

Das Playbook

Es werden bereits zwei Beispiel-Playbooks mitgeliefert, die sich im Pfad /usr/share/doc/rhel-system-roles/sshd/ befinden. Diese heißen:

• example-accept-env-playbook.yml und
• example-root-login-playbook.yml.

Aus diesen beiden Beispieldateien habe ich das folgende Playbook für meine Labor-Umgebung erstellt:

---
- hosts: all
  tasks:
  - name: Configure sshd to accept some useful environment variables
    include_role:
      name: rhel-system-roles.sshd
    vars:
      sshd:
        PermitRootLogin: without-password
        PasswordAuthentication: no
        PubkeyAuthentication: yes
        AuthorizedKeysFile: .ssh/authorized_keys
        # there are some handy environment variables to accept
        AcceptEnv:
          LANG
          LS_COLORS
          EDITOR
          GIT_*

Wie zu sehen ist, habe ich mich entschieden, noch ein paar weitere Umgebungsvariablen zu konfigurieren. Diese habe ich aus dem Beispiel example-accept-env-playbook.yml übernommen.

Testlauf in Labor-Umgebung

Auch dieses Playbook habe ich in meiner Labor-Umgebung, bestehend aus einem RHEL8-Ansible-Controller und jeweils einem rhel{7..9}-Client laufen lassen. Mit den Optionen -C -D ist die Ausgabe 707 Zeilen lang, weswegen der folgende Code-Block nur den Aufruf und das Ergebnis zeigt.

[root@ansible-ctrl ansible]# ansible-playbook sshd_config.yml -C -D

PLAY [all] ************************************************************************************************************
[...]
PLAY RECAP *******************************************************************************************************************************
ansible-pctrl              : ok=20   changed=2    unreachable=0    failed=0    skipped=13   rescued=0    ignored=0   
rhel7                      : ok=20   changed=2    unreachable=0    failed=0    skipped=13   rescued=0    ignored=0   
rhel8                      : ok=20   changed=2    unreachable=0    failed=0    skipped=13   rescued=0    ignored=0   
rhel9                      : ok=21   changed=2    unreachable=0    failed=0    skipped=12   rescued=0    ignored=0

Zusammenfassung

Die RHEL System Role sshd wurde kurz vorgestellt und genutzt, um meine bevorzugten Einstellungen für den OpenSSH-Dienst in meiner Labor-Umgebung zu konfigurieren. Alle Optionen in der sshd_config(5), welche ich nicht explizit über die Ansible-Rolle konfiguriert habe, werden auf die Standardwerte des Betriebssystems eingestellt. Es ist also ggf. Vorsicht geboten, wenn Systeme mit bestehender Konfiguration bearbeitet werden.

Selbstverständlich schützt ein einmaliger Playbook-Lauf nicht davor, dass ein Benutzer mit root-Berechtigungen lokale Änderungen an der Datei /etc/ssh/sshd_config vornimmt. Dies mag vorübergehend für Tests auch so gewollt sein. Damit die Konfiguration nicht dauerhaft vom SOLL-Zustand abweicht, kann man das Playbook regelmäßig durch cron(8) ausführen lassen, um evtl. Abweichungen zu korrigieren.

Quellen und weiterführende Links

1. Red Hat Enterprise Linux (RHEL) System Roles {en}
2. Ansible Documentation: Role Directory Structure {en}
3. Red Hat Software and Download Center {en}
4. Die Vorteile einer Red Hat Subskription
5. RHEL System Roles: selinux
6. RHEL System Roles: timesync
7. RHEL System Roles: firewall