Schlagwortarchiv: Planet

Tag für den Ubuntuusers.de Planeten.

Wie dnf.8.gz in den Container kam

Schreibe eine Antwort

Die folgende Geschichte soll mir zur Erinnerung und euch zur Unterhaltung dienen. Sie handelt von CentOS Stream 10, Containern und der Manpage dnf(8). Aber lest selbst.

Es war einmal ein Systemadministrator, der beim Training einige Subkommandos von dnf updateinfo kennenlernte, von deren Existenz er bislang nichts wusste. Und diese Subkommandos heißen list, info und summary. Neugierig schaute er in die Manpage dnf(8), doch zu seinem Erstaunen schwieg sich diese zu diesen Subkommandos aus.

Wut stieg in unserem Sysadmin auf. Wieder einmal haben sich die Entwickler keine Mühe gegeben, die Funktionalität ihrer Anwendung vernünftig zu dokumentieren. Die Qualitätssicherung hat geschlafen. So kann man doch nicht arbeiten. Doch nach dem ersten Wutanfall beschloss der Sysadmin, der Sache in Ruhe auf den Grund zu gehen, bevor er diesen Misstand anprangern würde.

Die Distribution des Sysadmins ist dafür bekannt, dass unter bestimmten Umständen Funktionalität von Upstream zurückportiert wird. Vielleicht hatte sich hier eine Diskrepanz eingeschlichen. Vielleicht war dieser Fehler in einer neueren Version ausgemerzt. Um dies schnell zu überprüfen, wollte unser Sysadmin einen Blick in dnf(8) in Centos 10 Stream werfen. Dazu führte er folgende Befehle in einer Kommandozeile aus:

$ podman run --rm -it centos:stream10
[root@01ede4521839 /]# man 8 dnf
bash: man: command not found
[root@01ede4521839 /]#

Mit einem Augenrollen erinnerte sich unser Sysadmin daran, dass Container-Images nur das absolut Notwendige enthalten, um möglichst wenig Speicherplatz auf der Festplatte zu belegen. Darüber, was absolut notwendig ist, werden seit anbeginn des Containerzeitalters philosophische Streitgespräche geführt. Also prüfte unser Sysadmin, ob es einen vertrauten Paketmanager gab, um die Manpages nachzuinstallieren:

[root@01ede4521839 /]# dnf in man-db man-pages
CentOS Stream 10 - BaseOS                       2.6 MB/s | 6.2 MB     00:02    
CentOS Stream 10 - AppStream                    1.5 MB/s | 2.4 MB     00:01    
CentOS Stream 10 - Extras packages              3.3 kB/s | 3.5 kB     00:01    
Dependencies resolved.
================================================================================
 Package             Architecture   Version                Repository      Size
================================================================================
Installing:
 man-db              x86_64         2.12.0-8.el10          baseos         1.3 M
 man-pages           noarch         6.06-3.el10            baseos         3.7 M
Installing dependencies:
 groff-base          x86_64         1.23.0-10.el10         baseos         1.1 M
 less                x86_64         661-3.el10             baseos         191 k
 libpipeline         x86_64         1.5.7-7.el10           baseos          53 k

Transaction Summary
================================================================================
Install  5 Packages

Total download size: 6.4 M
Installed size: 9.9 M
Is this ok [y/N]:
…
Installed:
  groff-base-1.23.0-10.el10.x86_64          less-661-3.el10.x86_64              
  libpipeline-1.5.7-7.el10.x86_64           man-db-2.12.0-8.el10.x86_64         
  man-pages-6.06-3.el10.noarch             

Complete!
[root@01ede4521839 /]# mandb
Processing manual pages under /usr/share/man...
Updating index cache for path `/usr/share/man/man7'. Wait...mandb: can't resolve man7/groff_man.7
mandb: warning: /usr/share/man/man7/man.7.gz: bad symlink or ROFF `.so' request
mandb: can't resolve man7/groff_man.7
mandb: warning: /usr/share/man/man7/man.man-pages.7.gz: bad symlink or ROFF `.so' request
Updating index cache for path `/usr/share/man/man3type'. Wait...done.
Checking for stray cats under /usr/share/man...
Checking for stray cats under /var/cache/man...
Processing manual pages under /usr/local/share/man...
Updating index cache for path `/usr/local/share/man/mann'. Wait...done.
Checking for stray cats under /usr/local/share/man...
Checking for stray cats under /var/cache/man/local...
45 man subdirectories contained newer manual pages.
2701 manual pages were added.
0 stray cats were added.
0 old database entries were purged.
[root@01ede4521839 /]# man 8 dnf
No manual entry for dnf in section 8

Resultat: Kein which-Befehl verfügbar. Diese Container-Image-Kuratöre sparten aber wirklich an allem. Doch der obige Codeblock enthüllt noch mehr. Zwar war der Paketmanager dnf installiert, auch die Manpages waren nun vorhanden, nur die Manpage dnf(8) fehlte immer noch. Und so bemühte der Sysadmin wieder die Tastatur, um zu prüfen, ob die entsprechende Datei tatsächlich fehlt, welches Paket sie bereitstellt und um das Problem zu lösen. Sehet und staunet:

[root@01ede4521839 /]# stat /usr/share/man/man8/dnf.8.gz
stat: cannot statx '/usr/share/man/man8/dnf.8.gz': No such file or directory
[root@01ede4521839 /]# dnf provides /usr/share/man/man8/dnf.8.gz
…    
dnf-4.20.0-9.el10.noarch : Package manager
Repo        : baseos
Matched from:
Filename    : /usr/share/man/man8/dnf.8.gz
[root@01ede4521839 /]# dnf reinstall dnf
Last metadata expiration check: 0:01:01 ago on Wed Jan  1 14:31:37 2025.
Dependencies resolved.
================================================================================
 Package       Architecture     Version                  Repository        Size
================================================================================
Reinstalling:
 dnf           noarch           4.20.0-9.el10            baseos           478 k

Transaction Summary
================================================================================

Total download size: 478 k
Installed size: 2.5 M
Is this ok [y/N]:y
…
Reinstalled:
  dnf-4.20.0-9.el10.noarch                                                      

Complete!
[root@01ede4521839 /]# stat /usr/share/man/man8/dnf.8.gz
  File: /usr/share/man/man8/dnf.8.gz -> dnf4.8.gz
  Size: 9         	Blocks: 8          IO Block: 4096   symbolic link
Device: 0,111	Inode: 6118189     Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-10-28 20:00:00.000000000 -0400
Modify: 2024-10-28 20:00:00.000000000 -0400
Change: 2025-01-01 14:32:59.692356995 -0500
 Birth: 2025-01-01 14:32:59.691356987 -0500

Überzeugt, dass der Spuk nun ein Ende habe, versuchte es unser Sysadmin erneut:

[root@01ede4521839 /]# man 8 dnf
No manual entry for dnf in section 8

Moment! Die Datei ist da, die Manpage jedoch nicht? Sind hier dunkle Mächte am Werke? Nein, denn wie die folgenden Befehle offenbarten, lag die Ursache lediglich in kaputten Symlinks und fehlenden Paketen:

[root@01ede4521839 /]# ls -l /usr/share/man/man8/dnf.8.gz
lrwxrwxrwx. 1 root root 9 Oct 28 20:00 /usr/share/man/man8/dnf.8.gz -> dnf4.8.gz
[root@01ede4521839 /]# ls -l /usr/share/man/man8/dnf4.8.gz
ls: cannot access '/usr/share/man/man8/dnf4.8.gz': No such file or directory
[root@01ede4521839 /]# dnf provides /usr/share/man/man8/dnf4.8.gz
Last metadata expiration check: 0:05:59 ago on Wed Jan  1 14:31:37 2025.
…
python3-dnf-4.20.0-9.el10.noarch : Python 3 interface to DNF
Repo        : baseos
Matched from:
Filename    : /usr/share/man/man8/dnf4.8.gz

[root@01ede4521839 /]# dnf list python3-dnf
Last metadata expiration check: 0:06:16 ago on Wed Jan  1 14:31:37 2025.
Installed Packages
python3-dnf.noarch                     4.20.0-9.el10                     @System

Getrieben von Ungeduld und etwas Frust installierte unser Sysadmin nun auch das Paket python3-dnf.noarch neu, in einem letzten, verzweifelten Versuch, endlich die lang ersehnte Manpage zu erhalten.

[root@01ede4521839 /]# dnf reinstall python3-dnf.noarch
…
Reinstalled:
  python3-dnf-4.20.0-9.el10.noarch                                              

Complete!
[root@01ede4521839 /]# man 8 dnf
DNF4(8)                               DNF                              DNF4(8)

NAME
       dnf4 - DNF Command Reference

SYNOPSIS
       dnf [options] <command> [<args>...]

DESCRIPTION
       DNF  is  the  next upcoming major version of YUM, a package manager for
       RPM-based Linux distributions. It roughly maintains  CLI  compatibility
       with YUM and defines a strict API for extensions and plugins.

Na endlich! Da war sie, die so lang ersehnte und schmerzlich vermisste Manpage. Und die Mühe unseres Sysadmins wurde mit der Erkenntnis belohnt, dass die gesuchte Information auch in dieser Version von dnf(8) nicht enthalten war. Zufrieden wandte sich der Sysadmin nun dem Ticketsystem zu, um zu erfragen, warum die gesuchten Informationen nicht vorhanden sind und um eine Ergänzung anzuregen.

Und wenn er nicht gestorben ist, wartet er noch immer auf eine Antwort.

Und die Moral von der Geschichte?

Erwarte nicht Manpages in Container-Images zu finden. Unser Sysadmin wäre deutlich schneller am ZIel angelangt, hätte er direkt in den Quelltext geschaut: https://github.com/rpm-software-management/dnf/blob/master/doc/command_ref.rst

Linux-Server mit oder ohne Swap-Partition bereitstellen?

10 Antworten

Wir schreiben das Jahr 2025. Die Frage, ob man Linux-Server mit oder ohne Swap-Partition betreiben sollte, spaltet die Linux-Gemeinschaft in einer Weise, wie wir es seit dem Editor War nicht mehr gesehen haben…

So könnte ein spannender Film für Sysadmins anfangen, oder? Ich möchte aber keinen Streit vom Zaun brechen, sondern bin an euren Erfahrungen und Gedanken interessiert. Daher freue ich mich, wenn ihr euch die Zeit nehmt, folgende Fragen in den Kommentaren zu diesem Beitrag oder in einem eigenen Blogpost zu beantworten.

  • Stellt ihr Linux-Server mit Swap-Partition bereit und wie begründet ihr eure Entscheidung?
  • Hat euch die Swap-Partition bei sehr hoher Speicherlast schon mal die Haut bzw. Daten gerettet?
  • War der Server während des Swapping noch administrierbar? Falls ja, welche Hardware wurde für die Swap-Partition genutzt?

Eine kleine Mastodon-Umfrage lieferte bisher folgendes Bild:

Quelle: https://social.anoxinon.de/@Tronde/114485601894007649

Schaue ich mir meine eigenen Server an, so ergibt sich ein gemischtes Bild:

  • Debian mit LAMP-Stack und Containern: 16 GB RAM & kein Swap
  • RHEL-KVM-Hypervisor 1: 32 GB RAM & 4 GB Swap
  • RHEL-KVM-Hypervisor 2: 128 GB RAM & kein Swap
  • RHEL-Container-Host (VM): 4 GB RAM & 4 GB Swap

Bis auf den Container-Host handelt es sich um Bare-Metal-Server.

Ich kann mich nicht daran erinnern, dass jemals einem dieser Systeme der Hauptspeicher ausgegangen ist oder der Swapspeicher genutzt worden wäre. Ich erinnere mich, zweimal Swapping auf Kunden-Servern beobachtet zu haben. Die Auswirkungen waren wie folgt.

Im ersten Fall kamen noch SCSI-Festplatten im RAID zum Einsatz. Die Leistung des Gesamtsystems verschlechterte sich durch das Swapping so stark, dass bereitgestellten Dienste praktisch nicht mehr verfügbar waren. Nutzer erhielten Zeitüberschreitungen ihrer Anfragen, Sitzungen brachen ab und das System war nicht mehr administrierbar. Am Ende wurde der Reset-Schalter gedrückt. Das Problem wurde schlussendlich durch eine Vergrößerung des Hauptspeichers gelöst.

Im zweiten Fall, an den ich mich erinnere, führte ein für die Nacht geplanter Task zu einem erhöhten Speicherverbrauch. Hier hat Swapping zunächst geholfen. Tasks liefen zwar länger, wurden aber erfolgreich beendet und verwendeter Hauptspeicher wurde anschließend wieder freigegeben. Hier entstand erst ein Problem, als der Speicherbedarf größer wurde und die Swap-Partition zu klein war. So kam es zum Auftritt des Out-of-Memory-Killer, der mit einer faszinierenden Genauigkeit immer genau den Prozess abgeräumt hat, den man als Sysadmin gern behalten hätte. Auch hier wurde das Problem letztendlich durch eine Erweiterung des Hauptspeichers gelöst.

Ich erinnere mich auch noch an die ein oder andere Anwendung mit einem Speicherleck. Hier hat vorhandener Swap-Speicher das Leid jedoch lediglich kurz verzögert. Das Problem wurde entweder durch einen Bugfix oder den Wechsel der Anwendung behoben.

Nun bin ich auf eure Antworten und Erfahrungsberichte gespannt.

Ein Blog sollte man immer dabei haben — auch offline

5 Antworten

Der Name meines Blogs ist Programm. Es dient mir als digitales Gedächtnis für IT-Themen, die mich mich beschäftigt haben und die nochmal interessant werden können. Es ist eine Art Wissensdatenbank, auf die ich auch gerne zugreifen können möchte, wenn ich mal keine Internetverbindung habe.

Inspiriert durch den heutigen Beitrag von Dirk, möchte ich hier kurz beschreiben, was ich tue, um eine statische Version meines Blogs zu erstellen, welche ich einfach auf dem Laptop, Smartphone oder Tablet mitnehmen kann.

Ich verwende das Plugin Simply Static – The WordPress Static Site Generator, um eine statische Version meines Blogs zu erzeugen und als Zip-Archiv zu speichern. Möchte ich auf die statische Version meines Blogs zugreifen, entpacke ich das Zip-Archiv in ein Verzeichnis wie z.B. /tmp/simply-static/ und öffne anschließend in einem Webbrowser die Datei /tmp/simply-static/index.html.

Bildschirmfoto der statischen Version meines Blogs

So kann ich z.B. auch dann auf meine Artikel und Anleitungen zugreifen, wenn mein Webserver oder Internetzugriff nicht verfügbar ist. Die Suche auf der Seite funktioniert nur sehr eingeschränkt. Hier behelfe ich mir mit einer Dateisystemsuche im Terminal.

Ein paar Zahlen:

  • Dauer zur Erstellung des Zip-Archivs: ca. 10 Minuten
  • Größe des Zip-Archivs: 274 MB
  • Entpackte Größe: 355 MB
  • Rythmus der Erstellung: Wenn mir danach ist; in der Regel einmal pro Quartal

Mir gefällt an dieser Lösung, dass ich auf meinem mobilen Gerät keinen Container, ja noch nichmal einen Webserver, sondern nur einen Browser benötige. Das ist einfach, sparsam und robust.

Was haltet ihr davon ein Blog auf diese Weise offline verfügbar zu machen? Tragt ihr eure Blogs auch mit euch herum? Welche Werkzeuge nutzt ihr, um sie stets bei euch zu haben? Teilt euch gerne in den Kommentaren oder einem eigenen Blog mit.

Dieser Artikel ist Teil der #BlogWochen2025. Von Mai bis Oktober schreiben (zumindest) Robert, Dirk und ich über unterschiedliche Themen rund ums Bloggen. Du kannst gerne jederzeit einsteigen und mitmachen – die gesammelten Posts aller Teilnehmer:innen findest du auf dieser Seite und kannst sie auch als Feed abonnieren.

Codeberg.org mit Forgejo Actions, Runner, Workflows und ich

Schreibe eine Antwort

In diesem Artikel halte ich fest, was es mit den genannten Begriffen auf sich hat und was ich in den vergangenen Tagen mit ihnen angestellt habe. Dabei gehe ich auch auf das Warum ein, während Fragen nach dem Wie vorwiegend in den Verweisen im Text beantwortet werden.

Der Artikel dient mir als Dokumentation und meinen Leser:innen zur Unterhaltung und zum Wissenstransfer.

Codeberg.org

Codeberg ist eine demokratische, gemeinschaftsgetriebene, gemeinnützige Softwareentwicklungsplattform, die von Codeberg e.V. betrieben wird und sich um Codeberg.org, eine auf Forgejo basierende Software, dreht. Der Sitz des Vereins ist in Berlin. Hier wird Codeberg.org auch gehosted.

Auf Codeberg könnt ihr eure eigenen Freie Software-Projekte entwickeln, zu anderen Projekten beitragen, inspirierende und nützliche Freie Software durchstöbern, euer Wissen teilen oder euren Projekten mit Codeberg Pages ein Zuhause im Web geben, um nur einige Beispiele zu nennen.

Die beiden vorstehenden Abschnitte wurden übersetzt mit DeepL.com (kostenlose Version) und anschließend leicht angepasst und mit Links angereichert.

Mit Codeberg.org werden keine kommerziellen Interessen verfolgt. Man ist hier (nur) Nutzer und/oder Unterstützer, jedoch nicht selbst ein Produkt. Mir gefällt die Mission des Projekts. Daher bin ich dazu übergegangen, einen Teil meiner Repositories hier zu verwalten. Zwar bin ich kein Mitglied des Vereins, unterstütze diesen jedoch durch gelegentliche Spenden.

Actions, Runner und Workflows

Plattformen wie Codeberg.org, GitHub und GitLab unterstützen Softwareentwicklungsprozesse durch CI/CD-Funktionalität.

Ein Forgejo-Runner ist ein Dienst, der Workflows von einer Forgejo-Instanz abruft, sie ausführt, mit den Protokollen zurücksendet und schließlich den Erfolg oder Misserfolg meldet.

Dabei ist ein Workflow in der Forgejo-Terminologie eine YAML-Datei im Verzeichnis .forgejo/workflows eines Repositories. Workflows umfassen einen oder mehrere Jobs, die wiederum aus einem oder mehreren Steps bestehen. Eine Action ist eine Funktion zur Erfüllung häufig benötigter Aufgaben, bspw. Quelltext auschecken, oder sich bei einer Container-Registry einloggen etc. Siehe für weitere Informationen Abschnitt Hierarchy ff. im Forgejo Actions user guide.

Motiviert, meinen eigenen Forgejo-Runner zu installieren, haben mich zwei Blog-Artikel von meinem Arbeitskollegen Jan Wildeboer:

Durch den Betrieb eigener Forgejo-Runner kann ich bereits vorhandene Rechenkapazität nutzen. Es fallen für mich und den Verein Codeberg e.V. dadurch keine zusätzlichen Kosten an. Für die Installation auf RHEL 9 bin ich dem Forgejo Runner installation guide gefolgt, da das in Jans Artikel erwähnte Repository ne0l/forgejo offensichtlich nicht mehr gepflegt wird und nur eine veraltete Version des Runner enthält.

Ein Dankeschön geht raus an Jan für unseren kurzen und produktiven Austausch dazu auf Mastodon.

Wozu das Ganze?

Ich beschäftige mich beruflich seit einiger Zeit mit dem RHEL image mode und möchte demnächst einen meiner KVM-Hypervisor damit betreiben. Bis es soweit ist, arbeite ich eine Weile im „Jugend forscht“-Modus und baue immer wieder neue Versionen meiner Container-Images. Der Ablauf ist dabei stets derselbe:

  1. Containerfile(5) erstellen bzw. anpassen
  2. Container-Image mit podman-build erstellen
  3. Das erstellte Image mit podman-push in eine Container-Registry hochladen
  4. Das Deployment auf diversen Zielsystemen testen

Dazu verwende ich das RHEL 9 Bootc Base Image aus der Registry registry.redhat.io.

The rhel-bootc and user-created containers based on rhel-bootc container image are subject to the Red Hat Enterprise Linux end user license agreement (EULA). You are not allowed to publicly redistribute these images.

Quelle: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_image_mode_for_rhel_to_build_deploy_and_manage_operating_systems/introducing-image-mode-for-rhel_using-image-mode-for-rhel-to-build-deploy-and-manage-operating-systems#introducing-image-mode-for-rhel_using-image-mode-for-rhel-to-build-deploy-and-manage-operating-systems

Um vorstehender Anforderung gerecht zu werden, speichere ich das erzeugte Container-Image in einem privaten Repository auf Quay.io. Sowohl für registry.redhat.io als auch für quay.io ist ein Login erforderlich, bevor es losgehen kann.

Für mich bot sich hier die Gelegenheit, die Nutzung von Forgejo Workflows zu lernen und damit den Ablauf zur Erstellung meines RHEL Bootc Images zu automatisieren.

Forgejo Workflow und Runner-Konfiguration

Im folgenden Codeblock findet ihr meinen Forgejo Workflow aus der Datei .forgejo/workflows/build_image.yaml, gefolgt von einer Beschreibung der einzelnen Schritte. Zur Erklärung der Begriffe name, on, env, jobs, steps, run, etc. siehe Workflow reference guide.

name: build_image

on:
  push:
    branches: main

env:
  REPO_URL: https://codeberg.org/Tronde/rhel-bootc.git
  REPO_NAME: rhel-bootc
  IMAGE_NAME: quay.io/rhn-support-jkastnin/rhel-bootc:9.5

jobs:
  build:
    runs-on: podman
    steps:
      - run: dnf -y install git
      - run: echo ${{ secrets.RH_REGISTRY_TOKEN }} | podman login -u ${{ secrets.RH_REGISTRY_USERNAME }} --password-stdin registry.redhat.io

      - run: echo ${{ secrets.QUAY_ROBOT_TOKEN }} | podman login -u ${{ secrets.QUAY_USERNAME }} --password-stdin quay.io

      - run: git clone ${{ env.REPO_URL }}
      - run: podman build -f /workspace/Tronde/rhel-bootc/rhel-bootc/Containerfile -t ${{ env.IMAGE_NAME }}
      - run: podman push ${{ env.IMAGE_NAME }}
  1. Der Workflow wird jedes Mal ausgeführt, wenn ich einen Commit in den Branch main pushe
  2. Ich definiere einige Umgebungsvariablen, um bei Änderungen nicht alle Schritte im Workflow einzeln auf notwendige Änderungen prüfen zu müssen
  3. Mit `runs-on: podman` bestimme ich, dass der Workflow auf einem Runner mit dem Label podman ausgeführt wird; der entsprechende Runner started dann einen rootless Podman-Container, in dem die folgenden Schritte innerhalb von rootful Podman ausgeführt werden (nested Podman bzw. Podman in Podman)
  4. Git wird installiert
  5. Anmeldung an registry.redhat.io erfolgt
  6. Anmeldung an quay.io erfolgt
  7. Das Git-Repository wird geklont, um es auf dem Runner verfügbar zu haben
  8. Der Runner baut ein Container-Image (Erinnerung an mich selbst: Ersetze den hardcodierten Pfad durch eine Variable)
  9. Das erstellte Image wird in die Registry gepusht

Damit mein Runner den obigen Workflow ausführen kann, existiert auf diesem die Konfigurationsdatei /etc/forgejo-runner/config.yml, welche ich mit dem Kommando forgejo-runner generate-config > config.yml erstellt und anschließend angepasst habe. Der folgende Codeblock zeigt nur die Abschnitte, die ich manuell angepasst habe.

…
  fetch_interval: 20s
…
  labels: [
    "rhel-9-ubi:docker://registry.access.redhat.com/ubi9/ubi",
    "podman:docker://registry.access.redhat.com/ubi9/podman",
    "ubuntu-latest:docker://ghcr.io/catthehacker/ubuntu:act-latest",
    "act-runner:docker://node:20-bullseye",
    "centos-stream-9:docker://quay.io/centos/centos:stream9"]
…
  privileged: true
…

Ich greife mal die Zeile podman:docker://registry.access.redhat.com/ubi9/podman heraus:

  • podman: am Beginn der Zeile beinhaltet das Label, welches im Worflow mit runs-on verwendet wird
  • Mit dem Rest der Zeile wird bestimmt, in welchem Container-Image der Workflow ausgeführt wird
  • Ich habe mich für ubi9/podman entschieden, weil
    • ich bei Red Hat arbeite und daher
    • mit den Prozessen zur Erstellung unserer Images vertraut bin,
    • wodurch sich ein gewisses Vertrauen gebildet hat.
    • Ich vertraue unseren Images mehr, als jenen, die irgendein Unbekannter gebaut hat und deren Inhalt ich nicht kenne (man kann den Inhalt aber selbstverständlich überprüfen)
    • und ich so prüfen konnte, ob sich ein Image mit „unseren“ Werkzeugen bauen läst (nicht, dass ich daran gezweifelt hätte).

Die Angabe von privileged: true ist erforderlich, wenn man innerhalb des Containers ebenfalls mit podman oder docker arbeiten möchte.

Entscheidungen

Meinem weiter oben abgebildeten Workflow ist zu entnehmen, dass ich auf die Verwendung von Forgejo Actions verzichtet habe. Das hat folgende Gründe:

  • Für die Verwendung ist node auf dem Runner erforderlich
  • node ist im Image ubi9/podman standardmäßig nicht installiert
  • Node.js ist für mich das Tor zur Hölle und ich vermeide dessen Nutzung wenn möglich
  • Die Nutzung ist keine Voraussetzung, da ich mein Ziel auch so ohne Mehraufwand erreicht habe

Sobald die Workflows länger und komplexer werden, mag sich meine Einstellung zu Actions ändern.

Zusammenfassung

Ich habe gelernt:

  • Forgejo Runner zu installieren und zu konfigurieren
  • Wie Forgejo Workflows funktionieren und auf Codeberg.org genutzt werden können
  • Wie ich mir damit zukünftig die Arbeit in anderen Projekten erleichtern kann
  • Was für großartige Open Source Projekte Codeberg.org und Forgejo sind

Ansible Collection tronde.opencloud

Schreibe eine Antwort

In diesem Beitrag berichte ich über mein Wochenend-Projekt „Ansible Collection tronde.opencloud“, welche ihr seit dem 4. Mai 2025 in Version 1.0.0 auf Ansible Galaxy sowie bei Codeberg.org findet.

Ich habe die Collection mit den folgenden Zielen erstellt:

  • Deployment von OpenCloud mittels Ansible in einer rootless Podman-Umgebung
  • Backup der OpenCloud und Speicherung des Backups auf dem Ansible Control Node
  • Restore der OpenCloud aus einem zuvor erzeugten Backup

Aktuell läuft eine OpenCloud-Instanz auf einem meiner Server unter Debian Bookworm.

Nicht so schnell! Was sind Ansible, OpenCloud und Podman?

Derjenige, dem diese Begriffe bereits geläufig sind, kann direkt zum Abschnitt Motivation springen. Für alle anderen gibt es hier eine knappe Erklärung mit Verweisen zu weiteren Informationen, um sich mit der Materie vertraut zu machen.

Ansible

Ansible hat sich zu einem beliebten Schweizer Taschenmesser für Automation, Konfigurations-Management, Deployment und Orchestrierung entwickelt. Über folgende Links findet ihr reichlich informationen dazu:

OpenCloud

OpenCloud ist die Filesharing & Kollaborations-Lösung der Heinlein Gruppe.

Durch intelligentes Datei-Management und eine starke Open Source-Community werden Dateien zu wertvollen Ressourcen – effektiv strukturiert und langfristig nutzbar.

Quelle: https://opencloud.eu/de

Links zu weiteren Informationen:

Podman

Podman ist ein Werkzeug zur Erstellung von Linux-Containern und der Verwaltung des gesamten Container-Lebenszyklus. Links mit Informationen zu Podman:

Motivation

Ich betreibe und nutze privat eine Nextcloud, um Dateien über mehrere Geräte zu synchronisieren, mit anderen zu teilen und um Backups verschiedener Geräte und Dienste darin abzulegen. Dazu betreibe ich neben dem Reverse Proxy (NGINX) einen Container mit einer MySQL-Datenbank und einen Anwendungscontainer mit Nextcloud selbst. Nextcloud verfügt über ein reichhaltiges Plugin-Ökosystem zur Erweiterung der Funktionalität, welche ich persönlich allerdings nicht benötige.

OpenCloud ist wie Nextcloud ein Fork von OwnCloud. Siehe dazu den Bericht: Opencloud forkt Owncloud — neue Wendung bei den freien Speichercloud-Versionen im Linux-Magazin vom 22. Januar 2025.

Mir gefällt, dass OpenCloud ganz ohne Datenbank auskommt und sich auf die Synchronisation und das Teilen von Daten fokussiert. Dies entspricht genau meinem Anwendungsfall. Wenn ich dadurch einen Dienst weniger betreiben kann (MySQL), ist das umso besser.

Nur passt der gewählte Technologie-Stack nicht zu meiner persönlichen Vorliebe. Während OpenCloud auf die Verwendung von Docker Compose mit Traefik als Reverse Proxy setzt, bevorzuge ich, Container mit Podman zu betreiben und verwende (noch) NGINX als Reverse Proxy.

Um OpenCloud etwas kennenzulernen, habe ich beschlossen, analog zu meiner Ansible Collection tronde.nextcloud eine Collection tronde.opencloud zu erstellen, um OpenCloud deployen und verwalten zu können.

Ob sich der Aufwand lohnt, werde ich mit der Zeit sehen. Wenn es mir zuviel wird oder ich den Gefallen daran verliere, werde ich dieses Wochenendprojekt wieder einstellen bzw. gern in die Hände motivierter Menschen geben, die es weiterführen möchten.

Informationen zur Collection

Das Wichtigste zu dieser Collection habe ich bereits zu Beginn dieses Textes geschrieben. Neben den für Ansible Collections und Roles typischen README.md-Dateien habe ich auch ein paar Zeilen Dokumentation erstellt:

Die Collection steht unter einer freien Lizenz und ich gebe keinerlei Garantie oder Gewähr, dass euch deren Verwendung nicht direkt in den Untergang führt. ;-)

Die Collection kann (noch) nicht viel. Das Wenige scheint jedoch robust zu funktionieren. Wenn ihr neugierig seid, probiert sie gerne aus. Auch euer konstruktives Feedback ist mir stets willkommen.

Für mich ist dies ein Wochenend-Projekt, das mit etlichen anderen Themen um meine Zeit konkurriert. Erwartet daher keine schnellen Entwicklungsfortschritte. Wenn ihr gern daran mitwirken möchtet, bin ich dafür offen. Werft einen Blick in den kurzen Contribution Guide und legt los. Falls ihr Fragen habt oder euch mit mir über die Collection austauschen möchtet, könnt ihr

  • eure Frage als Issue mit dem Label „Question“ im Repository stellen oder
  • in den Matrix-Raum #My-IT-Brain posten.

Erster Eindruck von OpenCloud

Das noch recht junge Projekt macht einen aufgeräumten Eindruck. Die Benutzeroberfläche ist nicht überladen und ich finde mich schnell darin zurecht. Das Entwicklerteam antwortet bereitwillig auf Fragen und kümmert sich in angemessener Zeit um Issues. Dies ist zumindest mein subjektiver Eindruck.

Einziger Wermudstropfen ist wie so oft die Dokumentation, welche mit der Entwicklung offenbar nicht Schritt halten kann. Diese lässt leider noch viele Fragen offen, welche über GitHub Discussions oder Suche im Quelltext geklärt werden können/müssen. Ich empfinde dies etwas ermüdend und es drückt die Motivation.

Nun werde ich OpenCloud erstmal einige Zeit nutzen und ein paar Versions-Upgrades hinter mich bringen. Anschließend werde ich dann einen Meinungsartikel schreiben, wie es mir gefällt.

Einen Tang-Server auf Debian installieren

3 Antworten

In diesem Text dokumentiere ich, wie ein Tang-Server auf Debian installiert werden kann und wie man den Zugriff auf diesen auf eine bestimmte IP-Adresse einschränkt.

Wer mit dem Begriff Tang-Server noch nichts anfangen kann und dies ändern möchte, dem empfehle ich: Network Bound Disk Encryption im Überblick.

Installation und Konfiguration

Installiert wird der Tang-Server mit folgendem Befehl:

sudo apt install tang

Standardmäßig lauscht der Tang-Server auf Port 80. Da dieser Port auf meinem Server bereits belegt ist, erstelle ich mit dem Befehl sudo systemctl edit tangd.socket eine Override-Datei mit folgendem Inhalt:

:~# cat /etc/systemd/system/tangd.socket.d/override.conf 
[Socket]
ListenStream=
ListenStream=7500

Mit den folgenden Kommandos wird die geänderte Konfiguration eingelesen, die Konfiguration kontrolliert und der Dienst gestartet:

:~# systemctl daemon-reload
:~# systemctl show tangd.socket -p Listen
Listen=[::]:7500 (Stream)
:~# systemctl enable tangd.socket --now

Zugriff auf eine IP-Adresse beschränken

Ich möchte den Zugriff auf den Tang-Server auf eine IP-Adresse beschränken, nämlich auf die IP-Adresse des einen Clevis-Clients, der diesen Server verwenden wird. Dazu führe ich die folgenden Schritte durch.

:~# iptables -A INPUT -p tcp -s 203.0.113.1 --dport 7500 -j ACCEPT
:~# iptables -A INPUT -p tcp --dport 7500 -j DROP
:~# mkdir /etc/iptables
:~# iptables-save >/etc/iptables/rules.v4

Damit die in der Datei /etc/iptables/rules.v4 gespeicherten Regeln nach einem Neustart wieder geladen werden, erstelle ich ein Systemd-Service:

:~# cat /etc/systemd/system/load-iptables.service 
[Unit]
Description=Load iptables rules
Before=network.target

[Service]
Type=oneshot
ExecStart=/sbin/iptables-restore < /etc/iptables/rules.v4
#ExecStart=/sbin/ip6tables-restore < /etc/iptables/rules.v6

[Install]
WantedBy=multi-user.target

:~# systemctl daemon-reload
root@vmd54920:~# systemctl enable load-iptables.service
Created symlink /etc/systemd/system/multi-user.target.wants/load-iptables.service → /etc/systemd/system/load-iptables.service.

Test

Um zu überprüfen, ob der Tang-Server wie gewünscht arbeitet, setze ich auf meinem Clevis-Client den folgenden Befehl ab. Dabei muss nach der Ver- und Entschlüsselung der gleiche Text ‚test‘ ausgegeben werden.

~]$ echo test | clevis encrypt tang '{"url":"tang1.example.com:7500"}' -y | clevis decrypt
test

Fertig.

Von SPAM-Kommentaren und Gegenmaßnahmen

2 Antworten

In der vergangenen Woche ist es einem Kommentar-Spammer gelungen meinen SPAM-Filter zu überwinden und die Kommentarspalte eines älteren Artikels mit SPAM zu füllen.

Eine erste Analyse ergab, dass diese SPAM-Welle von IP-Adressen aus durchgeführt wurde, die in der Russischen Föderation registriert sind. Da der großteil der unerwünschten Zugriffe auf meinen Server aus Russland und China stammen, habe ich eine erste Maßnahme ergriffen: Zugriffe von IP-Adressen aus der Russischen Föderation und China werden blockiert. Damit hatte ich mir zumindest Luft verschafft, um die Lage später etwas genauer zu analysieren.

Erste Erkenntnisse einer oberflächen Analyse

  • Nachdem die Zugriffe aus Russland und China gesperrt waren, erkannte ich, dass auch von IP-Adressen aus ganz anderen Regionen wie z.B. Vereinigte Arabische Emirate und Niederlande versuchte wurde SPAM in meinem Blog abzuladen; diese Versuche wurden jedoch von Antispam Bee blockiert
  • Auffällig oft wurde eine E-Mail-Adresse aus der Domain ‚.ru‘ für die Kommentare verwendet
  • Zwei ältere Artikel aus 2015 und 2022 waren auffällig oft das Ziel der Spammer
  • In den letzten 6 Tagen sind insgesamt 416 SPAM-Kommentare eingegangen, von denen ich 129 manuell markieren musste

Gegenmaßnahmen

  • Alle Kommentare, die innerhalb von Inhalt, Autornamen, URL oder E-Mail-Adresse die Zeichenkette ‚.ru‘ enthalten, müssen moderiert werden
  • Bevor ein Kommentar erscheint, muss der Autor bereits einen freigegebenen Kommentar geschrieben haben; alle anderen werden moderiert
  • Für die zwei am stärksten betroffenen Artikel habe ich die Kommentarfunktion deaktiviert

Die über Iptables konfigurierte Sperrliste habe ich voerst wieder deaktiviert.

Status um 2025-04-10T20:46+02

  • Nach der Umsetzung der ersten zwei Gegenmaßnahmen, wurden noch vier Kommentare von Antispam Bee blockiert
  • Seit der Umsetzung der dritten Gegenmaßnahme ist kein weiterer unerwünschter Kommentar eingegangen
  • Ich beobachte die Lage weiter.

Zugriffe von IP-Adressen aus der Russischen Föderation und China werden blockiert

7 Antworten

In den letzten Tagen, musste ich hier im Blog leider beobachten, wie sich ein Spammer an den wachsamen Augen der Antispam Bee vorbeigeschlichen hat und einzelne SPAM-Kommentare unter einem älteren Artikel aus dem Jahr 2015 hinterlassen hat.

Was mit einzelnen Kommentaren begann, erweiterte sich dann zu einer kleinen SPAM-Attacke, die in der Nacht vom 10.04.2025 weitere 129 SPAM-Kommentare unter den Artikel spülte. Dabei wurden 30 unterschiedliche IP-Adressen verwendet, die alle in der Russischen Föderation registriert sind.

Nach einer Sichtung weiterer blockierter SPAM-Kommentare stelle ich fest, dass der überwiegende Teil des SPAMs aus der Russischen Föderation und China kommt. IP-Adressen aus diesen Regionen werden auch regelmäßig durch fail2ban blockiert.

Da der letzte Spammer durch den Wechsel der IP-Adressen, bestehende Mechanismen jedoch unterlaufen konnte, baue ich nun eine weitere Verteidigungslinie auf. Zukünftig werden Zugriffe von IP-Adressen aus der Russischen Föderation und China von Iptables blockiert.

Update 2025-04-10T18:40+02: Ich habe die Maßnahme vorerst wieder ausgesetzt und prüfe, ob angepasste Kommentar-Einstellungen ausreichen, um dem Kommentar-SPAM zu begegnen. Ich lasse die folgende Lösung als Dokumentation online. Evtl. muss ich doch wieder darauf zurückfallen.

Hier ist eine iptables-Lösung zum Blockieren von IP-Adressen aus Russland und China:

Vorbereitung: GeoIP-Modul installieren

~# apt install xtables-addons-common geoip-bin libtext-csv-xs-perl
~# /usr/libexec/xtables-addons/xt_geoip_dl
~# /usr/libexec/xtables-addons/xt_geoip_build -D /usr/share/xt_geoip RU CN

Iptables-Regel erstellen und für persistenz speichern

~# iptables -A INPUT -m geoip --src-cc RU,CN -j DROP
~# iptables-save > /etc/iptables/rules.v4

Automatische Updates der Geo-IP-Daten einrichten

~# cat /usr/local/bin/geoip_update.sh 
# /usr/local/bin/geoip_update.sh
#!/bin/bash
wget -O /tmp/GeoIPCountryCSV.zip https://dl.miyuru.lk/geoip/maxmind/country/maxmind4.dat.zip
unzip -o /tmp/GeoIPCountryCSV.zip -d /usr/share/xt_geoip/
/usr/libexec/xtables-addons/xt_geoip_build -D /usr/share/xt_geoip RU CN
rm /tmp/GeoIPCountryCSV.zip

~# crontab -l
# Cronjob täglich um 3 Uhr
4 3 * * * /usr/local/bin/geoip_update.sh

Test und Logging aktivieren

# Zuerst in der Firewall-Chain testen
~# iptables -L -n -v | grep 'DROP.*geoip'

# Logging aktivieren (optional für Debugging)
~# iptables -I INPUT -m geoip --src-cc RU,CN -j LOG --log-prefix "[GEOIP BLOCK]"

Hinweis: Den Vorschlag für obige Lösung habe ich mir von perplexity.ai generieren lassen. Dabei musste ich lediglich den Pfad zu /usr/libexec/xtables-addons korrigieren, welcher fälschlicherweise auf /usr/lib/ zeigte.

Fazit

Das Internet ist kaputt. Die Zeiten in denen die Nutzer respektvoll und umsichtig miteinander umgingen, sind lange vorbei.

Mir ist bewusst, dass auch eine Sperrung von IP-Adressen basierend auf Geolokation keine absolute Sicherheit bietet und man mit dieser groben Maßnahme auch mögliche legitime Zugriffe blockiert. Allerdings prasseln aus diesen Teilen der Welt so viele unerwünschte Zugriffsversuche auf meinen kleinen Virtual Private Server ein, dass ich hier nun einen weiteren Riegel vorschiebe.

Welche Maßnahmen ergreift ihr, um unerwünschte Besucher von euren Servern fernzuhalten? Teilt eure Maßnahmen und Erfahrungen gern in den Kommentaren oder verlinkt dort eure Blog-Artikeln, in denen ihr darüber geschrieben habt.

Wie füge ich einer KVM/libvirt VM eine serielle Konsole hinzu?

Schreibe eine Antwort

Ich beantworte hier meine eigene Frage, damit ich zukünftig nicht so lange im Internet nach der Anwort suchen muss.

Mein Ziel ist es, eine virtuelle Maschine mit dem Kommando virt-install zu installieren, zu welcher ich mich anschließend mit dem Kommando virsh console <domain> verbinden kann, um z.B. das Netzwerk konfigurieren zu können.

Dies geht mit folgendem Befehl:

$ virt-install --connect qemu:///system --name vm1 --memory 4096 --vcpus 2 --disk VirtualMachines/vm1.qcow2,size=40 --os-variant rhel9.5 --cdrom iso/rhel-9.5-x86_64-dvd-ks.iso --network network=lab1,model=virtio --console pty,target_type=virtio

Der entscheidende Teil ist dabei --console pty,target_type=virtio. Der folgende Codeblock zeigt nun noch die erfolgreiche Verbindung zur seriellen Konsole der VM:

$ virsh -c qemu:///system console vm1 --safe
Connected to domain 'vm1'
Escape character is ^] (Ctrl + ])

localhost login:

Fertig.

Wie kann ich das MQTT-Passwort in Home Assistant auslesen?

Schreibe eine Antwort

Das MQTT-Passwort lässt sich auf der Konsole des Home Assistant Systems in der Datei /mnt/data/supervisor/homeassistant/.storage/core.config_entries finden. Der entsprechende Eintrag sieht bei mir wie folgt aus:

{
        "created_at": "1970-01-01T00:00:00+00:00",
        "data": {
          "birth_message": {
            "payload": "online",
            "qos": 0,
            "retain": false,
            "topic": "homeassistant/status"
          },
          "broker": "localhost",
          "discovery": true,
          "discovery_prefix": "homeassistant",
          "password": "hierstehtmeinmegalangesundkomplexespasswort",
          "port": 1883,
          "username": "homeassistant",
          "will_message": {
            "payload": "offline",
            "qos": 0,
            "retain": false,
            "topic": "homeassistant/status"
          }
},

Jetzt steht das Passwort in meinem Passwort-Manager KeePassXC und ich werde auf diesen Beitrag hoffentlich nicht so schnell zurückgreifen müssen.

Weitere Links zum Thema