Posts

Another year, another blog redesign

2026-07-04T16:12:39+00:00
After a lot of consideration, I've gone ahead and switched out both the backend and the theme of this site yet again. There were a number of ongoing issues, the most notable of which were:
The monospace font for the Cactus</code> theme</a> was honestly hard to read. Additionally, the mobile layout had poor padding.</li>
Configuration of the theme involved managing 2 different config files, which quickly became convoluted.</li>
There was no auto-dark mode for Cactus</code>, and I was not particularly interested in trying to design and configure one.</li>
The theme was not self-contained, and was loading 5 different minified JS scripts through Cloudflare.</li>
The hexo</code> backend</a> was excessive for what was essentially a collection of static webpages. It required 10 NPM packages, installing nearly 60Mb of dependencies (the theme was another 12Mb).</li>
To run hexo</code>, I had to install a NodeJS runtime and a specific version of NPM, which I was doing with NVM (Node Version Manager</a>). Sourcing this in my zshrc</code> was so bloated it was taking seconds to load my shell, which is a known problem</a>.</li> </ul> Ultimately, my requirements are very basic: convert Markdown files into HTML & attach minimal CSS styling (and maybe some very minimal JS for page interactions). I could have put in a lot of time trying to address these items with the existing framework, but my skills in the graphic design department, especially webdev, is currently not my strongest suit. I knew I had gone too far when I started to learn Figma... Luckily, there was an existing project made specifically for this use case!: Zola</a> This project hits all the points in my wishlist: A single, simple, small binary</li> Built-in, easy to use templating engine that can transpile Markdown into HTML</li> Can compile Sass into CSS</li> </ul> I also found a theme that looks much better on both mobile and on desktop: Serene</a> It has an auto-dark mode theme that looks nice</li> Padding is significantly better</li> The font choice is much more readable</li> </ul> All in all, this framework and theme is much easier to configure, so I may actually tweak it further (unlike with the previous theme). The only negative impact of this change is that the URL slugs have changed, which will break previous links: date baked-in (/2026/03/14/replacin...</code>) --> directly under /posts/</code> (/posts/replacin...</code>)</li> </ul> Given how minimal (and external dependency-free) this new theme is, I can also revisit hosting a copy of it on a Hidden site through Tor (or even I2P) which, although a fun project, was also annoyingly slow with the heavier framework & additional JS dependencies.

Deleting Sequoia-PGP certificates
2026-05-21T00:51:02+00:00
If you have been messing around with the potential GPG replacement command-line tool Sequoia-PGP</a>, you may have noticed that there doesn't appear to be a way to delete 'certs' from the certificate store.</p>
After spending some time digging in the manpages and documentation with no clarification, it appears that this isn't a mistake but a matter of opinion. The developers treat the certificate store as a completely intentional append-only list, and an issue created about this was closed as "won't complete" 3 years ago</a>.</p>
This means that if you were experimenting with creating/deleting keys and certs or importing external certs, your certificate store will become littered with unused or broken certs with no possibility to clean it up (this could even be considered a privacy risk, since the default stance is to automatically "hide" them from users).</p>
Unfortunately, if you are at this point, the only solution is nuclear - wipe the entire certstore and start over. Before moving forwards however, be sure to back up your certs & keys.</p>
Backing up keys & certs</a>
</h2>
First, export your full keys, as they are also listed in the cert output. List them with:</p>
sq</span> key</span> list</span></span></code></pre>
and then export them with:</p>
sq</span> key</span> export</span> -</span>-cert</span> KEYFINGERPRINT</span> -</span>-output</span> examplename.key.asc</span></span></code></pre>
Next, export any certs that you want to keep and re-import. List them with:</p>
sq</span> cert</span> list</span></span></code></pre>
and export with</p>
sq</span> cert</span> export</span> -</span>-cert</span> KEYFINGERPRINT</span> -</span>-output</span> examplename.cert.asc</span></span></code></pre>
The original documentation for these steps can be found here:</p>

Exporting Keys</a></li>
Exporting Certs</a></li>
</ul>
Wiping everything</a>
</h2>
To find where Sequoia-PGP is storing its configurations, run:</p>
sq</span> config</span> inspect</span> paths</span></span></code></pre>
On macOS, these will be in an entirely different location than indicated in the documentation</a>.</p>
Certificate Store:</p>
/Users/YOURUSERNAME/Library/Application Support/pgp.cert.d</span></span></code></pre>
Keystore:</p>
/Users/YOURUSERNAME/Library/Application Support/org.Sequoia-PGP.sequoia/keystore</span></span></code></pre>
Navigate to these directories and delete everything. You can confirm that this worked by running sq cert list</code> and sq key list</code> - no keys or certificates should show up.</p>
Note: if you have GNUPG set up, Sequoia-PGP will automatically pick up keys in the ~/.gnupd/</code> directory</em></p>
Re-import keys & certs</a>
</h2>
Importing is straightforwards:</p>
sq</span> key</span> import</span> examplename.key.asc</span></span>
sq</span> cert</span> import</span> examplename.cert.asc</span></span></code></pre>Workaround</a>
</h2>
A clunky workaround that was proposed in the above GitLab issue was creating a temporary configuration directory. By setting the SEQUOIA_HOME</code> variable to this temporary directory (eg., with export SEQUOIA_HOME=$HOME/.tmp-sequoia-data</code>), you can delete the directory later.</p>
Ultimately however, this isn't a real solution to proper certificate management, so GnuPG will remain my default choice for now.</p>



Replacing macOS BSD utils with GNU coreutils
2026-03-14T17:35:40+00:00
By default, macOS is packaged with the BSD versions of many common CLI utilities such as grep</code>, sed</code>, awk</code>, and more. These are not the same ones that can be found on most Linux distributions, and the slight differences between them can be confusing when working with both systems at the same time.</p>
Thankfully, most of these can be installed through Homebrew. There are some caveats, but for the most part, they can be treated as a one-to-one replacement. The coreutils</code> package is commonly cited, but over time, I have compiled a larger list of other non-GNU utilities that can be replaced.</p>
Installation</a>
</h2>
The full list of default mac packages that I've replaced are:</p>
brew</span> install</span> \</span></span>
    coreutils</span> \</span></span>
    diffutils</span> \</span></span>
    findutils</span> \</span></span>
    man-db</span> \</span></span>
    gawk</span> \</span></span>
    gnu-sed</span> \</span></span>
    watch</span> \</span></span>
    grep</span> \</span></span>
    gzip</span> \</span></span>
    less</span> \</span></span>
    curl</span> \</span></span>
    wget</span> \</span></span>
    rsync</span> \</span></span>
    git</span> \</span></span>
    vim</span></span></code></pre>Configuration</a>
</h2>
Since the BSD and GNU utils have the same names, these new utils are usually installed with a g</code> prefix. Additionally, their manpages</code> may not be properly pointed to the installed application either. As a result, you'll have to redefine the PATH</code> and MANPATH</code> shell variables for a number of these tools.</p>
However, it may not be clear which ones are necessary to set. I will provide a full list of these paths below, but this is the strategy I followed to build it.</p>
First, I made sure there were no PATH</code> or MANPATH</code> variables set in my ~/.zshrc</code> or remaining ZSH environment. Then, I closed out all ZSH sessions that might exist in the user environment, including tmux</code> sessions and the terminal. Then, I reopened my terminal and echo</code>'d the path variables to get a clear list of the default paths that macOS uses:</p>
$</span> echo</span> $</span>PATH</span> |</span> tr</span> '</span>:</span>'</span> '</span>\n</span>'</span></span>
/opt/homebrew/bin</span></span>
/opt/homebrew/sbin</span></span>
/usr/local/bin</span></span>
/System/Cryptexes/App/usr/bin</span></span>
/usr/bin</span></span>
/bin</span></span>
/usr/sbin</span></span>
/sbin</span></span>
/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin</span></span>
/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin</span></span>
/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin</span></span>
/Applications/Ghostty.app/Contents/MacOS</span></span>
</span>
$</span> echo</span> $</span>MANPATH</span> |</span> tr</span> '</span>:</span>'</span> '</span>\n</span>'</span></span>
/usr/share/man</span></span>
/usr/local/share/man</span></span>
/Applications/Ghostty.app/Contents/Resources/ghostty/../man</span></span></code></pre>
Next, I added the PATH</code> for coreutils</code> that was recommended during installation. (You can also re-print the message by running brew info coreutils</code>):</p>
export</span> PATH</span>=</span>"</span>/opt/homebrew/opt/coreutils/libexec/gnubin:</span>$</span>PATH</span>"</span></span></code></pre>
The MANPATH</code> location usually follows 2 directory conventions. They are located under either:</p>
/opt/homebrew/opt/</span><APPLICATION</span> NAM</span>E</span>></span>/libexec/gnuman</span></span>
</span>
#</span> or</span></span>
</span>
/opt/homebrew/opt/</span><APPLICATION</span> NAM</span>E</span>></span>/share/man</span></span></code></pre>
For coreutils</code>, diffutils</code> and findutils</code>, the PATH</code> and MANPATH</code> values were fairly straightforward:</p>
#</span> coreutils</span></span>
export</span> PATH</span>=</span>"</span>/opt/homebrew/opt/coreutils/libexec/gnubin:</span>$</span>PATH</span>"</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/coreutils/libexec/gnuman:</span>$</span>MANPATH</span>"</span></span>
</span>
#</span> diffutils</span></span>
export</span> PATH</span>=</span>"</span>/opt/homebrew/opt/diffutils/bin:</span>$</span>PATH</span>"</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/diffutils/share/man:</span>$</span>MANPATH</span>"</span></span>
</span>
#</span> findutils</span></span>
export</span> PATH</span>=</span>"</span>/opt/homebrew/opt/findutils/libexec/gnubin:</span>$</span>PATH</span>"</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/findutils/libexec/gnuman:</span>$</span>MANPATH</span>"</span></span></code></pre>
The other applications are not as clear. I first added man</code>, following the guide here</a>.</p>
#</span> man</span></span>
export</span> PATH</span>=</span>"</span>/opt/homebrew/opt/man-db/libexec/bin:</span>$</span>PATH</span>"</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/man-db/libexec/man:</span>$</span>MANPATH</span>"</span></span></code></pre>
This makes the next step simpler, which is to identify the default binary and manpath location. By running which <APPLICATION NAME></code> and man --path <APPLICATION NAME></code>, I can identify where they are located. Homebrew installs everything underneath /opt/homebrew/</code>, so if the path doesn't start there, then I know it needs to be reconfigured.</p>
In these three examples, awk</code> is not configured automatically at all, gzip</code> only has its binary in PATH</code>, and git</code> is automatically configured correctly for both its PATH</code> and MANPATH</code>:</p>
$</span> which</span> awk</span> &&</span> man</span> -</span>-path</span> awk</span></span>
/usr/bin/awk</span></span>
/usr/share/man/man1/awk.1</span></span>
</span>
$</span> which</span> gzip</span> &&</span> man</span> -</span>-path</span> gzip</span></span>
/opt/homebrew/bin/gzip</span></span>
/usr/share/man/man1/gunzip.1</span></span>
</span>
$</span> which</span> git</span> &&</span> man</span> -</span>-path</span> git</span></span>
/opt/homebrew/bin/git</span></span>
/opt/homebrew/Cellar/git/2.53.0/share/man/man1/git.1</span></span></code></pre>
The remaining list of values that need to be configured after man</code> are:</p>
#</span> awk</span></span>
export</span> PATH</span>=</span>"</span>/opt/homebrew/opt/gawk/libexec/gnubin:</span>$</span>PATH</span>"</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/gawk/libexec/gnuman:</span>$</span>MANPATH</span>"</span></span>
</span>
#</span> sed</span></span>
export</span> PATH</span>=</span>"</span>/opt/homebrew/opt/gnu-sed/libexec/gnubin:</span>$</span>PATH</span>"</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/gnu-sed/libexec/gnuman:</span>$</span>MANPATH</span>"</span></span>
</span>
#</span> grep</span></span>
export</span> PATH</span>=</span>"</span>/opt/homebrew/opt/grep/libexec/gnubin:</span>$</span>PATH</span>"</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/grep/libexec/gnuman:</span>$</span>MANPATH</span>"</span></span>
</span>
#</span> curl</span></span>
export</span> PATH</span>=</span>"</span>/opt/homebrew/opt/curl/bin:</span>$</span>PATH</span>"</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/curl/share/man:</span>$</span>MANPATH</span>"</span></span>
</span>
#</span> gzip</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/gzip/share/man:</span>$</span>MANPATH</span>"</span></span>
</span>
#</span> less</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/less/share/man:</span>$</span>MANPATH</span>"</span></span>
</span>
#</span> rsync</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/rsync/share/man:</span>$</span>MANPATH</span>"</span></span>
</span>
#</span> vim</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/vim/share/man:</span>$</span>MANPATH</span>"</span></span></code></pre>
For logical separation, I place all of these configurations in a file called gnu-coreutils.sh</code>, and source it in ~/.zshrc</code>:</p>
#</span> GNU coreutils, diffutils and findutils</span></span>
#</span> coreutils</span></span>
export</span> PATH</span>=</span>"</span>/opt/homebrew/opt/coreutils/libexec/gnubin:</span>$</span>PATH</span>"</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/coreutils/libexec/gnuman:</span>$</span>MANPATH</span>"</span></span>
</span>
#</span> diffutils</span></span>
export</span> PATH</span>=</span>"</span>/opt/homebrew/opt/diffutils/bin:</span>$</span>PATH</span>"</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/diffutils/share/man:</span>$</span>MANPATH</span>"</span></span>
</span>
#</span> findutils</span></span>
export</span> PATH</span>=</span>"</span>/opt/homebrew/opt/findutils/libexec/gnubin:</span>$</span>PATH</span>"</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/findutils/libexec/gnuman:</span>$</span>MANPATH</span>"</span></span>
</span>
</span>
#</span> Other CLI tools either installed with `g` prefix, or not under /opt/homebrew/bin</span></span>
#</span> man</span></span>
export</span> PATH</span>=</span>"</span>/opt/homebrew/opt/man-db/libexec/bin:</span>$</span>PATH</span>"</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/man-db/libexec/man:</span>$</span>MANPATH</span>"</span></span>
</span>
#</span> awk</span></span>
export</span> PATH</span>=</span>"</span>/opt/homebrew/opt/gawk/libexec/gnubin:</span>$</span>PATH</span>"</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/gawk/libexec/gnuman:</span>$</span>MANPATH</span>"</span></span>
</span>
#</span> sed</span></span>
export</span> PATH</span>=</span>"</span>/opt/homebrew/opt/gnu-sed/libexec/gnubin:</span>$</span>PATH</span>"</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/gnu-sed/libexec/gnuman:</span>$</span>MANPATH</span>"</span></span>
</span>
#</span> grep</span></span>
export</span> PATH</span>=</span>"</span>/opt/homebrew/opt/grep/libexec/gnubin:</span>$</span>PATH</span>"</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/grep/libexec/gnuman:</span>$</span>MANPATH</span>"</span></span>
</span>
#</span> curl</span></span>
export</span> PATH</span>=</span>"</span>/opt/homebrew/opt/curl/bin:</span>$</span>PATH</span>"</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/curl/share/man:</span>$</span>MANPATH</span>"</span></span>
</span>
</span>
#</span> CLI tools that already exist under /opt/homebrew/bin but don't</span></span>
#</span> have their manpath correctly updated</span></span>
#</span> gzip</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/gzip/share/man:</span>$</span>MANPATH</span>"</span></span>
</span>
#</span> less</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/less/share/man:</span>$</span>MANPATH</span>"</span></span>
</span>
#</span> rsync</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/rsync/share/man:</span>$</span>MANPATH</span>"</span></span>
</span>
#</span> vim</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/vim/share/man:</span>$</span>MANPATH</span>"</span></span></code></pre>Exclusions</a>
</h2>
There are some notable exclusions from this list of programs. Specifically, openssh</code>, unzip</code> and tar</code>. The reason for this is that the default versions bundled with macOS have been modified to recognize macOS-specific extended attributes/additional functionality, which the GNU versions do not recognize.</p>
For example, the coreutils</code> tools mv</code> and cp</code> tools do not preserve tags</a>. unzip</code> and tar</code> also reportedly do not recognize macOS metadata</a>. I've found that the bundled OpenSSH has a configuration option UseKeychain</code> that can cache your SSH key in macOS's Keychain.</p>
There may be many more examples, but these are the only ones I am aware of. I have re-aliased mv</code> & cp</code>, and haven't updated the PATH</code>/MANPATH</code> for unzip</code> and gnu-tar</code>:</p>
#</span>...</span></span>
alias</span> mv</span>=</span>"</span>/bin/mv</span>"</span></span>
alias</span> cp</span>=</span>"</span>/bin/cp</span>"</span></span>
#</span>...</span></span></code></pre>
I also haven't found a reason to replace the bundled zsh</code> as of yet.</p>

Resources</a>
</h2>

Older guide for installing coreutils</code></a></li>
Stackexchange guide for installing coreutils</code></a></li>
Warning regarding tag preservation failure</a></li>
Good guide on ZSH configuration for macOS</a></li>
</ul>


Minimally functional ZSH config for servers
2026-02-28T22:27:37+00:00
As I set up servers, I have a fairly minimal ZSH configuration I like to deploy to keep consistent behavior across all systems. A number of these tweaks make the shell much more usable and modify inconvenient defaults.</p>
ZSH has a massive list of options that can be modified, so for logical clarity, I will be grouping my configs below based on the manpages</code> where you can find them. This will make it easier to reference them and find related commands if needed. (If you need a quick refresher on using manpages</code>, I have written up a guide right here</a>)</p>
Jump to the complete ~/.zshrc</code> config here</a></em></p>
zshparam</code></a>
</h2>
ZSH parameters (man zshparam</code>) are the variables that can be set to configure ZSH defaults. I set a default HISTFILE</code> filename of ~/.zsh_history</code> that follows the same convention as Bash's ~/.bash_history</code>.</p>
I also set a generous HISTSIZE</code> of 10 million lines to save in memory, and set SAVEHIST</code> to the same value for the number of lines in the history file:</p>
HISTFILE</span>=</span>~</span>/</span>.</span>z</span>s</span>h</span>_</span>h</span>i</span>s</span>t</span>o</span>r</span>y</span></span>
HISTSIZE</span>=</span>1</span>0</span>0</span>0</span>0</span>0</span>0</span>0</span></span>
SAVEHIST</span>=</span>$</span>HISTSIZE</span></span></code></pre>
The KEYTIMEOUT</code> is set to 1 (10ms) to minimize the ESC</code> delay in the shell. I have another post that elaborates on this issue</a>:</p>
KEYTIMEOUT</span>=</span>1</span></span></code></pre>zshoptions</code></a>
</h2>
ZSH options (man zshoptions</code>) are toggles that can be flipped to modify default ZSH behavior. I adjust these to provide a better shell history experience.</p>
The first option ensures that every single shell instance immediately writes to ~/.zsh_history</code> as commands are typed. This ensures that I never lose a command, or that they get written in blocks as the shell exits as opposed to chronological order.</p>
An important point to note is that this doesn't update the in-memory history of each shell session. Thus, scrolling through the history with either the arrow keys or CTRL+r</code> means that the history still looks contiguous per-shell. New shell sessions will have the entire history loaded in chronological order, as they were typed:</p>
setopt</span> INC_APPEND_HISTORY_TIME</span></span></code></pre>
This next option ensures the history also captures the instant timestamp (format: :start:elapsed;command</code>) of when a command was run, and for how long:</p>
setopt</span> EXTENDED_HISTORY</span></span></code></pre>
These next two options are for search convenience. The first doesn't display duplicate lines while searching (with the up arrow or CTRL+r</code>), and the second option strips out unecessary spaces between commands (eg,. if you accidentally double-tapped the spacebar):</p>
setopt</span> HIST_FIND_NO_DUPS</span></span>
setopt</span> HIST_REDUCE_BLANKS</span></span></code></pre>
This next option allows you to deliberately exclude a specific command from being written to ZSH history by typing a space first. This is especially useful when specifying passwords or secret keys in environment variables before a command, so that it doesn't get recorded in shell history. Note that it is temporarily saved in-memory until the next command is entered, so that you can use the up arrow to edit the command & re-run it:</p>
setopt</span> HIST_IGNORE_SPACE</span></span></code></pre>
This is a simple command that automatically expands !!</code> into the previous command after you type a space. The advantage is better visibility into exactly what command you are re-running, which is a nice safeguard especially when typing sudo !!</code>:</p>
setopt</span> BANG_HIST</span></span></code></pre>
This last option disables a particularly annoying behavior: when using unquoted URLs in the shell (such as with curl</code> or wget</code>), certain common characters in the URL are the same ones that the shell uses for glob matching, such as ?</code>. While Bash silently ignores it, ZSH fails the command with an error; unsetting the option causes ZSH to behave like Bash:</p>
unsetopt</span> NOMATCH</span></span></code></pre>zshcompsys</code>, zshcontrib</code>, zshbuiltins</code></a>
</h2>
These are a collection of smaller functions that allow for advanced functionality in ZSH.</p>
ZSH has a completion system (man zshcompsys</code>) that allows for autocompletion of many command-line flags, options, and more. ZSH creates a dumped (cached) configuration file under ~/.zcompdump</code> that gets intelligently updated as CLI programs are upgraded:</p>
autoload</span> -</span>U</span> compinit</span>;</span> compinit</span></span></code></pre>
To navigate quickly over CLI options, I frequently use Control/Alt</code> to jump between words quickly instead of scrolling character-by-character. Bash only considers alphanumeric sequences of characters as words, so to mimic this in ZSH, set the word-style as Bash (man zshcontrib</code>, ZLE FUNCTIONS</code> section) with:</p>
autoload</span> -</span>U</span> select-word-style</span>;</span> select-word-style bash</span></span></code></pre>
ZSH builtins (man zshbuiltins</code>) are additional commands, bundled with ZSH, that expand on the functionality of the shell. One of these functions is the command fc</code>, which controls various aspects of the shell history.</p>
I can never remember this command name, so I alias 2 of the most useful functions to more memorable commands.</p>
zread</code> will instantly update the current shell's in-memory history with the ~/.zsh_history</code> file (which is being written to in realtime). I use this when I want to update command history from another open shell session into the current one (a common occurrence when I have multiple shells open in tmux</code>).</p>
zhist</code> is a quick way to preview the last few commands (globally, from ~/.zsh_history</code>) with the exact date-timestamps they were executed. By default, it only lists the last 10 commands. If a negative number is specified afterwards (eg., zhist -32</code>), it displays the last X number of lines.</p>
alias</span> zread</span>=</span>'</span>fc -R</span>'</span></span>
alias</span> zhist</span>=</span>'</span>fc -lni</span>'</span></span></code></pre>systemd</code> bonus</a>
</h2>
systemd</code> sets some frustrating options when the less</code> pager is called (by default, the full list of options passed to less</code> are: FRSXMK</code> (found in man systemctl</code>)).</p>
These two options are:</p>


S</code> This automatically chops lines that are wider than the terminal width instead of wrapping them. As a result, you have to start scrolling first right and then left to trigger the less</code> pager and read the entire line.</p>
</li>

X</code>: This prevents the terminal from restoring its previous view after you've exited the pager. This means that output from commands such as journalctl</code> completely fill up the terminal with lingering output.</p>
</li>
</ul>
By removing both of these options, you can have a more friendly default:</p>
export</span> SYSTEMD_LESS</span>=</span>'</span>FRMK</span>'</span></span></code></pre>Fedora double bonus</a>
</h2>
When I exited an ssh</code> session from my Fedora servers, it would clear the entire terminal pane. I didn't like this, since sometimes I was just jumping in to check a quick config option and this would reset my viewport.</p>
After some digging, I found that Fedora sets a default zlogout</code> in /etc/zlogout</code> that gets called every time I exit an ssh</code> session. I simply commented out the following line to disable the behavior:</p>
#</span>command -v clear &> /dev/null && clear</span></span></code></pre>
Alternatively, if you only want to disable this behavior for a single user, you can add the following to the local user's ~/.zlogout</code>:</p>
setop</span> norcs</span></span></code></pre>Full ZSH config</a>
</h2>
Here is the full ~/.zshrc</code> config file, annotated with short comments:</p>
#</span> zsh configuration</span></span>
#</span></span>
#</span> man zshparam</span></span>
HISTFILE</span>=</span>~</span>/</span>.</span>z</span>s</span>h</span>_</span>h</span>i</span>s</span>t</span>o</span>r</span>y</span>         #</span> history file</span></span>
HISTSIZE</span>=</span>1</span>0</span>0</span>0</span>0</span>0</span>0</span>0</span>               #</span> in-memory history</span></span>
SAVEHIST</span>=</span>$</span>HISTSIZE</span>              #</span> history file size</span></span>
KEYTIMEOUT</span>=</span>1</span>                    #</span> 10ms delay for key sequences</span></span>
#</span> man zshoptions</span></span>
setopt</span> INC_APPEND_HISTORY_TIME</span>  #</span> write history immediately, not when shell exits</span></span>
setopt</span> EXTENDED_HISTORY</span>         #</span> history format: ":start:elapsed;command"</span></span>
setopt</span> HIST_FIND_NO_DUPS</span>        #</span> don't display duplicate lines when searching</span></span>
setopt</span> HIST_REDUCE_BLANKS</span>       #</span> remove superfluous blanks</span></span>
setopt</span> HIST_IGNORE_SPACE</span>        #</span> don't save lines that start with a space</span></span>
setopt</span> BANG_HIST</span>                #</span> automatically expand !! after typing a space</span></span>
unsetopt</span> NOMATCH</span>                #</span> allow typing URLs without quoting them</span></span>
#</span> man zshcompsys, zshcontrib, zshbuiltins</span></span>
autoload</span> -</span>U</span> compinit</span>;</span> compinit</span>  #</span> initialize zsh completion</span></span>
autoload</span> -</span>U</span> select-word-style</span>;</span> select-word-style bash</span>   #</span> bash-style word jumping</span></span>
alias</span> zread</span>=</span>'</span>fc -R</span>'</span>             #</span> read latest shell history from file into memory</span></span>
alias</span> zhist</span>=</span>'</span>fc -lni</span>'</span>           #</span> list last 10 historical commands (zhist -<number> for more)</span></span>
</span>
#</span> remove 'X' and 'S' options</span></span>
export</span> SYSTEMD_LESS</span>=</span>'</span>FRMK</span>'</span></span></code></pre>

Resources</a>
</h2>

Good StackExchange reference for many of these options</a></li>
Manpage guide</a></li>
Escape Delay post</a></li>
StackExchange post to disable zlogout</code> behavior</a></li>
</ul>


Switching Fedora bootloader to systemd-boot
2026-02-22T12:30:03+00:00
The current default bootloader for Fedora 43 is still GRUB</code>, and I wanted to switch over to the native systemd bootloader systemd-boot</code>. However, it was somewhat of a challenge to find clear instructions for this process, so I'll step through them here.</p>
This guide only shows how to set up systemd-boot</code> on a fresh Fedora 43 install, since I had challenges trying to switch from GRUB</code> post-installation.</p>
Note</em>: Ironically, this method is broken specifically for Fedora 43</a>. A fix has been merged</a> into the upcoming Fedora 44 release.</p>
Before you even boot into the Fedora ISO of your choosing, the GRUB</code> bootloader will flash:</p>
</p>
Before the 60s timer runs out, use the arrow keys to select the installation and press e</code> to enter an Emacs-like editor:</p>
</p>
The editor will show the current boot parameters that are being used to boot into the specified ISO.</p>
Now, enter the text inst.sdboot</code> after the second line, linuxefi /images/pxeboot/vmlinuz </code>:</p>
</p>
Type Ctrl+x</code> to save & boot with the modified boot parameters, and you'll be good to start your OS installation!</p>
</p>

Resources</a>
</h2>

Fedora instructions for testing systemd-boot</code></a></li>
Arch Wiki entry for further information on systemd-boot</code></a></li>
</ul>


Quick aside on AI usage
2026-02-17T18:23:47+00:00
It seems that with the ubiquity of AI and its potential to disrupt so many fields, just about every blog has a take on its future. However, this is not what this post will be about.</p>
Rather, I'd like this to be more of a general disclaimer that, to date, in any of the work I do in the public/open source domain, I don't use AI to:</p>

Write any blog posts</li>
Generate or create any code</li>
Research any topics (including search engine summaries)</li>
</ul>
This isn't for ideological issues, but moreso that I genuinely enjoy the essence of the work I do. Using AI to replace myself in the loop feels like using an exoskeleton to lift weights, or an e-bike to cycle. I have also felt the frustration of becoming deeply engrossed in some technical article, only to eventually realize it isn't saying anything meaningful and was AI-generated (or heavily assisted).</p>
If at any point I change this approach, I'll be sure to clearly annotate it, either in my posts or in my code.</p>


man man
2026-02-16T20:09:59+00:00
Manpages are something I've often underutilized, despite how useful they are. After spending some time researching them further, here are some takeaways and modifications that significantly improve my usage.</p>
Using the pager</a>
</h2>
By default, man</code> uses the less</code> pager</a> to display documentation as pages in your terminal. As a result, it uses a lot of Vi-style keyboard commands that allow you to move around while rarely shifting your hands from the f</code> and j</code> keys.</p>
A few of the most useful ones are:</p>

j</code> - scroll down a line</li>
k</code> - scroll up a line</li>
d</code> - scroll d</code>own half a page. Useful for keeping visual context while scrolling quicker.</li>
u</code> - scroll u</code>p half a page</li>
PageUp/PageDown</code>, b/<SPACE></code> keys - scrolls up/down an entire 'page' of content. While fast, I find it harder to visually track content.</li>
</ul>
The most common searches can be done with:</p>

/</code> - search downwards in the manpage: /searchpattern<ENTER></code></li>
?</code> - search upwards in the manpage: ?searchpattern<ENTER></code></li>
n</code> - jump to the n</code>ext search result</li>
N</code> - jump to the previous search result. SHIFT+n</code>, the reverse action of n</code>, is a common pattern in Vi commands.</li>
g</code> - g</code>o to the bottom of the manpage</li>
G</code> - G</code>o to the top of the manpage. This used to be the way I restarted a new search from the top.*</li>
</ul>
*this is technically an anti-pattern that I picked up. Typing a /</code> followed by <CTRL>f</code> automatically jumps to the top of the page to restart the search while transforming your prompt to look like this:</p>
First-file /searchpattern<ENTER></code></p>
</p>
Continuing in the vein of more advanced search tricks, a few more are:</p>

/<CTRL>k</code> - show search results in the currently displayed screen area without moving</li>
/<CTRL>w</code> - wrap your search around to restart at the opposite end of the page</li>
/<CTRL>r</code> - disable the automatic regex when searching (searching in reverse would be ?<CTRL>r</code>)</li>
</ul>
The search line automatically uses regex, so special charaters such as ^</code> (start of line) will need to be escaped with a \</code> to be read literally; eg., /\^F<ENTER></code> to search for the literal characters '^F'.</p>
To escape out of any of these prompts, use backspace to reset the search line (instead of frantically hitting q</code> and Escape</code> like I often do ;) )</p>
Customizing the pager</a>
</h2>
As nice as the above commands are, there are a few command line flags you can pass to less</code> to make it play better and avoid using so many of them:</p>

--ignore-case</code> - by default, less</code> is case-sensitive. This ignores case, unless</em> you begin typing uppercase letters.</li>
--use-color</code> - colorizes various elements, including the status bar and search results</li>
--wordwrap</code> - wraps words as they reach the right side of the terminal instead of hyphenating them. This avoid words being split with a hypen (-</code>)</li>
--status-line</code> - highlights the entire line that has a mark</code>. Marks are covered below.</li>
</ul>
The full list of flags to export</code> for the MANPAGER</code> variable is:</p>
export</span> MANPAGER</span>=</span>"</span>less --ignore-case --use-color --wordwrap --status-line --lesskey-src=</span>$</span>HOME</span>/.manpage-lesskey</span>"</span></span></code></pre>
The last two flags are covered in the next two sections respectively:</p>
Advanced usage with marks</a>
</h2>
A common problem I had when using very large manpages for tools like tmux</code> was that I was constantly re-searching flags or keywords to check multiple sections (sometimes even opening up 2 tmux</code> manpages).</p>
However it turns out that you can 'bookmark</code>' sections of the manpage and jump between them! The process to do this is a little convoluted, but I've found it useful once I committed it to memory.</p>
Assuming you have already found a position you would like to (book)mark</code>:</p>

First, type m</code> followed by an upper- or lower-case letter: ma</code>. If you enabled the --status-line</code> flag above, the top line in your pager will be highlighted.</li>
Now, continue to another section of the manpage however you'd like (scrolling or through search)</li>
Then, mark</code> this new section with a different letter: mb</code></li>
Continue however many times as needed...</li>
To jump to a mark</code>, type a single apostrophe '</code> (right of ;</code> on keyboard) and the letter you used: 'a</code></li>
</ol>
While I initially tried to use letters that made sense for the current section, I found that it was too much mental overhead. Instead, I pick the next sequential letter in the alphabet.</p>
There is more you can do with marks, but I haven't found them particularly helpful:</p>

''</code> - jump to last position (often the top of the page). This doesn't seem to jump between marks though, which is unfortunate.</li>
M</code> - add a mark to the bottom of the page instead</li>
<ESC>ma</code> - clears the mark a</code></li>
--save‐marks</code> - when specified in the less</code> options, this saves the marks even when you close the file</li>
</ul>
Searching CLI flags</a>
</h2>
This following configuration has become invaluable for me on a daily basis. I find myself constantly searching for CLI flags (eg., -f</code>) and getting results somewhere in the middle of an explanation section instead of the actual flag. A user on StackOverflow provided an excellent solution</a> to this problem.</p>
The magic is a lesskey</code> configuration that jumps to the top of the file and auto-inserts a regex string:</p>
#</span>command</span></span>
\eF</span> forw-search</span> (</span>\^</span>\\</span>s</span>\+</span>-</span>|</span>,</span> -</span>)-</span>?</span></span>
\ef</span> noaction</span> g</span>\e</span>F</span></span></code></pre>
By adding this to the file ~/.manpage-lesskey</code> and using the flag --lesskey-src=$HOME/.manpage-lesskey</code> as above, you can enable this feature only on manpages and not anytime you open less</code>. ($HOME</code> is required because man</code> cannot interpret ~</code>)</p>
To use this, type ⌥f</code> (Option+f) or <ALT>f</code>. You'll immediately jump to the top of the manpage and the following prompt will appear in your search bar:</p>
/(^\s+-|, -)-?</code></p>
Type the flag letter or the name of the full flag, eg., s</code> or case</code> - there's no need to prepend the dash -</code> - and hit <ENTER></code> to jump to the definition.</p>
Searching everything man</code></a>
</h2>
To do a full text search of all manpages, use the -K</code>/--global-apropos</code> flag:</p>
man -K searchpattern</code></p>
However, this immediately opens up the manpage of the first search result, and when you exit with q</code>, it prompts you to:</p>
[ view (return) | skip (Ctrl-D) | quit (Ctrl-C) ]</code></p>
for every single entry, one at a time, looking like this:</p>
</p>
A bit inconvenient, so I may find a workaround eventually.</p>
tldr</code></a>
</h2>
Despite all the above, sometimes you don't want to trawl through a manpage for minutes to piece together a comprehensive command, flag-by-flag. In that case, the tldr</code> project</a> gives you a short synopsis and a list of example commands instead.</p>
</p>
While the front page instructions recommend installing it through npm</code>, thankfully there's a client written in Rust called tlrc</code></a>. It's available through Homebrew with brew install tlrc</code> (be sure to update the tldr</code> database with a tldr -u</code> before using).</p>
manpages</code> on macOS</a>
</h2>
If you've noticed that your man</code> does not have a status prompt at the bottom of your terminal, it's likely that you're using the bundled version of man</code> on macOS.</p>
Bundled:</p>
</p>
Modern:</p>
</p>
The default version of man</code> installed on macOS is frequently out of date and based on BSD. The more modern implementation that is normally seen on Linux machines is not man</code>, but another implementation called man-db</code></a>.</p>
Installation can be done through Homebrew</a>:</p>
brew</span> install</span> man-db</span></span></code></pre>
However, this will be installed as gman</code> to avoid breaking compatibilty with your default installation of  man</code>. To make it your default, export the path & its manpath in your shell configuration file, eg., ~/.zshrc</code>:</p>
export</span> PATH</span>=</span>"</span>/opt/homebrew/opt/man-db/libexec/bin:</span>$</span>PATH</span>"</span></span>
export</span> MANPATH</span>=</span>"</span>/opt/homebrew/opt/man-db/libexec/man:</span>$</span>MANPATH</span>"</span></span></code></pre>Strange bugs with hyphens</a>
</h2>
While trying to search flags with hyphens, I was confused why less</code> refused to match them especially if they were between letters. After some digging around, this StackOverflow post</a> revealed the issue: the manpages on my mac are being rendered with non-ASCII characters.</p>
I could validate this by running the following command:</p>
LC_COLLATE</span>=</span>C</span> LESS</span>=</span>'</span>+/[^ -~]</span>'</span> man</span> rsync</span></span></code></pre>
</p>
Every single highlight is a non-ASCII character.</p>
While a bit inelegant, I re-aliased man</code> such that it forces it to use an ASCII character set, as specified in the post:</p>
alias</span> man</span>=</span>"</span>LC_CTYPE=C man</span>"</span></span></code></pre>

Resources</a>
</h2>

ManKier: Search manpages translated to HTML5</a></li>
man-db</code> homepage</a></li>
BSD man</code> vs. man-db</code></a></li>
Excellent deep-dive into manpages</a></li>
</ul>


Vim encoding/decoding base64 in Kubernetes secrets
2025-08-09T21:54:21+00:00
Kubernetes provides the ability to edit secrets from the command line, but there's a catch: they're encoded with base64 and kubectl</code> provides no way to encode/decode it.</p>
There are several solutions online to this problem, often involving installing another tool. However, vim can do this with the help of the base64</code> binary commonly found on Linux systems.</p>
The following solution is based on this StackOverflow post</a>, but with a critical modification to fix unintended behavior.</p>
echo</code> decode in Command Mode</a>
</h2>
These commands rely on using Visual selection mode to select a block of text that should be encoded or decoded.</p>
This first configuration entry, which can be added in ~/.vimrc</code>, only decodes the selected text in Visual mode and prints it into the Command Mode line at the bottom of the vim editor:</p>
vnoremap</span> <</span>leader</span>></span>64</span> y:</span>echo</span> system</span>(</span>'</span>base64 --wrap=0 --decode</span>'</span>,</span> @</span>"</span>)<cr></span></span></code></pre>
After making a visual selection, type \</code> quickly followed by 64</code> to print the base64 decoded line. The 'quickly' is because \</code>, known as the 'leader', is a special character used to prefix these kinds of custom mappings and has a timeout of 1 second.</p>
This can be extended by setting the timeoutlen</code> variable in vim, but be sure to utilize the ttimeoutlen</code> variable so pressing ESC does not also use the same delay. This post</a> dives into this further.</p>
The --wrap=0</code> is very important because by default, base64</code> wraps to 76 characters - that flag will disable this behavior.</p>
Decode inline</a>
</h2>
This configuration line does the same as above, but actually modifies the text inline in the vim editor:</p>
vnoremap</span> <</span>leader</span>></span>d64 c</span><</span>c-r</span>></span>=</span>system</span>(</span>'</span>base64 --wrap=0 --decode</span>'</span>,</span> @</span>"</span>)<cr><esc></span></span></code></pre>
Use this by typing \</code> followed by d64</code> (decode 64).</p>
Encode inline</a>
</h2>
After making modifications to a secret, it should be re-encoded. This following configuration entry allows for re-encoding a block of visually selected text inline in the vim editor:</p>
vnoremap</span> <</span>leader</span>></span>e64 c</span><</span>c-r</span>></span>=</span>system</span>(</span>'</span>base64 --wrap=0</span>'</span>,</span> @</span>"</span>)<cr><esc></span></span></code></pre>
Use this by typing \</code> followed by e64</code> (encode 64)</p>
Correctly selecting text in Visual Mode</a>
</h2>
It might make sense to start Visual selection mode and select an entire line of text to the end with v$</code>. However, this would be a mistake since it also</em> selects the newline character \n</code>.</p>
Instead, to select to the end without the newline, type: vg_</code></p>
Alternatively if the cursor is already at the end of the line, the reverse selection up to (but not including) the first space character can be done with v + SHIFT t + SPACE (vT </code>).</p>

Resources</a>
</h2>

Reference StackOverflow post</a></li>
Excellent resource for creating vim mappings</a></li>
</ul>


ZFS local replication with systemd units + timers
2025-07-09T19:39:21+00:00
Following up the previous post on creating rolling ZFS snapshots with systemd units & timers</a>, this entry will cover continuous replication of these snapshots to another pool on the same host, using the same strategy.</p>
Unit file</a>
</h2>
The unit file relies on snapshots having a consistent naming scheme. The names here are the ones defined in the the previous post:</p>
autosnapshot-7-days-ago</span></span>
autosnapshot-6-days-ago</span></span>
...</span></span>
autosnapshot-1-day-ago</span></span></code></pre>
Unlike the autosnapshot unit file however, this is not initialized with the pool name as an instance variable. This is because there are 2 variables: the source pool and the target pool, which would necessitate some implicit functionality - they are both defined as environment variables in the unit file instead:</p>
[</span>Service</span>]</span></span>
...</span></span>
Environment</span>=</span>"</span>REPLICATION_SOURCE=pool-1/dataset2</span>"</span></span>
Environment</span>=</span>"</span>REPLICATION_TARGET=pool-2/backups/pool-1/dataset2</span>"</span></span>
...</span></span></code></pre>
This unit file handles rotating the snapshots on the replication target. This could be adjusted to save a different number of snapshots, but for consistency, it will match the strategy used in the autosnapshot unit file.</p>
Lastly, the replication command needs to be wrapped in a /usr/bin/sh -c "..."</code> statement since the ZFS CLI requires a unix pipe to send/receive and has no alternative. The systemd Exec* directives do not support pipes, so running it in a subshell is hacky but officially recommended (COMMAND LINES</code> section in the systemd.service(5)</code> manpage).</p>
[</span>Service</span>]</span></span>
...</span></span>
ExecStart</span>=</span>/usr/bin/sh -c </span>"</span>zfs send --raw --props -i @autosnapshot-2-days-ago ${REPLICATION_SOURCE}@autosnapshot-1-day-ago | zfs receive -Fv ${REPLICATION_TARGET}</span>"</span></span></code></pre>
The filename format of the unit file is:</p>
zfs-autoreplication-<dataset name>-<number of retained snapshots>-<frequency>.service</span></span></code></pre>zfs-autoreplication-dataset2-7-daily.service</code>:</a>
</h3>
[</span>Unit</span>]</span></span>
Description</span>=</span>Keep 7 rotating daily snapshots of pool-1/dataset2 replicated to pool-2</span></span>
Requires</span>=</span>zfs.target</span></span>
After</span>=</span>zfs.target</span></span>
ConditionACPower</span>=</span>true</span></span>
ConditionPathIsDirectory</span>=</span>/sys/module/zfs</span></span>
ConditionPathExists</span>=</span>!/home/gadget/pause-replications</span></span>
</span>
[</span>Service</span>]</span></span>
EnvironmentFile</span>=</span>-/etc/sysconfig/zfs</span></span>
Type</span>=</span>exec</span></span>
Environment</span>=</span>"</span>REPLICATION_SOURCE=pool-1/dataset2</span>"</span></span>
Environment</span>=</span>"</span>REPLICATION_TARGET=pool-2/backups/pool-1/dataset2</span>"</span></span>
ExecStartPre</span>=</span>-/sbin/zfs destroy ${REPLICATION_TARGET}@autosnapshot-7-days-ago</span></span>
ExecStartPre</span>=</span>-/sbin/zfs rename ${REPLICATION_TARGET}@autosnapshot-6-days-ago ${REPLICATION_TARGET}@autosnapshot-7-days-ago</span></span>
ExecStartPre</span>=</span>-/sbin/zfs rename ${REPLICATION_TARGET}@autosnapshot-5-days-ago ${REPLICATION_TARGET}@autosnapshot-6-days-ago</span></span>
ExecStartPre</span>=</span>-/sbin/zfs rename ${REPLICATION_TARGET}@autosnapshot-4-days-ago ${REPLICATION_TARGET}@autosnapshot-5-days-ago</span></span>
ExecStartPre</span>=</span>-/sbin/zfs rename ${REPLICATION_TARGET}@autosnapshot-3-days-ago ${REPLICATION_TARGET}@autosnapshot-4-days-ago</span></span>
ExecStartPre</span>=</span>-/sbin/zfs rename ${REPLICATION_TARGET}@autosnapshot-2-days-ago ${REPLICATION_TARGET}@autosnapshot-3-days-ago</span></span>
ExecStartPre</span>=</span>-/sbin/zfs rename ${REPLICATION_TARGET}@autosnapshot-1-day-ago ${REPLICATION_TARGET}@autosnapshot-2-days-ago</span></span>
ExecStart</span>=</span>/usr/bin/sh -c </span>"</span>zfs send --raw --props -i @autosnapshot-2-days-ago ${REPLICATION_SOURCE}@autosnapshot-1-day-ago | zfs receive -Fv ${REPLICATION_TARGET}</span>"</span></span></code></pre>Timer file</a>
</h2>
The timer is very simple. The OnCalendar</code> directive is set to 5 minutes after midnight, allowing the autosnapshot service plenty of time to complete first.</p>
zfs-autoreplication-dataset2-7-daily.timer</code>:</a>
</h3>
[</span>Unit</span>]</span></span>
Description</span>=</span>Keep 7 rotating daily snapshots of pool-1/dataset2 replicated to pool-2</span></span>
</span>
[</span>Timer</span>]</span></span>
OnCalendar</span>=</span>*-*-* 00:05:00</span></span>
Unit</span>=</span>zfs-autoreplication-dataset2-7-daily.service</span></span>
</span>
[</span>Install</span>]</span></span>
WantedBy</span>=</span>timers.target</span></span></code></pre>Enabling the service</a>
</h2>
Unlike the autosnapshot service, the autoreplication service requires some manual preliminary setup.</p>
First, the entire ZFS pool+dataset hierarchy needs to be created beforehand, except</em> for the actual dataset to be replicated. In this example, pool-1/dataset2</code> is being replicated to pool-2/backups/pool-1/dataset2</code>, so the path to create is pool-2/backups/pool-1</code>:</p>
sudo</span> zfs</span> create</span> -</span>p</span> pool-2/backups/pool-1</span></span></code></pre>
Next, send over the very first snapshot. In this case the dataset is encrypted, so the --raw</code> and --props</code> flags are used to send over the dataset exactly as it exists on disk with all of its custom properties:</p>
sudo</span> zfs</span> send</span> -</span>-raw</span> -</span>-props</span> pool-1/dataset2@autosnapshot-1-day-ago</span> |</span> zfs</span> receive</span> -</span>Fv</span> pool-2/backups/pool-1/dataset2@autosnapshot-1-day-ago</span></span></code></pre>
The reason for manually running this command is because it does not include the previous snapshot as an option (-i</code>) - something the unit file relies on.</p>
Finally, the autoreplication service + timer can be started:</p>
sudo</span> systemctl</span> enable</span> -</span>-now</span> zfs-autoreplication-dataset2-7-daily.timer</span></span></code></pre>



ZFS rolling snapshots with systemd units + timers
2025-07-06T19:49:33+00:00
As a copy-on-write filesystem, ZFS provides the capability to take snapshots. However, taking and managing them is completely manual, so maintaining a rolling list of snapshots requires either custom bash scripts + cron, installing external tools such as sanoid, or using an entire OS in the case of TrueNAS.</p>
However, this functionality can be easily achieved by utilizing systemd units and timers.</p>
Unit file</a>
</h2>
The goal of this unit file is to keep a week's worth of daily snapshots. Each snapshot is named in a way that is easily referenced:</p>
autosnapshot-7-days-ago</span></span>
autosnapshot-6-days-ago</span></span>
autosnapshot-5-days-ago</span></span>
autosnapshot-4-days-ago</span></span>
autosnapshot-3-days-ago</span></span>
autosnapshot-2-days-ago</span></span>
autosnapshot-1-day-ago</span></span></code></pre>
Since ZFS snapshots can be renamed, the strategy for rolling them is to delete the oldest one, rename all the subsequent ones, and take a new one.</p>
zfs</span> destroy</span> %I@autosnapshot-7-days-ago</span></span>
zfs</span> rename</span> %I@autosnapshot-6-days-ago</span> %I@autosnapshot-7-days-ago</span></span>
.</span>.</span>.</span></span>
zfs</span> snapshot</span> %I@autosnapshot-1-day-ago</span></span></code></pre>
Conveniently, systemd units have the ExecStartPre</code> directive in the [Service]</code> section, allowing for commands to be run before the actual target command., eg., the latest snapshot.</p>
Additionally, it is possible to prepend the entire command with a -</code>, which prevents the unit from failing if the command fails. This is great for a first-time run where none of the previous snapshots exist, causing the ZFS commands to fail.</p>
Finally, this unit file has the ability to pause snapshots instantly. This is done by requiring a specific path not</em> exist with a negated ConditionPathExists</code>:</p>
ConditionPathExists=!/home/gadget/pause-snapshots</span></span></code></pre>
Pausing is as simple as a touch ~/pause-snapshots</code>, and once the file is deleted, snapshots resume whenever the timer triggers the unit file again. This could even be used to pause multiple (or all) autosnapshots on a system if they are all pointed to the same file.</p>
The filename format of the unit file is:</p>
zfs-autosnapshot-<number of retained snapshots>-<frequency>@.service</span></span></code></pre>zfs-autosnapshot-7-daily@.service</code>:</a>
</h3>
[</span>Unit</span>]</span></span>
Description</span>=</span>Keep 7 rotating snapshots of %I daily</span></span>
Requires</span>=</span>zfs.target</span></span>
After</span>=</span>zfs.target</span></span>
ConditionACPower</span>=</span>true</span></span>
ConditionPathIsDirectory</span>=</span>/sys/module/zfs</span></span>
ConditionPathExists</span>=</span>!/home/gadget/pause-snapshots</span></span>
</span>
[</span>Service</span>]</span></span>
EnvironmentFile</span>=</span>-/etc/sysconfig/zfs</span></span>
Type</span>=</span>exec</span></span>
Restart</span>=</span>no</span></span>
ExecStartPre</span>=</span>-/sbin/zfs destroy %I@autosnapshot-7-days-ago</span></span>
ExecStartPre</span>=</span>-/sbin/zfs rename %I@autosnapshot-6-days-ago %I@autosnapshot-7-days-ago</span></span>
ExecStartPre</span>=</span>-/sbin/zfs rename %I@autosnapshot-5-days-ago %I@autosnapshot-6-days-ago</span></span>
ExecStartPre</span>=</span>-/sbin/zfs rename %I@autosnapshot-4-days-ago %I@autosnapshot-5-days-ago</span></span>
ExecStartPre</span>=</span>-/sbin/zfs rename %I@autosnapshot-3-days-ago %I@autosnapshot-4-days-ago</span></span>
ExecStartPre</span>=</span>-/sbin/zfs rename %I@autosnapshot-2-days-ago %I@autosnapshot-3-days-ago</span></span>
ExecStartPre</span>=</span>-/sbin/zfs rename %I@autosnapshot-1-day-ago %I@autosnapshot-2-days-ago</span></span>
ExecStart</span>=</span>/sbin/zfs snapshot %I@autosnapshot-1-day-ago</span></span></code></pre>
The remainder of the directives were taken from the zfs-scrub@.service</code> bundled along with the ZFS installation on Fedora 41. No [Install]</code> section is required since this unit file will be triggered by a timer.</p>
Timer file</a>
</h2>
The timer is even simpler, with the only customization being the OnCalendar</code> directive set to daily</code>:</p>
zfs-autosnapshot-7-daily@.timer</code>:</a>
</h3>
[</span>Unit</span>]</span></span>
Description</span>=</span>Keep 7 rotating snapshots of %I daily</span></span>
</span>
[</span>Timer</span>]</span></span>
OnCalendar</span>=</span>daily</span></span>
Unit</span>=</span>zfs-autosnapshot-7-daily@%i.service</span></span>
</span>
[</span>Install</span>]</span></span>
WantedBy</span>=</span>timers.target</span></span></code></pre>Enabling the service</a>
</h2>
There's a gotcha when trying to pass the full ZFS pool+dataset(s) path to the timer as an instance variable: a ZFS path contains invalid characters that can't be passed on the command line - namely, forward slashes and dashes (/</code>, -</code>).</p>
Luckily, systemd has a way to handle this: systemd-escape</code>, and the variables %i</code> and %I</code>.</p>
First, pass the full ZFS path to systemd-escape</code>:</p>
$</span> systemd-escape</span> "</span>pool-1/dataset2</span>"</span></span>
pool\x2d1-dataset2</span></span></code></pre>
This is the safely escaped ZFS path, and the timer can be enabled by using it:</p>
sudo</span> systemctl</span> enable</span> -</span>-now</span> '</span>zfs-autosnapshot-7-daily@pool\x2d1-dataset2.timer</span>'</span></span></code></pre>
Or in one command:</p>
sudo</span> systemctl</span> enable</span> -</span>-now</span> "</span>zfs-autosnapshot-7-daily@</span>$(</span>systemd-escape</span> '</span>pool-1/dataset2</span>'</span>)</span>.timer</span>"</span></span></code></pre>
The timer unit file will use %i</code> to enable the respective unit service file with the escaped string. However, the service will use the unescaped string with %I</code> to run the ZFS snapshot commands.</p>
The systemd timers can be listed with:</p>
systemctl</span> list-timers</span></span></code></pre>
And the snapshots, their creation dates, and the amount of space they use can be listed with:</p>
$</span> zfs</span> list</span> -</span>t</span> snapshot</span> -</span>o</span> name,creation,used</span></span>
NAME</span>                                                        CREATION</span>                USED</span></span>
pool-1/dataset2@autosnapshot-7-days-ago</span>                     Sun</span> Aug</span>  3</span>  0:00</span> 2025</span>     0B</span></span>
pool-1/dataset2@autosnapshot-6-days-ago</span>                     Mon</span> Aug</span>  4</span>  0:00</span> 2025</span>     0B</span></span>
pool-1/dataset2@autosnapshot-5-days-ago</span>                     Tue</span> Aug</span>  5</span>  0:00</span> 2025</span>     0B</span></span>
pool-1/dataset2@autosnapshot-4-days-ago</span>                     Wed</span> Aug</span>  6</span>  0:00</span> 2025</span>   432K</span></span>
pool-1/dataset2@autosnapshot-3-days-ago</span>                     Thu</span> Aug</span>  7</span>  0:00</span> 2025</span>     0B</span></span>
pool-1/dataset2@autosnapshot-2-days-ago</span>                     Fri</span> Aug</span>  8</span>  0:00</span> 2025</span>     0B</span></span>
pool-1/dataset2@autosnapshot-1-day-ago</span>                      Sat</span> Aug</span>  9</span>  0:00</span> 2025</span>     0B</span></span></code></pre>


Prometheus node_exporter on Fedora
2025-05-12T23:08:58+00:00
Prometheus provides a server-level metrics exporter called node_exporter</code></a> that reports hardware & kernel-level metrics. However, I found the container deployment method in Docker to be too extreme, and there was no clear documentation for setting it up manually or any officially supported package on Fedora.</p>
Other unofficial online resources didn't mention working with SELinux or firewalld, so this guide outlines how to set up a basic node_exporter</code> daemon on a Fedora 41 server.</p>
Download and extraction</a>
</h2>
Fairly straightforward, find your appropriate version on the downloads page</a> and download it:</p>
curl</span> -</span>JLO</span> https://github.com/prometheus/node_exporter/releases/...</span></span></code></pre>
and extract it:</p>
tar</span> -</span>xvf</span> node_exporter-1.9.1.linux-amd64.tar.gz</span></span></code></pre>User creation and manual installation</a>
</h2>
Manual installation involves moving the executable to the /usr/local/bin/</code> directory, which is specifically for programs</a> that normal users can run.</p>
sudo</span> mv</span> node_exporter-1.9.1.linux-amd64/node_exporter</span> /usr/local/bin/</span></span></code></pre>
Create the node_exporter</code> user & group for the service account that runs the binary, and apply them to the binary. It does not need to run with any special privileges to gather metrics, and the login shell is disabled for security:</p>
sudo</span> useradd</span> -</span>rs</span> /sbin/nologin</span> node_exporter</span></span>
sudo</span> chown</span> node_exporter:node_exporter</span> /usr/local/bin/node_exporter</span></span></code></pre>Systemd unit file</a>
</h2>
Create the systemd unit file at /etc/systemd/system/node_exporter.service</code>:</p>
[</span>Unit</span>]</span></span>
Description</span>=</span>Node Exporter</span></span>
After</span>=</span>network.target</span></span>
</span>
[</span>Service</span>]</span></span>
User</span>=</span>node_exporter</span></span>
Group</span>=</span>node_exporter</span></span>
Type</span>=</span>exec</span></span>
Restart</span>=</span>always</span></span>
ExecStart</span>=</span>/usr/local/bin/node_exporter --</span>web.listen-address</span>=</span>"</span>0.0.0.0:9100</span>"</span></span>
</span>
[</span>Install</span>]</span></span>
WantedBy</span>=</span>multi-user.target</span></span></code></pre>
This is a very simple configuration that gets node_exporter</code> listening on all interfaces on the default port 9100</code>.</p>
SELinux relabelling</a>
</h2>
Depending on where/how you downloaded it, the binary will likely have an incorrect SELinux label:</p>
[gadget@trinity ~]# ls -Z /usr/local/bin/</span></span>
unconfined_u:object_r:user_home_t:s0 node_exporter</span></span></code></pre>
This means that attempting to start it will fail. This is the journalctl</code> log, and you can see SELinux kicking in with the AVC</code> line:</p>
...</span></span>
May 12 17:11:45 trinity audit[569311]: AVC avc:  denied  { execute } for  pid=569311 comm="(exporter)" name="node_exporter" dev="dm-0" ino=180936 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=0</span></span>
May 12 17:11:45 trinity (exporter)[569311]: node_exporter.service: Unable to locate executable '/usr/local/bin/node_exporter': Permission denied</span></span>
May 12 17:11:45 trinity (exporter)[569311]: node_exporter.service: Failed at step EXEC spawning /usr/local/bin/node_exporter: Permission denied</span></span>
May 12 17:11:45 trinity systemd[1]: node_exporter.service: Main process exited, code=exited, status=203/EXEC</span></span>
May 12 17:11:45 trinity systemd[1]: node_exporter.service: Failed with result 'exit-code'.</span></span>
...</span></span></code></pre>
Fixing this is easy since the binary is located in the correct directory. The restorecon</code> command with the recursive flag (-R</code>) will apply the parent folder's label to its children, and /usr/local/bin</code> is already defined with a specific label:</p>
sudo</span> restorecon</span> -</span>R</span> -</span>v</span> /usr/local/bin/</span></span></code></pre>
In this case, SELinux is in targeted</code> mode rather than MLS</code> mode, so unconfined_u</code> is still allowed to run:</p>
[gadget@trinity ~]# ls -Z /usr/local/bin/</span></span>
unconfined_u:object_r:bin_t:s0 node_exporter</span></span></code></pre>Open firewall port</a>
</h2>
If firewalld</code> is enabled and running (the default), you will need to open its port to query the metrics from another host.</p>
You can check the active firewalld</code> zone with:</p>
[gadget@trinity ~]$ firewall-cmd --get-active-zones</span></span>
public (default)</span></span></code></pre>
Then, add the port as an exception to the zone:</p>
sudo</span> firewall-cmd</span> -</span>-zone=public</span> -</span>-add-port=9100/tcp</span> -</span>-permanent</span></span>
sudo</span> firewall-cmd</span> -</span>-reload</span></span></code></pre>Start node_exporter</code> and test</a>
</h2>
Enable and start node_exporter</code> in one line:</p>
sudo</span> systemctl</span> enable</span> -</span>-now</span> node_exporter</span></span></code></pre>
and from another host, query the endpoint:</p>
curl</span> trinity.local:9100/metrics</span></span></code></pre>
You will be greeted by a wall of metrics:</p>
# HELP go_gc_duration_seconds A summary of the wall-time pause (stop-the-world) duration in garbage collection cycles.</span></span>
# TYPE go_gc_duration_seconds summary</span></span>
go_gc_duration_seconds{quantile="0"} 3.7163e-05</span></span>
go_gc_duration_seconds{quantile="0.25"} 8.5233e-05</span></span>
go_gc_duration_seconds{quantile="0.5"} 9.2137e-05</span></span>
go_gc_duration_seconds{quantile="0.75"} 0.000103134</span></span>
go_gc_duration_seconds{quantile="1"} 0.000114001</span></span>
go_gc_duration_seconds_sum 0.001062938</span></span>
go_gc_duration_seconds_count 12</span></span>
# HELP go_gc_gogc_percent Heap size target percentage configured by the user, otherwise 100. This value is set by the GOGC environment variable, and the runtime/debug.SetGCPercent function. Sourced from /gc/gogc:percent</span></span>
# TYPE go_gc_gogc_percent gauge</span></span>
go_gc_gogc_percent 100</span></span>
# HELP go_gc_gomemlimit_bytes Go runtime memory limit configured by the user, otherwise math.MaxInt64. This value is set by the GOMEMLIMIT environment variable, and the runtime/debug.SetMemoryLimit function. Sourced from /gc/gomemlimit:bytes</span></span>
# TYPE go_gc_gomemlimit_bytes gauge</span></span>
go_gc_gomemlimit_bytes 9.223372036854776e+18</span></span>
# HELP go_goroutines Number of goroutines that currently exist.</span></span>
# TYPE go_goroutines gauge</span></span>
go_goroutines 7</span></span>
...</span></span></code></pre>

Resources</a>
</h2>

Prometheus Node Exporter home page</a></li>
</ul>


Eliminating ESC delays in tmux, Vim and ZSH
2025-05-09T17:36:40+00:00
For a while, I had vaguely noticed an odd delay whenever I pressed ESC</code> in vim. It was not until I started using vim inside tmux that the delay became very obvious. After some quick research, it turned out this was an intentional feature of both programs (and certainly many more).</p>
To cut a long story short, a number of key sequences that your keyboard transmits are actually a combination of ESC</code> and a letter on your keyboard for historical reasons (known as an escape squence</code></a>). As a result, older computers could have trouble telling the difference between them and a really fast typist. Programs such as tmux and vim get around this by adding an artifical delay any time the ESC</code> key is pressed, so it remains slower then when it is used as an escape sequence.</p>
Of course, these limitations rarely apply to modern computers anymore. Unless you're on a network connection with crazy latency, this is not an issue. The following are the settings to adjust in tmux, vim, and zsh to reduce this delay:</p>
tmux escape-time</code></a>
</h2>
Despite a lot of common advice, you should avoid setting the delay time to zero. Even though internet latency in general has never been shorter, the delay between characters is still not zero and can lead to strange problems</a> if you set it that low.</p>
I generally keep all of the combined delays to a value that is barely noticeable, often not perceptible at all. Anything above 100ms is annoying for me, and I currently keep the combined delay values across all 3 tools to 25ms.</p>
For tmux, this means setting the delay to 5ms in ~/.tmux.conf</code>:</p>
set -g escape-time 5</span></span></code></pre>Vim timeoutlen</code>, ttimeoutlen</code></a>
</h2>
vim has two settings for controlling delays. However by default, only one, timeoutlen</code>, is used to set a delay of 1000ms (1 second) for both mappings and for the delays between escape sequences. Since mappings are deliberate sequences of characters that you (usually) can't start typing in less than 10ms, it makes sense to keep that one at 1000ms (or longer if needed). This leaves us with the second option ttimeoutlen</code>, which we can set to a much lower value in ~/.vimrc</code>:</p>
set timeoutlen=1000 ttimeoutlen=10</span></span></code></pre>ZSH KEYTIMEOUT</code></a>
</h2>
Your shell will also have a delay for escape sequences. Since I use zsh, I set this in my ~/.zshrc</code> file:</p>
KEYTIMEOUT</span>=</span>1</span></span></code></pre>
This value is in hundredths of a second</a>, so a value of 1 will result in a 10ms delay.</p>

Resources</a>
</h2>

An excellent historical breakdown on the origin of escape sequences</a></li>
Cautionary warning against setting escape delay times to zero</a></li>
</ul>


Writing tmux scrollback to file
2025-05-03T22:55:37+00:00
Occasionally, I'll be running a command in tmux that prints a lot of output - then realize midway that I'd like to save it for further inspection (eg., bootloader recompilation errors on system upgrade).</p>
After digging around for a while, I found an excellent starting point on StackOverflow</a> and modified it:</p>
bind-key</span> -</span>T</span> copy-mode-vi</span> S</span> command-prompt</span> \</span></span>
    -</span>p</span> '</span>Save scrollback (start at cursor):</span>'</span> \</span></span>
    -</span>I</span> '</span>./tmuxscrollback-history-#{t|f|%%Y%%m%%d%%H%%M%%S:client_activity}.txt</span>'</span> \</span></span>
    -</span>F</span> '</span>capture-pane -S #{e|*:-1,#{e|-:#{scroll_position},#{copy_cursor_y}}} ; save-buffer %1 ; delete-buffer</span>'</span></span>
</span></code></pre>
To use this:</p>

jump into copy mode (Vi) with <TMUX PREFIX> [</code></li>
scroll up however far as needed</li>
leave the cursor at the line where the scrollback should start</li>
type SHIFT s</code>, and either use the default timestamped filename or overwrite it with a custom one</li>
hit <ENTER></code> to save to the file</li>
</ul>
The command automatically calculates the scrollback position and the cursor offset to pick the starting line, and writes everything from that point on downwards to the target file.</p>
Command breakdown</a>
</h2>
Bind S</code> (capital s) in Vi copy mode & prompt for a filename:</p>
bind-key -T copy-mode-vi S command-prompt -p 'Save scrollback (start at cursor):'</span></span></code></pre>
Autogenerate a default filename with an instant timestamp. The client_activity</code> event was picked because it continues to update as the user interacts with tmux, rather than something like buffer_created</code> which would not update when taking multiple scrollback saves. Use tmux string formatting (can be found under FORMATS</code> section in the manpage, or on the official Wiki</a>) to generate a YearMonthDayHourMinuteSecond</code> timestamp.</p>
-I './tmuxscrollback-history-#{t|f|%%Y%%m%%d%%H%%M%%S:client_activity}.txt'</span></span></code></pre>
The command that the command-prompt</code> directive will execute. The -F</code> flag is required for the calculation of the scrollback offset defined in the next section, and the -S</code> flag sets the starting line number.</p>
-F 'capture-pane -S</span></span></code></pre>
Calculate the offset. First, the entire calculation is multplied by -1</code> to provide a negative offset into the scroll buffer. #{e</code> marks this as an execution block, and the *</code> (after the |</code> delineator) marks the mathematical operation that will happen between the next 2 values, which are specified after the :</code> (-1</code> and the offset).</p>
#{e|*:-1, ... }</span></span></code></pre>
The offset is calculated by subtracting the scrollback position into the pane history from the cursor offset in the currently visible pane. These two variables are defined as:</p>

#{scroll_position}</code> the scrollback position during copy mode. This is anchored against the top of the tmux pane, and is zero-indexed when copy mode is initialized at the very bottom of the scrollback history.</li>
#{copy_cursor_y}</code> the cursor offset, which is zero-indexed against the top of the currently visible tmux pane.</li>
</ul>
The scroll_position</code> is the larger value unless the user does not scroll up. This makes the multiplication by -1</code> a much better choice than prepending the equation with a minus sign: the cursor offset copy_cursor_y</code> reduces the starting line position except</em> when the pane has not been scrolled up, which instead results in a positive value.</p>
... #{e|-:#{scroll_position},#{copy_cursor_y}} ...</span></span></code></pre>
Save the buffer that was just calculated into the filename, using the variable %1</code>. Then, clear it so it doesn't linger in the user's copy buffer.</p>
 ; save-buffer %1 ; delete-buffer'</span></span></code></pre>

Resources</a>
</h2>

tmux official Wiki</a></li>
tmux Wiki FORMATS</a></li>
</ul>


Creating ED25519 GPG keys to sign Git commits
2024-12-27T16:14:30+00:00
Git provides the ability to sign your commits with a GPG key. I felt this could be a fun thing to start doing, and since I've had trouble finding simple guides for doing this specifically with ed25519 keys, I'm writing my own.</p>

If you're just looking for a quick summary of the commands, here they are:</em></p>
export</span> KEYUID</span>=</span>'</span>Firstname Lastname (username) <firstname.lastname@email.com></span>'</span></span>
gpg</span> -</span>-quick-generate-key</span> "</span>$</span>KEYUID</span>"</span> ed25519</span> cert</span> never</span></span>
gpg</span> -</span>-quick-add-key</span> KEYFINGERPRINTFROMABOVE</span> ed25519</span> sign</span> 5y</span></span>
git</span> config</span> -</span>-local</span> user.signingkey</span> username</span></span>
git</span> config</span> -</span>-local</span> commit.gpgsign</span> true</span></span></code></pre>

Installation prerequisites</a>
</h2>
My development environment is a Macbook Pro, so your milage may vary depending on the system you're using. You'll need to install 2 items, gnupg</code> and pinentry</code>:</p>
brew</span> install</span> gnupg</span> pinentry-mac</span></span></code></pre>
While the first is self-evident, pinentry</code> is not - and unfortunately, if it is not installed, the errors you might run into are incomprehensible:</p>
error: gpg failed to sign the data:</span></span>
[GNUPG:] KEY_CONSIDERED 55BE5089F634003042AE70985E88702C976C97B1 0</span></span>
[GNUPG:] BEGIN_SIGNING H10</span></span>
[GNUPG:] PINENTRY_LAUNCHED 60797 curses 1.3.1 - alacritty - - 501/20 0</span></span>
gpg: signing failed: Inappropriate ioctl for device</span></span>
[GNUPG:] FAILURE sign 83918950</span></span>
gpg: signing failed: Inappropriate ioctl for device</span></span>
</span>
fatal: failed to write commit object</span></span></code></pre>
From what I have found, the regular TTY is insecure for entering passwords, so GnuPG has developed their own alternative (GnuPG architecture diagram found here</a>). However, I've found a lot of users reporting usability problems with this tool, especially over SSH, so I'll include a section on bypassing it altogether.</p>
Configuring gnupg</code> to use pinentry</code></a>
</h3>
In ~/.gnupg/gpg.conf</code>:</p>
use-agent</span></span></code></pre>
and in ~/.gnupg/gpg-agent.conf</code>:</p>
pinentry-program /opt/homebrew/bin/pinentry-mac</span></span></code></pre>
You can choose to cache it in macOS' Keychain so it does not need to be entered repeatedly.</p>
Bypassing pinentry</code> entirely</a>
</h3>
In ~/.gnupg/gpg.conf</code>:</p>
use-agent</span></span>
pinentry-mode loopback</span></span></code></pre>
and in ~/.gnupg/gpg-agent.conf</code>:</p>
allow-loopback-pinentry</span></span></code></pre>
These instructions were found online here: https://d.sb/2016/11/gpg-inappropriate-ioctl-for-device-errors</a></p>

And then run the following to let gpg-agent</code> pick up the configurations:</p>
echo</span> RELOADAGENT</span> |</span> gpg-connect-agent</span></span></code></pre>Generating the GPG keys</a>
</h2>
Many guides still show how to generate RSA keys. However, the modern alternative for a while has been ED25519. To use it, run:</p>
Master key</a>
</h3>
gpg</span> -</span>-quick-generate-key</span> '</span><User ID></span>'</span> ed25519</span> cert</span> never</span></span></code></pre>
This generates a Certify-only (cert</code>) ed25519</code> key that never</code> expires.</p>
The <User ID></code> can generally be anything. The standard format follows the convention of:</p>
Your Name (comment) <your.email@address.com></code></p>
However, keep in mind that for commits to appear as valid on websites such as Github, you need to include an email that matches one of your verified Github emails. The angle brackets surrounding the email (< ></code>) are required.</p>
Once you hit Enter, it'll ask you to provide a password. If you followed the configuration steps in the first section, it'll only ask for it once, so be sure to type/paste it correctly.</p>
GPG will then print the new key:</p>
pub   ed25519 2024-12-20 [C]</span></span>
      55BE5089F634003042AE70985E88702C976C97B1</span></span>
uid           [ultimate] Firstname Lastname (username) <firstname.lastname@email.com></span></span></code></pre>
The [C]</code> stands for Certify. Generally, since GPG relies on a 'web of trust' where people hold onto your key for a long time, you want your root level key to rarely expire. It will also have no abilities, existing solely to sign subkeys that you actually use for day-to-day work.</p>
Signing key</a>
</h3>
The signing key is a subkey of the master key, and they are both logically considered part of the same GPG key.</p>
gpg</span> -</span>-quick-add-key</span> 55BE5089F634003042AE70985E88702C976C97B1</span> ed25519</span> sign</span> 5y</span></span></code></pre>
This generates a Sign-only (sign</code>) ed25519</code> key that expires in 5 years (5y</code>). The 55BE5...</code> string is the master key's full fingerprint, which was printed above.</p>
To continue signing after this time has passed, you'll need to generate a new subkey again with the master key. The idea behind this is that if you've had your key copied/stolen somehow, it can't be used forever.</p>
Note on ed25519 encryption</em></a>
</h4>
Adding an encryption key involves a very small change: instead of ed25519</code>, you'll need to specify cv25519</code> for the encryption algorithm:</p>
gpg</span> -</span>-quick-add-key</span> 55BE5089F634003042AE70985E88702C976C97B1</span> cv25519</span> encr</span> 5y</span></span></code></pre>Listing keys</a>
</h2>
While there's numerous ways to list your keys, I've found that you generally don't need to worry about most of them. Regardless of how many subkeys your GPG key has, referencing either the master key's ID or any part of your UID will allow GPG to pick the appropriate subkey. If you have multiple subkeys with the same function, GPG picks the most recently created one.</p>
However, here's a few I've found useful:</p>
The default:</p>
$ gpg --list-keys username</span></span>
[keyboxd]</span></span>
---------</span></span>
pub   ed25519 2024-12-20 [C]</span></span>
      55BE5089F634003042AE70985E88702C976C97B1</span></span>
uid           [ultimate] Firstname Lastname (username) <firstname.lastname@email.com></span></span>
sub   ed25519 2024-12-20 [S] [expires: 2029-12-19]</span></span>
sub   cv25519 2024-12-29 [E] [expires: 2029-12-28]</span></span></code></pre>
Same as above, but with the master key ID split into 4-character chunks:</p>
$ gpg --fingerprint username</span></span>
pub   ed25519 2024-12-20 [C]</span></span>
      55BE 5089 F634 0030 42AE  7098 5E88 702C 976C 97B1</span></span>
uid           [ultimate] Firstname Lastname (username) <firstname.lastname@email.com></span></span>
sub   ed25519 2024-12-20 [S] [expires: 2029-12-19]</span></span>
sub   cv25519 2024-12-29 [E] [expires: 2029-12-28]</span></span></code></pre>
You can also go all-out and list each of the subkey fingerprints:</p>
$ gpg --list-keys --with-subkey-fingerprints --keyid-format=LONG username</span></span>
pub   ed25519/5E88702C976C97B1 2024-12-20 [C]</span></span>
      55BE5089F634003042AE70985E88702C976C97B1</span></span>
uid                 [ultimate] Firstname Lastname (username) <firstname.lastname@email.com></span></span>
sub   ed25519/882630A8E2F9526B 2024-12-20 [S] [expires: 2029-12-19]</span></span>
      AE9E8E56437D11587FAFE840882630A8E2F9526B</span></span>
sub   cv25519/258ADE692963C5B3 2024-12-29 [E] [expires: 2029-12-28]</span></span>
      1C3C6C37E6E0248E5B54C0E8258ADE692963C5B3</span></span></code></pre>
Finally, to export your public key in ASCII plaintext to share, run:</p>
$ gpg --armor --export username</span></span>
-----BEGIN PGP PUBLIC KEY BLOCK-----</span></span>
</span>
mDMEZ2TErhYJKwYBBAHaRw8BAQdAzgjB3r552mWBwNhcdGZ+2G48SnhSoTWr5CzK</span></span>
QfXxHre0O1JpY2hhcmQgSC4gUGFqZXJza2kgSUkgKGRldmVkZ2UpIDxyaWNoYXJk</span></span>
LnBqc2tpMkBwcm90b24ubWU+iJMEExYKADsWIQRVvlCJ9jQAMEKucJheiHAsl2yX</span></span>
sQUCZ2TIwwIbAQULCQgHAgIiAgYVCgkICwIEFgIDAQIeBwIXgAAKCRBeiHAsl2yX</span></span>
sTMKAQCcrv1D1M8pWFnpTA+SSCZxK1RVk9x/CUit2Hv+1oPPbQEAnIgqoryLxrkh</span></span>
wtt+OifSZzzhdN7qvcmJQbvkoq2MRwq4MwRnZMgtFgkrBgEEAdpHDwEBB0BA8iAQ</span></span>
7zCdTB5/7HFzWXbbCUndzykTezhkpksoqtTH9Yj1BBgWCgAmFiEEVb5QifY0ADBC</span></span>
rnCYXohwLJdsl7EFAmdkyC0CGwIFCQlmAYAAgQkQXohwLJdsl7F2IAQZFgoAHRYh</span></span>
BK6ejlZDfRFYf6/oQIgmMKji+VJrBQJnZMgtAAoJEIgmMKji+VJrb+UA/iIF0zAc</span></span>
LFKQbhzP6lY8GHfKd5mWKk2pjqG3E8HAErPlAP9MxH+qIF3FlpQB95Kog/oUh3EI</span></span>
hX9M+helqM8mMhGBBv9dAQCl2jqJrrJY9py53LejlLZ0pzTwDQA7FdzoHWz/UJF7</span></span>
+QEAosZC3I3kQD/pmIzupZbwROyDjYp4utqlPOS3uCC4PQi4OARncU/0EgorBgEE</span></span>
AZdVAQUBAQdA3Bs/kDcYB3WVD+V2uk7L5w0968NSvgjmpPgMrv1ScBkDAQgHiH4E</span></span>
GBYKACYWIQRVvlCJ9jQAMEKucJheiHAsl2yXsQUCZ3FP9AIbDAUJCWYBgAAKCRBe</span></span>
iHAsl2yXsU12AP46i6XmHRcWJY6vMI36F0LLXfe/IyaFNFI28vA4iQeV/AEAvqAi</span></span>
5/yO7vn/NItgMIfqC84ZeDirypv7f3y3LQq3xwU=</span></span>
=ubLP</span></span>
-----END PGP PUBLIC KEY BLOCK-----</span></span></code></pre>
Or directly exported to a file:</p>
gpg</span> -</span>-armor</span> -</span>-export</span> -</span>-output</span> username.asc</span> username</span></span></code></pre>Signing commits with them</a>
</h2>
A good idea to ensure you never forget to sign commits is to run the command:</p>
git</span> config</span> -</span>-local</span> commit.gpgsign</span> true</span></span></code></pre>
in the root directory of your git repository. This will add a configuration entry in .git/config</code> for that repo, automatically requiring a signature for every commit. This is more convenient than having to manually type the -S</code> flag to sign every git commit</code> as a one-off.</p>
To specify your new key for that repository, run one of the following:</p>
#</span> some part of the UID</span></span>
git</span> config</span> -</span>-local</span> user.signingkey</span> username</span></span>
</span>
#</span> a different example using the email instead</span></span>
git</span> config</span> -</span>-local</span> user.signingkey</span> firstname.lastname@email.com</span></span></code></pre>
You could also (confusingly) specify the key fingerprint or full key ID of either the master key or the signing key:</p>
#</span> master key fingerprint (last 16 characters of full key ID)</span></span>
git</span> config</span> -</span>-local</span> user.signingkey</span> 5E88702C976C97B1</span></span>
</span>
#</span> full master key ID</span></span>
git</span> config</span> -</span>-local</span> user.signingkey</span> 55BE5089F634003042AE70985E88702C976C97B1</span></span>
</span>
#</span> or likewise for the signing key:</span></span>
git</span> config</span> -</span>-local</span> user.signingkey</span> 882630A8E2F9526B</span></span>
git</span> config</span> -</span>-local</span> user.signingkey</span> AE9E8E56437D11587FAFE840882630A8E2F9526B</span></span></code></pre>
GPG will automatically pick the signing key you created. If you have multiple, it appears to use the most recently created one.</p>
If you want to use this key globally for every repository on your machine, replace the --local</code> flag with --global</code>. This will place the configuration options in your home directory instead, inside ~/.gitconfig</code>.</p>

Resources</a>
</h2>

Git guide to signing your work</a></li>
Github guide to using your GPG key with Github</a></li>
Fixing GPG "Inappropriate ioctl for device" errors</a></li>
Guide for pinentry-mac</code></a></li>
Another article covering a slightly different solution to signing commits over ssh</a></li>
</ul>


New site, new beginnings
2024-12-22T17:47:23+00:00
As you may have noticed, this site has a very different look.</p>
This has been a long time coming, as I had many problems with the previous Jekyll framework that this blog was built on. This often held me back from detailing the in-depth work I've always been doing, and as we move into the new year, I look forward to utilizing this new site much more.</p>
As for the previous posts: I will eventually bring them back, in one form or another. Looking back on them, there's a lot to be improved - some will stay as-is as a reminder of where I've come, but others will be completely reworked.</p>
The reason is that this site's purpose has always been threefold:</p>

A personal technical reference guide, accessible from anywhere</li>
Detailed guides on specific tools or processes that I can link to people during discussions, which is much easier than working off of (an often spotty) recollection</li>
An archive of the breadth and depth of my technical expertise that I can look back on as a reference, better than any resume</li>
</ul>
As a result, they will be molded to better fit these goals.</p>
What is this running on?</a>
</h2>
This blog is built using a NodeJS framework called hexo</a>.</p>
Specifically, I'm running a modified version of the Cactus theme</a> (github</a>), with a number of personal changes.</p>
These are:</p>

Removed all tracking & analytics from the codebase (Google/Baidu/Cloudflare/Umami Analytics)</li>
Removed the commenting frameworks (Disqus/Utterances)</li>
Used Nord Theme</a> as a color reference to create a new color style</li>
Designed a new icon/favicon, fitting with a more polar/edge-like theme</li>
</ul>
The future</a>
</h2>
There's a lot in store for the future. For starters:</p>

Setup and integration of the Hexo search extension to make finding content much easier</li>
Dedicated styling to mark specific sections of posts as 'out-of-date', or 'updated'</li>
The introduction of a new special category, 'living posts' of sorts, where certain items will always be considered in flux (think configurations or running services)</li>
Auto dark mode/light mode switching based on time of day</li>
</ul>
This is in addition to an ever-growing backlog of (at least) a couple dozen individual topics that have been patiently waiting in my Notes and Reminders to be brought to life.</p>
Happy new year!</p>
Workaround

Resources </a> </h2>

Older guide for installing `coreutils</code></a></li>`
`Stackexchange guide for installing coreutils</code></a></li>`
`Warning regarding tag preservation failure</a></li>`
`Good guide on ZSH configuration for macOS</a></li> </ul>`

Fedora double bonus
Full ZSH config
Resources </a> </h2>

Good StackExchange reference for many of these options</a></li>
Manpage guide</a></li>
Escape Delay post</a></li>
StackExchange post to disable `zlogout</code> behavior</a></li> </ul>`

Full ZSH config
Resources </a> </h2>

Good StackExchange reference for many of these options</a></li>
Manpage guide</a></li>
Escape Delay post</a></li>
StackExchange post to disable `zlogout</code> behavior</a></li> </ul>`

Resources </a> </h2>

Good StackExchange reference for many of these options</a></li>
Manpage guide</a></li>
Escape Delay post</a></li>
StackExchange post to disable `zlogout</code> behavior</a></li> </ul>`

Resources </a> </h2>

Fedora instructions for testing `systemd-boot</code></a></li>`
`Arch Wiki entry for further information on systemd-boot</code></a></li> </ul>`

Resources </a> </h2>

ManKier: Search manpages translated to HTML5</a></li>
`man-db</code> homepage</a></li>`
`BSD man</code> vs. man-db</code></a></li>`
`Excellent deep-dive into manpages</a></li> </ul>`

Resources </a> </h2>

Reference StackOverflow post</a></li>
Excellent resource for creating vim mappings</a></li> </ul>

Enabling the service

Enabling the service

Resources </a> </h2>

Prometheus Node Exporter home page</a></li> </ul>

Resources </a> </h2>

An excellent historical breakdown on the origin of escape sequences</a></li>
Cautionary warning against setting escape delay times to zero</a></li> </ul>

Resources </a> </h2>

tmux official Wiki</a></li>
tmux Wiki FORMATS</a></li> </ul>

The future

Posts

Another year, another blog redesign

Deleting Sequoia-PGP certificates

Replacing macOS BSD utils with GNU coreutils

Minimally functional ZSH config for servers

Switching Fedora bootloader to systemd-boot

Quick aside on AI usage

man man

Vim encoding/decoding base64 in Kubernetes secrets

ZFS local replication with systemd units + timers

ZFS rolling snapshots with systemd units + timers

Prometheus node_exporter on Fedora

Eliminating ESC delays in tmux, Vim and ZSH

Writing tmux scrollback to file

Creating ED25519 GPG keys to sign Git commits

New site, new beginnings
