staging.inyokaproject.org

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:

• Running a runner for codeberg/forgejo on RHEL9 as user
• Be a Builder of Decentralisation – codeberg, forgejo, runners

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

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:

• Ansible – IT-Automation für Jedermann
• Ansible Community Documentation (Englisch)
• Ansible in der deutschsprachigen Wikipedia
• Meine Vorträge und englischsprachigen Artikel rund um Ansible

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:

• Webseite des Projekts
• Projektseite auf GitHub (Englisch)
• Vortrag während der Chemnitzer LInux-Tage 2025: OpenCloud: Exzellentes File-Management

Podman

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

• Webseite (Englisch)
• What is Podman? (Englisch)
• Podman in der englischsprachigen Wikipedia
• Diverse Verweise in meiner Linksammlung

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:

• Get Started
• Backup and Restore

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.

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.

Die semi-immutable Distribution mit atomaren Updates geht in den Alpha-Test.

Es ist schon einige Zeit her, dass Manjaro eine experimentelle Version ihrer atomaren Distribution bekannt gegeben hat. Seitdem wurde fleissig an der Verbesserung der Technologie gearbeitet und einige häufig gewünschte Funktionen implementiert. Manjaro Immutable heisst jetzt Manjaro Summit und wurde am Montag als öffentliche Alpha-Version freigegeben.

Manjaro Summit ist eine Semi-Immutable-Distribution mit einem atomaren Update-System. Updates werden durch das Herunterladen von vorgefertigten Disk-Images durchgeführt, die Root-Partition ist schreibgeschützt und nur Teile des Dateisystems werden bei einem Update migriert.

Der Vorteil eines solchen Systems ist, dass jeder mit einer nahezu identischen Systemkonfiguration arbeitet, was es vereinfacht, Fehler und Probleme zu reproduzieren. Ausserdem können die Abbilder vor der Veröffentlichung getestet werden. Und sollte sich eine Aktualisierung als fehlerhaft erweisen, kann man einfach auf eine ältere, nicht betroffene Version zurückgehen. Die Unveränderlichkeit macht das System widerstandsfähiger gegen Benutzer- und Softwarefehler und bietet auch einen gewissen Schutz gegen Malware.

Das Manjaro-Team ist sich noch nicht sicher, was Summit letztendlich werden wird: eine stabile, rollende Workstation-Distribution oder eine sich ständig bewegende Distro. Die Technologie, die Summit antreibt, ist darauf ausgelegt, so einfach wie möglich zu sein.

Systemvoraussetzungen

• UEFI
• 4 GB RAM oder mehr empfohlen
• Mindestens 32 GB Speicherplatz
• Netzwerk ist während der Installation erforderlich

Systeme, bei denen alle Treiber als Upstream im Kernel enthalten sind, bieten die beste Benutzererfahrung. Nvidia wird derzeit weder unterstützt noch getestet, aber es sollte nicht schwer sein, diese Treiber zu installieren und zu aktivieren, indem man Layering verwendet, um die Pakete zu installieren und das Overlay, um sie in das initramfs zu laden.

Herunterladen

• Ventoy kann das ISO nicht booten.
• Das Team empfiehlt gnome-boxes oder QEMU+SPICE für die Installation innerhalb einer virtuellen Maschine
• ISO-Download
• Prüfsumme

Mir ist es nicht gelungen, Summit in GNOME-Boxes zu installieren.

Änderungen seit der experimentellen Version

• Unterstützung für Package Layering wurde hinzugefügt.
• Keine EFI-Variablen mehr für die Auswahl des Booteintrags, die Bootpriorität wird nun über Zeitstempel im Dateinamen des Booteintrags definiert.
• systemd-bless-boot-Unterstützung wurde implementiert, das System führt einen automatischen Rollback durch, falls ein neues Image nicht bootet.
• Das initramfs wird mit Binärdateien aus dem neuen Deployment und nicht aus dem aktuellen Root erstellt.
• Verschiedene Änderungen, Verbesserungen und Korrekturen am Backend.

Was noch fehlt

• Eine Willkommens-App. Momentan wird man bei der Installation in eine grösstenteils leere Umgebung geworfen. Das Team würde dem Benutzer gerne ermöglichen, beim ersten Start eine Standardsammlung von Anwendungen als Flatpak zu installieren.
• GPG-Image-Signierung. Derzeit wird die Gültigkeit von Images anhand einer Prüfsumme überprüft. Arkdep ist bereits in der Lage, Images mit GPG zu validieren, aber dies wurde bislang nicht in der Image-Build-Automatisierung implementiert.
• Automatische System-Updates im Hintergrund. Updates müssen immer noch manuell über die Kommandozeile durchgeführt werden.
• Momentan wird nur GNOME unterstützt. Es sind auch Konfigurationen für Plasma, XFCE und COSMIC verfügbar. Diese sind jedoch alle ungetestet und können kaputtgehen oder grundlegende Funktionen vermissen lassen.
• Sudolose Arkdep-Nutzung. Es wird evaluiert, ob eine sudolose Systemverwaltung mit Arkdep für sudo-Benutzer zugelassen werden soll; dies kann über Polkit implementiert werden.
• Beschränkung des Systemzugriffs von Arkdep. Man möchte den Systemzugriff von Arkdep mit Apparmor einschränken, um zu verhindern, dass Bugs zu Datenverlusten führen und um die Angriffsfläche zu begrenzen, wenn von der Community erstellte Images ausgeführt werden.
• Verbessertes Ausrollen von Updates. Momentan werden die Images direkt nach der Erstellung und ohne Tests nach „stable“ verschoben.
• Arkdep Bash und Zsh Autokomplettierung.

Was man von der Manjaro Summit Alpha erwarten kann

• Wöchentliche Updates. Das Manjaro-Team versucht, wöchentlich neue Images für Manjaro Unstable zu erstellen.
• Die Konfiguration wird auf der Grundlage des Feedbacks der Community optimiert und geändert.
• Die oben erwähnten fehlenden Funktionen werden mit der Zeit hinzugefügt.
• Es sollte stabil genug sein, um für Leute, die mit Linux vertraut sind, täglich nutzbar zu sein.
• Alle grösseren Änderungen werden automatisch durch Updates übernommen.

Fazit

Zurzeit lohnt sich eine Installation dieser Alpha-Version nicht. Falls ihr euch tatsächlich für eine Arch-basierte atomare Distribution interessiert, schlage ich Arkane vor. Darauf basiert Manjaro Summit. Diese Distro ist zwar auch noch instabil, aber immerhin im Beta-Stadium angekommen.

Tipp: falls ihr Einsteiger oder Umsteigerinnen seid, lasst die Finger von diesem "geheimen Kommandomaterial" und nehmt Linux Mint 👍

Titelbild:

• https://pixabay.com/vectors/mountain-climber-man-silhouette-7921253/
• https://manjaro.org/

Quelle:

https://forum.manjaro.org/t/manjaro-summit-public-alpha-now-available/176995

https://arkanelinux.org/

Derzeit laufen Kampagnen, die Open Source Software angesichts der weltweiten Entwicklungen wieder stärker in den Vordergrund rücken wollen. Ein hehres Ziel, das aber nicht über die Tatsachen hinwegtäuschen sollte. Auch die Open-Source-Welt wird von US-amerikanischen Strukturen dominiert.

Ältere Nutzer werden sich vielleicht noch an PRISM-Break erinnern. PRISM war eines der NSA-Programme, die Edward Snowden bei seiner Enthüllung der globalen Überwachungs- und Spionageaffäre aufgedeckt hatte. PRISM-Break war eine Seite, die Nutzer davon überzeugen sollte, quelloffene Alternativen zu nutzen. Der Sinn war angesichts der Überwachungsarchitektur der NSA schon damals mehr als fraglich.

Angesichts der Politik von US-Präsident Trump erfahren solche Kampagnen gerade eine Neuauflage (z.B. #UnplugTrump aber auch sehr prominent auf Mastodon) und wieder geht es darum, sich von der US-dominierten IT-Landschaft zu emanzipieren. Und wieder zielen solche Kampagnen vor allem darauf ab, Open-Source-Alternativen zu stärken. Was vermutlich schon daran liegt, dass die proprietären Alternativen aus Europa überschaubar sind.

Dagegen ist grundsätzlich nichts einzuwenden. Open Source kann immer einen Schub gebrauchen. Das Problem hinter solchen Kampagnen ist nur leider, dass hier ein Ziel vorgeschoben wird, das so unmittelbar gar nicht zu erreichen ist. Gegen die US-Dominanz im IT-Bereich hilft eine Hinwendung zu Open Source in der jetzigen Organisationsform nur bedingt. Denn Open-Source ist nicht staatenlos, darauf habe ich in der Vergangenheit schon hingewiesen.

Gehen wir einige problematische Beispiele durch.:

1. Signal: Wird entwickelt von der Signal Foundation mit Sitz in den USA. Die Daten sind vollständig verschlüsselt, laufen aber über Service von AWS.
2. Suchmaschinen: MetaGer und andere Alternativen zu Google greifen im Hintergrund immer noch auf die US-Dienste wie Google, Bing & Co zu.
3. MyCroft wird eine Foundation mit Sitz in den USA entwickelt. Allerdins gab es hier positive Entwicklungen. OpenVoiceOS sitzt nun in den Niederlanden.
4. Linux: Die Linux Foundation sitzt in den USA und unterliegt US-Gesetzen. Wichtige Distributionen wie Red Hat / Fedora ebenfalls. Das gilt für Beteiligung, wie auch für Exportbestimmungen.
5. GitHub als zentrale Codeverwaltung für viele Open-Source-Projekte gehört Microsoft. Das löst immer wieder Schwierigkeiten aus. Jüngst wurde OrganicMaps wegen Beiträgen aus sanktionierten Staaten gesperrt (Siehe Meldung auf Mastodon).
6. Die Mozilla Foundation als Rückgrat des letzten freien Webbrowsers sitzt ebenfalls in den USA.
7. Die GNOME Foundation (wichtige Desktopumgebung und Spendenabwickler für Projekte wie GIMP) sitzt in den USA.
8. Die Apache Foundation sitzt in den USA
9. Das Tor Project hat seinen Sitz in den USA und wurde in der Vergangenheit stark von US-Regierungsstellen finanziert.

Zum Glück sitzen nicht alle Strukturen in den USA:

1. Manche Foundations wie OpenStreetMap oder Collabora haben ihren Sitz in Großbritannien. Das stärkt zwar die Unabhängigkeit von den USA, bedeutet aber keineswegs bessere Bedingungen im Bereich Überwachung und Datenschutz. Die jüngsten Schwierigkeiten von Apple sollten hier Mahnung genug sein.
2. Die GrapheneOS Foundation ist ziemlich versteckt, sitzt aber vermutlich aktuell in Kanada.
3. BigBlueButton Inc. sitzt ebenfalls in Kanada.
4. Nur sehr wenige Entwicklungen wie LibreOffice oder Nextcloud sitzen wirklich in der EU.

Das bedeutet natürlich nicht, dass eine Hinwendung zu Open-Source falsch ist. Den Kopf in den Sand stecken und einfach dem US-Tech-Oligopol mit seinen opportunistischen politischen Wendungen zu folgen, kann mit Sicherheit nicht die Lösung sein. Letztlich bietet nur eine kollaborative Entwicklung und offene und transparente Strukturen genug Unabhängigkeit vom Tech-Oligopol, das sich (hauptsächlich) in den USA formiert hat. Es sitzen natürlich auch nicht alle Hauptentwickler und Contributors im Land, in dem die jeweilige Stiftung/Foundation angesiedelt ist.

Ich halte es nur für falsch zu kommunizieren, dass eine Hinwendung zu Open-Source alleine alle unsere Probleme löst, denn auch innerhalb der Open-Source-Projekte haben die USA eine übermächtige Position und die meisten Projekte müssen sich direkt oder indirekt den US-Bestimmungen beugen. Wer das unterschlägt, betreibt billige Open-Source-Propaganda, um auf einer aktuellen Trump-Aufmerksamkeitswelle mitzugleiten.

Dieser Beitrag stammt ursprünglich aus dem Jahr 2014, wurde 2025 aber nochmal grundsätzlich überarbeitet, vor allem der Imagemagick- und ffmpeg-Abschnitt.

Ich finde, dass es kaum schönere Videos von Landschaften oder Städten gibt als Zeitrafferaufnahmen. Diese haben meistens eine Dynamik, die das gewisse Extra ausmachen.

Jetzt habe ich bei eine recht gute Kamera herumliegen (Canon EOS 550D), die sehr gute Fotos macht. Jetzt hat sich mir die Frage gestellt: Kann man die Kamera in einstellbaren Intervallen auslösen lassen, sodass sie für mich die Zeitraffer-Fotos erstellt? Man kann!

Die Kamera zeitgesteuert auslösen

Leider gibt es für die Canon EOS 550D keine interne Funktion, mit der man massenhaft Bildern in voreingestellten Intervallen machen kann.

Externe Hardware

Es gibt aber kommerzielle Systeme, mit denen das geht. Diese kosten etwa 25 Euro. Irgendwann versuche ich mal, mir selbst so ein Teil zu basteln, aber das wird dann ein eigener Artikel hier im Blog

Gphoto2

Die Mühen und das Geld kann man sich aber sparen, wenn man einen Laptop zur Verfügung hat, auf dem z.B. Ubuntu läuft. Denn mit einem kleinen Helferlein kann man diese Aufgabe auch über den PC steuern!

Das Paket nennt sich Gphoto2 und lässt sich in den meisten Distributionen sehr leicht installieren.

sudo apt-get install gphoto2

Nach der Installation kann man seine Kamera über USB anschließen. Vermutlich wird sie automatisch eingehängt, das umgeht man, indem man die Kamera auf PTP stellt oder sie einfach wieder aushängt. Das geht zum Beispiel in Nautilus, indem ihr den Escape-Button anklickt.

Jetzt kann man überprüfen, ob gphoto2 mit der Kamera zusammenarbeitet. Das macht man mit dem folgenden Befehl, der die Typenbezeichnung der angeschlossenen Kamera ausgeben sollte (siehe meine Ausgabe).

$ gphoto2 --auto-detect
Modell                         Port                                            
----------------------------------------------------------
Canon EOS 550D                 usb:002,003

Jetzt kann es losgehen. Die Kamera hatte ich im M-Modus (manuell) und habe folgendes manuell eingestellt:

• ISO,
• Blende,
• Verschlusszeit,
• Weißabgleich und
• Fokus

Ist man im Halbautomatik-Modus (Av oder Tv) können sich die Bilder in der Helligkeit unterscheiden. Den Autofokus kann man am Anfang verwenden, sollte ihn dann aber abschalten. Das sieht auf dem Video sonst nicht schön aus!

Mit dem folgenden Befehl werden die Bilder für das Zeitraffer aufgenommen.

gphoto2 --capture-image-and-download -I 5 -F 600

Die Einstellungen:

• –capture-image-and-download  → Die Bilder werden geschossen und sofort auf den Computer geladen. Auf der Speicherkarte sind die Bilder nicht mehr!
  Alternative: –capture-image  → Die Bilder werden auf der Speicherkarte abgelegt.
• -I 5  → Das Intervall der Aufnahmen beträgt 5 Sekunden
• -F 600  → Es werden 600 Aufnahmen gemacht.

Wer noch mehr einstellen möchte, kann sich über den folgenden Befehl all seine Einstellmöglichkeiten auflisten lassen:

gphoto2 --list-config

 Aus einer Bilderserie ein Timelapse-Video machen

Der schwierigste Schritt ist gemacht. Den Rest übernimmt für uns mal wieder Imagemagick, das Bildverarbeitungsprogramm aus der Konsole. Das Herrliche daran: mit wenigen Zeilen kann man mit einem Rutsch alle seine Bilder bearbeiten lassen.

Bilder auf Full-HD Auflösung bringen

Da die Kamera die Bilder in einer sehr hohen Auflösung aufnimmt, muss man diese auf Videogröße skalieren.

Wenn man sich mit dem Terminal im Ordner der Bilder befindet, verkleinert man sie mit dem folgenden Einzeiler auf die Auflösung 1920×1280 (das Bildverhältnis zwingt uns zunächst dazu).

x=1; for i in *.jpg; do convert $i -resize 1920x1280 -shave 0x100 `printf "%05d.jpg" $x`; x=$(($x+1)); done

mit -shave schneiden wir oben und unten jeweils 100 Pixel ab, um auf die finale Auflösung von 1920×1080 Pixel (Full-HD) zu gelangen.

Weiteres Beispiel: Bilder zurechtschneiden und drehen (crop und rotate)

Die Bilderserie wurde mit einer Gopro aufgezeichnet. Der Bildausschnitt muss noch zurechtgeschnitten werden und um 90 ° gedreht werden. Das kann man mit folgendem Befehl durchführen.

$ x=1; for i in *.jpg; do convert $i -crop 3380x1900+300+730 +repage -rotate 90 `printf "%05d.jpg" $x`; x=$(($x+1)); done

Die Geometrie-Angaben für imagemagick Breite x Höhe geben die Größe des fertigen Bildes an. Der Offset x und y wird von der oberen linken Ecke gemessen. Ich habe sie mittels Bildbearbeitungssoftware herausgemessen. Mit +repage stellt man sicher, dass Leinwand und Bild richtig zueinander ausgerichtet sind. Am Ende rotiert die Flagge -rotate das Bild um 90° im Uhrzeigersinn.

Einzelbilder zu Video konvertieren

Mit diesem letzten Befehl verbindet man nun alle Einzelbilder zu einem Video. Ich habe hier eine Framerate von 25 fps (Frames per second) gewählt. Man kann auch weniger nehmen, dann dauert das Video etwas länger, ruckelt allerdings.

ffmpeg -r 25 -f image2 -i 0%04d.jpg -c:v libx264 -profile:v high -level 4.0 -pix_fmt yuv420p -movflags +faststart zeitraffer.mp4

Zu beachten ist der Punkt -i 0%04d.jpg . Die Dateien müssen z.B. 00001.jpg genannt sein, das haben wir oben mit imagemagick sichergestellt. Mit der genannten Flagge teile ich das ffmpeg mit, dass eine vierstellige Dezimalzahl in den Dateinamen vorkommt, nach der es die Bilder aneinandersetzen soll.

• -profile:v high -level 4.0: das stellt die Kompatibilität zu Handys (z.B. mit Android) sicher
• -movflags +faststart: Stellt den Metatag „moov“ an den Beginn der Datei, sodass das Video schon starten kann, bevor es vollständig geladen ist. Das ist wichtig für Handykompatibilität
• -pix_fmt yuv420p: Das ist das am weitesten verbreitete Pixelformat.
• optional: -vf scale=1280:720 für eine niedrigere Auflösung
• optional: -b:v 2M für eine niedrigere Bitrate

Einstellungen für 4K-Videos

4K-Videos haben eine Auflösung von 3840×2160 Pixeln und sind nur auf wenigen Geräten in voller Größe abspielbar.

Tipps und Tricks

Zeitraffer planen

Bevor ihr ein Zeitraffer aufnehmt, solltet ihr es planen. Es ist wichtig zu wissen, wie lange das fertige Video dauern wird und wie schnell sich die Objekte darauf bewegen sollen.

Für ein 30-Sekunden-Video sind  30×25= 750 Fotos notwendig. Wenn in diesen 30 Sekunden ein Zeitraum von 60 Minuten abgebildet werden soll, muss man das Intervall auf 4,8 ~ 5 Sekunden stellen.

Spiegelreflex-Kameras vermeiden

Wer professionell oder zumindest häufiger Zeitraffer aufnehmen möchte, sollte sich eine Alternative zu einer Spiegelreflex-Kamera überlegen. Meine Kamera ist laut (dubioser) Foren im Internet auf 50.000 Bilder ausgelegt, danach beginnen die Probleme. Die Kamera hat also starken Wertverlust durch die Zeitraffer, da hier in kurzer Zeit viele Bilder gemacht werden.

Anzahl der Auslösungen der Kamera anzeigen

Die Anzahl der Auslösungen der Kamera kann man ebenfalls mit gphoto2 auslesen. Man startet es im Terminal in einer ncurses-Umgebung und navigiert durch das Menü: Statusinformationen → Auslösezahl

gphoto2 --config

 Weiterführende Links

• gphoto2 Dokumentation
• Fotoschnack Episode über Zeitraffer

The post Timelapse aufnehmen und mit imagemagick und ffmpeg zu einem Video umwandeln first appeared on bejonet - Linux | Smart Home | Technik.

Neue Terminal-Anwendungen vor allem im Gnome-Lager ersetzen die bisherigen Programme – und haben dabei neuerdings die Fähigkeit eingebüßt, den Hintergrund der Fenster durchscheinen zu lassen. Transparenz scheint out. Aber man muss nicht darauf verzichten. Der bislang vom Fedora-Projekt betreute Patch für das Gnome-Terminal ist zwar Geschichte, was auch Auswirkungen auf andere Distributionen hat – aber eine neue Lösung steht schon bereit: Ptyxis.

Ptyxis beherrscht Transparenz – und färbt die Titelleiste rötlich im Superuser-Modus

Wenn man sich auf eine Konstante verlassen kann in Desktopumgebungen, dann sind das die Terminalprogramme. KDE hat die „Konsole“, XFCE das XFCE4-Terminal und Gnome das Gnome-Terminal. Letzteres existiert weiter, hat aber vor einiger Zeit Konkurrenz im eigenen Desktop bekommen: Mit der „Gnome-Console“ kam eine schlichtere Anwendung als Standard-Terminal in die Desktopumgebung. Transparenz beherrschte dieses Programm nicht mehr.

Aber auch das Gnome-Terminal, das als Alternative weiterhin vorhanden war, hatte transparente Fenster in Wirklichkeit schon lange abgeschafft. Dass das z. B. unter Ubuntu oder Fedora den Anwendern noch nicht aufgefallen war, lag einzig daran, dass die Distributionen die früher enthaltene Transparenz-Einstellungen ins Gnome-Terminal wieder hineingepatcht hatten. Statt das Original-Gnome-Terminal wurde dort eine modifizierte Version angeboten. Für viele Anwender gehört die Transperenz zum Linux-Coolness-Desktop-Faktor einfach dazu. Auch andere Distributionen nahmen die Fedora-Version des Gnome-Terminals deshalb in ihre Paketquellen auf, damit auch dort Transparenz im Terminal möglich wurde.

Doch wer etwa unter aktuellem Fedora das Gnome-Terminal nutzt, konnte ebenfalls keine durchscheinenden Fenster mehr sehen. Die Einstellungen für Transparenz sind verschwunden. Der Grund: Die gepatchte Version wird nicht mehr weiterbetreut, es wird auch bei Fedora nun wieder das eigentliche Gnome-Terminal angeboten. Transparenz schien damit nun endgültig zu den Akten gelegt worden zu sein. Jedenfalls beim Gnome-Terminal.

Gesundheit!

Inzwischen ist aber auch das Gnome-Terminal nicht mehr erste Wahl bei Fedora, stattdessen wurde „Ptyxis“ zum neuen Standard-Terminal gemacht. Wer ein Terminal aufruft, sieht Ptyxis, das äußerlich der schob bekannten abgespeckten Gnome-Console ähnelt. Der Programmname klingt nicht nur wie eine verschleppte Erkältung, sondern das Terminal ist auch zunächst ungewohnt, da es auf den ersten Blick noch spartanischer daherzukommen scheint als die bisherigen Lösungen. Auf den zweiten Blick ist es aber ziemlich edel. Denn es ermöglicht eine Dash-Übersicht in der Dash-Übersicht: Terminal-Tabs lassen sich wie bei der Gnome-Shell verkleinern und auswählen. Und mit noch einem praktischen Detail fällt Ptyxis auf: Wenn man mit Root-Rechten im Terminal unterwegs ist, wechselt die Fensterleiste in die Farbe Rot.

Transparenz für Ptyxis

Einstellungen für durchscheinende Fenster scheint aber auch Ptyxis nicht zu haben – scheinbar. In Wirklichkeit ist die Funktion aber vorhanden, sie wird in den Einstellungen nur bislang noch nicht abgebildet. Die versteckte Option lässt sich jedoch relativ simpel aktivieren:

Mit dem Befehl

gsettings set 'org.gnome.Ptyxis.Profile:/org/gnome/Ptyxis/Profiles/'$PTYXIS_PROFILE'/' 'opacity' '0.85'

wird das Ptyxsis-Terminal leicht transparent. Je niedriger der gewählte Wert, desto durchscheinender ist das Terminalfenster.

Derselbe Befehl mit dem Wert 1.0 statt 0.85 hebt die Transparenz wieder auf und macht die Anwendung erneut standardmäßig undurchsichtig.

Bei Distributionen mit nichttransparentem Gnome-Terminal kann man alternativ zu Ptyxis auch noch zu Konsole oder Xfce4-Terminal raten. In diesen Programmen ist Transparenz ebenfalls weiterhin von Haus aus eingebaut und in den Programmeinstellungen aktivierbar.