initial draft of the tmux post

2 files changed, 170 insertions, 286 deletions

diff --git a/gemfeed/DRAFT-KISS-high-availability-with-OpenBSD.gmi b/gemfeed/DRAFT-KISS-high-availability-with-OpenBSD.gmi
deleted file mode 100644
index 640f3de5..00000000
--- a/gemfeed/DRAFT-KISS-high-availability-with-OpenBSD.gmi
+++ /dev/null
@@ -1,286 +0,0 @@
-# KISS high-availability with OpenBSD
-
-```
-Art by Michael J. Penick (mod. by Paul B)
-
-        __________
-       / nsd tower\                                             (
-      /____________\                                           (\) awk-ward
-       |:_:_:_:_:_|                                             ))   plant
-       |_:_,--.:_:|                       dig-bubble         (\//   )
-       |:_:|__|_:_|  relayd-castle          _               ) ))   ((
-    _  |_   _  :_:|   _   _   _            (_)             ((((   /)\`
-   | |_| |_| |   _|  | |_| |_| |             o              \\)) (( (
-    \_:_:_:_:/|_|_|_|\:_:_:_:_/             .                ((   ))))
-     |_,-._:_:_:_:_:_:_:_.-,_|                                )) ((//
-     |:|_|:_:_:,---,:_:_:|_|:|                               ,-.  )/
-     |_:_:_:_,'puffy `,_:_:_:_|           _  o               ,;'))((
-     |:_:_:_/  _ | _  \_:_:_:|          (_O                   ((  ))
-_____|_:_:_|  (o)-(o)  |_:_:_|--'`-.     ,--. ksh under-water (((\'/
- ', ;|:_:_:| -( .-. )- |:_:_:| ', ; `--._\  /,---.~  goat     \`))
-.  ` |_:_:_|   \`-'/   |_:_:_|.  ` .  `  /()\.__( ) .,-----'`-\(( sed-root
- ', ;|:_:_:|    `-'    |:_:_:| ', ; ', ; `--'|   \ ', ; ', ; ',')).,--
-.  ` MJP ` .  ` .  ` .  ` . httpd-soil ` .    .  ` .  ` .  ` .  ` .  `
- ', ; ', ; ', ; ', ; ', ; ', ; ', ; ', ; ', ; ', ; ', ; ', ; ', ; ', ;
-
-```
-
-I have always wanted a highly available setup for my personal websites. I could have used off-the-shelf hosting solutions or hosted my sites in an AWS S3 bucket. I have used technologies like BGP, LVS/IPVS, ldirectord, Pacemaker, heartbeat, heartbeat2, Corosync, keepalived, DRBD, and commercial F5 Load Balancers for high availability at work. 
-
-But still, my personal sites were never highly available. All those technologies are great for professional use, but I was looking for something much more straightforward for my personal space—something as KISS (keep it simple and stupid) as possible.
-
-It would be fine if my personal website wasn't highly available, but the geek in me wants it anyway.
-
-> PS: ASCII-art reflects the OpenBSD under-water world with all the tools available in the base system.
-
-## My auto-failover requirements
-
-* Be OpenBSD-based (I prefer OpenBSD because of the cleanliness and good documentation) and rely on as few external packages as possible. 
-* Don't rely on the hottest and newest tech (don't want to migrate everything to a new and fancier technology next month).
-* It should be reasonably cheap. I want to avoid paying a premium for floating IPs or fancy Elastic Load Balancers.
-* It should be geo-redundant. 
-* It's fine if my sites aren't reachable for five or ten minutes every other month. Due to their static nature, I don't care if there's a split-brain scenario where some requests reach one server and other requests reach another server.
-* Failover should work for both HTTP/HTTPS and Gemini protocols. My self-hosted MTAs and DNS servers should also be highly available.
-* Let's Encrypt TLS certificates should always work (before and after a failover).
-* Have good monitoring in place so I know when a failover was performed and when something went wrong with the failover.
-* Don't configure everything manually. The configuration should be automated and reproducible.
-
-## My HA solution
-
-### Only OpenBSD base installation required
-
-My HA solution for Web and Gemini is based on DNS (OpenBSD's `nsd`) and a simple shell script (OpenBSD's `ksh` and some little `sed` and `awk` and `grep`). All software used here is part of the OpenBSD base system and no external package needs to be installed - OpenBSD is a complete operating system.
-
-=> https://man.OpenBSD.org/nsd.8
-=> https://man.OpenBSD.org/ksh
-=> https://man.OpenBSD.org/awk
-=> https://man.OpenBSD.org/sed
-=> https://man.OpenBSD.org/dig
-=> https://man.OpenBSD.org/ftp
-
-I also used the `dig` (for DNS checks) and `ftp` (for HTTP/HTTPS checks) programs. 
-
-The DNS failover is performed automatically between the two OpenBSD VMs involved (my setup doesn't require any quorum for a failover, so there isn't a need for a 3rd VM). The `ksh` script, executed once per minute via CRON (on both VMs), performs a health check to determine whether the current master node is available. If the current master isn't available (no HTTP response as expected), a failover is performed to the standby VM: 
-
-```sh
-#!/bin/ksh
-
-ZONES_DIR=/var/nsd/zones/master/
-DEFAULT_MASTER=fishfinger.buetow.org
-DEFAULT_STANDBY=blowfish.buetow.org
-
-determine_master_and_standby () {
-    local master=$DEFAULT_MASTER
-    local standby=$DEFAULT_STANDBY
-
-    .
-    .
-    .
-    
-    local -i health_ok=1
-    if ! ftp -4 -o - https://$master/index.txt | grep -q "Welcome to $master"; then
-        echo "https://$master/index.txt IPv4 health check failed"
-        health_ok=0
-    elif ! ftp -6 -o - https://$master/index.txt | grep -q "Welcome to $master"; then
-        echo "https://$master/index.txt IPv6 health check failed"
-        health_ok=0
-    fi
-    if [ $health_ok -eq 0 ]; then
-        local tmp=$master
-        master=$standby
-        standby=$tmp
-    fi
-
-    .
-    .
-    .
-}
-```
-
-The failover scripts looks for the ` ; Enable failover` string in the DNS zone files and swaps the `A` and `AAAA` records of the DNS entries accordingly:
-
-```sh
-fishfinger$ grep failover /var/nsd/zones/master/foo.zone.zone
-        300 IN A 46.23.94.99 ; Enable failover
-        300 IN AAAA 2a03:6000:6f67:624::99 ; Enable failover
-www     300 IN A 46.23.94.99 ; Enable failover
-www     300 IN AAAA 2a03:6000:6f67:624::99 ; Enable failover
-standby  300 IN A 23.88.35.144 ; Enable failover
-standby  300 IN AAAA 2a01:4f8:c17:20f1::42 ; Enable failover
-```
-
-```sh
-tramsform () {
-	sed -E '
-	/IN A .*; Enable failover/ {
-	    /^standby/! {
-	        s/^(.*) 300 IN A (.*) ; (.*)/\1 300 IN A '$(cat /var/nsd/run/master_a)' ; \3/;
-	    }
-	    /^standby/ {
-	        s/^(.*) 300 IN A (.*) ; (.*)/\1 300 IN A '$(cat /var/nsd/run/standby_a)' ; \3/;
-	    }
-	}
-	/IN AAAA .*; Enable failover/ {
-	    /^standby/! {
-	        s/^(.*) 300 IN AAAA (.*) ; (.*)/\1 300 IN AAAA '$(cat /var/nsd/run/master_aaaa)' ; \3/;
-	    }
-	    /^standby/ {
-	        s/^(.*) 300 IN AAAA (.*) ; (.*)/\1 300 IN AAAA '$(cat /var/nsd/run/standby_aaaa)' ; \3/;
-	    }
-	}
-	/ ; serial/ {
-	    s/^( +) ([0-9]+) .*; (.*)/\1 '$(date +%s)' ; \3/;
-	}
-	'
-}
-```
-
-After the failover, the script reloads `nsd` and performs a sanity check to see if DNS still works. If not, a rollback will be performed:
-
-```sh
-# Race condition (e.g. script execution abored in the middle of the previous run)
-if [ -f $zone_file.bak ]; then
-    mv $zone_file.bak $zone_file
-fi
-
-cat $zone_file | transform > $zone_file.new.tmp 
-
-grep -v ' ; serial' $zone_file.new.tmp > $zone_file.new.noserial.tmp
-grep -v ' ; serial' $zone_file > $zone_file.old.noserial.tmp
-
-echo "Has zone $zone_file changed?"
-if diff -u $zone_file.old.noserial.tmp $zone_file.new.noserial.tmp; then
-    echo "The zone $zone_file hasn't changed"
-    rm $zone_file.*.tmp
-    return 0
-fi
-
-cp $zone_file $zone_file.bak
-mv $zone_file.new.tmp $zone_file
-rm $zone_file.*.tmp
-echo "Reloading nsd"
-nsd-control reload
-
-if ! zone_is_ok $zone; then
-    echo "Rolling back $zone_file changes"
-    cp $zone_file $zone_file.invalid
-    mv $zone_file.bak $zone_file
-    echo "Reloading nsd"
-    nsd-control reload
-    zone_is_ok $zone
-    return 3
-fi
-
-for cleanup in invalid bak; do
-    if [ -f $zone_file.$cleanup ]; then
-        rm $zone_file.$cleanup
-    fi
-done
-
-echo "Failover of zone $zone to $MASTER completed"
-return 1
-```
-
-A non-zero return code (here, 3 when a rollback and 1 when a DNS failover was performed) will cause CRON to send an E-Mail with the whole script output.
-
-The nameserver is running on both VMs, and both are configured to be "master" DNS servers so that they have their own individual zone files, which can be changed independently. Otherwise, my setup wouldn't work. The side effect is that under a split-brain scenario (both VMs cannot see each other), both would promote themselves to master via their local DNS entries. More about that later, but that's fine in my use case.
-
-Check out the whole script here:
-
-=> https://codeberg.org/snonux/rexfiles/src/branch/master/frontends/scripts/dns-failover.ksh
-
-### Fairly cheap and geo-redundant
-
-I am renting two small OpenBSD VMs: One at OpenBSD Amsterdam and the other at Hetzner Cloud. So, both VMs are hosted at another provider, in different IP subnets, and in different countries (the Netherlands and Germany).
-
-=> https://openbsd.amsterdam
-=> https://www.hetzner.cloud
-
-I only have a little traffic on my sites. I could always upload the static content to AWS S3 if I suddenly had to. But this will never be required.
-
-A DNS-based failover is cheap, as there isn't any BGP or fancy load balancer to pay for. Small VMs also cost less than millions.
-
-### Failover time and split-brain
-
-A DNS failover doesn't happen immediately. I've configured a DNS TTL of `300` seconds, and the failover script checks once per minute whether to perform a failover or not. So, in total, a failover can take six minutes (not including other DNS caching servers somewhere in the interweb, but that's fine - eventually, all requests will resolve to the new master after a failover).
-
-A split-brain scenario between the old master and the new master might happen. That's OK, as my sites are static, and there's no database to synchronise other than HTML, CSS, and images when the site is updated.
-
-### Failover support for multiple protocols
-
-With the DNS failover, HTTP, HTTPS, and Gemini protocols are failovered. This works because all domain virtual hosts are configured on either VM's `httpd` (OpenBSD's HTTP server) and `relayd` (it's also part of OpenBSD and I use it to TLS offload the Gemini protocol). So, both VMs accept requests for all the hosts. It's just a matter of the DNS entry, which hosts receive the requests.
-
-=> https://man.openbsd.org/httpd.8
-=> https://man.openbsd.org/relayd.8
-
-For example, the master is responsible for the `https://www.foo.zone` and `https://foo.zone` hosts, whereas the standby can be reached via `https://standby.foo.zone` (port 80 for plain HTTP works as well). The same principle is followed with all the other hosts, e.g. `irregular.ninja`, `paul.buetow.org` and so on. The same applies to my Gemini capsules for `gemini://foo.zone`, `gemini://standby.foo.zone`, `gemini://paul.buetow.org` and `gemini://standby.paul.buetow.org`.
-
-On DNS failover, master and standby swap roles without config changes other than the DNS entries. That's KISS (keep it simple and stupid)!
-
-### Let's encrypt TLS certificates
-
-All my hosts use TLS certificates from Let's Encrypt. The ACME automation for requesting and keeping the certificates valid (up to date) requires that the host requesting a certificate from Let's Encrypt is also the host using that certificate.
-
-If the master always serves `foo.zone` and the standby always `standby.foo.zone`, then there would be a problem after the failover, as the new master wouldn't have a valid certificate for `foo.zone` and the new standby wouldn't have a valid certificate for `standby.foo.zone` which would lead to TLS errors on the clients.
-
-As a solution, the CRON job responsible for the DNS failover also checks for the current week number of the year so that:
-
-* In an odd week number, the first server is the default master
-* In an even week number, the second server is the default master.
-
-Which translates to:
-
-```sh
-# Weekly auto-failover for Let's Encrypt automation
-local -i -r week_of_the_year=$(date +%U)
-if [ $(( week_of_the_year % 2 )) -eq 0 ]; then
-    local tmp=$master
-    master=$standby
-    standby=$tmp
-fi
-```
-
-This way, a DNS failover is performed weekly so that the ACME automation can update the Let's Encrypt certificates (for master and standby) before they expire on each VM.
-
-The ACME automation is yet another daily CRON script `/usr/local/bin/acme.sh`. It iterates over all of my Let's Encrypt hosts, checks whether they resolve to the same IP address as the current VM, and only then invokes the ACME client to request or renew the TLS certificates. So, there are always correct requests made to Let's Encrypt. 
-
-Let's encrypt certificates usually expire after 3 months, so a weekly failover of my VMs is plenty.
-
-=> https://codeberg.org/snonux/rexfiles/src/branch/master/frontends/scripts/acme.sh.tpl `acme.sh.tpl` - Rex template for the `acme.sh` script of mine.
-=> https://man.openbsd.org/acme-client.1
-=> ./2022-07-30-lets-encrypt-with-openbsd-and-rex.gmi Let's Encrypt with OpenBSD and Rex
-
-### Monitoring
-
-CRON is sending me an E-Mail whenever a failover is performed (or whenever a failover failed). Furthermore, I am monitoring my DNS servers and hosts through Gogios, the monitoring system I have developed. 
-
-=> https://codeberg.org/snonux/gogios
-=> ./2023-06-01-kiss-server-monitoring-with-gogios.gmi KISS server monitoring with Gogios
- 
-### Rex automation
-
-I use Rexify, a friendly configuration management system that allows automatic deployment and configuration.
-
-=> https://www.rexify.org
-=> https://codeberg.org/snonux/rexfiles/src/branch/master/frontends
-
-## More HA
-
-Other high-available services running on my OpenBSD VMs are my MTAs for mail forwarding (OpenSMTPD) and the authoritative DNS servers (`nsd`) for all my domains. No particular HA setup is required, though, as the protocols (SMTP and DNS) already take care of the failover to the next available host! 
-
-As a password manager, I use `geheim`, a command-line tool I wrote in Ruby with encrypted files in a git repository (I even have it installed in Termux on my Phone). For HA reasons, I simply updated the client code so that it always synchronises the database with both servers when I run the `sync` command there. 
-
-=> https://codeberg.org/snonux/geheim
-
-E-Mail your comments to `paul@nospam.buetow.org` :-)
-
-Other *BSD and KISS related posts are:
-
-=> ./2016-04-09-jails-and-zfs-on-freebsd-with-puppet.gmi 2016-04-09 Jails and ZFS with Puppet on FreeBSD
-=> ./2022-07-30-lets-encrypt-with-openbsd-and-rex.gmi 2022-07-30 Let's Encrypt with OpenBSD and Rex
-=> ./2022-10-30-installing-dtail-on-openbsd.gmi 2022-10-30 Installing DTail on OpenBSD
-=> ./2023-06-01-kiss-server-monitoring-with-gogios.gmi 2023-06-01 KISS server monitoring with Gogios
-=> ./2023-10-29-kiss-static-web-photo-albums-with-photoalbum.sh.gmi 2023-10-29 KISS static web photo albums with `photoalbum.sh`
-=> ./2024-01-13-one-reason-why-i-love-openbsd.gmi 2024-01-13 One reason why I love OpenBSD
-
-=> ../ Back to the main site
diff --git a/gemfeed/DRAFT-terminal-multiplexing-with-tmux.gmi b/gemfeed/DRAFT-terminal-multiplexing-with-tmux.gmi
new file mode 100644
index 00000000..f330f210
--- /dev/null
+++ b/gemfeed/DRAFT-terminal-multiplexing-with-tmux.gmi
@@ -0,0 +1,170 @@
+# Terminal multiplexing with `tmux`
+
+## Introduction
+
+Tmux (Terminal Multiplexer) is a powerful, terminal-based tool that allows to manage multiple terminal sessions within a single window. Here are some of its primary features and functionalities:
+
+* Session management
+* Window and Pane management
+* Persistent Workspacec
+* Customization
+
+=> https://github.com/tmux/tmux/wiki
+
+Before continuing reading this post, I encourage to get familiar with Tmux first (unless, of course, you know already the basics). You could go through the official getting started guide:
+
+=> https://github.com/tmux/tmux/wiki/Getting-Started
+
+Over the years, I have build a couple of shell helper functions to optimize my workflows. 
+
+Tmux is integrated into my daily workflows (personal and work) a lot. I had colleagues asking me about my tmux config and halper scripts for temux a couple of times. I thought it would be neat to blog about it, so that everyone who is interested in it, can make a copy of my configuration and scripts.
+
+The configuration and the scripts in this blog post are only the non-work specific parts. There are more helper scripts which I only use for work (and aren't really useful outside of work due to the nature how servers and clusters are structured there).
+
+Tmux is highly configurable and I think I am only scratching the surfice with what is possible with it. Nethertheless, it may be still useful for you.
+
+## Shell aliases
+
+I am a user of the Z-Shell (`zsh`) but I believe all the snippets mentioned in this blog post also work with Bash. 
+
+=> https://www.zsh.org
+
+For the most common tmux commands I use I have created the following shell aliases:
+
+```bash
+alias tm=tmux
+alias tl='tmux list-sessions'
+alias tn=tmux::new
+alias ta=tmux::attach
+alias tx=tmux::remote
+alias ts=tmux::search
+alias tssh=tmux::cluster_ssh
+```
+
+Note all `tmux::...`, those are custom shell functions doing certain things, those aren't part of the Tmux distribution. But let's run through every alias one-by-one. 
+
+The first two are pretty straight forward. `tm` is simply a shorthand for `tmux`, so I have to type less and `tl` simply lists all Tmux sessions currently open. Not much magic here.
+
+### The `tn` alias
+
+The `tn` alias is referencing this function:
+
+```bash
+# Create new session and if alread exists attach to it
+tmux::new () {
+    readonly session=$1
+    local date=date
+    if where gdate &>/dev/null; then
+        date=gdate
+    fi
+
+    tmux::cleanup_default
+    if [ -z "$session" ]; then
+        tmux::new T$($date +%s)
+    else
+        tmux new-session -d -s $session
+        tmux -2 attach-session -t $session || tmux -2 switch-client -t $session
+    fi
+}
+alias tn=tmux::new
+```
+
+There is a lot of stuff going on here. Let's have a look in detail what it is doing. As a note, the function relies on GNU Date, so for MacOS it is looking for the `gdate` commans to be available. Otherwise, it will fallback to `date`. For Mac, you would need to install GNU Date as it isn't installed by default there.
+
+First, as a first argument, a Tmux session name can be passed to the function. That session name is only optional. Without it, Tmux will select a session named `T$($date +%s)` as a default. Which is T followed by the UNIX epoch, e.g. `T1717133796`.
+
+Note also the call to `tmux::cleanup_default`, it would clean up all already opened default sessions if they aren't attached. Those kind of sessions are only of temporal nature and I found myself that I had too many flying around after a while. So I decided to auto delete the sessions if they aren't still attached. If I want to keep sessions around I would rename them with the Tmux command `prefix-key $`. This is the cleanup function:
+
+```bash
+tmux::cleanup_default () {
+    local s
+    tmux list-sessions | grep '^T.*: ' | grep -F -v attached |
+    cut -d: -f1 | while read -r s; do
+        echo "Killing $s"
+        tmux kill-session -t "$s"
+    done
+}
+```
+
+
+## Cluster SSH replacement
+
+I am using `tmux` as a Cluster SSH replacement.
+
+# Tmux
+
+
+This is my `~/.tmux.conf`:
+
+```
+source ~/.tmux.local.conf
+
+set-option -g allow-rename off
+set-option -g default-terminal "screen-256color"
+set-option -g history-limit 100000
+set-option -g status-bg '#444444'
+set-option -g status-fg '#ffa500'
+set-option -s escape-time 0
+
+set-window-option -g mode-keys vi
+
+bind-key h select-pane -L
+bind-key j select-pane -D
+bind-key k select-pane -U
+bind-key l select-pane -R
+
+bind-key H resize-pane -L 5
+bind-key J resize-pane -D 5
+bind-key K resize-pane -U 5
+bind-key L resize-pane -R 5
+
+bind-key c new-window -c '#{pane_current_path}'
+bind-key F new-window -n "session-switcher" "tmux list-sessions | fzf | cut -d: -f1 | xargs tmux switch-client -t"
+bind-key p setw synchronize-panes off
+bind-key P setw synchronize-panes on
+bind-key r source-file ~/.tmux.conf \; display-message "~/.tmux.conf reloaded"
+bind-key T choose-tree
+```
+
+* I don't like programs running in tmux to change the window title, so i configured `allow-rename` to `off.`
+* Somtimes, I deal with a lot of terminal output which I also want to search. So I configured the `history-limit` to apretty high value.
+* The `escape-time` had to be configured to 0 to avoid issues with Helix, the text editor of my choice.
+* I am using vi key bindings in tmux, which is configured with `set-window-option -g mode-keys vi`.
+* The `bind-key h`...`bind-key l` make it so, that I can cycle tyhrought the tmux windows with the hjkl keys (vi and Helix editor emulation for arrow keys)
+* Respectively, the capital letters HJKL are used to resize the windows.
+* bind-key c creates a new window.
+* bind-key F opens a fuzzy finder for all open sessions.
+* bind-key p and C-P for controlling whether to syncrhonise the panes or not.
+* bind-key T to show a tree of all sessions and windows.
+
+
+
+This is my `~/.tmux.local.conf` on my local laptops:
+
+```
+bind-key -T copy-mode-vi 'v' send -X begin-selection
+bind-key -T copy-mode-vi 'y' send -X copy-selection-and-cancel
+```
+
+    
+
+Copy n paste, buffer search
+
+Clusterssh + p P
+
+Nested tmuxes are nice, too. E.g. one tmux on your laptop or workstation. In there you SSH into remote servers (use tmux as a ClusterSSH replacement). And then on the remote servers you start tmux again. I have configured a different leader key for the remote tmux instances, so they dont conflict with the local instance of tmux.
+
+Remote config file
+
+Zsh helper functions
+
+foo alias on remote servers
+
+Tmux is part of the OpenBSD Base system.
+
+Tmux book I read.
+
+Rename sessions I use frequently 
+
+TL and ta aliases 
+