Paucis Verbis

In part, this a formalized index of notes related to system administration and software development, along with the occasional essay when the mood strikes.

All opinions therein are my own, and do not necessarily reflect that of any employers or clients.

A Vim Note-Taking System

Few things are more effective at sabotaging productivity than the pursuit of the perfect productivity software. My guilt in this ranges from endless Markdown editors (VNote, Marktext), task managers (TaskWarrior), calendaring (Khal, Orage), Bullet journals, and so forth. Even if a program meets all my feature requirements, it will often fail to integrate smoothly into my daily workflow, so the likelihood that I continue to use it is slim. Given that the majority of my time is spent in a terminal with neovim, the logical conclusion is to extend those two utilities to be able to achieve the following:

Notes on Using GnuPG

Preliminaries Creating an Encrypted RAM Disk Workspace Since you may be temporarily storing your private keys unencrypted, it’s best not to do so on a physical drive–particularly since utilities like wipe or shred are ineffectual with modern SSDs. The general workflow is to allocate a ram disk, create a file with random data on it, then use LUKS to create an encrypted loop device from that file, format it, and mount it.

Configuring Weave Flux

Installing the Flux Helm Operator Notes taken from Stefan Prodan’s Gitops Helm repository. The first step in automating Helm releases with Weave Flux is to create a Git repository with your charts source code. You can fork the gitops-helm project and use it as a template for your cluster config. Add the Weave Flux chart repo: helm repo add weaveworks https://weaveworks.github.io/flux Install Weave Flux and its Helm Operator by specifying your fork URL (replace stefanprodan with your GitHub username):

Notes from Kubernetes: Up & Running

Page: 51 Contexts If you want to change the default namespace more permanently, you can use a context. This gets recorded in a kubectl configuration file, usually located at $HOME/.kube/config. This configuration file also stores how to both find and authenticate to your cluster. For example, you can create a context with a different default namespace for your kubectl commands using: $ kubectl config set-context my-context --namespace=mystuff This creates a new context, but it doesn’t actually start using it yet.

Bootstrapping a GKE Cluster (Part 1)

For those wishing to get some hands-on experience with running containers, Google Cloud provides a $300 / 12-month credit for new users. Kubernetes is tightly integrated with Google’s cloud administration panel and gcloud client, making tools like kops and kubernetes-dashboard unnecessary. Coupled with offerings like the Container Registry, GKE is a convenient choice to start testing quickly. Prerequisites Enable billing on your account Install the Cloud SDK for your distribution and initialize it Add the kubectl component with gcloud components install kubectl Install the latest version of Terraform Initializing the Cluster Manual As an ad-hoc test, the gcloud client makes it very simple to stand up a cluster:

Xenix & the SLIP Rabbithole

The latest distraction has been trying to get Xenix 386 2.3.4h installed in a VM and have some sort of TCP networking for more reliable file transfers. The first distribution I managed to install was Slackware 3.0, so this predates my own nostalgia by a few years. It’s mostly born from a curiosity of what Unix on a microcomputer was like prior to Linux. Aside from the… odd filesystem layout (system configuration utilities in /etc?