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!

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.

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.

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.

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

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.

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.

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.

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.

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.