The idea of having a singular Kubernetes config, authenticated to all your production, staging and dev environments alike, should fill you with trepidation. An accidental mis-selection from your shell history of a potentially destructive command could end up being enacted against the wrong cluster. In any case, a stark visual indicator of the current environment is desirable. Folks do this with browser configs, terminal sessions or IDE-database connections being colour coded to an environment, so we want to achieve a similar result here.

## The problem / background

• You have a limited IP address space to use for Docker.
• Docker’s default pool is a /12.
• For Compose it allocates /16s from it by default.
• This gives each Compose project 65,536 IPs.
• That’s likely overkill for most folks’ needs.
• It also effectively limits you to having 16 Compose projects.

The other problem we’d like to solve, is to provide some space outside of the allocation pool for Compose projects that want to define their own IP ranges to use. Like you’d do for DHCP, we want a pool and some reserved space.

Assumptions:

• You have fprintd installed already, following the Arch wiki.
• You have enrolled your fingerprints.

Install polkit:

sudo pacman -S polkit

Create a polkit-1 file in pam.d:

sudo nano /etc/pam.d/polkit-1

#%PAM-1.0
auth       sufficient   pam_fprintd.so
auth       include      system-auth
account    include      system-auth
password   include      system-auth
session    include      system-auth

Testing:

pkexec whoami

You should see the system authentication prompt and it should prompt for your fingerprint as well.

To Bitwarden:

In Settings -> Security, check “Unlock with system authentication”. Then close the settings and lock the vault with either the menu item or Ctrl+L.

As developers the one thing that’s central to everything is communication. We’re responsible for communicating our ideas and intentions to others and to our future selves. Whether it’s through the code itself, its token names and comments, or through its accompanying documentation. Whether it’s through the commit messages: title and description, or through the pull request content.

It’s often been said that we should optimise our code for reading, not writing, as we spend more time reading it than writing it. Well the same is true for our writing. It should be optimised for the future reader. You aren’t, or shouldn’t, be writing just for its own sake, to tick a box, or so you can say you have documented your code. You’re writing to span the temporal gap between whatever it is you’re working on and its future maintenance requirements. You’re writing to have, an admittedly one-sided, conversation with future maintainers. Often for yourself.

The following are my random thoughts during setting up NixOS. I already have Manjaro installations boiled down into a set of shell scripts that let me reinstall and configure the OS fairly quickly and repeatably. NixOS solves this in a much nicer way, so that appealed. The ability to rollback a bad configuration or update was also a big draw.

Rolling back doesn’t revert the broken configuration.nix, so should I make /etc/nixos a git repo?