2021 begann für mich eine Reise in ein Rabbit Hole, dass bisher immer noch nicht sein Ende erreicht hat: Ich bin Terminal Enthusiasts geworden.

Von Mutt (Mails) über newsboat (RSS Feed Reader) bis hin zum spotify-player nutze ich in meinem Alltag nahezu immer Tools im Terminal. Spezifisch für meinen Arbeitsalltag oder Software-Entwicklung im Privaten setze ich auf Neovim als Code Editor und das Git CLI für Softwareversionierung. Terraform/OpenTofu sowie kubectl sind per se auch CLI Tools.

(Die einzige Aufnahme ist der Browser - Ich weiß auch nicht wieso, aber w3m oder Lynx ist mir dann doch zu abstract)

Diese exzessive Nutzung des Terminals vereinfacht mir tmux. tmux ist ein sogenannter Terminal Multiplexer. Es ermöglicht, mehre Terminal Sessions zu erstellen und zu verwalten. Somit lassen sich quasi Tabs von Terminal Sessions erstellen.

Wie es sich für eine Unix-Anwendung gehört: Man kann wundbar mit der tmux CLI Skripten:

#!/bin/bash

DIRECTORY=$(pwd)
BASENAME=$(basename $(pwd))

tmux rename-session $BASENAME
tmux rename-window nvim
tmux send-keys 'nvim' Enter
tmux new-window -c $DIRECTORY -n tofu
tmux new-window -c $DIRECTORY -n git
tmux send-keys 'git status' Enter
tmux new-window -c $DIRECTORY -n terminal
tmux select-window -t 1

Das vorhergehende Skript baut mir meine IaC spezifische Arbeitsumgebung aus vier Tabs:

1. Neovim zum Bearbeiten des IaC Codes.
2. Eine Terminal Session spezifisch zum Ausführen der IaC Tools, z.B. für tofu init oder terraform apply.
3. Eine weitere Terminal Session für die Arbeit mit git. Es wird bei Aufbau der Arbeitsumgebung automatisch ein git status ausgeführt.
4. Schlussendlich eine weitere Terminal Session für Experimente oder Spielereien, wie das Ausführen von Befehlen in der Azure CLI oder zum Ausführen von Lintern wie tflint.

All diese Tabs nutzen als Working Directory das Directory, indem das Skript initial ausgeführt wurde.

In tmux lassen sich mehrere Terminals als eine Session zusammenfassen. Jedes Projekt bekommt seine eigene Session, somit stelle ich einerseits sicher, dass der Index der Tabs bei jedem Projekt identisch sind (Neovim im Tab 1, Git im Tab 3, ... ). Andererseits wird so aus meiner Sicht dem Extraneous cognitive load entgegen gewirkt, da man nur die relevanten und bekannten Elemente einer anstehenden Tätigkeit geöffnet hat/angezeigt bekommt.

Das war mal ein kleiner Überblick über meinen IaC Workflow mit tmux. Anregungen und Fragen gerne bei mir adressieren. Unter Kontakt findet man genug Möglichkeiten, um ins Gespräch zu kommen!

Mit der Version 4 des terraform azurerm providers, wurde die Subscription ID aus Azure zum Pflichtfeld zur Erstellung neuer Ressourcen. Dies betrifft nicht nur den tofu apply, sondern auch bereits das tofu plan.

Vorher wurde bei Nutzung der Azure CLI immer die aktive Subscription aus dem User-Kontext genutzt.

Beim Fehlen der Subscription ID im Provider Block wirft der Aufruf von tofu plan nun die folgende Fehlermeldung:

Planning failed. OpenTofu encountered an error while generating this plan.

╷
│ Error: `subscription_id` is a required provider property when performing a plan/apply operation
│
│   with provider["registry.opentofu.org/hashicorp/azurerm"],
│   on main.tf line 11, in provider "azurerm":
│   11: provider "azurerm" {

Das einfachste Vorgehen ist natürlich, die Subscription ID direkt im Provider Block zu setzen:

provider "azurerm" {
  subscription_id = "cf4ea9ae-cfef-4132-a5a1-c507a07a3371"
  features {}
}

Alternativ dazu kann auch auf eine Umgebungsvariable mit dem Namen ARM_SUBSCRIPTION_ID gesetzt werden.

export ARM_SUBSCRIPTION_ID=cf4ea9ae-cfef-4132-a5a1-c507a07a3371

Um ein ähnliches Verhalten wie vorm Update der Version 4 beizubehalten, kann man sich via Azure CLI und dem CLI-Tool jq die aktuelle Subscription ID aus dem aktiven User-Kontext filtern und diese dann als Umgebungsvariable setzen.

export ARM_SUBSCRIPTION_ID=$(az account show | jq -r .id)

Mit der ingress-nginx annotation nginx.ingress.kubernetes.io/permanent-redirect koennen simpel HTTP Redirects umgesetzt werden

Ich nutze, wie z.B. fuer diesen Blog, gerne Azure Static Web Apps. Allerdings haben diese den Nachteil, das die Root einer Domain nicht als Custom Domain genutzt werden kann, so z.B. bei meiner Homepage - www.tjarks.dev, weil auf der root kein CNAME gesetzt werden darf/kann.

Um dennoch Zugriff via der root (tjarks.dev) moeglich zu machen, habe ich einen Ingress fuer den Host tjarks.dev in meinem Kubernetes Cluster gebaut, welcher auf Basis der nginx.ingress.kubernetes.io/permanent-redirect annotation ein Redirect auf https://www.tjarks.dev vornimmt.

nginx.ingress.kubernetes.io/permanent-redirect: https://www.tjarks.dev

Mehr Informationen zu der annotation koennen in der ingress-nginx Dokumentation gefunden werden.

Snippet​

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tjarks-dev 
  kubernetes.io/ingress.class: "nginx"
  cert-manager.io/cluster-issuer: "letsencrypt-prod"
  annotations:
    nginx.ingress.kubernetes.io/permanent-redirect: https://www.tjarks.dev
spec:
  ingressClassName: nginx
  tls:
  - hosts:
      - tjarks.dev
    secretName: tjarks-dev-tls
  rules:
  - host: tjarks.dev

Standardmaessig erwarten Electron Apps auch im Jahr 2024 X11 als Windowing System. Daher werden auf Wayland-Sytemen Electron Apps meist mit XWayland gestartet. Die Folge ist die bekannte Blurriness/Unschaerfe.

Allerdings beherrschen aktuelle Electron Apps bereits nativen Wayland Support. Hierbei spielt es auch keine Rolle, ob die Programme via Paketmanager lokal installiert wurden oder mit Flatpak.

Genutzt wird die sogenannte OZONE platform abstraction layer des Chromium Projektes. Als Platform kann mittels des command flags --ozone-platform=wayland die Nutzung von Wayland erzwungen werden.

Es folgen Beispiele zu VS Code und Obsidian in der Flatpak Variante.

Beispiele​

VS Code​

code --ozone-platform=wayland

Obsidian (Flatpak)​

flatpak run --socket=wayland md.obsidian.Obsidian --ozone-platform=wayland

Nach einem Lizenzwechsel bei Terraform entstand mit dem OpenTofu Projekt ein Fork, damit die bekannte Toolchain weiterhin als Open-Source weiterentwickelt werden kann

Aktuell gibt es noch keine offizielen Binaries vom OpenTofu Projekt. Die Installation ist jedoch grundsaetzlich sehr simpel gehalten, da es sich um Go Tool handelt. Der Quellcode findet sich auf Github unter opentofu/opentofu.

Zum Bauen der Binaries wird der Go compiler benoetigt. Die notwendige Version ist im Git-Repository von OpenTofu in der Datei .go-version angegeben. Nach einem Download des Git-Repository kann in dessen Root-Verzeichnis der folgende Befehl ausgefuehrt werden:

go install .

Dadurch wird das OpenTofu CLI Tool zuerst compiliert und dann Go executable directory installiert. Mit dem Kommando go env GOPATH wird der Pfad zum Go executable directory ausgegeben.

Empfohlen ist, dass der GOPATH in die PATH Variable hinzugefuegt wird. Dadurch kann opentofu mit einem einfachen Aufruf von opentofu ausgefuehrt werden.

➜ 11:40PM janno opentofu (main) ✔ opentofu
Usage: tofu [global options] <subcommand> [args]

The available commands for execution are listed below.
The primary workflow commands are given first, followed by
less common or more advanced commands.

Main commands:
  init          Prepare your working directory for other commands
  validate      Check whether the configuration is valid
  plan          Show changes required by the current configuration
  apply         Create or update infrastructure
  destroy       Destroy previously-created infrastructure

All other commands:
  console       Try OpenTofu expressions at an interactive command prompt
  fmt           Reformat your configuration in the standard style
  force-unlock  Release a stuck lock on the current workspace
  get           Install or upgrade remote OpenTofu modules
  graph         Generate a Graphviz graph of the steps in an operation
  import        Associate existing infrastructure with a OpenTofu resource
  login         Obtain and save credentials for a remote host
  logout        Remove locally-stored credentials for a remote host
  metadata      Metadata related commands
  output        Show output values from your root module
  providers     Show the providers required for this configuration
  refresh       Update the state to match remote systems
  show          Show the current state or a saved plan
  state         Advanced state management
  taint         Mark a resource instance as not fully functional
  test          Execute integration tests for OpenTofu modules
  untaint       Remove the 'tainted' state from a resource instance
  version       Show the current OpenTofu version
  workspace     Workspace management

Global options (use these before the subcommand, if any):
  -chdir=DIR    Switch to a different working directory before executing the
                given subcommand.
  -help         Show this help output, or the help for a specified subcommand.
  -version      An alias for the "version" subcomm

Beim einem Besuch bei der Linux User Group in Bremen Anfang des Jahres, lernte ich das Collatz-Problem - auch (3n+1)-Vermutung genannt - kennen.

Hierbei handelt es sich um ein mathematisches Problem, das 1937 vom Mathematiker Lothar Collatz formuliert wurde. Collatz erdachte den folgenden Bildungssatz:

• Beginne mit irgendeiner natürlichen Zahl, wo gilt n > 0
• Ist n gerade, so nimm als nächstes n / 2
• Ist n ungerade, so nimm als nächstes 3n + 1
• Wiederhole die Vorgehensweise mit der erhaltenen Zahl

Dessen dazugehoerige Vermutung lautet:

Die Zahlenfolge mündet immer in den Zyklus 4, 2, 1, egal, mit welcher positiven natürlichen Zahl man beginnt.

Trotz mehreren Aufrufen und mehreren Preisgeldern konnte bis zum Erscheinen dieses Eintrages die Vermutung nicht bestaetigt werden.

Wer Interesse hat, sich das Collatz-Problem einmal auf Software-Ebene anzusehen, kann einen Blick auf mein Github-Profil legen. Dort findet sich Sourcecode unter JannoTjarks/collatz, wo ich mich dem ganzen einmal genaehert habe. Es ist in Go geschrieben; daher verhaeltnismaessig gut lesbar! ;)

Visual Studio Code besitzt einen built-in Markdown Reader, aufrufbar über die Command Palette

Visual Studio Code hat seit seinem ersten Release in 2015 eine unglaublich große Nutzerbasis akquiriert - sowohl bei allen Arten von Softwareentwicklern als auch SysAdmins und NetAdmins.
Gleichzeitig halfen DevOps Plattformen wie Github oder auch Static site generators, z.B. Hugo oder Jekyll, beim Durchbruch von Markdown zur de-facto Standardsyntax für Dokumentation aller Art.
Daher bietet Visual Studio Code auch bereits im Default ohne Extensions aus dem Marketplace nützlich Features zum Schreiben in Markdown.

Visual Studio Code besitzt einen built-in Markdown Reader, der aufrufbar ist über die Command Palette oder über die Tastenkürzel CTRL+Shift+V bzw. Ctrl+K V. CTRL+Shift+V öffnet ein neues Tab innerhalb von Visual Studio Code, während Ctrl+K V hingegen eine Side-by-side Anzeige öffnet.

Da ich selber neovim Nutzer bin, kann ich mir den Hinweis nicht ersparen, dass eine ähnliche Funktionalität in Neovim mit dem Plugin markdown-preview.nvim nachgerüstet werden kann.

Desweiteren kann ich für Visual Studio Code Nutzer auch das Plugin markdownlint empfehlen, welche auf das gleichnamige Open-Source Tool basiert. Markdownlint ist ein Style Checker, der den geschrieben Markdown Text anhand fester Regel überprüft und so beim Schreiben von syntaktisch sauberen Markdown unterstützt. Zu dem Thema Markdownlint wird sicherlich in Zukunft noch ein eigener Post erscheinen.

Tastenkürzel​

Weiterführende Links​

• Markdown and Visual Studio Code
• Markdown Specification
• CommonMark

Dieser Blog ist mit Markdown verfasst; genutzt wird das built-in Blog Plugin von Docusaurus