toheine.net

Chemnitzer Linux-Tage 2026

2026-03-31T19:51:53+01:00

Wieder hatte ich die Gelegenheit die diesjährigen Linux-Tage in Chemnitz zu besuchen. Gemeinsam mit @and1bm , @angry , @frank , @graueralltag Jürgen und @miXsed war das wieder ein überragendes Erlebnis. Bei allen Veranstaltungen die im Jahr so anfallen, sind die CLTs mein Favorit!

Die Begegnungen und Gespräche vor Ort sind einfach unersetzlich, die Vorträge waren super und mein persönlicher Ideen-Rucksack ist prall gefüllt. Ich kann diese Art von Veranstaltung aus dem Umfeld der FLOSS-Szene total empfehlen. Das muss man erlebt haben.

Auch in diesem Jahr hatte ich einen Vortrag mit dem Thema Der eigene Blog mit Hugo – Ein Praxisbeispiel. Das Material dazu gibt es hier:

Korrektur zum Vortrag

Es gab im Anschluss an den Vortrag eine Frage aus dem Publikum, wie man Beiträge veröffentlicht, die erst in X Tagen erscheinen sollen. Ich war etwas im Tunnel und habe das missverständlich ausgedrückt, aber von einem der weiteren Zuhörenden kam der richtige Hinweis. Daher möchte ich das hiermit richtig stellen:

Wenn ein neuer Hugo-Blogpost verfasst ist, der ein Veröffentlichungsdatum in der Zukunft beinhaltet und der Buildprozess durch ist, dann erscheint dieser erst im Blog, wenn ein erneuter Build (nach dem Veröffentlichungsdatum), zusammen mit einer Bereitstellung auf einem Webserver erfolgt. Um das zu automatisieren bietet Woodpecker die Möglichkeit Cron-Jobs zu hinterlegen. Infos dazu sind hier zu finden: https://woodpecker-ci.org/docs/usage/cron

Lesson learned

Von @ascherbaum kam noch der Hinweis, dass Hugo relativ häufig einzelne Features für deprecated erklärt. Je nach eingesetztem Theme oder nach den verwendeten Features kann das zu Problemen führen. Bisher bin ich da noch nicht drüber gestolpert. Da geht ein fetter Dank an @xoxys , der das hier eingesetzte Theme hugo-geekblog so aktuell hält.

Weitere Infos

Webseite der Veranstaltung
https://chemnitzer.linux-tage.de/2026/de/
Video-Aufzeichnungen der Vorträge:
https://media.ccc.de/c/clt26

PostgreSQL Upgrade

2026-02-21T11:39:06+01:00

Gestern hab ich Wartungsarbeiten auf einem Peertube-Server durchgeführt. Dieser verwendet im Hintergrund eine PostgreSQL-Datenbank. In diesem Zusammenhang hab ich auch das darunter liegende Debian auf die Version 13 (Trixie) aktualisiert. Dabei wurde auch die PostgreSQL Datenbank von 15 auf Version 17 aktualisert. Mittlerweile geht das ja wirklich gut von der Hand, aber wenn ich nachfolgende Warnmeldungen sehe, bin ich immer etwas skeptisch.

Hinweis zur Konfiguration von Postgres beim Update auf Debian Trixie

Im Zweifel sage ich bei solchen Dingen eher “Nein”. So auch gestern. Nach dem Upgrade musste ich dann aber das Upgrade selbst durchführen. Vorher noch schnell einen Snapshot erstellt und die entsprechenden Man-Pages konsultiert. Die Lösung sah wie folgt aus:

Update durchführen

Die aktuellen Posgres-Instanzen können mit dem Befehl pg_lsclusters angezeigt werden:

root@video01:~# pg_lsclusters
Ver Cluster Port Status Owner    Data directory              Log file
15  main    5432 online postgres /var/lib/postgresql/15/main /var/log/postgresql/postgresql-15-main.log
17  main    5433 online postgres /var/lib/postgresql/17/main /var/log/postgresql/postgresql-17-main.log

Die alte Version 15, läuft unter dem Standard-Port 5432 und wird von Peertube verwendet. Der neue Cluster mit der Version 17, ist nicht aktiv genutzt. Dieser Cluster wurde in einem ersten Schritt entfernt:

root@video01:~# pg_dropcluster 17 main --stop
root@video01:~# pg_lsclusters
Ver Cluster Port Status Owner    Data directory              Log file
15  main    5432 online postgres /var/lib/postgresql/15/main /var/log/postgresql/postgresql-15-main.log

Nun konnte der neue Postrgres-Cluster angelegt und die Datenbank aus dem alten Postgres-Cluster rüber gezogen werden. Es wurde der entsprechende Befehl (siehe Screenshot oben) ausgeführt:

`1`	`pg_upgradecluster 15 main -v 17`

Es folgten eine Latte von Ausgabemeldungen die mit einem Success [..] endeten. Im Anschluss konnte der alte Postgres-Cluster entfernt und die entsprechenden Pakete gelöscht werden:

1
2

pg_dropluster 15 main
apt purge postgresql-15 postgresql-client-15

Fazit

Dieser kurze Artikel fällt Mal wieder unter die Kategorie “Info an mich”. Wenn ich erneut in die Situation komme einen PostrgeSQL-Cluster zu aktuslisieren, weiß ich wo ich nachschauen kann.

Quellen

Fosdem 2026

2026-02-01T19:40:41+01:00

Durch ein paar glückliche Umstände, bekam ich die Gelegenheit dieses Jahr auf die Fosdem 2026 (Free and Open Source Software Developers European Meeting) zu fahren. Gemeinsam mit @angry sind wir am Freitag nach Brüssel gereist um uns Europas größte Entwicklerkonferenz mit über 8.000 Besuchern und 1.013 Vorträgen nicht entgehen zu lassen.

Banner der Fosdem 2026

Tag 1 verbrachten wir fast ausschließlich im Developer Room Modern Email . Hier bekam man das Gefühl, es passiert richtig was … in dem schon so häufig tot gesagten Protokoll. Neben Erfahrungsberichten und modernen Ansätzen von Mail-Clients, ging es vielfach um das Protokoll JMAP und das Mailserver-Projekt Stalwart . Meine beiden Favoriten waren hier:

Beide Vorträge waren kurzweilig und informativ. Inbesondere der Mensch hinter Stalwart, Mauro De Gennaro, war der gefragte Typ im Raum, da die Mail-Server-Communiy nach der ersten stabilen Version 1.0 lechzt, die im Sommer 2026 zu erwarten ist. Für mich ist das schon äußerst beeindruckend. Hier wird quasi ein neues Protokoll mit JMAP entwickelt und die ICANN (auch vor Ort vertreten) wartet auf “Futter” um die Details in einen Standard zu gießen. Mir ist zwar grundsätzlich klar wie das läuft, aber ich war noch nie (gefühlt) live dabei.

Dass die Vertreter von Thunderbird, in ihrem Vortrag die aktuelle Entwicklung mit nur EINEM Wort (in den Slides) erwähnt und sich sonst um die Integration von Microsoft-Exchange befasst haben, hab ich überhaupt nicht verstanden.

Neben den Vorträgen gab es einen persönlichen Austausch zwischen ein paar Entwicklern der Heinlein-Gruppe und uns. Die sind in der Szene insbesondere für die Mail-Server-Angebote von https://mailbox.org bekannt.

Am Abend fanden wir uns dann in einer Brüssler Bar, mitten im Treffen der XWiki-, CryptPad-, Passbolt-, Nextcloud-, und OpenProject-Communitiy, wieder. Auch an dieser Stelle gab es noch einen bereichernden Austausch mit einer Psychologin (Bereich Forschung) und @ramrom .

Tag 2 wurde dann hauptsächlich zur Erkundundung der zahlreichen Aussteller mit vielen kleinen Gesprächen, dem ein oder anderen Wiedersehen von bekannten Gesichtern und ein paar Vorträgen aus dem Track Identity and Access Management gefüllt. Auch das war interessant. Aber wir waren dann irgendwann komplett bedient. Wenn wundert es? Nach zwei Tagen Druckbetankung von technisch anspruchsvollen Vorträgen ist das Hirn irgendwann nicht mehr aufnahmefähig.

Nun (auf der Heimfahrt) denke ich, dass sich der Weg nach Brüssel absolut gelohnt hat. Ich hab das Gefühl nicht das letzte Mal auf der Fosdem gewesen zu sein und freue mich wenn es nochmal klappt. Aber das nächste Mal gibt es gleich an Tag 1 einen Fosdem-Hoodie. Die waren einfach zu schnell ausverkauft.

Aktuelles zu Let's Encrypt

2026-01-03T06:05:59+01:00

Ich bin diese Woche über die Podcast-Episode News PKI-Neuerungen, Tor-Umbau und React2Shell von Passwort gestolpert, die sich mit den Neuerungen von Let’s Encrypt sowie dem Thema PKI insgesammt angenommen hat. Die komplette Episode geht dabei auf einige weitere interessante Themen ein. Für mich wertvoll waren insbesondere die im Folgenden beschriebenen Infos.

Laufzeit von Let’s-Encrypt-Zertifikaten wird angepasst

Am 02.12.2025 veröffentlichte Let’s Encrypt einen Blog-Post , in dem eine Änderung der Zertifikats-Laufzeiten bekannt gegeben wurde. Die Umsetzung wird in folgenden Schritten geschehen:

13.05.2026: Reduzierung der Laufzeit von Zertifikaten auf 45 Tagen im ACME-Profil tlsserver.
Das Default-Profil classic ist davon nicht betroffen.
10.02.2027: Reduzierung der Laufzeit von Zertifikaten im Default-Profil classic auf 64 Tage.
16.02.2028: Reduzierung der Laufzeit von Zertifikaten im Default-Profil classic auf 45 Tage.

Damit die ACME-Clients ordentlich mitbekommen, wann sie das Zeritifkat erneuern müssen, sollten diese das Feature ACME Renewal Information (ARI) unterstützen. Ich präferiere bisher dehydrated als ACME-Client. Dieser unterstützt (soweit ich das sehe) derzeit noch kein ARI. Aber ein entsprechender Pull-Request liegt bereits vor. Ich gehe davon aus, dass das rechtzeitig umgesetzt wird.

Mit der Anpassung der Laufzeiten kommt Let’s Encrypt den Basline Requirements (s.u.) nach die u. a. die maximale Dauer von Zertifikats-Laufzeiten für CAs vorgibt. Dort heißt es aktuell:

Subscriber Certificates issued on or after 15 March 2029 SHOULD NOT have a Validity Period greater than 46 days and MUST NOT have a Validity Period greater than 47 days.

Das muss man aktiv weiter verfolgen. Es ist zu erwarten, dass die Laufzeiten in Zukunft weiter reduziert werden. Das ist zumindest der Wunsch der Browserhersteller.

DNS-PERSIST-01 in Planung

Im gleichen Blog-Post von Let’s Encrypt wird ein neuer DNS-Challenge-Typ namens DNS-PERSIST-01 angekündigt. Dieser soll die Automatisierung zur Ausstellung von Zertifikaten vereinfachen. Geplant ist, dass der DNS-Ressource-Record vom Typ TXT, der bei der (bisherigen) DNS-01-Challgenge dynamisch gesetzt werden musste, einmalig und dauerhaft eingetragen wird. Hier darf man gespannt sein, wie schnell das kommt, da es hier Absprachen mit der IETF und dem CA/Browser-Forum gibt/geben muss. Ein erster Entwurf liegt bei der IETF bereits vor.

Baseline Requirements

Nicht neu … aber ich hatte das bisher einfach noch nicht hinterfragt: Wie kann es funktionieren, dass verschiedene die Certificate Authorities (CAs) die ausgestellten Zertifikate einheitlich und nach bestimmten Qualitätskriterien/Richtlinien ausstellen? Hier kommen die eben erwähnten Baseline Requirements ins Spiel. Verfasser ist ein Zusammenschluss verschiedener Browser-Hersteller und Zertifizierungsstellen, der unter dem namen CA/Browser-Fourm auftritt.

Certificate Transparency (CT) Logs

Die Logs über die bisher ausgestellten Zertifikate wechseln von RFC 6962 API zu Static CT API . Der eigentlich neue RFC 9162 fand keine praktische Anwendung. Durch Static CT wird der Aufwand für das Vorhalten der Logs und die Beantwortung von Anfragen deutlich reduziert. Eine Beschreibung, wie das funktioniert, ist im Let’s-Encrypt-Blogbeitrag End of Life Plan for RFC 6962 Certificate Transparency Logs vom 14.08.2025 und im Heise-Artikel Static-CT verbessert Zertifikatsprotokolle vom 18.07.25 gut nachzulesen.

Um die CT Logs einzusehen gibt es Tools wie z. B. crt.sh . Das war mir auch komplett neu. Hier sind pro Domain alle bisher ausgestellten Zeritifikate hinterlegt. Ich bin fasst vom Stuhl gefallen, als ich gesehen hab, was man hier alles ablesen kann:

Gekürzte Ausgabe von crt.sh am Beispiel toheine.net

Natürlich sind die ausgestellten und produktive Zertifikate im Internet und damit für alle Welt einsehbar. Aber mir war nicht klar, dass jede Erzeugung auch offen im Netz steht (auch wenn ich das Zertifikat nicht nutze). In Zukunft werde ich wohl in meinen Fortbildungen keine exemplarischen Zertifikate auf den Namen <name>-is-doof.meine-domain.tld erzeugen 😉 .

Fazit

Die erwähnte Podcast-Episode mit dem Titel News PKI-Neuerungen, Tor-Umbau und React2Shell war mit zahlreichen wichtigen Infos für mich gespickt. Nicht nur zu den aktuellen News von Let’s Encrypt … auch die weiteren Themen waren super aufbereitet. Ich muss peinlich berührt zugeben, dass ich entsprechende SSL-/TLS-Zertifikate schon seit vielen Jahren fröhlich ausstelle, aber mir hat gleichzeitig einiges an Hintergrundwissen gefehlt. Wieder was gelernt! Danke an @christopherkunz und @syst für die Aufbereitung. Euren Podcast werde ich in Zukunft aktiv verfolgen und weiter empfehlen.

Quellen

Debian: Einzelne Pakete aus Testing installieren

2025-11-29T14:47:13+01:00

Auf meinen PCs oder Notebooks setze ich in der Regel auf Debian oder Arch Linux. Dieser Mix ermöglicht mir entweder eine stabile Distribution mit Point-Releases (Debian) oder ein Rolling-Release-Prinzip mit wirklich aktueller Software (Arch Linux). Somit habe ich das Beste aus zwei Welten. Brauch ich auf meinen Debian-Kisten vereinzelt aktuellere Software, helfe ich mir mit Flatpak aus.

In seltenen Fällen möchte ich auf Debian neuere Software nutzen, die ich nicht über Flatpak installieren kann oder will und die aus einer zuverlässigen Paket-Quelle stammen soll. Hierfür gibt es für mich zwei Möglichkeiten:

Debian Backports : Hier handelt es sich um Pakete aus dem Testing-Repo die jedoch mit dem aktuellen Stable-Release kompatibel sind (Zitat: adjusted and recompiled for usage on Debian stable). Das ist super. Allerdings muss das jeweilige Paket auch in den Backports vorliegen. Häufig ist genau das Paket, das ich suche, hierüber nicht verfügbar.
Debian Testing aktivieren und über Apt pinning dafür sorgen, dass nur bestimmte Pakete aus Testing installiert werden. Grundsätzlich verbleibt das System auf dem jeweiligen Stable-Zweig.

Für mein heutiges Bedüfrnis, ein aktuelles Paket fwupd zu installieren, musste ich an dieser Stelle Variante 2 wählen, da dieses nicht über die Debian Backports angeboten wird.

Vorbereitung der Debian Quellen

In einem ersten Schritt müssen die notwendigen Einträge für Testing in den Quellen eingetragen werden. Ich hab seit Debian Trixie die neue Schreibweise nach deb822 übernommen. Sofern dass auf einem bestehenden System noch nicht nach diesem System umgebaut wurde, hilft der Befehl apt modernize-sources. Mehr Details gibt es auf Linuxnews dazu.

Meine Debian-Quellen liegen in der Datei /etc/apt/sources.list.d/debian.sources und haben folgenden Aufbau:

Types: deb deb-src
URIs: http://deb.debian.org/debian/
Suites: trixie
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb deb-src
URIs: http://security.debian.org/debian-security/
Suites: trixie-security
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb deb-src
URIs: http://deb.debian.org/debian/
Suites: trixie-updates
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: http://deb.debian.org/debian/
Suites: trixie-backports
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
Enabled: yes

Types: deb
URIs: http://deb.debian.org/debian/
Suites: testing
Components: main contrib non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
Enabled: yes

Neben den Backports (im vierten Code-Block) liegen im nachfolgenden Block die Testing Quellen. Dieser Block überschreibt allerdings die Einstellungen des ersten Blocks (Stable-Quellen). Würde jetzt das System aktualisiert werden, zieht es den Rechner komplett auf Debian Testing hoch. Und genau das soll vermieden werden.

Feinjustierung mit Apt Pinning

Mit der zusätzlichen Datei /etc/apt/preferences können nun Einstellungen vorgenommen werden, welche Pakete aus welchen Quellen kommen sollen. Für meinen Verwendungszweck hier, soll nur Das Paket fwupd aus testing installiert werden. Da es hier noch die Abhängikeiten auf zwei weitere Pakete gibt (libfwupd3 und libflashrom1), sind diese ebenfalls aus testing zu beziehen. Die Datei hat folgenden Aufbau:

Package: *
Pin: release n=trixie
Pin-Priority: 900

Package: *
Pin: release a=testing
Pin-Priority: 50

Package: fwupd
Pin: release a=testing
Pin-Priority: 950

Package: libfwupd3
Pin: release a=testing
Pin-Priority: 950

Package: libflashrom1
Pin: release a=testing
Pin-Priority: 950

Im Prinzip steht hier, dass alle Pakete(Package: *) mit einer Priorität von 900 von der aktuellen stabilen Debian Version trixie installiert werden sollen. Testing hat hingegen eine kleine Priorität bekommen. Die drei genannten Ausnahmen haben hingegen eine höhere Priorität als die üblichen Pakete und werden daher aus dem Testing-Repo genommen.

Hinweis

Angaben zu Trixie-Backports sind hier nicht enthalten. Dieses Repo erhält standardmäßig eine Prioriät von 100 und kann mit dem Befehl apt install -t trixie-backports <paket> verwendet werden.

Damit ist die Einstellung fertig. Das Programm fwupd steht nun über beide Repos (Trixie und Testing) zu Verfügung. Dies kann mit dem Befehl apt show -a fwupd eingesehen werden:

Package: fwupd
Version: 2.0.17-6
Priority: optional
Section: admin
Maintainer: Debian EFI <debian-efi@lists.debian.org>
Installed-Size: 11,7 MB
Provides: fwupdate
Depends: systemd-sysusers, libarchive13t64 (>= 3.2.1), libblkid1 (>= 2.17.2), libc6 (>= 2.38), libcbor0.10 (>=>
Recommends: python3, bolt, default-dbus-system-bus | dbus-system-bus, udisks2, fwupd-signed, jq
Suggests: gir1.2-fwupd-2.0
Conflicts: fwupdate-amd64-signed, fwupdate-arm64-signed, fwupdate-armhf-signed, fwupdate-i386-signed
Breaks: fwupdate (<< 12-7), libdfu-dev (<< 0.9.7-1), libdfu1 (<< 0.9.7-1)
Replaces: fwupdate (<< 12-7), gir1.2-dfu-1.0 (<< 0.9.7-1), libdfu-dev (<< 0.9.7-1), libdfu1 (<< 0.9.7-1)
Homepage: https://github.com/fwupd/fwupd
Download-Size: 4.729 kB
APT-Manual-Installed: yes
APT-Sources: http://deb.debian.org/debian testing/main amd64 Packages
Description: Daemon für Firmware-Updates
 Der Daemon fwupd ermöglicht Sitzungs-Software die Aktualisierung von
 Geräte-Firmware. Sie können entweder eine GUI-Softwareverwaltung wie
 GNOME Software verwenden, um Updates anzusehen und anzuwenden, oder
 das Kommandozeilenwerkzeug oder direkt die D-Bus-Systemschnittstelle.
 Firmware-Updates werden für eine Vielzahl von Technologien unterstützt.
 Siehe <https://github.com/fwupd/fwupd> für Details.

Package: fwupd
Version: 2.0.8-3
Priority: optional
Section: admin
Maintainer: Debian EFI <debian-efi@lists.debian.org>
Installed-Size: 10,5 MB
Provides: fwupdate
Depends: systemd-sysusers, libarchive13t64 (>= 3.2.1), libblkid1 (>= 2.17.2), libc6 (>= 2.38), libcbor0.10 (>=>
Recommends: python3, bolt, default-dbus-system-bus | dbus-system-bus, udisks2, fwupd-signed, jq
Suggests: gir1.2-fwupd-2.0
Conflicts: fwupdate-amd64-signed, fwupdate-arm64-signed, fwupdate-armhf-signed, fwupdate-i386-signed
Breaks: fwupdate (<< 12-7), gir1.2-dfu-1.0 (<< 0.9.7-1), libdfu-dev (<< 0.9.7-1), libdfu1 (<< 0.9.7-1)
Replaces: fwupdate (<< 12-7), gir1.2-dfu-1.0 (<< 0.9.7-1), libdfu-dev (<< 0.9.7-1), libdfu1 (<< 0.9.7-1)
Homepage: https://github.com/fwupd/fwupd
Download-Size: 4.409 kB
APT-Sources: http://deb.debian.org/debian trixie/main amd64 Packages
Description: Daemon für Firmware-Updates
 Der Daemon fwupd ermöglicht Sitzungs-Software die Aktualisierung von
 Geräte-Firmware. Sie können entweder eine GUI-Softwareverwaltung wie
 GNOME Software verwenden, um Updates anzusehen und anzuwenden, oder
 das Kommandozeilenwerkzeug oder direkt die D-Bus-Systemschnittstelle.
 Firmware-Updates werden für eine Vielzahl von Technologien unterstützt.
 Siehe <https://github.com/fwupd/fwupd> für Details.

Durch die höher gesetzte Priorität in der /etc/apt/preferences wird die neueste Version (hier 2.0.17-6) über den regulären Befehl installiert:

apt install fwupd

Fazit

Damit bin ich glücklich. Mein Paket ist in der gewünschten (aktuelleren) Version installiert, ich bleibe auf dem Stable-Release (Trixie) und hab trotzdem eine vertrauenswürdige Art und Weise der Installation über die Paket-Quellen von Debian.

Der Grund für den Wunsch nach der höheren Version ist übrigens ein Bug in der über Trixie bereit gestellten Version 2.0.8-3, die ein Firmware-Update meines Thunderbold Host Controllers verhindert .

Quellen

Archiv-Seite bereit gestellt

2025-11-16T10:49:35+01:00

Nach etwas über 2 Jahren dieses Blog-Betriebs, muss ich immer mehr herum klicken, um bestimmte Artikel zu finden. Es ist ja nicht so, dass hier wöchentlich was passiert. Aber einige wichtige Artikel rutschen nach hinten. Es gibt zwar deutlich mächtigere Hugo-Themes, wie das von mir verwendete Theme hugo-geekblog , aber die sind mir häufig zu überladen und ich hab schlichtweg nicht die Zeit und Lust mich in ein neues System einzudenken. Außerdem finde ich das Theme echt gut.

Erfreulicherweise ist Hugo aber sehr anpassungsfähig. Ich benötige mit meinen wenigen Beiträgen pro Jahr keine Suchfunktion. Eine einfache Archivseite sollte reichen und diese war in einer Sonntag-Morgen-Aktion auch schnell bereit gestellt. Das Ergebnis findet sich oben in der Navigation bzw. über nachfolgenden Link: Archive

Umsetzung

Ganz ehrlich: Ich bin absolut kein Hugo-Profi. Aber mit der vorhandenen Doku und der Communtity, wird man schnell fündig. Die relevanten Links befinden sich unten in den Quellen-Angaben. Ich habe mich hauptsächlich an diesem Beitrag orientiert. Damit konnte ich arbeiten und eine Anpassung für meinen Verwendungszweck vornehmen.

Schritt 1 ist die Bereitstellung einer Seite unter content/archive.md:

---
title: "Posts Archive"
layout: archive
---

Schritt 2: Die Inhalte werden dynamisch erzeugt und kommmen aus der Datei layouts/archive.html:

{{ define "main" }}
<section class="gblog-markdown">
  
  {{/* List all usesd tags */}}
  <h1>Tags</h1>
  {{ $tags := .Site.Taxonomies.tags }}
  {{ if gt (len $tags) 0 }}
    {{ range $name, $taxonomy := $tags }}
      {{ with $.Site.GetPage (printf "/tags/%s" $name) }}
        <span class="gblog-post__tag gblog-button gblog-button--regular" style="margin: 5px">
          <a 
            class="gblog-button__link"
            href="{{ .RelPermalink }}" title="{{ .Title }}">
            {{ .Title }}
          </a>
        </span>
      {{ end }}
    {{ end }}
  {{ end }}

  {{/* List all blog posts grouped by year */}}
  {{ $type := "posts" }}
  {{ $.Store.Set "count" 1 }}
  {{ range (.Site.RegularPages.GroupByDate "2006") }}
    {{ if (gt (where .Pages "Type" $type) 0) }}
      {{ range (where .Pages "Type" $type) }}
        {{ if (eq ($.Store.Get "count") 1) }}
          <h1>{{ .Date.Format "2006" }}</h1>
          {{ $.Store.Set "count" 0 }}
        {{ end }}
      {{ end }}
      {{ $.Store.Set "count" 1 }}
      <ul>
      {{ range (where .Pages "Type" $type) }}
        <li>
            {{ .Date.Format "02.01." }}:
            <a href="{{ .RelPermalink }}">{{ .Title }} </a>
        </li>
      {{ end }}
      </ul>
    {{ end }}
  {{ end }}

</section>
{{ end }}

Ein paar Anmerkungen dazu:

Zeile 2 und 10: Formatierung mit meinem Theme-CSS
Zeile 4 bis 19: Übersicht der verwendeten Tags. Formatiert als Button des eingesetzten Hugo-Themes
Zeile 22: Nur der Typ “Posts” erscheint in den Archiv-Einträgen
Zeile 23 bis 42: Die eigentliche, nach Jahr gruppierte Auflistung aller Posts

Fazit

In den Zeilen sind noch ein paar Altlasten enthalten. Diese werden im Nachgang entfernt. Evtl. bekomme ich noch einen Input von den Hugo-Profis aus meiner Communtiy. Ansonsten finde ich das erste Ergebnis hier recht hilfreich. Die Aktion hatte darüber hinaus noch den Nebeneffekt, dass ich mal in meinen verwendeten Tags etwas ausgemistet habe.

Update am 19.11.2025: Die genannten Altlasten wurden soeben entfernt. Die Codeblöcke in diesem Beitrag sind entsprechend angepasst.

Quellen

Wordle mit Regex lösen

2025-11-11T09:12:24+01:00

Reguläre Ausdrücke (Regex oder RegExp) sind hilfreich, wenn relevante Informationen aus Texten heraus gefiltert werden müssen. In der Praxis ist das total hilfreich aber im Unterricht kann das Thema eine trockene Sache sein. Hier hilft es das Thema spielerisch anzugehen. Eine Idee ist das Lösen des Wortsuche-Spiels Wordle mit einer vorhandenen Wortliste und unter Verwendung von Regulären Ausdrücken.

Das originale Spiel ist auf den Seiten der New York Times . Allerdings gibt es hier nur ein Spiel pro Tag. Wer immer wieder neue Rätsel zum üben haben möchte, findet hier sein Glück:

https://wordlegame.org/

Inhalt

Die Idee

Sinn des Spiels ist es eigentlich, das jeweilige Wort ohne Cheating zu finden. Allerdings ist die Intention hier im Blog-Beitrag, nicht das Spiel an sich, sondern Lernende an Regex zu gewöhnen. Daher ist das Ziel, das Spiel mit Hilfe von Regex und einer Wortliste sicher zu lösen.

Unter Debian gibt es das bereits installierte Paket wamerican. Falls ein deutschsprachiges Wordle gelöst werden soll, kann das ebenfalls schon vorhandene Paket wngerman verwendet werden. Die beiden Pakete stellen im Verzeichnis
/usr/share/dict entweder eine englische (american-englisch) oder deutsche (ngerman) Wortliste bereit.

Beispielvorgehen

Zu Spielbeginn gibt man ein beliebigesi, fünfstelliges, Wort ein. Wenn keine oder wenige Treffer erzielt werden, verwendet man ein weiteres Wort, das möglichst keine Buchstaben aus dem ersten Versuch enthält. Im folgenden Beispiel kann das wie folgt aussehen.

Eingabe 1 und 2 in Wordle

Bei dem Versuch aus der Abbildung ist zu erkennen, dass die Buchstaben G und T an der korrekten Stelle stehen. Die Buchstaben I und L hingegen, sind zwar im Wort enthalten, aber stehen der falschen Stelle. Mit Regex kann jetzt gefiltert werden. Die englischsprachige Wortliste besteht aus 104.334 Wörtern:

cd /usr/share/dict/
wc -l american-english

In dem Spiel sind jedoch nur fünfstellige Wörter verlangt. Das heißt, zwischen Zeilenanfang ^ und Zeilenende $ müssen genau fünf Zeichen stehen (jeweils repräsentiert durch einen Punkt):

grep ^.....$ american-english

Es sind in der hier verwendeten Liste 7.044 fünfstellige Wörter enthalten. Das reduziert die verbleibende Anzahl der Lösungsmöglichkeiten erheblich, aber bringt hier noch keinen Mehrwert. Es verbleiben nur noch vier Versuche. Wenn im regulären Ausruck die Buchstaben G und T schon gesetzt werden, reduziert sich die Liste weiter. Zusätzlich wird über die Option -i die Unterscheidung zwischen Groß- und Kleinschreibung ignoriert:

grep -i ^..g.t$ american-english

Es verbleiben 24 Wörter. Das ist deutlich besser, aber immer noch schwer zu erraten. Es ist zu erkennen, dass die Buchstaben E, O, A, V, N und M überhaupt nicht enthalten sind. Also können diese an den noch nicht fest stehenden Stellen ausgeschlossen werden:

grep -i ^[^eoavnm][^eoavnm]g[^eoavnm]t$ american-english

Es verbleiben nur noch 8 Wörter. Weiterhin ist zus sehen, dass der Buchstabe I nicht an Stelle 4 sein kann. Der Filterausdruck wird somit entsprechend erweitert:

grep -i ^[^eoavnm][^eoavnm]g[^ieoavnm]t$ american-english

-> Es verbleiben 7 Wörter:

bight
fight
light
right
sight
tight
wight

Damit kann es weiter gehen. In der Folge wird ein weiteres Wort probiert:

Eingabe 3 in Wordle

Das Wort ist zwar nicht erraten, aber es ist zu sehen dass uns unser Vorgehen weiter bringt. Die Wortliste hat sich nicht weiter reduziert, was der angepasste reguläre Ausdruck verrät:

grep -i ^[^eoavnm]ight$ american-english

Die Liste hat die gleiche Länge wie zuvor:

bight
fight
light
right
sight
tight
wight

Es ist jedoch auch zu sehen, dass der Bustabe L enthalten sein muss. Das hätte auch schon im Schritt vorher auffallen können. Damit bleibt nur noch das letzte mögliche Wort Light:

Eingabe 4 in Wordle

Varianten

Die Ausgabe kann auch via Pipelines weiter gefiltert werden. Im nachfolgenden Beispiel wird nach den ersten beiden Eingabe-Versuchen im Spiel definiert, an welcher Stelle welcher Buchstabe nicht stehen kann und dann erneut gefilter, was als Buchstabe enthalten sein muss (egal an welcher Stelle). Damit wären wir schon nach drei Versuchen offensichtlich zum Ziel gekommen:

grep -i ^[^eoavnm][^eoavnm]g[^ieoavnm]t$ american-english | grep l

Viele Wege führen nach Rom: Die Verwendung oben ist nicht sehr elegant aber sie ist eine Art Herleitung wie man sich Schritt für Schritt zum Zielwort filtert. Mit folgender Eingabe kann man die Durchführung etwas effizienter durchführen:

grep -vi [eoavnm] american-english | grep -i ^..g.t$ | grep l

Abschließende Hinweise

Je nach verwendeter Wortliste verbleiben bei der Filterung mehr oder weniger Wörter als hier im Beispiel gezeigt.
Es empfiehlt sich bei Wordle in den ersten beiden Versuchen möglichst alle Vokale auszuschließen
In den Online verfügbaren Spielen können auch Wörter gesucht sein, die in den verwendeten Wortlisten nicht stehen. Dann kann das Spiel natürlich nicht auf die hier beschriebene Weise gelöst werden. Das ist aber eine sehr seltene Ausnahme.

Fazit

Mit diesem Ansatz zur Lösung eines Spiels ist die Hürde zur Nutzung von Regulären Ausdrücken etwas weniger hoch und es wird schnell ersichtlich, dass mir das Werkzeug helfen kann. Darüber hinaus gibt es aber noch viele weitere Ideen. Witzig finde ich die Idee von @blinry , der auf seiner Webseite (vor vielen Jahren schon) einen kleinen Blogpost mit einem Hinweis hinterlegt hat, dass in den Kommentaren des Linux-Kernels zahlreiche Kraftausdrücke enthalten sind. Beispielhaftes vorgehen:

cd /tmp
wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.19.12.tar.xz
tar -xJvf linux-5.19.12.tar.xz
cd linux-5.19.12
egrep -ir "(fuck|sucks|shit|bloody|crap)" .

Quellen

DNS-Cleanup bei Hetzner

2025-11-06T15:30:26+01:00

Ich bin seit vielen Jahren Kunde bei Hetzner (beruflich wie privat). Und wie oft gehe ich in die WebUI von Hetzner Robot, die DNS-Konsole oder in die Hetzner Console (ehemals Hetzner Cloud)? Antwort: Nicht so oft. Es läuft ja alles und selbst neue VMs kann ich über die API erzeugen. Warum soll ich mir das dann zusammen klicken. Das ist aber genau so lange voll OK, bis es eine wesentliche Änderung gibt, die mir dann über die Bubble zugespielt wird: Ey … haste mitbekommen … die schalten die DNS Console ab. 😳

Inhalt:

DNS Console zieht um

Dann muss ich mich halt mal wieder einloggen. In der DNS-Console fällt mir dann sofort das Banner auf:

Info-Banner: DNS Console zieht in die Hetzner Console

Umgezogen war das wirklich einfach. Wie gewohnt ist in den Docs alles vorbildlich beschrieben. Kann nichts schief gehen.

In einem meiner Projekte, mit denen ich zu tun habe, gab es dann aber doch einen Impact: Dort werden via API die _acme-challenge-Einträge für die DNS-01-Challenge gesetzt. Das bisher verwendete Ansbile-Modul Community.Dns ist aber nach der durchgeführten Migration nicht mehr kompatibel. Ein wenig weitere Recherche führte mich zu dem zone_rrset-Modul von Hetzner.Hcloud .

Das Modul wird gerade aktiv entwickelt und erst vor wenigen Tagen wurde die Version 6.0.0 veröffentlicht. Daher musste ich das Modul auf meinem Ansible-Host erstmal aktualisieren:

ansible-galaxy collection install hetzner.hcloud --force

Damit konnte ich nun relativ schnell erfolgreich testen und die notwendigen Resource Records setzen. Aber … und das ist meine komplett individuelle und subjektive Erkenntnis: Das Vorgehen via API die DNS-Einträge zu setzen ist gut und schön. Das funktioniert auch. Aber wenn der DNS-Server-Betreiber seinen Zugriff über die API ändert, muss man halt selbst nacharbeiten. Mir ist das jetzt zum zweiten Mal auf die Füße gefallen (das erste Mal war ich aber bei einem anderen DNS-Registrar).

Dieses Szenario ist genau der Grund, warum ich bevorzugt auf einen eigenen DNS-Server setze und dann darüber die Let’s-Encrypt-Zertifikate via DNS-01-Challenge erzeuge. Ich hab das Vorgehen hier im Blog bereits beschrieben.

Domain-Erwerb und Zonen-Datei

Bei meinen Tests ist mir noch ein weiterer Sachverhalt aufgefallen. Und das schreibe ich hier nur, damit ich in ferner Zukunft wieder in meinem eigenen Notizen nachlesen kann, was der Stolperstein ist. Es geht um die Schritte die bei Domain-Kauf durchzuführen sind.

Bei den meisten mir bekannten DNS-Registraren wird bei Kauf einer Domain sofort und automatisch eine entsprechende Zonen-Datei angelegt auf die ich über eine WebUI zugreifen kann. Bei Hetzner ist das nicht so. Wenn ich via Hetzner Robot eine Domain kaufe und ich nicht im Vorfeld eine entsprechende Zonen-Datei mit den notwendigen authoritativen DNS-Servern und einem SOA-Eintrag eingestellt habe, erfolgt eine Warnung bei Kauf, die ich bestätigen muss …

Warnung bei Kauf der Domain dass noch kein DNS-Eintrag hinterlegt wurde

… und eine Fehlermeldung (per Mail und in der GUI) wenn ich dann die Domain “zahlungspflichtig registriert” habe. Im Robot wird das auch schön dargestellt (Weißes Kreuz auf rotem Grund rechts im Bild):

Hinweis auf unvollständig registrierte Domain

Die Fehlermeldung kann in den Domainmeldungen nachgelesen werden (Auszug):

response:
  result:
    code: '2305'
    msg: 'Object association prohibits operation'
    extValue:
      -
        value: ERROR
        reason: 'Nameserver error [ERROR: 133 Answer must be authoritative \
                 (nameserver, ip, proto, record) \
                 (oxygen.ns.hetzner.com, 2a01:4f8:0:1::add:2992, udp, NS)]'
      -
        value: ERROR
        reason: 'Nameserver error [ERROR: 901 Unexpected RCODE \
                 (nameserver, ip, proto, record) \
                 (oxygen.ns.hetzner.com, 2a01:4f8:0:1::add:2992, udp, NS)]'

Die Korrektur ist dann kein Hexenwerk, wenn man weiß wie.

Schritt 1 - Zonen-Datei anlegen: In der Hetzner-Console muss in dem entsprechenden Projekt unter DNS (1) eine DNS-Zone mit der neu erworbenen Domain hinzu gefügt werden (2). Im Formular trägt man den gewünschten Domainnamen (3) ein. Für den Test reicht eine leere Zone (4):

DNS-Zone anlegen

Im Anschluss kann ich in die eben angelegte Zonen-Datei klicken und mir die dort hinterlegten NS- und SOA-Einträge anschauen, sowie weitere eigene Records anlegen. Oben erscheint eine kleine Warnmeldung mit einem Button daneben, der auf eine fehlerhafte Zonen-Delegierung hinweist:

Hinweis auf fehlerhafte Zonen-Delegierung

Schritt 2 - Fehler beseitigen: Ein reiner Klick auf “Nameserver überprüfen” bringt hier nichts. Es muss noch im Hetzner Robot, bei den Domains 1x auf “Domain ändern” geklickt werden. Aktualisiere ich dann die Seite, ist die oben erwähnte rote Fehlermeldung weg. Zudem wird die Korrektur via Mail bestätigt. Erst im Anschluss führt der Klick in der Hetzner Console “Nameserver überprüfen” das gewünschte Ergebnis und die Meldung verschwindet.

Fazit

Die Migration und das Troubleshooting meiner unvollständigen Domain-Registrierung hat mich gestern überhaupt nicht gestört. Es war alles irgendwie plausibel, nachvollziehbar und super dokumentiert. Zeit gekostet hat es dennoch. Wenn ich aber erneut über so ne Migration stolpere oder mich beim nächsten Domainkauf über Fehlermeldungen wundere, dann lese ich halt meinen eigenen Blog-Artikel. 😎

Quellen

Hello GrapheneOS

2025-10-02T15:16:38+02:00

Ich hatte jetzt lange Jahre auf CalyxOS gestzt. Das war für mich total gut. Zumal ich wirklich kein Custom-ROM-Experte bin. Ich lese mich ein, höre mich um und entscheide. Da muss es schon gewichtige Gründe geben von einem funktionierenden System zu wechseln. Und den gab es jetzt. Aufgrund den (vorbildlich transparenten) Informationen von CalyxOS in einem Letter to the CalyxOS community wurde über den aktuellen Stand mit dem Hinweis informiert, das das Projekt in den kommenden Monaten pausiert und daher auch keine Updates erhält. Für mich der Grund auf meinem Smartphone ein anderes, interessantes System zu installieren.

Entschieden habe ich mich für GrapheneOS . Dieses System wird in dem Kreis meiner Techie-Kollegen häufig eingesetzt und für mich enstand die Gelegenheit das zu testen. Die Installation war denkbar einfach und ist hier Schritt-für-Schritt dokumentiert. Ich habe mich dabei für die Installation via CLI entschieden und das hat auf anhieb geklappt. Wenn ich denke was für ein Krampf das noch vor Jahren war, ist das ganze Prozess in 60 Minuten erledigt. Die meiste Zeit ging für das Einlesen drauf. Die eigentliche Installation ist in wenigen Minuten erledigt.

Jetzt gilt es in den nächsten Tagen die ganzen Messenger und Konten auf dem neuen Gerät einzurichten. Wer mehr zu GrapheneOS wissen will … ich kann den folgenden Artikel von Mike Kuketz (2023) empfehlen: https://www.kuketz-blog.de/grapheneos-der-goldstandard-unter-den-android-roms-custom-roms-teil7/

Toolbox aktualisiert

2025-06-03T10:27:13+02:00

Ich hatte mir schon länger vorgenommen die Toolbox dieser Webseite etwas zu überarbeiten. Ziel ist es, für verschiedene Bereiche, die jeweiligen Werkzeuge aufzuführen. Daher gibt es nun die folgenden Abschnitte:

Allgemeine Hinweise zur Software-Auswahl
Werkzeuge für den PC bzw. für das Notebook
Empfehlungen (vorwiegend Apps) für Smartphones/Tablets
Kleine Werkzeuge die online zu Verfügung stehen
Tools die ich ich auf der Kommandozeile empfehlen kann

Insbesondere die letzten beiden Kategorien sind jetzt nur initial gefüllt. Es fehlen noch weitere Apps/Online-Tools, ein paar Beschreibungen und weitere Quellen. Da wird noch einiges folgen.

Nationaler Akademietag 2025 in Weilburg

2025-05-25T08:21:21+01:00

Ein kleiner Beitrag für das Archiv hier. am 23./24.05.2025 fand an der Technikakademie Weilburg der Nationale Akademietag des Vereins IT-Bildungsnetz statt. Infos dazu gibt es unter https://www.it-bildungsnetz.de .

Es waren spannende Vorträge dabei, die ich in den kommenden Wochen unbedingt nacharbeiten möchte. Das Material zu den Vorträgen, gibt es unter dem eben genannten Link. Die Folien zu meinem Vortrag Praktische Prüfungen in CCNA-Modulen unter Verwendung eines Instruktoren-Servers stelle ich direkt hier ein: Foliendownload

Festplatten auf Rootserver sicher löschen

2025-05-03T07:15:24+02:00

Heute habe ich einen Root-Server bei Hetzner gekündigt. Das Ding war ein Proxmox-Backup-Server und hat knapp 4 Jahre seinen Dienst getan. Ich hab den Service auf einen anderen Rooti umgezogen. Nun wollte ich allerdings sicher stellen, dass die Platten auch garantiert keine Daten mehr enthalten und dazu habe ich das Tool shred verwendet.

Zu Beginn musste ich im Hetzner Robot das Rescue-System aktivieren und den Server neu starten. Nach einem SSH-Login erscheint der Prompt root@rescue ~ # und ich konnte direkt los legen. Das Software-RAID und das LVM sind im Rescue-Modus aktiv (wenn auch nicht gemountet). Beides musste ich vorab entfernen.

Mit dem Kommando lsblk werden mir alle Block-Devices deren Partitionsschema gezeigt. Die für diesen Beitrag leicht veränderte Ausgabe, sah wie folgt aus:

NAME              MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
loop0               7:0    0  3.4G  1 loop  
sda                 8:0    0  2.7T  0 disk  
├─sda1              8:1    0  512M  0 part
│ └─md0             9:0    0 1022M  0 raid1
├─sda2              8:2    0  2.7T  0 part  
│ └─md1             9:1    0  2.7T  0 raid1 
│   ├─vg0-root    253:0    0   20G  0 lvm   
│   ├─vg0-swap    253:1    0    4G  0 lvm   
│   └─vg0-data    253:2    0  2.5T  0 lvm   
└─sda3              8:3    0    1M  0 part  
sdb                 8:16   0  2.7T  0 disk  
├─sdb1              8:17   0  512M  0 part
│ └─md0             9:0    0 1022M  0 raid1  
├─sdb2              8:18   0  2.7T  0 part  
│ └─md1             9:1    0  2.7T  0 raid1 
│   ├─vg0-root    253:0    0   20G  0 lvm   
│   ├─vg0-swap    253:1    0    4G  0 lvm   
│   └─vg0-data    253:2    0  2.5T  0 lvm   
└─sdb3              8:19   0    1M  0 part

Um das Schreddern sauber durchzuführen, hab ich alle Logical Volumes, die Volumengruppe vg0 und das Physical Volume /dev/md1 gelöscht …

lvremove /dev/vg0/swap 
lvremove /dev/vg0/root 
lvremove /dev/vg0/home
lvremove /dev/vg0/data
vgremove vg0 
pvremove /dev/md1

… und auch das Software-RAID gestoppt:

mdadm --stop /dev/md0
mdadm --stop /dev/md1

Das notwendige Tool shred ist schon im Rescue-System bereits installiert. Allerdings dauert der Durchlauf ja einige Stunden bzw. Tage. Damit ich etwas flexibler in der Handhabung bin, hab ich noch tmux installiert:

apt install tmux

Nun konnte ich das Tool in einer tmux-Session starten:

tmux
shred -v /dev/sda /dev/sdb

Möchte ich die Verbindung detachen, so dass der Prozess in der tmux-Session weiterläuft, erreiche ich das mit STRG+B D

Das war es auch schon. Während des Schredderns, hab ich alle paar Stunden nach dem aktuellen Sand geschaut. Sobald ich eingeloggt war, konnte ich mit tmux a den Fortschritt beobachten. Nach etwa 34 Stunden war der Prozess beendet und ich konnte den Server kündigen. Wenn ich mich nicht täusche, hätte ich mir das Löschen des LVMs und das Stoppen des Software-Raids sparen können, wenn ich shred mit der Option -f (force) gestartet hätte. Das teste ich dann das nächste Mal.

Chemnitzer Linux-Tage 2025

2025-03-23T11:30:16+01:00

Seit langem war ich endlich wieder, zusammen mit @and1bm , @angry , @frank , Jürgen und Flori, auf den Chemnitzern Linux-Tagen. Irgendwie ist in den letzten Jahren immer wieder was dazwischen gekommen. Um so größer war die Vorfreude. Das ist schon ein ganz besonderes Event.

Ich muss sagen, es war wieder super: Das ist eine so große Veranstaltung und die ist hervorragend organisiert. Vom Catering, der Technik, der Security, dem Essen in der Mensa, bis hin zur Get-Together-Party am Samstag Abend. Ich hab keine Ahnung wie viele 1000 Stunden da im Vorfeld reingeflossen sind. Das ist der Wahnsinn. Sofern das hier irgend jemand vom CLT-Team liest: DAAAANKKEEE!!!

Dazu gab es an der Veranstaltung selbst zahlreiche freiwillige Helfer, ansprechende Stände, interessante Vorträge und ein unheimlich tolles Publikum. Die Begegnungen sind so wichtig und geben mir wieder genug Energie für den Alltag.

Abgesehen davon hab ich nen Sack voller Ideen im Gepäck, die ich mir in den nächsten Tagen ansehen werde. Chezmoi und Incus stehen ganz oben auf der Liste. Und ich werde mir noch die zahlreichen Videos von Vorträgen rein ziehen, die ich verpasst hab.

Ich hatte selbst einen Vortrag zum Thema Kleine Bash Tricks eingereicht und gehalten. Das dazugehörige Material findet Ihr hier:

Ich musste zwar etwas vorzeitig abreisen, aber ich bin insgesamt total zufrieden. Nun sitze ich im Zug, genieße die Landschaft und hoffe das ich nächstes Jahr wieder dabei sein werde.

Weitere Infos

Webseite der Veranstaltung:
https://chemnitzer.linux-tage.de/2025/de/
Video-Aufzeichnungen der Vorträge:
https://media.ccc.de/b/conferences/clt/2025

SSH-Grundlagen

2025-02-20T13:58:05+01:00

Sofern wir Dienste im Netz bereitstellen wollen, brauchen wir in der Regel auch einen sicheren Zugriff auf die entsprechenden Server. Das Protokoll der Wahl dafür ist ssh, das in wenigen Schritten auf einem System installiert ist und sofort seine Arbeit aufnimmt. Die Verbindung zwischen einem Admin-PC/-Notebook und der Remote-Maschine läuft ab diesem Zeitpunkt verschlüsselt.

Es müssen jedoch noch einige weitere Konfigurationen vorgenommen werden, um einen wirklich sicheren Zugriff zu gewährleisten. Im folgenden Beitrag, beschreibe ich die (aus meiner Sicht) dafür notwendigen Schritte, um einen OpenSSH-Server auf einem Linux-System zu betreiben.

Arbeitsweise von SSH

SSH steht für Secure Shell und arbeitet nach dem Client-Server-Prinzip. Der Zweck des Protokolls ist, dass sich ein User von einer lokalen Maschine auf einen entfernten Rechner verschlüsselt (secure) und konsolenbasiert (shell) verbinden kann. Nach Verbindungsaufbau können auf der Remote-Maschine entweder Befehle ausgeführt oder Konfigurationen vorgenommen werden.

Auf einem Debian-System kann der Server-Dienst mit dem Befehl …

apt install openssh-server

… installiert werden. Die Konfiguration findet in der Datei /etc/ssh/sshd_config statt. Um sich mit einem SSH-Server zu verbinden, wird ein SSH-Client benötigt, der in der Regel schon auf den unterschiedlichen Betriebssystemen zu Verfügung steht. Seit dem Update 1709 gilt das auch für Windows 10/11-Systeme. Der Weg über manuell installierte Clients (z. B. Putty) ist somit nicht mehr zwingend notwendig.

Bei Verbindungsaufbau, authentfiziert sich …

der Server bei dem verwendeten SSH-Client mit einem seiner SSH-Host-Keys aus dem Verzeichnis /etc/ssh/ und
der User beim Server via Passwort oder via Public-Key-Authentifizierung.

Bei einer ersten Verbindung von einer lokalen Maschine zu einem Benutzerkonto <username> auf einem SSH-Server <ziel> (kann eine IP-Adresse oder ein DNS-auflösbarer Name sein) via …

ssh <username>@<ziel>

… erfolgt in der Regel eine Warnmeldung, in der ein Fingerprint des verwendeten (öffentlichen) SSH-Host-Keys angezeigt wird. Beispiel:

The authenticity of host '192.168.56.114 (192.168.56.114)' can't be established.
ED25519 key fingerprint is SHA256:a8Uj2qFtWnW2ujoj6A3lZOh6WiqxmfcmqINS/2ttiIE.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Man sollte sich hier grundsätzlich die Zeit nehmen und diese Meldung nicht einfach ignorieren. Die Frage die sich hier stellt ist, ob der Fingerprint aus Zeile 2 (SHA256:a8Uj2qFtWnW2ujoj6A3lZOh6WiqxmfcmqINS/2ttiIE) auch wirklich unseren SSH-Server, mit dem wir uns verbinden wollen, identifiziert.

Bei Installation des SSH-Servers werden die SSH-Host-Keys generiert und die dazugehörigen Fingerprints auf der Konsole ausgegeben. Auszug:

Creating SSH2 RSA key; this may take some time ...
3072 SHA256:uxqATqHB5yuIhFM5ntHR4c/plCzgDd0U7ceHDeOlFE8 root@srwe2501 (RSA)
Creating SSH2 ECDSA key; this may take some time ...
256 SHA256:DkZKa/n5YgxHHMsFEaFrNodFVybNrCCw9EMq9+Mqc88 root@srwe2501 (ECDSA)
Creating SSH2 ED25519 key; this may take some time ...
256 SHA256:a8Uj2qFtWnW2ujoj6A3lZOh6WiqxmfcmqINS/2ttiIE root@srwe2501 (ED25519)
rescue-ssh.target is a disabled or a static unit not running, not starting it.
ssh.socket is a disabled or a static unit not running, not starting it.

In diesem Beispiel wurden insgesammt drei verschiedene SSH-Host-Key-Typen erstellt. Wir können sehen, dass der angzeigte Fingerprint vom Typ ED25519 (Zeile 6) unserer oben genannten Warnmeldung entspricht. Daher ist davon auszugehen, dass unser Zielserver tatsächlich das Gerät ist, mit dem wir uns verbinden wollen. In diesem Fall bestätigen wir die Frage oben mit yes. Sind die Fingerprints unterschiedlich, haben wir entweder bei Verbindungsaufbau einen Fehler gemacht oder wir laufen in einen MITM-Angriff (Machine in the Middle).

Tipp

Sofern man später nochmal die Fingerprints der SSH-Host-Keys benötigt, können diese mit dem folgenden Befehl ausgegeben werden: for i in /etc/ssh/*pub; do ssh-keygen -lf $i; done

Sobald die Warnmeldung akzeptiert wurde, wird der öffentliche Schlüssel in der Datei ~/.ssh/known_hosts auf dem lokalen Client gespeichert. Dadurch …

erfolgt keine erneute Warnmeldung bei erneuter Verbindung.
eine andere Warnmeldung, die nicht einfach ignoriert werden kann, sobald sich der Host-Key ändert.

Hinweis

Falls wir den Server bei einem Service-Provider bestellen, haben wir keinen Einblick in die SSH-Host-Key-Erzeugung bei der Installation. Je nach Anbieter bekommen wir i. d. R. die Fingerprints der SSH-Host-Keys via Mail oder können sie über ein Portal einsehen.

Zum Seitenanfang

Absicherung eines SSH-Server-Dienstes

Nach der Installation des SSH-Servers, nimmt dieser sofort seinen Betrieb auf und lauscht auf TCP-Port 22. Alle lokal angelegten Benutzerinnen und Benutzer, die auf dem SSH-Server existieren, können sich mit Ihrem Passowort anmelden. Ausnahme: Der Benutzer root darf sich i.d.R. nicht mit einem Passwort anmelden.

Der Verbindungsaufbau von einem SSH-Client erfolgt mit dem folgenden Kommando:

ssh -l <username> <ziel>

Häufig verwendet ist auch der folgende Aufruf, der zum gleichen Ergebnis führt:

ssh <username>@<ziel>

Wollen wir nun das Verhalten des SSH-Servers anpassen, müssen wir die notwendige Konfigurationsdatei unter /etc/ssh/sshd_config anpassen.

Hinweis

Bitte beachte das d in sshd_config. Es handelt sich dabei um die Konfigurationsdatei für den SSH-Server (d = Daemon). Bei der im selben Verzeichnis befindlichen Datei ssh_config, handelt es sich um die Client-Konfiguration.

Die Konfigurationsdatei sshd_config ist übersichtlich aufgebaut. Es gibt zahlreiche Einstellungsparameter, die bereits auskommentiert mit ihrem Default-Wert hinterlegt sind. Ich empfehle an dieser Stelle folgende Anpassung:

root-Login komplett verbieten:
PermitRootLogin no
SSH-Port auf einen anderen Port im Bereich von 49152 und 65535 (dynamische Ports) legen. Im weiteren Verlauf dieses Artikels verwende ich exemplarisch den Port 54321:
Port 54321
SSH-Agent-Forwarding abschalten:
AllowAgentForwarding no
Banner-Nachricht vor Authentifizierung hinterlegen:
Banner /etc/issue.net

Die Banner-Mitteilung wird vor der Authentifizierung angezeigt. Um internationaler Rechtsprechung zu genügen, wäre hier ein Text ähnlich dem folgenden Beispiel zu empfehlen, der in der Datei /etc/issue.net hinterlegt wird:

===============================================================

                !!!Authorized Access Only!!! 
      This server is under the control of Tobias Heine
         All connections are monitored and recorded!
   Disconnect IMMEDIATELY if you are not an authorized user!

===============================================================

Änderungen in der /etc/ssh/sshd_config werden erst wirksam, nachdem die Konfiguration neu geladen bzw. der Serverdienst neu gestartet wurde:

systemctl restart sshd.service

Darüber hinaus sollte noch eine Firewall installiert/aktiviert werden. Setzen wir an dieser Stelle auf ufw, brauchen wir zu Beginn nur wenige Befehle:

apt install ufw
ufw allow 54321 comment "Allow SSH from everywhere"
ufw enable

Dass die Firewall korrekt konfiguriert ist, sehen wir mit dem Befehl ufw status verbose:

Aktive UFW Firewall die derzeit nur Port 54321 erlaubt

Im weiteren Verlauf, werden wir den Zugriff auf SSH noch weiter einschränken. Für den Anfang kann man auf unserem Server nur den konfigurierten Port für eine SSH-Verbindung verwenden. Möchten wir den Server nach unserer SSH-Konfiguration z. B. als Webserver verwenden, müssen wir für dieses Einsatzszenario noch die TCP-Ports 80 und 443 öffnen.

Im letzten Schritt der Absicherung installieren wir noch fail2ban. Dieses Tool sperrt direkt nach der Installation alle IP-Adressen, die wiederholt Authentifizierungs-Fehler verursachen. Unter Debian 12 installiere ich zusätzlich rsyslog, damit fail2ban gleich problemlos arbeitet.

apt install fail2ban rsyslog

Der Service fail2ban übernimmt sofort seine Arbeit und sperrt alle IP-Adressen für eine definierte Zeit (Default = 1 Stunde) aus, die sich mehr als drei Mal falsch an unserem Server authentifizeren.

Bei Bedarf können wir hier restriktiver konfigurieren oder auch die Login-Versuche für weitere Services überwachen.

Zum Seitenanfang

Verwendung von Public-Key-Auth

Die Verwendung von Passwörtern bei SSH-Verbindungen ist aus folgenden Gründen nicht zu empfehlen:

Passwörter sind entweder unsicher oder so sicher, dass die wiederholte Eingabe zeitraubend und fehleranfällig ist.
Jeder Login-Vorgang benötigt immer ein Passwort. Das geht eleganter.
Wenn auf dem Zielserver mehrere Admins mit Funktions-Accounts arbeiten (z. B. admin), dann muss das Passwort für den SSH-Zugriff im Team geteilt werden. Das führt dazu, dass die Sicherheit weiter aufgegeben wird und dass bei Ausscheiden von Mitarbeitern die Passwörter geändert werden müssen. Das ist nicht praktikabel.

Die Alternative ist, dass statt eines Passworts, jeder user auf dem jeweiligen Arbeitsgerät, ein eigenes SSH-Key-Pärchen für die Authentifizierung erstellt und auf dem SSH-Server die öffentlichen Schlüssel der berechtigen Personen hinterlegt werden.

Für die Erzeugung der Key-Pärchen nutzen wir ssh-keygen auf unserem persönlichen Arbeits-Gerät (PC oder Notebook). Der reine Aufruf des Befehls startet einen Assistenten und erzeugt einen RSA-Key. Wir wollen (sofern vom Server unterstützt) jedoch den etwas moderneren Algorithmus ed25519 verwenden.

Das erreichen wir mit folgendem Kommando:

ssh-keygen -t ed25519

Der Assistent fragt uns nach dem Speicherort und einer Passphrase. Lassen wir den Dateinamen unverändert liegen die beiden erzeugten Dateien (das Keypärchen) unter ~/.ssh/id_ed25519 und ~/.ssh/id_ed25519.pub. Handelt es sich bei meinem Arbeitsgerät um ein Windows-System, sind die beiden Dateien vss. unter C:\Users\<username>\.ssh zu finden.

Hinweis

Bitte an dieser Stelle unbedingt ein solides Passwort bzw. eine Passphrase vergeben.

Der Aufruf der Key-Erzeugung kann noch mit weiteren Optionen erfolgen. Für mich hat sich bewährt, dass ich den Speicherpfad via Option übergebe und das Kommentarfeld anpasse. Der Aufruf sieht dann wie folgt aus:

ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_sshlab -C "<mailadresse>:$(hostname)"

Mit der Option -a 100 wird die Passphrasebestätigung in die länge gezogen. Damit fällt es schwerer das Passwort zu knacken, sollte der Key Mal von meinem Arbeitsgerät gestohlen werden. Mit der Verwendung von -C "<mailadresse>:$(hostname)" wird das übliche Muster <username>@<client-hostname> überschrieben. Das erleichtert im Team die Identifizierung.

Tipp

Aus meiner Sicht ist es ratsam, wenn jede Arbeitsstation (z. B. PC und Notebook) ihr eigenes SSH-Key-Pärchen bereit stellt. Wird das Notebook mit einem der beiden SSH-Keys gestohlen, ist es dadurch einfacher, die betroffenen Keys von den SSH-Servern zu löschen und gleichzeitig mit dem PC sorgenfrei weiter zu arbeiten.

Sobald die Keypärchen erstellt wurden, sind nach dem Aufruf oben unter ~/.ssh/ die folgenden beiden Dateien zu finden:

Erzeugtes SSH-Keypärchen

Die Datei mit der Endung .pub enthält den öffentlichen SSH-Schlüssel (1) sowie den Kommentar (2), den wir bei Erzeugung mit der Option -C übergeben haben:

Inhalt der Datei `~/.ssh/id_ed25519_sshlab.pub`

Diese Datei werden wir im weiteren Verlauf auf den oder die SSH-Server schieben. Die zweite Datei beinhaltet den privaten Schlüssel. Diesen hüten wir wie unseren Augapfel und geben ihn niemals raus. Die Dateizugriffsberechtigungen sind hier mit -rw------- entsprechend gesetzt worden.

Der Public-Key muss nun auf den Ziel-Servern in der Datei ~/.ssh/authorized_keys des Users hinterlegt werden, mit dem wir uns auf dem Zielhost verbinden. Das kann mit dem Befehl ssh-copy-id erfolgen:

ssh-copy-id -i ~/.ssh/id_ed25519_sshlab.pub <username>@<IP-Adresse oder FQDN>

Im Anschluss muss man sich via Passwort authentifizieren und der Key wird in die ~/.ssh/authorized_keys von <username>, auf dem SSH-Server eingetragen. Sobald das erledigt ist, kann mit dem Befehl …

ssh -i ~/.ssh/id_ed25519_sshlab <username>@<ziel>

… die Verbindung aufgebaut werden. Es muss bei jedem Verbindungsaufbau die PASSPHRASE des Keys mit übergeben werden.

Hinweis

Hätten wir den Standard-Pfad bei Ausführung von ssh-keygen unverändert gelassen, wäre das Keypärchen unter den Namen id_ed25519 und id_ed25519.pub erzeugt worden. In diesem Fall brauchen wir bei Verbindungsaufruf die Option -i nicht mit angeben. Es reicht dann ein ssh <username>@<ziel>, da der SSH-Client automatisch diese Default-Schlüssel verwendet.

Im Anschluss ist es sinnvoll den Zugriff zu testen und dann den SSH-Server so zu konfigurieren, dass eine Authentifizierung nur noch über Public-Key-Authentifizierung erlaubt ist. Daher setzen wir auf der Remote-Maschine die entsprechenden Zeilen in der /etc/sshd_config auf …

PasswordAuthentication no

… und starten den SSH-Service neu:

sytemctl restart sshd.service

Sofern man sich nun mit einem Passwort auf unserem SSH-Server anmelden möchte, erfolgt folgende Warnung und der Verbindungsaufbau wird abgebrochen:

<username>@<ziel>: Permission denied (publickey).

Perfekt: Damit kommt man nur noch via Public-Key-Authentifizierung auf unseren SSH-Server.

Zum Seitenanfang

Mehr Komfort mit dem SSH-Agent

Hinweis

Je nach Betriebssystem oder eingesetzer Desktopumgebung unterscheidet sich die Handhabung des SSH-Agents. Die nachfolgenden Zeilen beschreiben die Verwendung auf einer Linux Shell (bash).

Die Verwendung der Public-Key-Authentifizierung erhöht die Sicherheit deutlich. Aber das Handling ist für uns noch etwas schwierig. Grund: Jeder Login erfordert eine Eingabe der oben gesetzten Passphrase.

Das kann auf dem Arbeitsgerät mit der Verwendung von ssh-agent optimiert werden. Den Agent starten wir mit folgendem Aufruf:

eval "$(ssh-agent -s)"

Nun können wir einen oder mehrere Keys in den ssh-agent laden. Das machen wir VOR einem Verbidnungsaufbau mit unseren SSH-Servern:

ssh-add ~/.ssh/id_ed25519_sshlab

Wir werden (1) nach der entsprechenden PASSPHRASE gefragt, die wir eingeben und erhalten im Anschluss die Meldung (2), dass der Key (die Identität) hinzugefügt wurde:

SSH-Key an SSH-Agent übergeben

Wenn wir im späteren Verlauf kontrollieren wollen, welche Keys zum SSH-Agent hinzugefügt wurden, können wir das mit folgendem Befehl kontrollieren:

ssh-add -l

Das war es. Der Verbindungsaufbau erfolgt wie gehabt:

ssh -i ~/.ssh/id_ed25519_sshlab <username>@<ziel>

Im Gegensatz zum Verfahren ohne ssh-agent ist zu beobachten, dass wir nun die Passphrase bei Login nicht mehr übergeben mussten. Das übernimmt der ssh-agent ab jetzt und funktioniert so lange ich mich nicht aus der Sitzung am Arbeitsgerät abmelde. Will ich mich auf 10 Servern verbinden, muss ich meine Identität (meinen Key) nur einemal mit der PASSPHRASE an den ssh-agent übergeben und komme für den Rest der Zeit ohne Passwort auf meine Systeme. Auch Entwickler die ihre Projekte auf einer git-Instanz lagern und via SSH clonen, fetchen, pushen oder pullen, werden diesen Vorteil zu schätzen wissen.

Zum Seitenanfang

Anpassungen am SSH-Client

Der Zugriff auf entfernte Systeme kann noch weiter vereinfacht werden. Hierzu wird die Client-Konfiguration auf dem Arbeitsgerät angepasst. Wie schon oben erwähnt, liegt die dazu notwendige Konfig-Datei unter /etc/ssh/ssh_config (diesmal ohne d) und ist global für alle Benutzerinnen und Benutzer eines Systems gültig.

Zudem gibt es im eigenen Verzeichnis unter ~/.ssh/config die Möglichkeit eine Konfigurationsdatei zu hinterlegen. Diese ist nur für den jeweiligen User gültig und der Ort der Wahl für unseren weiteren Anpassungen.

Tipp

Windows-User erstellen die erwähnte Datei ebenfalls in ihrem Homeverzeichnis:
(z. B. unter C:\Users\<username>\.ssh\config)

In dieser Datei werden pro Host entsprechende Verbindungsparameter hinterlegt. Ein Beispiel für den Zugriff auf zwei verschiedene SSH-Server könnte wie folgt aussehen:

Host yodasvm
  Hostname 192.168.56.101
  User yoda
  Port 54321
  IdentityFile ~/.ssh/id_ed25519_sshlab

Host vadersvm
  Hostname 192.168.56.102
  User vader
  Port 22
  IdentityFile ~/.ssh/id_ed25519_sshlab

Der Verbindungsaufruf ist somit massiv verkürzt. Wollen wir uns mit dem SSH-Server vadersvm verbinden, erfolgt der Aufruf via:

ssh vadersvm

Es können auf diese Weise zahlreiche Zielhosts angegeben und einfach aufgerufen werden. Hier hat es sich übrigens für mich bewährt, dass ich pro Projekt eine eigene Config-Datei vorhalte. Dazu hab ich in meiner ~/.ssh/config die Anweisung Include config.d/* hinterlegt …

SSH-Konfiguration mit Verweis auf weitere Dateien in einem Unterordner

… und dann im angegebenen Ordner config.d die einzelnen Dateien abgespeichert:

SSH-Client-Konfigurationen nach Projekten geteilt

Der Vorteil von diesem Verfahren ist, dass ich dadurch etwas aufgeräumter arbeite und zudem die Dateien bei meinen jeweiligen Kollegen schnell austauschen kann.

Zum Seitenanfang

Fazit/Ausblick

Das ist jetzt ein relativ großer Beitrag geworden (für meine Verhältnisse). Und es wurden so viele Dinge noch nicht angesprochen, die einen weiteren Beitrag verlangen. Im Admin-Alltag nützlich sind z. B. die proxyjump-Verbindungsparamter und eigentlich gehört auch noch erwähnt, dass SSH-Agent-Forwarding eine kritische Funktion ist. Professionelle Umgebungen setzen zudem auf Zertifikate um ein Vertrauen zu einem SSH-Server herzustellen. Darüber hinaus gibt es noch weitere Möglichkeiten, wie man SSH in Arbeitsgruppen optimiert einsetzt.

Aber dieser Artikel sollte ein erster SSH-Grundlagen-Beitrag werden, der einen Überblick über das Protokoll, den sichern Zugriff auf Remote-Hosts und ein paar Tipps für das Handling zu Verfügung stellt. Ich hoffe dass ist mir halbwegs gelungen. Sofern ich hier zwischen den Zeilen irgend einen Quatsch fabriziert habe, freue ich mich über eine Rückmeldung auf den üblichen Kanälen.

Apropos Überblick: Eine schöne Übersicht, welche Dateien bei einer Public-Key-Authentifizierung relevant sind, findet man auf folgender Grafik:

Arbeitsweise SSH (And1mu, CC BY-SA 4.0 , via Wikimedia Commons )

Zum Seitenanfang

Quellen

Blog umgezogen

2025-01-23T19:36:58+01:00

Dieser Blog hier läuft nun seit etwa 18 Monaten. Gleich zu Beginn hatte ich hier dokumentiert, wie ich das mit Hilfe von Codeberg CI und Codeberg Pages umgesetzt habe. Im Prinzip hat das auch super funktioniert und ich war mit dem Setting grundsätzlich zufrieden.

Allerdings sind die Seiten von https://codeberg.org ziemlich unter Last und ich hatte fast täglich kleine Downtimes. Dieser Blog hat wirklich keine besonders große Reichweite und von daher hat mich das bisher wenig gestört. Allerdings war die Seite diese Woche zum zweiten Mal in einer Veranstaltung offline, in der ich als Referent auf Inhalte verweisen wollte.

Aus diesem Grund habe ich beschlossen, den Blog auf einen eigenen Webserver umzuziehen. Falls das hier irgendwann Mal jemand von Codeberg e. V. lesen sollte: Bitte nicht falsch verstehen … Ihr macht einen super Job. Ich bin und bleibe ein großer Codeberg-Fan und werde weiterhin alle meine öffentlichen Git-Repos unter https://codeberg.org/toheine ablegen.

Das Deployment funktioniert ab jetzt wie folgt:

Die Hugo Sourcen liegen auf einer Forgejo -Instanz unter https://git.toheine.net in einem privaten Repo. Das hat den Vorteil, dass ich dort meine eigenen Notizen in den Issues hinterlegen kann, die ich nicht veröffentlichen will (Ideen, Verbesserungen, sonstige Notizen).
Zusätzlich werden von dort die Quelldateien auf https://codeberg.org/toheine/toheine_sources gespiegelt. Jedes einzelne git push-Kommando führt zu einer Synchronisation.
Die Bereitstellung der gebauten Seiten auf meinem Webserver erfolgt in einer leicht veränderten Pipeline (vergleiche Zeile 30 bis 38 in .woodpecker.yml ) nach dem ähnlichen Prinzip wie bisher.

Letztendlich sind Verfahrensweise und die verwendeten Tools die gleichen. Die eigene Forgjo-Instanz (Ein Gitea-Fork der durch Codeberg e. V. entwickelt wird) und Woodpecker CI waren auch im vorherigen Setting im Einsatz. Nur das Ziel ist nun kein Git-Repo-Pages-Branch, sondern ein Webroot-Verzeichnis auf einem herkömmlichen Webserver.

Shell-Session-Recordings mit asciinema via Skript

2025-01-05T11:11:07+01:00

Ich hab mir in der Adventszeit mit meinen Kollegen Gedanken darüber gemacht, wie wir Linux-Befehle für unsere Schülerinnen und Schüler besser zugänglich machen. Die Lebenswelt unserer Lernenden fordert an dieser Stelle häufig … Videos. Das ist aber so überhaupt nicht meine Art der Unterrichtsgestaltung. Ich hab zwar schon das ein oder andere Video erstellt, aber das skaliert nicht im Alltag für dutzende Themen.

Dabei fiel mir ein, dass ich schon vor drei Jahren mit asciinema experimentiert hatte. Allerdings ist das damals für mich eingeschlafen. Nun nahm ich gestern einen neuen Anlauf und hab drei Bash-Sessions aufgenommen. Das ist relativ einfach. Allerdings vertippte ich mich häufig bei der Eingabe und musste die Befehls-Sequenzen wiederholt aufnehmen. Und mit dem Endergebnis war ich immer noch nicht zufrieden.

Das war etwas frustrierend und ich dachte mir … das kann ich doch mit einem kleinen Bash-Skript lösen. Die Umsetzung und das Ergebnis beschreibe ich im folgenden Beitrag.

Ausgangslage

Zu Beginn hab ich die Doku von asciinema , die Issues auf dem entsprechenden Git-Repo und die Suchmaschine meines Vertrauens benutzt um zu schauen, was für Möglichkeiten ich habe und ob nicht doch schon jemand das Problem gelöst hatte. Letzteres war auch so. Aber die Skripte haben entweder nicht so funktioniert wie ich das wollte oder ich kam nicht damit klar.

Wenn die Tools mehr als 20 Zeilen Code hatten, hab ich auch nicht verstanden warum das so sein muss. Ich will ja nur einfaches Skript, das eine Textdatei mit Befehlen ausliest und dann bei der Aufnahme eine User-Eingabe simuliert. Für letzteres gibt es ein kleines Tool pv (Pipe Viewer) mit dem man genau das einfach machen kann. So erzeugt der Aufruf …

echo Hallo Welt | pv -qL 10

… eine solche gewünschte simulierte Eingabe: Die Zeichenkette Hallo Welt wird Zeichen für Zeichen verzögert ausgegeben. Die Geschwindigkeit (-L = Rate Limit) ist auf 10 Zeichen pro Sekunde begrenzt und es werden keine Zeitangaben dargestellt (-q = quiet). Mein Gedanke: Kann also nicht so schwer sein.

Das Skript

Nach einigen Versuchen, kam dann das folgende Skript aus meinen Fingern (Korrigierter Stand vom : 01.03.2026). Dieses liegt auch auf Codeberg unter https://codeberg.org/toheine/autotype_commands :

#!/bin/bash

# January 2025
# Tobias Heine <toheine@posteo.de>
# GPLv3
#
# Usage: 
#   asciinema rec <filename> -c "./autotype_commands.sh <commands-file> [<directory>]"

# Design prompt
PS1='\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '

# Set commands
commands=$(realpath "$1")

# Change directory if $2 is set
if [[ -n "$2" ]]; then
    cd "$2" || exit
fi

while IFS= read -r line; do

    # Collect continuation lines
    display="$line"
    joined="$line"
    while [[ "$line" == *\\ ]]; do
        IFS= read -r next_line
        display="${display}"$'\n> '"${next_line}"
        joined="${joined%\\} ${next_line}"
        line="$next_line"
    done

    # Build prompt
    echo -n "${PS1@P}"

    # Sleep a few secs
    sleep 1

    # Simulate user input (typed with \ and line breaks as written)
    echo "$display" | pv -qL 10

    # Comments are not executed
    if [[ $joined != "#"* ]]; then
        eval "$joined"
    fi

done < "$commands"

Vernachlässigt man die Leerzeilen und die Kommentare sind das knapp 20 Zeilen Code. Dabei werden …

einen Standardprompt simuliert,
die notwendigen Befehle von einer Datei eingelesen ($1)
eine verzögerte Usereingabe simuliert und
bei Bedarf die Ausführung in einem andern Ordner vorgenommen (Optionales $2).

Die Befehle schreibt man in eine Textdatei. Hierzu habe ich im entsprechenden Git-Repo eine demo.txt hinterlegt, die wie folgt aufgebaut ist:

# A simple echo command
echo Hello world
# A simple ls command
ls
# Go to the home directory
cd
# Go back to the old working directory
cd -

Die Idee: Kommentare (Zeilen die mit “#” beginnen), sind die Anweisungen. Die übrigen Zeilen entsprechen den jeweiligen Befehlen.

Damit ist das Skript fertig und es kann mit folgendem Aufruf gestartet werden:

./autotype_commands.sh demo.txt

Soll ein anderes Verzeichnis als Start-Ordner verwendet werden, muss dieses vorher angelegt sein. Evtl. ist es sinnvoll darin dann ein paar Beispieldateien zu hinterlegen:

mkdir ~/workdir
cd ~/workdir
touch file1 file2 file3 
cd -

Im Anschluss erfolgt der Aufruf mit einem weiteren Argument. Beispiel:

./autotype_commands.sh demo.txt ~/workdir

Verwendung mit asciinema

Die Aufnahme erfolgt mit dem Programm asciinema [as-kee-nuh-muh] das aus den Paketquellen installiert werden kann (siehe hierzu: https://docs.asciinema.org/getting-started) . Mit dem folgenden Aufruf wird eine Aufnahme mit rec gestartet, diese in die Datei demo.cast gespeichert und und als Kommando -c mein autotype-Skript übergeben.

asciinema rec demo.cast -c "./autotype_commands.sh demo.txt"

Sofern man wiederholt die gleiche cast-Datei erstellen will (z. B. beim Feintuning der Befehle), wirft asscinema einen Fehler. Dieser kann mit der overwrite-Option vermieden werden:

asciinema rec demo.cast --overwrite -c "./autotype_commands.sh demo.txt"

Wie bereits oben erwähnt … Ausführung von einem anderen Startverzeichnis aus, geht ebenfalls:

asciinema rec demo.cast --overwrite -c "./autotype_commands.sh demo.txt ~/workdir"

Das Ergebnis kann man direkt auf der Konsole anschauen:

asciinema play demo.cast

Bei Bedarf kann diese Aufnahme noch auf den asciinema-Server oder eine eigene Serverinstanz hoch geladen werden. Hierzu empfiehlt es sich die Doku von asciinema zu sichten.

Ergebnis

Der Aufruf oben führt zu folgendem Ergebnis:

Ich bin damit zufrieden. Bash-Screen-Recordings zu erstellen, bedeutet für mich in Zukunft, kleine Textdateien zu verfassen und diese via Skript an asciinema zu übergeben. So ist das für mich jetzt gut handlebar. Nun müssen nur noch meine Lernenden diese Videos auch nutzen und einen Mehrwert daraus ziehen.

Einschränkungen

Mit dem Skript wird ein Pseudo-Prompt generiert. Ursprünglich war das nur zu Testzwecken enthalten. Ich finde das aber eigentlich eine gute Idee, da ich meinen Prompt immer stark anpasse und ich auf diese Weise meine Schülerinnen und Schülern einen Standardprompt biete. Das bedeutet aber auch, dass Recordings von anderen Shells mit meinem Skript fehlerhaft dargestellt werden.

Update vom 01.03.2026

Nach einem Pull-Request von @stoeps ist das Tool nun auch in der Lage, Multi-Line-Befehle mit der Konsole PS2 korrekt darzustellen. Infos dazu sind auf Codeberg im entsprechenden PR zu finden:
https://codeberg.org/toheine/autotype_commands/pulls/1

Quellen

Linux-Distris veröffentlicht

2024-10-24T15:26:51+02:00

Seit heute gibt es auf dieser Seite eine (derzeit noch) kleine Info zu ausgewählten Linux-Distributionen die ich unter dem Menü-Punkt Linux-Distris verortet habe. Dort werden Linux-Distributionen vorgestellt, mit denen ich arbeite UND die ich empfehlen kann. Ich hab mit Debian GNU/Linux, Arch Linux und Linux Mint begonnen. Weitere Distributionen werden folgen.

Die in der Seite erwähnten Aspekte bleiben ziemlich an der Oberfläche und beleuchten kurz die Zielgruppe, Kernaspekte der jeweiligen Distribution, warum ich diese einsetze und wo es weitere Infos gibt. Ich hoffe dadurch ein wenig Licht in den dichten Wald der vielen Distributionen zu bekommen.

Wer das liest, dem muss klar sein, dass ich das durch meine Brille beurteile. Andere Distributionen sind bestimmt auch gut!

Git-Branch im Bash-Prompt anzeigen

2024-09-14T20:39:14+02:00

Meine kleinen Coding-Projekte setze ich meistens, direkt auf der Kommandozeile, mit dem Editor vim um. Ich arbeite eher selten in dem grafischen Editor VSCodium und noch weniger in einer Entwicklungsumgebung (IDE) wie Eclipse, Netbeans oder IntelliJ. Gerade die grafischen Tools integrieren die Versionsverwaltung git sehr gut und man hat als Entwickler jederzeit den Einblick, wie es um die Versionierung steht. Auf der Kommandozeile sehe ich das nur, wenn ich die jeweiligen Befehle wie z. B. git branch oder git log eingebe.

Vor ein paar Wochen ist es dann zum wiederholten Mal passiert: Ich hatte im falschen Branch gearbeitet (genervter Blick).

Mein Gedanke: Das passiert mir nicht nochmal … ich will den jeweiligen Branch im Shell-Prompt sehen, sofern ich in einem git-Repo arbeite. Wie ich das umgesetzt hab, dokumentiere ich im folgenden Beitrag.

Vorab-Gedanken

Mir ist bekannt dass es für meinen Bedarf schon komplett fertige Lösungen gibt. Mit Projekten wie https://ohmyposh.dev (Bash) oder https://ohmyz.sh/ (zsh) bekommt man schöne Prompts vor’s Auge gezaubert, die den jeweiligen Status im Branch anzeigen.

Diese Lösungen kommen für mich jedoch nicht in Frage, weil es entweder zu bunt oder zu überladen ist. Ich will einfach nur meinen Editor auf der Konsole bedienen und mit wenigen Zeilen Code einen kleinen Hinweis erhalten, auf welchem git Branch ich mich gerade befinde. Den Prompt auf meinen Clients hatte ich sowieso schon (in Anlehnung an den Bash-Prompt von Kali-Linux) angepasst. Daher dachte ich mir, diese kleine Optimierung kann nicht so schwer sein. Das Ergebnis soll dann wie folgt aussehen:

Mein Wunsch-Prompt

Grundlage: Die Variable PS1

Die Konfiguration des Standard-Prompts (primary prompt) der bash erfolgt über die Variable PS1 die man entweder systemweit in der /etc/profile hinterlegt oder User-spezifisch im Verzeichnis ~/.bashrc. Da auf einem Multiuser-System, jeder User seinen eigenen Prompt generieren dürfen soll, wähle ich die Option mit der ~/.bashrc.

Bei der Erstellung des Prompts können “special characters” verwendet werden (eben auch Variablen), die je nach Hostname, Username oder aktuellem Verzeichnis den Prompt generieren. Ein Debian-System (und viele andere Distros) hat initial folgenden Prompt:

Standard-Bash-Prompt auf einem Debian-System

Mein Test-Benutzer yoda auf der Maschine debvm befindet sich derzeit im Homeverzeichnis (~). Möchte man die Darstellung nun anpassen, hinterlegt man eine passende Zeichenkette in der Variable PS1. Für Testzwecke kann das direkt auf der Kommandozeile eingegeben werden:

Erster eigener Prompt

Möchte ich den Standard-Prompt nachbilden, können die eben genannten “special characters” (Begriff aus der Man-Page ) genutzt werden. Eine erneute Zuweisung zur Variable PS1 sieht wie folgt aus:

PS1="\u@\h:\w\$ "

Geben wir das auf der Konsole ein, sieht das Ergebnis dem Standardprompt schon recht ähnlich:

Standard-Prompt (etwas farblos)

Bedeutung der Variablen:

Zeichen	Bedeutung
`\u`	Username
`@`	Normales Zeichen, das im Prompt dargestellt wird
`\h`	Hostname
`:`	Normales Zeichen, das im Prompt dargestellt wird
`\w`	Aktuelles Arbeitsverzeichnis
`\$`	Indikator für einen eingeschränkten User, der als Zeichen im Prompt dargestellt wird

Farbiger Prompt

Die farbliche Gestaltung ist darüber hinaus etwas komplizierter. Farben werden mit einer Art Tag (ähnich HTML) eingeleitet. Der korrekte Begriff lautet “Escape-Sequenz”. \[\033 oder \[\e leitet die Zeichenformatierung ein, gefolgt von einer Zeichenkette [<ZAHL>m\]¸ die beispielsweise den Text oder den Hintergrund farbig darstellt.

Das kann ziemlich “frickelig” sein. Soll der komplette Prompt in grün erscheinen, kann das wie folgt umgesetzt werden:

Standard-Prompt in Farbe

Man kann erkennen, dass schon ein einfacher Prompt sehr schnell recht unübersichtlich werden kann. Letztendlich instruiert \[\e[32m\], dass alle nachfolgenden Zeichen in grüner Farbe dargestellt werden. Am Ende der Zeile sorgt die Sequenz \[\e[m\] dafür, dass an dieser Stelle der Farbverlauf endet. Alles danach wird wieder wie gewohnt dargestellt.

Die Zeichenfolge 32m steht dabei für grün. Weitere Farben sind möglich. Ich benötige später gelb (33m), grau (37m) und rot (31m). Nicht weil diese Farben besonders schön sind, sondern weil mir die farbig hinterlegten Bestandteile gut ins Auge fallen.

Eine etwas ausführlichere Erklärung zu den Farbcodes hab ich hier gefunden. Eine entsprechende Man-Page man console_codes gibt es ebenfalls. Wer hier zusätzliche Unterstützung möchte, sucht sich im Netz einen Bash-Prompt-Generator. Die können häufig ebenfalls farbige Prompts generieren.

Mit den genannten Möglichkeiten, hatte meine Variable PS1 bisher folgenden Aufbau:

PS1="\n┌── \[\e[33m\]\A \[\e[m\]- \[\e[37m\]\u@\h\[\e[m\]: \[\e[33m\][ \w ]\[\e[m\]\n└─\$ "

Der Prompt stellt sich wie folgt dar:

Mein bisheriger Prompt

Der Aufbau hat sich aus folgenden Gründen bewährt:

Uhrzeit vorne: Manchmal führe ich ein Skript aus, das längere Zeit läuft. Da schau ich nicht zu und drehe Däumchen. Wenn das Skript fertig ist, sehe ich anhand des neuen Prompts, wie lange das Ding gelaufen ist.
Angabe von Usernamen und Host (wie im Standard-Prompt)
Arbeitsverzeichnis (wie im Standard-Prompt)
Kommando-Eingabe in der zweiten Zeile: Der gesamte Pfad des aktuellen Arbeitsverzeichnisses kann sehr lang sein. Dann brechen die Befehle im Standardprompt hässlich um. Durch die Eingabe meines Kommandos in der zweiten Zeile umgehe ich das. Wie oben beschrieben: Das ist jetzt keine geniale Eigenleistung. Ich hatte das in der Distro Kali-Linux aufgeschnappt und empfand diese Darstellung praktisch.

Branch im Prompt darstellen

Um meinem eigentlichen Ziel näher zu kommen, brauche ich eine Funktion in der Datei ~/.bashrc. Diese soll prüfen ob ich in einem Branch bin:

function check_branch {
    if git status > /dev/null 2>&1; then
        branch="<<< $(printf '\uE0A0') $(git branch --show current) >>>"
    else
        branch=""
    fi
}

Es wird in der Bedingungsprüfung der Befehl git status ausgeführt, jedoch sämtliche Ausgaben nach /dev/null geschoben. Das System registriert dabei jedoch, ob der Return-Wert des letzten Befehls 0 (=wahr) ist oder nicht. Ist das der Fall wird eine Zeichenkette gebaut die ein kleines Symbol \uE0A0 (dieser abzweigende Pfeil) und den aktuellen Branch zurück gibt. Andernfalls ist die Zeichenkette leer.

Bleibt die Frage, wann die Funktion aufgerufen wird? Im Prinzip möchte ich bei jedem Bestätigen mit der Eingabetaste checken, ob ich derzeit in einem git-Repo arbeite. Hierfür gibt es eine Variable PROMPT_COMMAND. Deren Inhalt wird ausgeführt, bevor ein neuer Prompt in der Kommandozeile angezeigt wird. Daher erfolgt der Funktionsaufruf per Zuweisung an diese Variable:

PROMPT_COMMAND="check_branch"

Zuletzt muss noch der Variable PS1 die Prompt-Struktur in leicht abgewandelter Form (mit zusätzlicher Variable $branch) zugewiesen werden:

PS1="\n┌── \[\e[33m\]\A \[\e[m\]- \[\e[37m\]\u@\h\[\e[m\]: \[\e[33m\][ \w ]\[\e[m\] \[\e[31m\]\$branch \[\e[m\]\n└─\$ "

Die drei Bausteine liegen hintereinander in der erwähnten ~/.bashrc. Jedes Mal wenn ich nach einer Eingabe die Enter-Taste drücke, wird die Variable PROMPT_COMMAND ausgelesen und die Funktion check_branch aufgerufen, die mir eine Zeichenkette baut (entsprechender Branch oder leere Zeichenkette). Das Ergebnis sieht dann wie folgt aus:

Mein neuer Prompt mit Hinweis auf aktuellen git Branch

Ich bin mit dem Ergebnis erstmal zufrieden. Klar … es können noch weitere nützliche Infos hinterlegt werden. Aber das reicht mir für’s Erste. Die Variable PROMPT_COMMAND benötige ich noch für ein weiteres Szenario. Das beschreibe ich in einem folgenden Beitrag hier.

Fazit

Ich hatte die Möglichkeit mit einem 32MB großen Fertig-Gericht (https://ohmyposh.dev/ ) oder mit 8 Zeilen Code mein Ziel zu erreichen. Der Zeitaufwand hier, ist eher in den Blog-Beitrag als in die reine Umsetzung geflossen. Hätte ich mich für ohmyposh entschieden, hätte ich wahrscheinlich meine Zeit mit der Auswahl von Themes und deren Anpassung verbraten (siehe: ohmyposh themes ).

Quellen

Screenshots mit Flameshot

2024-07-31T15:11:49+02:00

Es gibt einige Tools, die uns die Arbeit erleichtern. Eine Anwendung, die ich täglich verwende ist Flameshot, um Screenshots zu erstellen und direkt zu bearbeiten. Im Gegensatz zu den üblichen Screenshot-Tools, die von Seiten des Betriebssystems bzw. der jeweiligen Linux-Distribution vorinstalliert sind, bietet Flameshot einen größeren Funktionsumfang und ist ziemlich eingängig zu bedienen. Screenshots für Anleitungen sind so im Handumdrehen erstellt.

Installation

Wie beinahe alle Tools, die ich auf diesem Blog empfehle, ist auch Flameshot eine Open-Source-Anwendung, die für alle gängingen Desktop-Betriebssysteme verfügbar ist (Windows, macOS, Linux). Infos zu den jeweiligen Systemen gibt es unter https://flameshot.org/#download .

Unter Debian installiere ich Flameshot direkt über die Paketverwaltung:

apt install flameshot

Einrichtung

Auf Windows ist Flameshot direkt nach Installation einsatzbereit. Mit der Taste [Druck], kann ein Screenshot erstellt und direkt bearbeitet werden. In einer Linux-Distro wird mit dieser Taste nach wie vor das Screenshot-Tool verwendet, das der jeweilige Distributor zu Verfügung stellt. Daher muss die Tastenbelegung noch angepasst werden. Unter KDE erreiche ich das unter Systemeinstellungen > Kurzbefehle > + Anwendung hinzfügen. Im nachfolgenden Dialog sucht man nach flameshot und bestätigt die Eingabe mit OK.

Anschließend muss noch mindestens der Kurzbefehl für “Bildschirmfoto aufnehmen” gewählt werden. Hier klickt man auf auf das Drop-Downmenü hinter dem genannten Eintrag, wählt "+ Eigenen Kurzbefehl hinzufügen", drückt die gewünschte Taste (in meinem Fall [Druck]) und bestätigt die Auswahl mit “Anwenden”. In meinem Fall ist die [Druck]-Taste schon belegt. Die daraus resultierende Warnung bestätige ich mit “Ja”:

Tastenkombination für "Bildschirmfoto aufnehmen" hinterlegen

Bedienung

Sobald Flameshot über den gesetzten Kurzbefehl aufgerufen wird, verändert sich der Cursor und es erscheint ein Hinweis-Fenster:

Hinweisfenster bei Screenshot-Erstellung

Es können nun die gewünschten Bildschirminhalte ausgewählt werden (Cursor über Bereich ziehen und dabei linke Maustaste festhalten). Im Anschluss erscheint der Bearbeitungsmodus:

Zahlreiche Möglichkeiten den Screenshot zu bearbeiten

Jede der hier abgebildeten lila-farbigen Schaltflächen steht für eine Aktion. So können (1) zahlreiche Formen hinterlegt, (2) Text hinzugefügt oder auch (3) verpixelt werden. Um die Aktion auszuführen, muss die jeweilige Schaltfläche ausgewählt und im Auswahlbereich des Screenshots hinterlegt werden:

Ein bearbeiteter Beispiel-Screenshot

Die Nummerierung erfolgt automatisch. Möchte man, dass die Nummer auf einen bestimmten Breich zeigt (im Beispiel 2 und 3), dann hält man die linke Maustaste nach dem Setzen der jeweiligen Nummer fest und zieht diese in den Bereich auf den gezeigt werden soll.

Sollen die hinterlegten Markierungen im Screenshot in verschiedenen Farben dargestellt werden, so kann mit einem rechten Mausklick einen Farbkreis aufrufen und eine andere Farbe auswählen:

Markierungen im Screenshots können verschiedene Farben haben

Sobald der Screenshot den eigenen Vorstellungen entspricht, kann dieser in die Zwischenablage kopiert oder gespeichert werden. Hierzu einfach die gewünschte Schaltfläche auswählen (Kopie- oder Diskettensymbol).

Im Detail sind noch weitere Bearbeitungsmöglichkeiten enthalten. Hier empfiehlt es sich das Tool in einer ruhigen Minute auf seinen Funktionsumfang hin abzuklopfen und bei Bedarf die Doku zu lesen https://flameshot.org/docs/ . Einen ersten (animierten) Eindruck bietet folgendes gif-File:

https://flameshot.org/img/flameshot-demo.gif

Optimierung

Flameshot kann in einem gewissen Rahmen auf die eigenen Bedürfnisse hin angepasst werden. Mit einem Rechtsklick auf den Starter, erscheinen die dazu notwendigen Einstellungen:

Flameshot Einstellungen öffnen

Hier können das grundsätzliche Design angepasst, Schaltflächen ausgeblendet, Speicherpfade vorgegeben und Shortcuts eingesehen werden. In der Regel lasse ich das unverändert … mit einer Ausnahme: Unter “Filename Editor” passe ich den Default-Name für einen zu speichernden Screenshot wie folgt an:

Default-Dateiname für Screenshot konfigurieren

Tipp: verzögerter Screenshot

In Einzelfällen kann es notwendig sein, den Screenshot mit einer Verzögerung aufzurufen. Diese Funktion benötige ich, sofern ich Kontextmenüs aufnehme möchte, die verschwinden, sobald ich die [Druck]-Taste betätige. Unter Linux erreiche ich das, sofern ich auf der Konsole

flameshot gui -d 5000

eingebe. Ich hab dann fünf Sekunden Zeit, mein Menü so vorzubereiten, dass der Screenshot diesen aufnimmt. Soweit ich das korrekt verstanden habe, funktioniert das auch unter macOS, jedoch nicht unter Windows.

Quellen

Codeberg-CI - pipeline definition not found

2024-07-31T10:47:49+02:00

Heute wollte ich nach langer Zeit meinen Blog hier wieder mit Inhalten füllen. Nach dem git push auf Codeberg, hat Woodpecker einen Fehler beim build gemeldet: “pipeline definition not found”. Das hat mich doch sehr gewundert, da ich weder an der .woodpecker.yml im Codeberg-Repo noch in Woodpecker selbst Änderungen vorgenommen hatte.

Scheinbar bin ich nicht die erste Person, die darüber stolpert (siehe hier ). Letztendlich hat das komplette Löschen des Repos in Woodpecker und das neue Anlegen geholfen.

Update 15.09.2024

Gestern ist der Fehler wieder aufgeschlagen. Ich hab mir nochmals das obige Issue näher angeschaut. Das komplette Löschen des Repos auf der Codeberg-CI wollte ich vermeiden. Und tatsächlich hat das “Repository deaktivieren” und eine anschließendes “aktivieren” ausgereicht. Merke ich mir für die Zukunft.

DNS-01 challenge mit dehydrated und bind9

2024-04-17T00:00:00+00:00

Es gibt viele Wege zu einem gültigen SSL/-TLS-Zertifikat für die eigene Server-Landschaft. In zahlreichen Anleitungen beschrieben ist die Möglichkeit, eine HTTP-01 challenge auf dem jeweiligen Webserver durchzuführen. Dieses Verfahren ist gut und solide. Spätestens wenn Zertifikate für Server benötigt werden, die nicht über das Internet erreichbar sind/sein sollen, scheitert diese Vorgehensweise jedoch. Zudem können Wildcard-Zertifikate nur über die DNS-01 Challenge austgestellt werden.

Diese Anleitung beschreibt eine Einrichtung eines eigenen DNS-Servers mit bind9, der Einrichtung des ACME-Clients dehydrated und dem anschließenden automatischen Erzeugen von Let’s-Encrypt-Zertifikaten via DNS-01 challenge. Diese werden im Anschluss via ansible auf die Zielserver verteilt

Konzept

Let’s Encrypt unterstützt (derzeit aktiv) drei verschiedene Challenge-Arten . Bei der nachfolgend beschriebenen DNS-01 challenge erfolgt der Beweis der Domänen-Inhaberschaft über einen besonderen DNS-Eintrag, der bei der Challenge im DNS-System hinterlegt werden muss. Nur der Eigener der Domän kann dies tun (zumindest sollte das so sein ;-)). Ist der Eintrag erfolgt, prüft Let’s encrpyt (= CA: Certificate Authority), ob der Eintrag an Ort und Stelle ist. Ist das der Fall, wird das Zertifikat ausgestellt.

Das Vorgehen kann mit einem ACME-Client (certbot, dehydrated, etc.) manuell durchgeführt, aber eben auch automatisiert werden. Der Ablauf von der DNS-01 challegene bis zur Verteilung der Zertifikate (wie ich sie hier beschreibe) wird durch folgende Abbildung verdeutlicht:

Mögliche Struktur zur Erzeugung von Let's encrypt-Zertifikaten via DNS-01 challenge

Legende

Im Vorfeld werden Zonen vom DNS-Registrar an eigenen DNS-Server delegiert.

Auf dem DNS-Server ist ein ACME-Client installiert der die DNS-Challegene initiiert.

Let’s Encrypt gibt Token vor, prüft ob dieser im DNS hinterlegt wurde und stellt Zertifikate aus.

Die Zertifikate werden dann an die jeweilgen Stellen via ansible verteilt.

Zum Seitenanfang

Basisinstallation eines Debian-Servers

Hinweis

Bei der Erstellung dieses Beitrags, habe ich die nachfolgenden Codezeilen auf einem Server durchgeführt, der unter der IP-Adresse 128.140.114.17 lief. Dieser wurde nur kurzfristig durch einen Cloud-Provider bereit gestellt. Wer die Anleitung durcharbeitet, muss die Adresse des eigenen DNS-Servers verwenden.

Die Installation wird auf einem Debian-Server (zum Zeitpunkt dieses Beitrags Debian 12) durchgeführt. Nach der Basisinstallation sollte eine Minimalabsicherung erfolgen:

SSH aktivieren
[evtl. einen alternativen Port für SSH verwenden]
Public-Key-Auth einrichten
fail2ban installieren, so dass fehlerhafte Logins zu einem BAN führen
Firewall installieren und nur Port für SSH und Port 53 freigeben.

Könnte in der Kürze wie folgt aussehen:

SSH-Key von meinem Client hochladen:

ssh-copy-id -i ~/.ssh/<mein-ssh-key>.pub <user>@<server>

Auf dem Server ufw und fail2ban installieren, SSH-Port umziehen (Mach ich so, müsst Ihr nicht) und passende UFW-Regeln erstellen:

apt update
apt install ufw fail2ban
sed -i 's/#Port 22/Port 42042/' /etc/ssh/sshd_config
systemctl restart sshd.service
ufw allow 42042
ufw allow 53
ufw enable

Aufgepasst

Vorsicht bei der Port-Änderung von SSH und der anschließenden Einrichtung der Firewall. Man kann sich ganz schön aussperren, wenn man hier nur abtippt.

Bei Debian 12 muss bzgl. fail2ban noch an einer Stelle nachgearbeitet werden. Nach der Installation läuft der Service nicht korrekt. Die Anpassung erfolgt in der /etc/fail2ban/jail.conf. Ich löse das Problem in dem ich die Zeile backend = %(sshd_backend)s durch backend = systemd tausche und dann fail2ban neu starte:

apt install python3-systemd
sed -i 's/backend = %(sshd_backend)s/backend = systemd/' /etc/fail2ban/jail.conf
systemctl restart fail2ban

Siehe hierzu auch: https://github.com/fail2ban/fail2ban/issues/3292

Zum Seitenanfang

Installation und Einrichtung von bind9

Nun beginnt die eigentliche Einrichtung und wir beginnen mit der Installation eines DNS-Servers.

apt install bind9 bind9-dnsutils

Konfiguration des DNS-Servers

Die Konfigurationsdateien liegen unter /etc/bind/. Die Hauptkonfiugrationsdatei /etc/bind/named.conf lassen wir in Ruhe. Diese Datei beinhaltet nur die Includes auf die anderen Dateien die uns wichtig sind.

Die eigentliche Konfiguration (außerhalb der Zonendefinitionen) erfolgt in der /etc/bind/named.conf.options. Im Beispiel hier habe ich folgende Konfiguration hinzugefügt:

options {
        directory "/var/cache/bind";
        listen-on port 53 { any; };
        allow-query { any; };
        allow-transfer {"none";};
        allow-recursion {"none";};
        recursion no;
        rate-limit {
            responses-per-second 5;
            window 5;
        };
        // Weiterer Inhalt gekürzt

Damit darf weltweit jedes Gerät diesen DNS-Server verwenden. Allerdings ist eine rekursive Anfrage nicht erlaubt. Somit kann der DNS-Server nur für die eigenen (delegierten) Domains verwendet werden. Zusätzlich sorgt das rate-limit dafür, dass der Server nur eine gewisse Anzahl an DNS-Anfragen pro Zeiteinheit zulässt. Somit wird ein Missbrauch vermieden wie z. B. hier beschrieben: BSI-Hinweise zu offenen DNS-Resolvern .

Zonen definieren

In der /etc/bind/named.conf.local werden die einzelnen Zonen definiert:

include "/etc/bind/nsupdate.key";

zone "lab.toheine.net" IN {
  type master;
  allow-update { key "nsupdate-key"; };
  file "db.lab.toheine.net";
  notify yes;
};

zone "_acme-challenge.toheine.net" IN {
  type master;
  allow-update { key "nsupdate-key"; };
  file "db._acme-challenge.toheine.net";
  notify yes;
};

Im Beispiel wurden zwei Zonen definiert. Die erste Zone ist für die Subdomain lab.toheine.net komplett zuständig. Diese Form verwende ich, wenn ich neben der DNS-01 challenge auch weitere Records erstellen will. Die zweite Zone _acme-challenge.toheine.net wird später ausschließlich für die Zertifikats-Erstellung verwendet. Alle anderen Records die unter der toheine.net Domain laufen, werden direkt bei meinem Registrar eingegeben.

Innerhalb der Zone verraten die Zuweisungen für file, wo die einzelnen Records tatsächlich liegen und allow-update ermöglicht das dynamische Eintragen von Resource Records, sofern der korrekte Key verwendet wird. Über dieses Verfahren trägt der ACME-Client ein Token als TXT-Record ein. Den Key brauchen wir erst später … aber weil wir gerade dabei sind, erzeugen wir diesen gleich und verpassen der Datei die minimalen Rechte:

tsig-keygen -a sha512 nsupdate-key > /etc/bind/nsupdate.key
chmod 600 /etc/bind/nsupdate.key
chown bind: /etc/bind/nsupdate.key

Zoneneinträge erzeugen/vorbereiten

Wenn wir bind9 konfiguriert haben, werden die einzelnen Zonen-Dateien unter /var/cache/bind/ erwartet. Für jede Zone erstellen wir eine eigene Datei, die wir im Anschluss mit Inhalten füllen:

Die Zonendatei /var/cache/bind/db.lab.toheine.net hat nachfolgenden exemplarischen Aufbau:

$TTL 300	  ; 5 minutes 

@   IN SOA	dns.lab.toheine.net. mail.toheine.net. (
       2024041701 ; serial
       86400      ; refresh (1 day)
       7200       ; retry (2 hours)
       604800     ; expire (1 week)
       172800     ; minimum (2 days)
)

@      NS    dns             
dns    A     128.140.114.17  ; produktive IP meines DNS-Servers
www    A     192.0.2.1       ; Test-Net-IP
test   CNAME www             ; Alias auf www
cloud  CNAME www             ; Alias auf www

Das Kommentar-Zeichen der Zonendatei ist das Semikolon. Gerade wenn man neu in der DNS-Welt unterwegs ist, hilft das für die Zuordnung der vielen Werte oder DNS-Typen. Wichtig ist der SOA-Eintrag (Start of Authority), der einige Parameter enthält, die für die Eröffnung der Zone notwendig sind. Der Aufbau der Datei ist auf Wikipedia gut erklärt.

Die weiteren Einträge dienen erstmal nur dazu, um später zu sehen, ob der DNS-Server tatsächlich die Anfragen korrekt auflöst. Hier können beliebige, gültige Einträge vorgenommen werden. Analog dazu erstelle ich eine leere Zonen-Datei unter /var/cache/bind/db._acme-challenge.toheine.net die allerdings neben dem SOA- und NS-Eintrag keine weiteren Records enthält:

$TTL 300	; 5 minutes
@  IN   SOA dns.lab.toheine.net. mail.toheine.net. (
       2024041701 ; serial
       86400      ; refresh (1 day)
       7200       ; retry (2 hours)
       604800     ; expire (1 week)
       172800     ; minimum (2 days)
)
@      NS   dns.lab.toheine.net.

Nun sind wir fertig und wir können bind9 neu starten, damit die geänderten Konfigurationen neu eingelesen werden. Vorab ist es allerdings absolut empfehlenswert, die Konfiguration mit folgendem Befehl zu überprüfen:

named-checkconf -z

Die Ausgabe sollte wie folgt aussehen:

zone lab.toheine.net/IN: loaded serial 2024041701
zone _acme-challenge.toheine.net/IN: loaded serial 2024041701
zone localhost/IN: loaded serial 2
zone 127.in-addr.arpa/IN: loaded serial 1
zone 0.in-addr.arpa/IN: loaded serial 1
zone 255.in-addr.arpa/IN: loaded serial 1

Wenn hier Fehler enthalten sind, müssen diese vor einem Nameserver-Neustart bereinigt werden. Ansonsten wird bind9 nicht starten. Ist alles korrekt, kann der named-service neu gestartet werden:

systemctl restart named.service

Damit ist die DNS-Konfiguration fertig. Um von einem lokalen Client zu testen, ob der DNS-Server seine Arbeit korrekt erledigt, können wir mit dem Kommando dig @128.140.114.17 test.lab.toheine.net einen DNS-Lookup durchführen. Wichtig ist zum jetzigen Zeitpunkt, dass wir den DNS-Server (hinter dem @-Zeichen) angeben. Die Ausgabe sollte wie folgt aussehen:

; <<>> DiG 9.18.24-1-Debian <<>> @128.140.114.17 test.lab.toheine.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45885
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: def4386d4f9e1e0f010000006620039ac691052a8e61c70f (good)
;; QUESTION SECTION:
;test.lab.toheine.net.		IN	A

;; ANSWER SECTION:
test.lab.toheine.net.	300	IN	CNAME	www.lab.toheine.net.
www.lab.toheine.net.	300	IN	A	192.0.2.1

;; Query time: 4 msec
;; SERVER: 128.140.114.17#53(128.140.114.17) (UDP)
;; WHEN: Wed Apr 17 19:15:06 CEST 2024
;; MSG SIZE  rcvd: 111

Bei DNS-Registrar die Zonen-Delegation eintragen

Im letzten Schritt der DNS-Konfiguration, müssen wir bei unserem DNS-Registrar noch die Zonen-Delegation hinterlegen. Hier sind die Einträge je nach Anbieter recht ähnlich und kann wie folgt aussehen:

Einträge beim DNS-Registrar

Legende

IPv4- und IPv6- Eintrag, um den eingerichteten DNS-Server mit Namen aufzulösen

Zonen-Delegation ausschließlich für die DNS-01 challenge.

Zonen-Delegation für eine komplette Suddomain (DNS-01 challengenge und sonstige Records)

Zum Seitenanfang

Dynamisches Eintragen von DNS-Records via nsupdate

Sobald man eigene Konfigurations-Dateien auf einem eigenen Server hat, kann man grundsätzlich mit Hilfe von Skripten (bash-Skripte, python, etc.) die Dateien anpassen. Für das dynamische Einspielen von DNS-Records sind aber solche Skripte nicht wirklich geeignet, da u. a. der DNS-Server nach einem Resource-Eintrag seine Konfiguration jedes Mal neu laden müsste.

Für dynamische DNS-Updates ist das Tool nsupdate vorgesehen, das wir im Rahmen von bind9-dnsutils oben installiert haben. Unser ACME-Client soll später über dieses Tool die DNS-Einträge vornehmen. Sofern man nsupdate ohne Angabe von Optionen oder Argumenten aufruft, befindet man sich in einem interaktiven nsupdate-Modus von wo aus verschiedene nsupdate-Befehle übergeben werden können. Mit help sieht man die Möglichkeiten vor Ort und mit quit beendet man den interaktiven Modus wieder.

Sehr komfortabel ist die Verwendung einer Textdatei um die Funktion von nsupdate zu prüfen. Diese enthält die Befehlsfolge, die wir bei Aufruf von nsupdate übergeben. Im Beispiel schreibe ich folgenden Inhalt in eine ~/nsupdate.txt-Datei:

server 127.0.0.1
zone lab.lfb-linux.de
update add botschaft.lfb-linux.de. 300 in TXT "HeyYoda"
show
send

Sinn und Zweck ist das Testen des dynamischen Eintrags. Später brauchen wir die Datei nicht mehr. Das übernimmt dann der ACME-Client. Daher ist der RRecord (Resource Record) im Beispiel eben, mit HeyYoda relativ sinnfrei. Wenn wir den Eintrag vornehmen wollen, rufen wir nsupdate mit folgendem Befehl auf:

nsupdate -k /etc/bind/nsupdate.key -v nsupdate.txt

Es erfolgt folgende Ausgabe:

Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; ZONE SECTION:
;lab.toheine.net.		IN	SOA

;; UPDATE SECTION:
botschaft.lab.toheine.net. 300	IN	TXT	"HeyYoda"

Um zu prüfen, ob der dynamische Eintrag funktioniert hat, führen wir auf dem Client ein DNS-Lookup durch:

dig -t TXT botschaft.lab.toheine.net

Die Ausgabe sollte dann (gekürzt wie folgt aussehen):

;; ANSWER SECTION:
botschaft.lab.toheine.net. 300	IN	TXT	"HeyYoda"

;; AUTHORITY SECTION:
lab.toheine.net.	300	IN	NS	dns.lab.toheine.net.

;; ADDITIONAL SECTION:
dns.lab.toheine.net.	300	IN	A	128.140.114.17

Zum Seitenanfang

Einrichtung von dehydrated

Hinweis

Die Installation von dehydrated auf dem DNS-Server kann man diskutieren. Die DNS-01 Challenge und damit verbundenen dynamischen Updates können auch von jedem anderen Host aus angestoßen werden, sofern dieser über den oben erzeugten nsupdate-key verfügt.

Nun kommen wir zur Einrichtung von dehydrated, das wir via apt install dehydrated installieren. Die Konfiguration erfolgt im Verzeichnis /etc/dehydrated. Eine gute Doku mit Beispielen findet sich bei Debian unter /usr/share/doc/dehydrated/.

Die Hauptkonfigurationsdatei ist die /etc/dehydrated/config, die folgenden Aufbau besitzt:

CONFIG_D=/etc/dehydrated/conf.d
BASEDIR=/etc/dehydrated
DOMAINS_TXT="${BASEDIR}/domains.txt"
CERTDIR="${BASEDIR}/certs"
CHALLENGETYPE="dns-01"
CA="https://acme-staging-v02.api.letsencrypt.org/directory"
#CA="letsencrypt"
HOOK="${BASEDIR}/hook.sh"
AUTO_CLEANUP="yes"
CONTACT_EMAIL=mail@toheine.net

Vieles erklärt sich von selbst. Bei Ersteinrichtung von dehydrated, nehme ich vorab die Staging-CA, die verhindert, dass ich bei Konfigurationsfehlern gegen das Rate Limit von Let’s encrypt laufe (siehe dazu: staging-environment ). Produktiv verwendet wird später die korrekte CA (CA="letsencrypt").

Die einzelnen Domains, für die ein Zertifikat ausgestellt werden sollen, liegen in einer eigenen Datei unter /etc/dehydrated/domains.txt:

lab.toheine.net *.lab.toheine.net > lab.toheine.net
toheine.net                       > toheine.net

Jede Domain, die hier pro Zeile eingetragen wird, enthält ein eigenes Zertifikat. Möchte man ein Zertifikat für mehrere Domains haben, werden diese Leerzeichen-getrennt in eine Zeile geschrieben. Hinter dem >-Zeichen ist dann der für dehydrated hinterlegte Alias eingetragen. Unter diesem Namen werden die Zertifikate dann unter /etc/dehydrated/certs abgelegt.

Im Anschluss brauchen wir das Hook-Skript, das während der Challenge aufgerufen wird und den dynamischen Eintrag erzeugt. Darin enthalten:

#!/usr/bin/env bash

#
# Example how to deploy a DNS challenge using nsupdate
# https://github.com/dehydrated-io/dehydrated/wiki/example-dns-01-nsupdate-script
#

set -e
set -u
set -o pipefail

NSUPDATE="nsupdate -k /etc/dehydrated/nsupdate.key"
DNSSERVER="127.0.0.1"
TTL=300

case "$1" in
    "deploy_challenge")
        printf "server %s\nupdate add _acme-challenge.%s. %d in TXT \"%s\"\nsend\n" "${DNSSERVER}" "${2}" "${TTL}" "${4}" | $NSUPDATE
        ;;
    "clean_challenge")
        printf "server %s\nupdate delete _acme-challenge.%s. %d in TXT \"%s\"\nsend\n" "${DNSSERVER}" "${2}" "${TTL}" "${4}" | $NSUPDATE
        ;;
    "deploy_cert")
        # optional:
        # /path/to/deploy_cert.sh "$@"
        ;;
    "unchanged_cert")
        # do nothing for now
        ;;
    "startup_hook")
        # do nothing for now
        ;;
    "exit_hook")
        # do nothing for now
        ;;
esac

exit 0

Dieses Skript muss zur Ausführung berechtigt sein chmod +x hook.sh. Zuletzt kopieren wir noch den nsupdate.key an Ort und Stelle:

cp ../bind/nsupdate.key .

Im Anschluss an die Einrichtung von dehydrated, muss man sich (pro CA) einmal regisitrieren …

dehydrated --register --accept-terms

… und kann im Anschluss dehydrated manuell ausführen:

dehydrated -c

Hat alles geklappt sollte die Ausgabe wie folgt aussehen:

# INFO: Using main config file /etc/dehydrated/config
 + Creating chain cache directory /etc/dehydrated/chains
Processing lab.toheine.net with alternative names: *.lab.toheine.net 
 + Creating new directory /etc/dehydrated/certs/lab.toheine.net ...
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting new certificate order from CA...
 + Received 2 authorizations URLs from the CA
 + Handling authorization for lab.toheine.net
 + Handling authorization for lab.toheine.net
 + 2 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for lab.toheine.net authorization...
 + Challenge is valid!
 + Responding to challenge for lab.toheine.net authorization...
 + Challenge is valid!
 + Cleaning challenge tokens...
 + Requesting certificate...
 + Order is processing...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Done!
Processing toheine.net
 + Creating new directory /etc/dehydrated/certs/toheine.net ...
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting new certificate order from CA...
 + Received 1 authorizations URLs from the CA
 + Handling authorization for toheine.net
 + 1 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for toheine.net authorization...
 + Challenge is valid!
 + Cleaning challenge tokens...
 + Requesting certificate...
 + Order is processing...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Done!
 + Running automatic cleanup

Die notwendigen Zertifikate liegen nun in unter /etc/dehydrated/certs.

Hinweis

Haben wir mit der Staging-CA begonnen, muss in der /etc/dehydrated/config noch die korrekte CA hinterlegt werden und wir müssen uns für diese ebenfalls einmalig mit dehydrated --register --accept-terms regisitrieren.

Damit die Zertifikate in regelmäßigen Abständen neu gezogen werden, richten wir cron mit dem Aufruf crontab -e ein und hinterlegen folgende Zeile:

25 10 * * 1 /usr/bin/dehydrated -c >> /var/log/dehydrated.log 2>&1

Die Challenge wird nun 1x pro Woche initiiert. Sofern sich das Zertifikat dem Verfallsdatum nährt, wird ein neues ausgestellt. Ob ich das loggen muss, mir eine Mail zu sende oder die Ausgabe nach /dev/null schiebe, ist Geschmackssache.

Zum Seitenanfang

Verteilung der Zertifikate auf die Server via ansible

Nun werden die notwendigen Zertifikate automatisch und regelmäßig erstellt. Die Verteilung läuft via ansible. Klar … auch das kann man automatisieren. Dieses letzte Stück manuelle Ausführung behalte ich mir jedoch vor, da ich dann auch wirklich weiß, das die Zertifikate an Ort und Stelle sind und die notwendigen Dienste diese auch tatsächlich geladen haben.

Ich stelle hier nur kurz die entsprechende Rolle und ein exemplarisches Playbook vor. Wer mit ansible arbeitet, wird vorab einen ansible-Host einrichten, von wo aus die Playbooks auf die zu orchestrierenden Server losgelassen werden: ansible installieren, ansible.cfg anlegen, gewisse Ordnerstruktur erstellen. Einfache Beispiele dazu sind hier zu finden: https://codeberg.org/toheine/linadv_infra .

Wir benötigen auf dem ansible-host eine eigene Rolle update-certs. Diese liegt unter {{ roles_path }}/update-certs/tasks/main.yml und hat in meinem Fall folgenden Aufbau:

---
- name: Copy fullchain.pem to local
  ansible.builtin.fetch:
    src: /etc/dehydrated/certs/{{ certname }}/fullchain.pem
    dest: /tmp/{{ certname }}/fullchain.pem
    flat: yes
    mode: 0644
  run_once: true
  delegate_to: "{{ acmehost }}"

- name: Copy privkey.pem to local
  ansible.builtin.fetch:
    src: /etc/dehydrated/certs/{{ certname }}/privkey.pem
    dest: /tmp/{{ certname }}/privkey.pem
    flat: yes
    mode: 0640
  run_once: true
  delegate_to: "{{ acmehost }}"

- name: Create /etc/ssl/{{ certname }} directory
  ansible.builtin.file:
      path: /etc/ssl/{{ certname }}
      state: directory
      recurse: yes

- name: Copy {{ certname }}-wildcard-certificates
  ansible.builtin.copy:
      src: /tmp/{{ certname }}/fullchain.pem
      dest: /etc/ssl/{{ certname }}/fullchain.pem
      mode: 0644
  register: crt

- name: Copy {{ certname }}-wildcard-key
  ansible.builtin.copy:
      src: /tmp/{{ certname }}/privkey.pem
      dest: /etc/ssl/{{ certname }}/privkey.pem
      mode: 0600

- name: check if restart-services.sh exists
  ansible.builtin.stat:
      path: /usr/local/sbin/restart-services.sh
  register: resfile

- name: restart services
  command: /usr/local/sbin/restart-services.sh
  when: resfile.stat.exists and crt.changed

Der letzte Task aus der Rolle, führt ein Bashskript auf dem Zielsystem aus, das alle Services neu startet, die das Zertifikat verwenden. Das kann exemplarisch wie folgt aussehen:

#!/bin/bash
systemctl restart nginx.service

Pro Zielsystem muss die entsprechende Datei einmalig unter /usr/local/sbin/restart-services.sh` abgelegt werden.

Zu der Rolle gibt es pro Zertifikat ein eigenes Playbook, das dann

die Gruppe der Ziel-Hosts,
den Zeritifkats-Namen (alias der dehydrated-domains.txt),
den Namen des acme-hosts auf dem die Zertifikate ausgestellt werden
und den Rollenaufruf enthält.

Am Beispiel von lab.toheine.net sieht das playbook update-certs-lab-toheine.yml wie folgt aus:

- name: update SSL/TLS certs 
  hosts: certs_lab_toheine
  become: yes
  vars:
    certname: lab.toheine.net
    acmehost: heidns
  roles:
     - update-certs

Das dazugehörige Inventory enthält eine Zuordnung zu einer Gruppe certs_lab_toheine, der ein oder mehrere Hosts zugeordnet werden. In meinem Fall sind das zwei Host mit dem Namen web01 und web02. Ist alles an Ort und Stelle, kann das Playbook via ansible-playbook update-certs-toheine-net.yml ausgeführt werden. In meinem Fall erfolgt folgende Ausgabe:

PLAY [update SSL/TLS certs] *******************************************************

TASK [Gathering Facts] ************************************************************
ok: [web02]
ok: [web01]

TASK [update-certs : Copy fullchain.pem to local] *********************************
ok: [web01 -> heidns(128.140.114.17)]

TASK [update-certs : Copy privkey.pem to local] ***********************************
ok: [web01 -> heidns(128.140.114.17)]

TASK [update-certs : Create /etc/ssl/lab.toheine.net directory] *******************
changed: [web02]
changed: [web01]

TASK [update-certs : Copy lab.toheine.net-wildcard-certificates] ******************
changed: [web02]
changed: [web01]

TASK [update-certs : Copy lab.toheine.net-wildcard-key] ***************************
changed: [web02]
changed: [web01]

TASK [update-certs : check if restart-services.sh exists] *************************
ok: [web01]
ok: [web02]

TASK [update-certs : restart services] ********************************************
skipping: [web01]
skipping: [web02]

PLAY RECAP ************************************************************************
web01                      : ok=7    changed=3    unreachable=0    failed=0    skipped=1
web02                      : ok=5    changed=3    unreachable=0    failed=0    skipped=1

Damit sind die SSL-Zertifikate an eingestellten Ort und Stelle. Der jeweilige Service (Apache, nginx, Postifx, etc.) muss in der Folge eben noch dieses Zertifikat nutzen.

Fazit

Dieses Setting umzusetzen, ist nicht in fünf Minuten erledigt. Darüber hinaus gibt es zahlreiche andere Wege zu einem gültigen Zertifikat. Wer allerdings sowieso einen DNS-Server betreibt und eine große Farm an vielen Servern vorhält, kann über die DNS-01 Challenge saubere (Wildcard-)-Zertifikate für alle Services ausstellen.

Zum Seitenanfang

Quellen

Zum Seitenanfang

ASN Lookup Tool

2024-01-31T00:00:00+00:00

Die IANA vergibt in Europa IP-Adressen über die Regional Internet Registry RIPE NCC . Die öffentlichen IPv4-Adressen bzw. Global-Unicast-IPv6-Adressen werden Organisationen zugeordnet, die eine “Autonomous System Number (ASN)” besitzen. Um die IP-Adressen und Peeringpartner eines AS abzurufen, bietet sich das Tool asn an.

Installation

Bei dem Tool asn handelt es sich um ein Bash-Skript. Es ist unter https://github.com/nitefood/asn zu bekommen. Auf (m)einem Debian werden die notwendigen Pakete installiert, das Tool herunter geladen und zur Ausführung vorbereitet:

sudo apt install curl whois bind9-host mtr-tiny jq ipcalc grepcidr nmap ncat aha
wget https://raw.githubusercontent.com/nitefood/asn/master/asn
chmod u+x asn

Aufruf

Möchte ich ASN-Informationen zu einer IP-Adresse, wird das Skript mit der Adresse als Argument aufgerufen …

./asn 129.143.76.1

… und ich erhalte folgende Ausgabe (Auszug):

Bildschirmforto: asn Informationen zur IP-Adresse 129.143.76.1

Die IP-Adresse gehört zur ASN 553 (Belwue). Daneben erhalten wir traceroute-Informationen und können der Spur folgen, welche AS wir auf dem Weg zu unserem Ziel passieren:

Bildschirmforto: Auszug asn Informationen zu AS Pfad

Interessant ist ein Lookup des kompletten AS. Sofern das Tool mit einer ASN als Argument aufgerufen wird, die zu der eben verwendeten IP-Adresse gehört, …

./asn 553

… können alle dazugehörigen IPv4-/IPv6-Adressbereiche und Peeringpartner eingesehen werden.Der Abruf dauert je nach ASN etwas länger. Die Gegenüberstellung der Treffer für IPv4 zu IPv6 sieht bei Belwue auszugsweise wie folgt aus:

Bildschirmforto: Auszug asn Informationen zu ASN 553.

Schön zu erkennen ist das Verhältnis der zahlreichen IPv4-Netzbereiche zu den IPv6-Netzbereichen (hier 42:3). Der oft genannte Vorteil, dass IPv6-Routing-Tabellen deutlich kleiner ausfallen, kann hiermit examplarisch nachvollzogen werden. Je nach AS fällt der Unterschied noch deutlicher ins Gewicht: Bei einem asn Lookup mit Netcup war das Verhältnis etwa 3000:4.

Die Idee dieses Tool zu verwenden, ist nicht auf meinem Mist gewachsen. Ich hab das aus einem Linux-Magazin-Artikel , in dem @charlykuehnast “Aus dem Alltag eines Sysadmin” das Werkzeug beschreibt.

Quellen

Multi-Boot USB-Stick mit Ventoy

2023-11-24T00:00:00+00:00

Für den Betrieb des Server-Parks werden allerlei verschiedene Betriebssysteme bzw. Linux-Distributionen benötigt. Sei es zur Installation eines neuen Systems, zur Analyse, zur Fehlerbehebung oder einfach nur für Testzwecke. Die dazu benötigten Installationsdateien liegen normalerweise in so genannten iso-Abbildern vor. Diese wurden früher auf CDs/DVDs gebrannt, während heutzutage eher bootbare USB-Sticks verwendet werden.

Das Problem: Sofern man den Anweisungen der jeweiligen Dokus folgt, installiert man mit Tools wie DiskDump oder einer grafischen Lösung die Installationsdateien EINES Systems auf EINEN USB-Stick.

Viel praktischer ist jedoch die Nutzung eines Multi-Boot-USB-Sticks um auf diesem möglichst viele Betriebssysteme/Distributionen zu hinterlegen. Bei Bedarf wählt man aus einem Bootmenü das gewünschte System aus, das gestartet werden soll. Eine sehr charmante Lösung hierfür ist das Tool Ventoy . Die Vorbereitung eines USB-Sticks mit Ventoy ist schnell erledigt und erleichtert den Admin-Alltag.

Installation

Um den Multi-USB-Stick zu erzeugen, müssen wir …

die Ventoy-Software auf einem PC/Notebook (irgend ein verfügbares Arbeitsgerät) installieren.
mit Ventoy einmalig einen USB-Stick vorbereiten (Ich würde einen Stick >= 32GB empfehlen).
mindestens ein iso-File im Anschluss auf den Stick schieben (und bei Bedarf nach und nach mehr ;-))

Ventoy wird für Windows und Linux bereit gestellt. Die Software kann über die Webseite, Github oder Sourceforge herunter geladen werden. Die Installation auf meinem Debian-Notebook ist mit zwei Befehlen erledigt:

$ wget https://github.com/ventoy/Ventoy/releases/download/v1.0.96/ventoy-1.0.96-linux.tar.gz
$ tar -xzvf ventoy-1.0.96-linux.tar.gz 
$ cd ventoy-1.0.96/

Im eben entpackten Verzeichnis liegen verschiedene Skripte bereit:

$ ls
boot                    README           VentoyGUI.aarch64   VentoyVlnk.sh
CreatePersistentImg.sh  tool             VentoyGUI.i386      VentoyWeb.sh
ExtendPersistentImg.sh  ventoy           VentoyGUI.mips64el  WebUI
log.txt                 Ventoy2Disk.ini  VentoyGUI.x86_64
plugin                  Ventoy2Disk.sh   VentoyPlugson.sh

Sofern wir das Tool konsolenbasiert nutzen wollen, ist Ventoy2Disk.sh das Skript der Wahl. Mit folgendem Aufruf sehen wir die vorhandenen Möglichkeiten:

$ ./Ventoy2Disk.sh --help

**********************************************
      Ventoy: 1.0.96  x86_64
      longpanda admin@ventoy.net
      https://www.ventoy.net
**********************************************

Usage:  Ventoy2Disk.sh CMD [ OPTION ] /dev/sdX
  CMD:
   -i  install Ventoy to sdX (fails if disk already installed with Ventoy)
   -I  force install Ventoy to sdX (no matter if installed or not)
   -u  update Ventoy in sdX
   -l  list Ventoy information in sdX

  OPTION: (optional)
   -r SIZE_MB  preserve some space at the bottom of the disk (only for install)
   -s/-S       enable/disable secure boot support (default is enabled)
   -g          use GPT partition style, default is MBR (only for install)
   -L          Label of the 1st exfat partition (default is Ventoy)
   -n          try non-destructive installation (only for install)

USB-Stick einrichten

Mit der eben angezeigten Ausgabe kann man eigentlich schon arbeiten. Für uns relevant wäre bei der Erstinstallation ./Ventoy2Disk.sh -i /dev/sdX. Die entsprechende Gerätedatei können wir mit Programm lsblk identifizieren:

$ lsblk
NAME                    MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
sda                       8:0    1    0B  0 disk  
sdb                       8:16   1 57,3G  0 disk  
└─sdb1                    8:17   1 57,3G  0 part  
[...]

In diesem Fall also /dev/sdb. Achtung: Das System sollte im Folgenden nicht gemountet sein. Der Aufruf erfolgt mit Super-User-Rechten:

$ sudo ./Ventoy2Disk.sh -i /dev/sdb

**********************************************
      Ventoy: 1.0.96  x86_64
      longpanda admin@ventoy.net
      https://www.ventoy.net
**********************************************

Disk : /dev/sdb
Model:  USB  SanDisk 3.2Gen1 (scsi)
Size : 57 GB
Style: MBR


Attention:
You will install Ventoy to /dev/sdb.
All the data on the disk /dev/sdb will be lost!!!

Continue? (y/n) 

All the data on the disk /dev/sdb will be lost!!!
Double-check. Continue? (y/n)

Wir können nochmal kontrollieren, ob es sich wirklich um unseren USB-Stick handelt und mit 2x y fahren wir fort. Ventoy erstellt nun eigenständig zwei Partitionen, kopiert die notwendigen Daten an Ort und Stelle und schließt die Installation ab:

Create partitions on /dev/sdb by parted in MBR style ...
Done
Wait for partitions ...
partition exist OK
create efi fat fs /dev/sdb2 ...
mkfs.fat 4.2 (2021-01-31)
success
Wait for partitions ...
/dev/sdb1 exist OK
/dev/sdb2 exist OK
partition exist OK
Format partition 1 /dev/sdb1 ...
mkexfatfs 1.3.0
Creating... done.
Flushing... done.
File system created successfully.
mkexfatfs success
writing data to disk ...
sync data ...
esp partition processing ...

Install Ventoy to /dev/sdb successfully finished.

Für uns relevant ist die größere, bootbare Partition:

$ sudo fdisk -l /dev/sdb
[...]
Device     Boot     Start       End   Sectors  Size Id Type
/dev/sdb1  *         2048 120111103 120109056 57,3G  7 HPFS/NTFS/exFAT
/dev/sdb2       120111104 120176639     65536   32M ef EFI (FAT-12/16/32)

Damit ist die Installation beendet. Wenn /dev/sdb1 gemountet ist, können iso-Dateien von Betriebssystemen/Linux-Distributionen auf den USB-Stick kopiert werden.

Bildschirmfoto: Ventoy-Stick mit fünf verschiedenen Linux-Distributionen

Ein Gerät, das von unserem Ventoy-Stick bootet, schlägt via Grub2 die einzelnen hinterlegten Systeme vor. Je nach Auswahl startet der Installationsprozess oder das Live-System des jeweiligen Eintrags:

Bildschirmforto: Die einzelnen iso-Dateien werden im Grub2-Menü aufgeführt.

Ventoy aktualisieren

Ventoy wird aktiv weiter entwickelt. Sofern es Updates gibt, lädt man die Software wie oben beschrieben herunter und steckt seinen USB-Stick ein. Die Ventoy-Version kann nun ausgelesen werden:

$ sudo ./Ventoy2Disk.sh -l /dev/sdb

**********************************************
      Ventoy: 1.0.96  x86_64
      longpanda admin@ventoy.net
      https://www.ventoy.net
**********************************************

Ventoy Version in Disk: 1.0.93
Disk Partition Style  : MBR
Secure Boot Support   : YES

Bei dem eben angezeigten Gerät, handelt es sich um meinen derzeitigen produktiv genutzten Ventoy-Multi-Boot-Stick der mit der Version 1.0.93 nicht die neueste Version besitzt. Mit folgendem Befehl führen wir ein Update durch:

$ ./Ventoy2Disk.sh -u /dev/sdb

**********************************************
      Ventoy: 1.0.96  x86_64
      longpanda admin@ventoy.net
      https://www.ventoy.net
**********************************************

Upgrade operation is safe, all the data in the 1st partition (iso files and other) will be unchanged!

Update Ventoy  1.0.93 ===> 1.0.96   Continue? (y/n) 
esp partition processing ...

Update Ventoy on /dev/sdb successfully finished.

Sobald wir die die Abfrage mit y bestätigen, wird das Update durchgeführt.

Fazit

Im Vergleich zu den früheren Lösungen ist die Einrichtung eines Multi-Boot-Sticks ziemlich einfach. Ein paar Eingaben auf der Kommandozeile und der Stick ist fertig. Wer es grafisch möchte, kann z. B. mit VentoyGUI.x86_64 über ein GUI die Einrichtung vornehmen

Bildschirmfoto: Die Einrichtung des Ventoy-Sticks kann auch via GUI vorgenommen werden.

Einmal eingerichtet, können je nach Belieben iso-Dateien auf den Stick gezogen oder wieder entfernt werden. Begrenzt ist man halt hier durch die Größe des USB-Sticks. Mein hier verwendeter 64G-Stick, reicht mir locker.

Quellen

https://github.com/ventoy/Ventoy/
https://www.ventoy.net/

Toolbox veröffentlicht

2023-10-03T00:00:00+00:00

Seit gestern gibt es auf dieser Seite eine (derzeit noch) kleine Toolbox . Dort werden Anwendungen, Plugins, Dienste im Netz, etc. aufgeführt, die in meinen Augen gute/bessere Alternativen zu proprietären oder datensammelwüttigen Angeboten darstellen.

In diesem Zusammenhang wurde auch die Navigation etwas umgebaut. Das hier eingesetzte Theme hugo-geekblog erstellt im Standard pro vergebenem Schlagwort einen Navigationseintrag. Mir erschien dieses Feature anfangs als sehr nützlich. Ich habe aber schnell gemerkt, dass es mir die Navigation unnötig aufbläht, sofern ich Beiträge mit zwei oder mehr Tags versehe.

Erste Gehversuche mit FreeBSD

2023-09-15T00:00:00+00:00

Ich bin ein großer GNU/Linux-Fan und im Besonderen mit Debian und Arch Linux sehr zufrieden. Dennoch hatte ich schon länger den Plan, in das FreeBSD-Universum zu schnuppern. Bisher ist mir das System bei der Firewall-Lösung OPNsense begegenet, die jedoch (im Normalfall) über die WebUI konfiguriert wird. Mit den Spezifika von FreeBSD setzt man sich dort eher weniger auseinander. Nun kam ich dazu, über den Tellerrand zu schauen und hab mich initial mit FreeBSD auseinander gesetzt. Mein erster Installationsversuch ist im Folgenden dokumentiert.

Installation

Der erste Blick fiel in die offizielle Dokumentation, die mir sehr ausführlich erscheint und die in deutscher Sprache vorliegt. Nachdem ich mir einen Überblick verschafft hatte, wurde das entsprechende ISO-File hier herunter geladen, auf einen Ventoy-Multiboot-Stick gezogen und davon gebootet.

Es öffnet sich sofort der Installer. Die vorgeschlagenen Einstellungen wurden weitgehend übernommen. Einzige wesentliche Änderung: Der zusätzlich angelegte User tobi wurde der Gruppe wheel zugeordnet. Dadurch kann mit dem Befehl su - root von meinem eigenen User zu root gewechselt werden. Sonst hätte ich das su: Sorry-Problem . Zudem wurde SSH aktiviert.

Der Installations-Assistent war schnell durchlaufen. Doch beim darauf folgenden Neustart lief mir folgende Fehlermeldung über den Weg:

sdhci_pci0-slot0: Controller timeout
sdhci_pci0-slot0: ============== REGISTER DUMP ==============
sdhci_pci0-slot0: Sys addr: 0x00000000 | Version:  0x00001002
sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt:  0x00000000
sdhci_pci0-slot0: Argument: 0x000001aa | Trn mode: 0x00000000
sdhci_pci0-slot0: Present:  0x00020001 | Host ctl: 0x00000001
sdhci_pci0-slot0: Power:    0x0000000e | Blk gap:  0x00000080
sdhci_pci0-slot0: Wake-up:  0x00000000 | Clock:    0x0000fa07
sdhci_pci0-slot0: Timeout:  0x00000000 | Int stat: 0x00000000
sdhci_pci0-slot0: Int enab: 0x01ff003b | Sig enab: 0x01ff003b
sdhci_pci0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
sdhci_pci0-slot0: Caps:     0x7568c881 | Caps2:    0x00000807
sdhci_pci0-slot0: Max curr: 0x00000000 | ADMA err: 0x00000000
sdhci_pci0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000
sdhci_pci0-slot0: ===========================================

Diese Meldung erscheint etwa 2 bis 3 Minuten im Sekunden-Takt. Die Maschine bootet jedoch im Anschluss ordentlich durch. Die genannte Fehlermeldung konnte im Kernel-Ring-Buffer mit dmesg nachvollzogen werden. Weitere Infos zu sdhci_pci0 können wie folgt ausgegeben werden:

root@fbsd:~ # pciconf -lv sdhci_pci0
sdhci_pci0@pci0:0:30:6: class=0x080501 rev=0x21 hdr=0x00 vendor=0x8086 [...] 
    vendor     = 'Intel Corporation'
    device     = 'Sunrise Point-LP Secure Digital IO Controller'
    class      = base peripheral
    subclass   = SD host controller

Der in meinem NUC eingebaute SD-Kartenleser schien das Problem zu sein. Der Hinweis hier hat mir auf die Sprünge geholfen:

root@fbsd:~ # echo hint.sdhci_pci.0.disabled="1" >> /boot/loader.conf

Die Warnungen und die Verzögerung beim Boot-Prozess sind somit weg. Ich kann mich anmelden, Das System scheint zu laufen.

Ersteinrichtung

Im Anschluss an die Basis-Installation hab ich mich umgesehen. Neben den bekannten Befehlen wie uname -a oder dem FreeBSD-typischen Kommando freebsd-version -kru ist vor allem die Datei /etc/os-release aufschlussreich:

root@fbsd:~ # cat /etc/os-release
NAME=FreeBSD
VERSION="13.2-RELEASE"
VERSION_ID="13.2"
ID=freebsd
ANSI_COLOR="0;31"
PRETTY_NAME="FreeBSD 13.2-RELEASE"
CPE_NAME="cpe:/o:freebsd:freebsd:13.2"
HOME_URL="https://FreeBSD.org/"
BUG_REPORT_URL="https://bugs.FreeBSD.org/"

Es wird empfohlen, nach einer Installation das System zu aktualisieren (Auszug):

root@fbsd:~ # freebsd-update fetch install
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching public key from update1.freebsd.org... done.
Fetching metadata signature for 13.2-RELEASE from update1.freebsd.org... done.
Fetching metadata index... done.
Fetching 2 metadata files... done.
Inspecting system... done.
Preparing to download files... done.
Fetching 42 patches.....10....20....30....40. done.
Applying patches... done.
Fetching 20 files... ....10....20 done.
The following files will be added as part of updating to
13.2-RELEASE-p3:
/etc/ssl/certs/0179095f.0
[...]

Im Anschluss, war mir nicht so ganz klar, in welcher Umgebung ich nach dem Login unterwegs bin. Die erste Verwunderung: Nach einem Logout bzw. Neustart ist die history leer. Eine Untersuchung der Shell ergab …

root@fbsd:~ # echo $SHELL
/bin/csh

Die Ausgabe verrät mir, dass ich DAS nicht haben will. Daher wurden im Anschluss erstmal ein paar Basis-Tools installiert und den beiden Usern, die ich verwende (tobi und root), in der Folge die bash als Standard-Shell untergejubelt (Ja … genau … ich mag die BASH).

root@fbsd:~ # pkg install vim sudo tmux bash 
chsh -s /usr/local/bin/bash tobi
chsh -s /usr/local/bin/bash root

Danach ist alles wie gewohnt: Die eingegebenen Befehle werden beim Logout-Vorgang in die ~/.bash_history geschrieben und sind somit nach einem Reboot oder neuem Login verfügbar.

Im Anschluss wurde noch sudo eingerichtet. Oh … sieh an … visudo funktioniert. Wie gewohnt sind schon zahlreiche auskommentierte Konfigurationsanweisungen enthalten. Die folgende Zeile wurde auskommentiert:

%wheel ALL=(ALL:ALL) NOPASSWD: ALL

Somit kann ich mit mit meinem User tobi via sudo -i ohne die Eingabe eines Passwortes in den User root wechseln. Wie oben beschrieben funktioniert das nur, wenn der entsprechende User ein Mitglied der Gruppe wheel ist:

[tobi@fbsd ~]$ sudo -i
[root@fbsd ~]#

SSH einrichten

Der SSH-Server wurde bei der Installation schon installiert und aktiviert. Ein Blick in die /etc/rc.conf verrät, dass dieser aktiviert ist …

[root@fbsd ~]# cat /etc/rc.conf | grep ssh
sshd_enable="YES"

… der Service läuft …

[root@fbsd ~]# service sshd status
sshd is running as pid 4336.

… und laut sockstat lauscht der SSH-Server korrekt auf Port 22:

[root@fbsd ~]# sockstat -4| grep ssh
root     sshd       4336  5  tcp4   *:22                  *:*

Die Authentifizierung des Users bei Anmeldung soll via PubKey-Auth erfolgen. Typischerweise liegt die Konfigurationsdatei für SSH, wie gewohnt unter /etc/ssh/sshd_config. Für den Testlauf lasse ich diese unverändert. Auf produktiven Maschinen, die über das Internet erreichbar sind, würde ich Anpassungen zur Absicherung vornehmen (SSH-Port wechseln, Passwort-Login verbieten, etc.).

Von meinem Debian-Notebook aus kopiere ich den entsprechenden Public-Key mit ssh-copy-id auf die FreeBSD-Maschine:

$ ssh-copy-id -i ~/.ssh/id_ed25519.pub tobi@<FreeBSD-PC-IP>

Klappt wie erwartet: Der Pub-Key liegt jetzt in der Datei ~/.ssh/authorized_keys mit den korrekten Berechtigungen.

Grafische Benutzeroberfläche

Zuletzt wurde auf der Test-Maschine noch die grafische Benutzeroberfläche KDE und der Display-Manager SDDM installiert. Hierzu gibt es verschiedene Wege. Unter Debian bietet sich hier der Weg über tasksel an. Daher hab ich nach einem Pendant unter FreeBSD gesucht und ein ähnliches Tool gefunden: `

[root@fbsd ~]# pkg install desktop-installer
[root@fbsd ~]# desktop-installer

Hierbei handelt es sich um einen Assistenten, der durch die Installation führt und neben einer Auswahl von Desktop-Umgebungen wie KDE, Gnome, LXQT, etc., auch die notwendigen grafischen Treiber und Anwendungen installiert bzw. konfiguriert. Bei der Ausführung von desktop-installer, gibt es allerlei Fragen zu beantworten. In der Regel wurde die jeweils vorgeschlagene Option gewählt.

Allerdings habe ich drei Anläufe gebraucht, bis es dann lief. Meine Erkenntnisse:

Wenn man den desktop-installer z. B. durch einen Reboot unterbricht, kann man diesen erneut aufrufen und die bisherigen gewählten Einstellungen sind vorausgewählt.
Es gibt nach der Treiber-Konfiguration der Grafikkarte die Möglichkeit KDE anzutesten. In diesem Zustand ist die Installation noch nicht fertig. Man kann jedoch sehen, ob die gewählten Einstellungen zu einer korrekten Darstellung führen.
SDDM begrüßte mich nach der Installation mit einem “Black-Screen”. Ursache war ein ausgewähltes SDDM-Theme, das nicht installiert war.

Fazit

Damit ist die Installation abgeschlossen. Die aufkommenden Hürden waren für mich durch die Doku, die Community und meinen eigenen Lösungsansätzen gut zu bewältigen. Ich werde in den kommenden Monaten diesen Rechner in meinem kleinen Heim-Labor verwenden und schauen, ob ich damit arbeiten kann. Ich bin gespannt wie sich die Kiste so macht und welche Erkenntnisse ich gewinnen kann.

Quellen

https://docs.freebsd.org/de/books/handbook/basics/
https://docs.freebsd.org/en/articles/linux-users/
https://forums.freebsd.org/threads/sdhci_pci0_slot0-controller-timeout.59077
https://ostechnix.com/install-freebsd/
https://cstan.io/post/2011/12/freebsd-su-sorry/
https://www.cyberciti.biz/faq/freebsd-bash-installation/
https://nudesystems.com/install-freebsd-with-kde/

Website Deployment mit Codeberg Pages und CI

2023-08-15T00:00:00+00:00

Wer mit dem Static-Site-Generator Hugo seine Webauftritt erstellt, will die generierten Webseiten auf einem Server bereitstellen: Irgendwo einen Webspace besitzen, Markdown-Dateien bearbeiten, hugo ausführen und im Anschluss per scp die Dateien im Hugo-Projekt aus dem Unter-Verzeichnis public hochladen. Das ist kein Hexenwerk, aber von der Bearbeitung des Inhaltes bis zur Bereitstellung auf dem Webspace sind einige Schritte notwendig. Insbesondere bei kleinen Änderungen kann das nervig sein.

Da ich für meinen Teil sehr gerne mit git arbeite und meine Quellen in der Regel auf irgendwelchen gitea-/forgejo-Instanzen verteile, habe ich mich bei dieser Website dafür entschieden, Codeberg Pages für das Hosting zu verwenden. Darüber hinaus automatisiere ich den Build- und Deploy-Prozess mit Hilfe von Codeberg CI . Wie das im Detail geht, beschreibe ich im Folgenden.

Inhalt:

Die Idee

Es gibt zwei Repos auf Codeberg:

toheine_sources enthält das Hugo-Projekt. (Quellen-Repo)
toheine enthält die durch Hugo generierten Dateien für den Webserver. (Pages-Repo)

Das Hugo-Projekt ist wie folgt aufgebaut:

. -> Quellen-Repo
├── archetypes
├── assets
├── content
├── data
├── layouts
├── public -> Pages-Repo
├── resources
├── static
└── themes

Damit liegt ein Repo in einem Repo. Das ist kein Problem, da git hierfür eine Lösung gleich liefert: git submodule

Jedes Mal, wenn Änderungen im Hugo-Projekt (im Quellen-Repo) durchgeführt werden, wird im Anschluss ein Commit erzeugt und in mein Codeberg-Repo gepusht toheine_sources . Dieses Event wird von der Codeberg CI registriert, der dort verwendete Woodpecker beginnt die Hugo-Files zu bauen und hinterlegt die so erzeugten Dateien im Pages-Repo toheine . Letzteres nutzt Codeberg Pages, der die Dateien unter einer Domain als Webseite bereitstellt.

Repos vorbereiten und Pages-Server nutzen

In einem ersten Schritt habe ich auf Codeberg die beiden öffentlichen, leeren Repos erstellt. Wichtig: Damit die Webseite von Codeberg Pages später korrekt dargestellt wird, lautet der Name des einzigen Branches im Webseiten-Repo “pages”.

Branch-Name im Pages-Repo lautet "pages"

Beim Quellen-Repo ist der Name des/der verwendeten Branches egal. Auf dem Rechner habe ich dann das Quellen-Repo heruntergeladen und mein (bereits vorhandenes) Hugoprojekt dort hinein kopiert:

git clone git@codeberg.org:toheine/toheine_sources.git
cd toheine_sources
cp -r /Quelle/meines/Hugo-Projektes/* .

Im Anschluss hab ich das Public-Verzeichnis entfernt und das Submodul hinzugefügt:

rm -rf public
git submodule add git@codeberg.org:toheine/toheine.git public

Die Struktur meiner Git-Repos ist somit fertig und die Webseite kann via https://toheine.codeberg.page/toheine/ aufgerufen werden (Aufbau: https://<user>.codeberg.page/repo). Ich will allerdings meine eigene Domain verwenden. Das ist hier auch gut dokumentiert. Ich habe mich für Option 2 (via ALIAS record) entschieden und folgende DNS-Einträge vorgenommen:

Domain 	         Type 	Data
toheine.net      ALIAS	codeberg.page
toheine.net      TXT    toheine.toheine.codeberg.page
www.toheine.net	 CNAME	toheine.net

Im letzten Schritt brauche ich in meinem pages-Repo noch eine Datei .domains, die pro Zeile einen Eintrag mit allen Adressen enthält, über die ich meine Seite aufrufen will. Diese hat in meinem Fall folgenden Aufbau:

toheine.net
www.toheine.net

Der Pages-Server von Codeberg sorgt jetzt dafür, dass die Seiten korrekt angezeigt werden und hinterlegt ein passendes Lets-Encrypt-Zertifikat:

LetsEncrypt schon implementiert

Ab jetzt kann ich manuell (ohne CI) neue Seiten veröffentlichen, in dem ich nach einer Änderung an meinem Hugo-Projekt lokal hugo ausführe, dann in das Verzeichnis public navigiere und die dortigen Änderungen in mein Pages-Repo auf Codeberg pushe:

hugo
cd public
git add *
git commit -m "Manuelle Änderung meiner Hugo-Seite"
git push

Codeberg CI einrichten

Es fehlt noch der Schritt zur Automatisierung via Codeberg CI. Dieses System kann allerdings nicht ohne Anmeldung benutzt werden. Es muss vorab ein Request gestellt werden. Das Verfahren ist unter folgender Adresse beschrieben: https://codeberg.org/Codeberg-e.V./requests .

Nachdem ich das Issue erstellt hatte (siehe hier ), erfolgte wenige Stunden später eine Freigabe und damit Zugriff auf Codeberg CI via https://ci.codeberg.org/ . Der Login erfolgt via SSO: Wer auf Codeberg angemeldet ist, klickt auf “Anmelden” und kann loslegen:

Woodpecker mit Repo verbinden

Über den Button “Repository hinzufügen” wählt man das Quellen-Repo aus und klickt auf “Aktivieren”. Wenn das hinterlegt ist, brauchen wir noch eine Pipeline im Quellen-Repo, dass den Namen .woodpecker.yml trägt. Letztendlich ist das die Abfolge an Befehlen, die von der Codeberg CI (Woodpecker) ausgeführt wird, sobald eine Änderung auf Codeberg erfolgt. Freundlicherweise, liegen für viele erdenkliche Szenarien schon Beispiele bereit (siehe hier ).

Ich hab die Datei für meine Verwendung leicht angepasst, aber im Wesentlichen so beibehalten (siehe hier ). Wichtig ist allerdings, dass bei Verwendung die Codeberg CI die beiden Variablen mail und codeberg_token gesetzt werden. Den Token müssen wir vorab im Codeberg-Konto generieren:

Hierzu muss in den Profil-Einstellungen, unter Anwendungen, ein Zugriffstoken hinzugefügt werden. Dieser bekommt einen eindeutigen Namen und entsprechende Berechtigungen:

Zugriffstoken auf Codeberg erstellen

Soblad man auf “Token generieren” klickt, erscheint der Token mit einem Hinweis, diesen jetzt zu kopieren, da er später nicht mehr angezeigt wird.

Im letzten Schritt der Einrichtung hinterlegen wir die beiden oben erwähnten Secrets noch in Woodpecker. Dazu im Repo (also auf https://ci.codeberg.org/ ), in den Einstellungen …

Woodpecker-Einstellungen öffnen

… unter dem Reiter “Geheimnisse” die beiden gewünschten Werte hinterlegen:

Secrets in Woodpecker verwalten

Damit ist Woodpecker (Codeberg CI) fertig eingerichtet.

Abschließende Anpassung und Nutzung

So … da in Zukunft eigentlich nur noch im Quellen-Repo gearbeitet wird und die Erzeugung nicht mehr lokal erfolgt, ist der lokale Ordner public im Hugo-Projekt für die Versionierung nicht mehr relevant. Daher hab ich diesen auf die Ignore-Liste gesetzt:

echo public >> .gitignore

Wenn Änderungen im Hugo-Projekt durchgeführt und versioniert werden, bekommt das Woodpecker mit. Codeberg CI erstellt die Seiten und veröfffentlicht diese auf Codeberg Pages. Wenn man nach einem commit, das Projekt in das Quellen-Repo auf Codeberg pusht, kann man den Prozess in der Woodpecker-Webui verfolgen:

Sobald der Specht anfängt zu klopfen …

Woodpecker läuft

… kann der Prozess im Detail eingesehen werden, in dem man auf die Commit-Botschaft klickt. Die einzelnen Schritte werden abgearbeitet und können in den “Step Logs” nachvollzogen werden:

Woodpecker-Änderungen nachvollziehen

Sofern alles korrekt gelaufen ist, erscheint ein grüner Haken pro einzelnem Schritt und nach Fertigstellung für den ganzen Commit:

Rückmeldung mit grünem Haken in Woodpecker

Fazit

Es ist ein wenig Aufwand, diese hier erwähnte Automatisierung mit Woodpecker zu realisieren. Aber … wenn das System eingerichtet ist, ist die Veröffentlichung in Sekunden realisiert und auch kleinere Änderungen an der Webseite sind schnell erledigt. Daher war das IMHO eine sinnvolle Investition.

Darüber hinaus hat man als Lehrkraft oder in der Fortbildung gleich ein Beispiel für einen sinnvollen Einsatz von CI/CD.

Codeberg e. V. bietet neben den reinen git-Repos mit Codeberg Pages und Codeberg CI ein überragendes Angebot. Die Doku und die erwähnten Beispiele für die.woodpecker.yml lassen keine Wünsche übrig. Ich finde das der absolute Hammer und Codeberg ist ein toller Verein!!!

Quellen

Hallo Welt

2023-08-11T00:00:00+00:00

Der/das nächste (total unnötige) Blog geht an den Start. Jep … aber mir ging es auf den Keks, dass ich meine Infos über zig Kanäle unter mein Umfeld streue, so dass selbst ich nicht mehr weiß, wem ich auf welchen Weg, was zu Verfügung gestellt habe. Ein Video hier, ein Link dort, eine kurze Zusammenfassung via Mail.

Daher: Mein Ziel dieser Seite ist, diese Infos in Zukunft zu bündeln. Es soll sich hier um öffentliche Notizen oder Anleitungen handeln, die ich nicht für mich behalten will. Es gibt nur einen Author, die Anrede ist “Du” und wer mich kontaktieren möchte, kann dies gerne auf den hier angegebenen Kanälen tun.

Die Webseite an sich soll dabei möglichst keinen zeitlichen Aufwand verschlingen. Daher setze ich hier auf Hugo , einen Static-Site-Generator. Dadurch spare ich mir die ständige Pflege eines CMS, das offen ist wie ein Scheunentor, wenn nicht zeitnah die notwendigen Updates eingespielt werden. Die Inhalte werden mittels Markdown verfasst.

Als Theme kommt hugo-geekblog zum Einsatz. Schick, schlank, genügt meinen Anforderungen.

Damit steht das Ding … und ich bin mal gespannt wie häufig ich das hier mit Leben fülle und ob das bei meiner angedachten Zielgruppe ankommt.

Update:

Die Bereitstellung erfolgt über Codeberg Pages in Verbindung mit der Codeberg CI . Wie das im Detail läuft, dokumentiere ich in den nächsten Tagen hier.