Schlagwort-Archive: osbn

Tag OSBN

Gold-Images für KVM/QEMU erstellen

Nachdem ich bereits beschrieben habe, wie ich Labor-Umgebungen mit Ansible in KVM erstelle, beschreibe ich in diesem Artikel, wie ich die dort verwendeten Gold-Images erstelle.

Ich erkläre kurz, was ein Gold-Image ist und wofür man es verwendet. Anschließend zeige ich, wie man mit dem Programm qemu-img eine Image-Datei auf der Kommandozeile erzeugt und diese im Installationsprozess für die Partitionierung und Erzeugung des LVM nutzt. Im Anschluss daran dokumentiere ich, welche Laufwerke und Dateisysteme ich für welchen Zweck erstelle und warum ich mich so entschieden habe. Der Text endet mit einer Sammlung von Quellen und weiterführenden Links zum Thema.

Der Text soll mir helfen, in Zukunft nachvollziehen zu können, warum ich mich so entschieden habe. Für euch mag er als Information dienen, wie ich im Unterschied zu euch an das Thema herangehe. Wer noch nie etwas von Gold-Images gehört hat, findet in diesem Text eine Erklärung und passende Quellen dazu.

Was ist ein Gold-Image?

Ein Gold-Image, auch Golden Image oder Baseline-Image genannt, bezeichnet eine Vorlage (engl. template) in virtuellen Umgebungen, woraus sich virtuelle Maschinen (VMs) klonen lassen (siehe [1-5]).

In ein Gold-Image werden all die Softwarekomponenten, Anwendungen und Konfigurationsoptionen aufgenommen, welche Bestandteil aller davon abgeleiteten VMs sein sollen. Klonen ermöglicht die schnelle Bereitstellung neuer Systeme. Dies ist besonders dann nützlich, wenn sich die VMs sehr ähnlich sind und man nur eine geringe Anzahl von Gold-Images pflegen muss.

Ich nutze Gold-Images, um für die von mir verwendeten Linux-Distributionen jeweils eine Installation manuell durchzuführen, welche die minimal erforderlichen Pakete enthält, um die abgeleiteten Klone mit Ansible fertig konfigurieren zu können. Wie ich dabei vorgehe, beschreibe ich in den folgenden Abschnitten.

Erstellung der Image-Datei

Im ersten Schritt erstelle ich Image-Dateien im qcow2-Format. Bei diesem Format handelt es sich um das heute gebräuchliche Format in KVM-/QEMU-Umgebungen. Zur Erstellung verwende ich das QEMU disk image utility qemu-img.

Die allgemeine Form des Befehls lautet (Details siehe Manpage qemu-img(1)):

qemu-img create -f FORMAT DATEINAME GRÖßE

Der folgende Befehl erstellt eine Image-Datei im qcow2-Format, mit 20 Gigabyte Größe und dem Dateinamen debian11-template.qcow2 im Pfad /var/lib/libvirt/images/:

$ qemu-img create -f qcow2 /var/lib/libvirt/images/debian11-template.qcow2 20G
Formatting '/var/lib/libvirt/images/debian11-template.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=21474836480 lazy_refcounts=off refcount_bits=16

Dabei werden die 20 GB nicht sofort alloziert. Zu Beginn belegt die Datei lediglich einige Kilobyte und kann je nach Nutzung auf die maximale Größe von 20 GB anwachsen. Diese Bereitstellungsform ist auch als Thin provisioning bekannt.

ls -sh /var/lib/libvirt/images/debian11-template.qcow2
193K /var/lib/libvirt/images/debian11-template.qcow2

Es lässt sich auf diese Weise mehr Speicherplatz provisionieren, als tatsächlich im System zur Verfügung steht. Dabei gilt jedoch zu beachten, dass sich die Physik nicht betrügen lässt. Man ist gut beraten, den realen Speicherverbrauch zu überwachen, um volllaufende Dateisysteme zu vermeiden.

Installation und Partitionierung

Bei der Installation des Gold-Images für Labor-Umgebungen mache ich es mir relativ einfach. Ich erstelle z.B. im virt-manager oder cockpit eine VM, die ich von einem Installations-ISO-Image der jeweiligen Distribution installiere.

Bei Debian installiere ich für gewöhnlich ein System ohne grafische Oberfläche, welches zusätzlich zur Basis-Installation lediglich die Paketgruppen SSH-Server und System-Werkzeuge umfasst. Bei Fedora oder RHEL führe ich die Minimal-Installation durch.

Ob bzw. welches Passwort für den Benutzer root vergeben wird, ist an dieser Stelle nicht wichtig, da dies beim Klonen in eine neue VM durch die Ansible-Rolle kvm_provision_lab geändert wird.

Der Installer erkennt eine Festplatte, die in diesem Text exemplarisch als /dev/vda bezeichnet wird. Diese wird nun wie folgt konfiguriert.

Vorwort zur Partitionierung

Das optimale Partitionslayout hängt vom konkreten Anwendungsfall ab und kann sich je nach Umgebung stark unterscheiden. Das von mir verwendete Layout passt aktuell am besten zu meinen Anforderungen. Es mag in Zukunft völlig anders aussehen.

Ich beschreibe, welche Partitionen ich erstelle und erläutere, warum ich mich zum Zeitpunkt der Erstellung dieses Textes dafür entschieden habe. Bitte übernehmt dieses Layout nicht stumpf, sondern überlegt, ob es zu euren Anforderungen passt.

Primäre Partition /dev/vda1 für /boot

In dieser Partition werden die Kernel und das initramfs abgelegt. Nach meiner Erfahrung reicht eine Größe von 1 GiB aus, um auch einige ältere Kernel vorzuhalten. Formatiert habe ich diese Partition mit dem Dateisystem ext4.

Ich bevorzuge ext4 gegenüber XFS, da es sich im Gegensatz zu letzterem auch verkleinern lässt. Zugegeben, dass dies notwendig ist, ist mir in 20 Jahren nur einmal untergekommen. Doch in diesem einen Moment war ich froh, dass es möglich war.

LVM, PV, VG, LV, Dateisysteme und Einhängepunkte

Der Logical Volume Manager (LVM) (siehe [11-13]) bietet die Möglichkeit, Partitionen (genaugenommen Logical Volumes) für weitere Einhängepunkte zu erstellen, welche sich später noch flexibel in der Größe anpassen lassen (Vergrößern und Verkleinern). Und dies, ohne die verwendeten Dateisysteme aushängen zu müssen.

Wer mit den für LVM relevanten Begriffen Physical Volume, Volume Group und Logical Volume nicht vertraut ist, findet weiterführende Hinweise in [12] für Debian bzw. [13] für RHEL. Ich werde die Erstellung hier nicht im Detail beschreiben.

Ich erstelle eine zweite primäre Partition /dev/vda2 mit Typ LVM, welcher ich die verbleibende Speicherkapazität von 19 GiB zuweise. Mein fertiges Partitionslayout sieht wie folgt aus:

lsblk -o +FSTYPE
NAME                  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT FSTYPE
sr0                    11:0    1 1024M  0 rom             
vda                   254:0    0   20G  0 disk            
├─vda1                254:1    0  953M  0 part /boot      ext4
└─vda2                254:2    0 19.1G  0 part            LVM2_member
  ├─vg_system-root    253:0    0  9.3G  0 lvm  /          ext4
  ├─vg_system-var_log 253:1    0  4.7G  0 lvm  /var/log   ext4
  └─vg_system-home    253:2    0  1.9G  0 lvm  /home      ext4

Vorstehendem Code-Block ist zu entnehmen, dass ich drei Logical Volumes für die Einhängepunkte /, /var/log und /home verwende. Ich verwende auch hier durchgängig das ext4-Dateisystem.

Log-Dateien und unkontrolliert wachsende Daten in HOME-Verzeichnissen führen schnell dazu, dass das Root-Dateisystem (/) vollläuft. Dies lässt sich mit der Verwendung separater Einhängepunkte sicher verhindern.

Eurem aufmerksamen Auge ist sicher aufgefallen, dass ich keine Swap-Partition verwende. Da ich sie für die meist kurzlebigen Labor-VMs nicht benötige, lasse ich diese in der Regel weg. Für Systeme, die ich für langfristigen Betrieb installiere, füge ich diese nachträglich hinzu. Dank LVM ist dies kein Problem.

Darüber, ob man eine Swap-Partition braucht und wie groß diese sein sollte, werden teils esoterische Diskussionen geführt. Ich selbst orientiere mich an Table B.1. Recommended system swap space aus [14].

Damit habe ich ein Gold-Image erstellt, welches mir als Vorlage für weitere VMs dient und dabei nur wenig Platz auf der Festplatte des Hypervisor belegt:

ls -sh /var/lib/libvirt/images/debian11-template.qcow2
2.3G /var/lib/libvirt/images/debian11-template.qcow2

Sysprep

Sysprep ist ursprünglich ein Programm von Microsoft, mit welchem Gold-Images für die automatische Verteilung von Microsoft Windows vorbereitet werden. Heute taucht dieser Begriff in den Programmbezeichnungen weiterer Projekte auf und beschreibt gleichzeitig die Tätigkeit, ein Gold-Image für die weitere Verwendung vorzubereiten. Ich selbst verwende das Programm virt-sysprep von Richard W.M. Jones (Red Hat) und Wanglong Gao (Fujitsu Ltd.).

Virt-sysprep entfernt Einstellungen, User, Host-spezifische Dateien und leert Protokolldateien in dem erzeugten Image. Damit soll sichergestellt werden, dass die von dem Gold-Image abgeleiteten VMs keine Eigenschaften besitzen, die spezifisch für das Original sind, wie z.B. der Hostname, MAC-Adressen oder die SSH-Host-Keys, um nur drei Beispiele zu nennen. Die Anwendung ist daher dringend empfohlen.

Mit dem Befehl virt-sysprep --list-operations kann man sich die Aktionen anzeigen lassen, die virt-sysprep ausführen kann. Die Standard-Aktionen sind in der Ausgabe mit einem ‚*‘ markiert. Unter RHEL 9 sieht die Ausgabe wie folgt aus:

$ virt-sysprep --list-operations
abrt-data * Remove the crash data generated by ABRT
backup-files * Remove editor backup files from the guest
bash-history * Remove the bash history in the guest
blkid-tab * Remove blkid tab in the guest
ca-certificates   Remove CA certificates in the guest
crash-data * Remove the crash data generated by kexec-tools
cron-spool * Remove user at-jobs and cron-jobs
customize * Customize the guest
dhcp-client-state * Remove DHCP client leases
dhcp-server-state * Remove DHCP server leases
dovecot-data * Remove Dovecot (mail server) data
firewall-rules   Remove the firewall rules
flag-reconfiguration   Flag the system for reconfiguration
fs-uuids   Change filesystem UUIDs
ipa-client * Remove the IPA files
kerberos-data   Remove Kerberos data in the guest
kerberos-hostkeytab * Remove the Kerberos host keytab file in the guest
logfiles * Remove many log files from the guest
lvm-system-devices * Remove LVM2 system.devices file
lvm-uuids * Change LVM2 PV and VG UUIDs
machine-id * Remove the local machine ID
mail-spool * Remove email from the local mail spool directory
net-hostname * Remove HOSTNAME and DHCP_HOSTNAME in network interface configuration
net-hwaddr * Remove HWADDR (hard-coded MAC address) configuration
net-nmconn * Remove system-local NetworkManager connection profiles (keyfiles)
pacct-log * Remove the process accounting log files
package-manager-cache * Remove package manager cache
pam-data * Remove the PAM data in the guest
passwd-backups * Remove /etc/passwd- and similar backup files
puppet-data-log * Remove the data and log files of puppet
rh-subscription-manager * Remove the RH subscription manager files
rhn-systemid * Remove the RHN system ID
rpm-db * Remove host-specific RPM database files
samba-db-log * Remove the database and log files of Samba
script * Run arbitrary scripts against the guest
smolt-uuid * Remove the Smolt hardware UUID
ssh-hostkeys * Remove the SSH host keys in the guest
ssh-userdir * Remove ".ssh" directories in the guest
sssd-db-log * Remove the database and log files of sssd
tmp-files * Remove temporary files
udev-persistent-net * Remove udev persistent net rules
user-account   Remove the user accounts in the guest
utmp * Remove the utmp file
yum-uuid * Remove the yum UUID
customize * Customize the guest
dhcp-client-state * Remove DHCP client leases
dhcp-server-state * Remove DHCP server leases
dovecot-data * Remove Dovecot (mail server) data
firewall-rules   Remove the firewall rules
flag-reconfiguration   Flag the system for reconfiguration
fs-uuids   Change filesystem UUIDs
ipa-client * Remove the IPA files
kerberos-data   Remove Kerberos data in the guest
kerberos-hostkeytab * Remove the Kerberos host keytab file in the guest
logfiles * Remove many log files from the guest
lvm-system-devices * Remove LVM2 system.devices file
lvm-uuids * Change LVM2 PV and VG UUIDs
machine-id * Remove the local machine ID
mail-spool * Remove email from the local mail spool directory
net-hostname * Remove HOSTNAME and DHCP_HOSTNAME in network interface configuration
net-hwaddr * Remove HWADDR (hard-coded MAC address) configuration
net-nmconn * Remove system-local NetworkManager connection profiles (keyfiles)
pacct-log * Remove the process accounting log files
package-manager-cache * Remove package manager cache
pam-data * Remove the PAM data in the guest
passwd-backups * Remove /etc/passwd- and similar backup files
puppet-data-log * Remove the data and log files of puppet
rh-subscription-manager * Remove the RH subscription manager files
rhn-systemid * Remove the RHN system ID
rpm-db * Remove host-specific RPM database files
samba-db-log * Remove the database and log files of Samba
script * Run arbitrary scripts against the guest
smolt-uuid * Remove the Smolt hardware UUID
ssh-hostkeys * Remove the SSH host keys in the guest
ssh-userdir * Remove ".ssh" directories in the guest
sssd-db-log * Remove the database and log files of sssd
tmp-files * Remove temporary files
udev-persistent-net * Remove udev persistent net rules
user-account   Remove the user accounts in the guest
utmp * Remove the utmp file
yum-uuid * Remove the yum UUID

Selbstverständlich gibt es mit virt-sysprep(1) auch eine Manpage, welche die Nutzung des Programms und sämtliche Optionen erläutert.

Es ist sehr wichtig, dass die zu behandelnde Domain (VM) ausgeschaltet ist, bevor virt-sysprep gestartet wird, um eine Korruption der Image-Datei zu vermeiden.

Der nun folgende Code-Block zeigt die Anwendung von virt-sysprep auf die qcow2-Datei meines debian11-templates. Die dabei verwendeten Option --operations defaults,-ssh-userdir sorgt dafür, dass alle Standard-Operationen mit der Ausnahme durchgeführt werden, dass die .ssh-Verzeichnisse der User erhalten bleiben. Die Option --firstboot-command 'dpkg-reconfigure openssh-server' stellt sicher, dass beim ersten Start des Klons neue SSH-Hostkeys generiert werden. Andernfalls kann der SSH-Dienst nicht starten und ich wäre nicht in der Lage mich via SSH anzumelden. Anschließend ist das Image bereit, um geklont bzw. kopiert zu werden.

$ virt-sysprep -a /var/lib/libvirt/images/debian11-template.qcow2 --operations defaults,-ssh-userdir --firstboot-command 'dpkg-reconfigure openssh-server'
[   0.0] Examining the guest ...
[   2.0] Performing "abrt-data" ...
[   2.0] Performing "backup-files" ...
[   2.1] Performing "bash-history" ...
[   2.1] Performing "blkid-tab" ...
[   2.1] Performing "crash-data" ...
[   2.1] Performing "cron-spool" ...
[   2.1] Performing "dhcp-client-state" ...
[   2.1] Performing "dhcp-server-state" ...
[   2.1] Performing "dovecot-data" ...
[   2.1] Performing "ipa-client" ...
[   2.1] Performing "kerberos-hostkeytab" ...
[   2.2] Performing "logfiles" ...
[   2.2] Performing "lvm-system-devices" ...
[   2.2] Performing "machine-id" ...
[   2.2] Performing "mail-spool" ...
[   2.2] Performing "net-hostname" ...
[   2.2] Performing "net-hwaddr" ...
[   2.3] Performing "net-nmconn" ...
[   2.3] Performing "pacct-log" ...
[   2.3] Performing "package-manager-cache" ...
[   2.3] Performing "pam-data" ...
[   2.3] Performing "passwd-backups" ...
[   2.3] Performing "puppet-data-log" ...
[   2.3] Performing "rh-subscription-manager" ...
[   2.3] Performing "rhn-systemid" ...
[   2.4] Performing "rpm-db" ...
[   2.4] Performing "samba-db-log" ...
[   2.4] Performing "script" ...
[   2.4] Performing "smolt-uuid" ...
[   2.4] Performing "ssh-hostkeys" ...
[   2.4] Performing "sssd-db-log" ...
[   2.4] Performing "tmp-files" ...
[   2.4] Performing "udev-persistent-net" ...
[   2.4] Performing "utmp" ...
[   2.4] Performing "yum-uuid" ...
[   2.4] Performing "customize" ...
[   2.4] Setting a random seed
[   2.5] Setting the machine ID in /etc/machine-id
[   2.5] Installing firstboot command: dpkg-reconfigure openssh-server
[   2.5] SELinux relabelling
[   2.5] Performing "lvm-uuids" ...

Das Programm ist nicht auf qcow2-Images beschränkt. Einen weiteren Anwendungsfall habe ich bereits hier im Blog beschrieben: VMware ESXi: VMDK-Datei einer Gast-VM mit virt-sysprep bereinigen.

Verwendung der Gold-Images

Die Gold-Images werden verwendet, um durch Klonen neue VMs zu erstellen. Ich verwende dazu die Eingangs erwähnte Ansible-Rolle kvm_provision_lab.

Was tun, wenn der Platz knapp wird?

Wird im Laufe des Lebenszyklus einer VM mehr Speicherplatz benötigt, so lässt sich das Vorgehen wie folgt skizzieren:

  1. Neue virtuelle Festplatte mit ausreichend Speicherkapazität der VM hinzufügen.
  2. Eine Partition auf der neuen virtuellen Festplatte erstellen (optional).
  3. Mit pvcreate ein neues Physical Volume erstellen.
  4. Das Physical Volume mit vgextend der Volume Group hinzufügen.
  5. Das Logical Volume mit lvextend vergrößern.

Die Schritte 3-5 werden ausführlich in der RHEL-9-Dokumentation in Chapter 5. Modifying the size of a logical volume beschrieben. Dort wird auch beschrieben, wie ein Logical Volume verkleinert werden kann.

Falls ihr euch hierzu ein Tutorial wünscht, lasst es mich bitte in den Kommentaren wissen. Dann liefere ich ein entsprechendes Beispiel nach.

  1. Was ist ein Golden Image? URL: https://www.redhat.com/de/topics/linux/what-is-a-golden-image.
  2. What is a golden image? On opensource.com by Seth Kenlon (Team, Red Hat). URL: https://opensource.com/article/19/7/what-golden-image.
  3. What is a golden image? Definition by Nick Martin on TechTarget. URL: https://www.techtarget.com/searchitoperations/definition/golden-image
  4. Definition Golden Image (auch Master Image oder Goldenes Abbild). ComputerWeekly.de. URL: https://www.computerweekly.com/de/definition/Golden-Image-auch-Master-Image-oder-Goldenes-Abbild
  5. Was ist ein Golden Image? 21.11.2018: Autor / Redakteur: Dipl. Betriebswirt Otto Geißler / Ulrike Ostler. URL: https://www.datacenter-insider.de/was-ist-ein-golden-image-a-775197/
  6. Wikipedia-Artikel zu qcow {EN}
  7. QEMU disk image utility
  8. Wikepdia-Artikel Thin zu provisioning {EN}
  9. Performing a standard RHEL 9 installation; Appendix B. Partitioning reference; URL: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/performing_a_standard_rhel_9_installation/partitioning-reference_installing-rhel#recommended-partitioning-scheme_partitioning-reference
  10. Debian: Empfohlene Partitionsschemata. URL: https://www.debian.org/releases/bullseye/amd64/apcs03.de.html
  11. Wikipedia-Artikel zu LVM
  12. LVM – Debian Wiki {EN}
  13. Configuring and managing logical volumes. Red Hat Enterprise Linux 9. A guide to the configuration and management of LVM logical volumes. {EN}
  14. Appendix B. Partitioning reference. Performing a standard RHEL 9 installation. {EN}
  15. VMware ESXi: VMDK-Datei einer Gast-VM mit virt-sysprep bereinigen

RHEL System Roles: sshd

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

RHEL System Roles: timesync

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.

  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

Vorfreude auf die Chemnitzer Linux-Tage 2023

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.

Meine privaten Arbeitsmittel 2023

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.

IPFire oder nicht?

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

Vereinfachte Struktur des betrachteten Netzwerks

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.

Vereinfachte Netzwerkstruktur mit IPFire

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

Was ich 2022 für/mit FLOSS getan habe

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:

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:

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:

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:

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:

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.“

Der My-IT-Brain Jahresrückblick 2022

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:

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:

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.

Der Prototype Fund fördert eure Open-Source-Projektidee

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.