May 28, 2019 storm

At the very end of a front it seemed like storms might just miss Kansas City, but a cell forming around Topeka ended up producing an EF-4 tornado up to around a mile wide. The tornado tracked east northeast south of Lawrence paralleling I-70 toward Bonner Springs. Thankfully the storm weakened and the tornado dissipated just west of the Kansas City metropolitan area. A tornado warning was issued for the area and I retreated to the basement but thankfully rain, wind, and lightning were the extent of it. Storm circulation intensified and another tornado was spawned northeast of the Interstate 435 loop, making it all the more amazing it spared the more densely populated areas.

Tablets

Not long before the modern smartphone revolution, I acquired a Nokia N800, described by the company as an Internet tablet. Despite being limited to wifi connectivity the device seemed idea for have a portable, personal device that would be far more portable than a laptop.

In practice the 4.13" resistive touchscreen was less than ideal and software offerings were limited. The platform, Maemo, was based on Debian and GTK+, two things I have used on the desktop for years but feel unfortunately feel foreign in this form. Skype and Flash were the only mainstream applications ported.

Excited by the prospect of Android on a higher end tablet I had the much hyped Motorola Xoom from a Verizon store, the exclusive retailer. The somewhat expensive and heavy device delivered great performance on the Nvidia Tegra 2 though without many apps created for the platform. It was the first device to run Android 3.0 Honeycomb, specifically designed to bring the OS up to the task of tablet computing from its smartphone roots.

Android tablets have waxed and waned over the years with some great devices and mixed software. I owned both the first and second generations of Nexus 7, both excellent, svelte devices with snappy performance. The second generation especially is perhaps the best overall tablet experience I can recall, though looking at it today apps seem slow by comparison and the bezels are huge. As smartphones have increased in size, the screen is now not much bigger than the phone I carry.

Nexus 9 was the last Android tablet I've owned. The larger screen helps differentiate it's use from a phone, but the 50% greater mass is evident along with significant top and bottom bezels.

In my use Android and iPad tables continue to feel like large phones, with the same grid of icons and limiting touch interface. Android had Termux that creates a command line Unix environment though no X Windows capabilities. iOS has a couple of excellent SSH clients but nothing creating a local environment that I have come across.

Thus far the Pixel Slate seems to offer the best of both worlds, as a lightweight, long batter life tablet, and a capable, if locked down, Linux machine. Crostini, an official successor to Crouton, provides a Debian Linux VM within the Chrome OS Linux environment including full dpkg and X windows support. While not the fastest machine it's perhaps a more stable lightweight dev machine than my more powerful XPS 13.

Yubikey

In the past year I've taken steps to increase security on some of my accounts and machines. One of these measures was to protect my network with public key authentication and two-step verification with TOTP (Google Authenticator). It was easier than I had feared to set up the two-step via Linux PAM. Logging in thus does require having my phone available and then unlocking, launching an app, and entering the code.

Yubikey is a hardware authentication device, with a form factor similar to that of a small USB flash drive. It supports a number of different protocols, including U2F to replace one time codes with a direct message with the site. What interested me the most was as a secure place to keep SSH keys. Keys sitting on disk can potentially be taken and need long passwords to keep secure. With a Yubikey the private key can remain locked away, only usable with the device present, a PIN, and optionally contact with the device (to prevent remote exploitation).

There are a couple of ways to create keys that can be used for SSH: PIV and OpenPGP. I've had issues with GPG in the past and it seemed likely to require replacing ssh-agent, so I thought I'd first try PIV, or Personal Identity Verification. At work I use a smart card that meets the same standard and it works with standard SSH components combined with opensc software. The syntax is a little odd, requiring the full path to the smart card library.

ssh -I /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so <host>

ssh-agent is able to cache and forward but plugging and unplugging the Yubikey can cause issues. At times a flush of ssh-agent or a restart of GNOME Keyring fixes the issue. Reading more about the higher encryption standards available through PGP, and that Chrome OS has support for smart cards in the built-in SSH app, I decided to try PGP as well. Creating keys and subkeys was fairly quick with reasonable defaults to most of the prompts.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Create GPG key
gpg --gen-key

# Create subkey on Yubikey
gpg addcardkey

# Get PGP Yubikey applet information
gpg --card-status

# Get an SSH format public key
gpg --export-ssh-key <key>

There are rather vociferous arguments about the interactions between GNOME Keyring and gpg-agent. Keyring has generally worked well for me but it does not show the card-based subkeys at all. Switching the SSH agent socket to GPG agent provides a very seamless experience with card removal and insertion. Keyring does not fully support smart card authentication so I first created an alias to switch the SSH agent socket on the fly, before just permanently disabling the ssh-agent functionality of the Keyring, after which gpg automatically took over. Other keys can still be loaded on-the-fly.

1
2
3
4
5
6

# Use gpg-agent for SSH agent
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)

# Disable GNOME Keyring ssh-agent
cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart/
echo 'Hidden=true' >> ~/.config/autostart/gnome-keyring-ssh.desktop

fzf, ripgrep, git grep

Recent work has found me searching through large directory structures for files with sometimes less than obvious names. grep -r had become a go-to but it's not particularly speedy. Seeing a mention or two on Twitter led me to ripgrep which is specifically designed for such recursive file content searches. It also handily ignores files specified by gitignore and hidden files by default. Discovering ripgrep reminded me I had forgotten all about git grep which also allows for recursive searches, taking advantage of the git index, for files already in a repo.

fzf is a fuzzy finder, presenting an interactive way to search lists like filenames and git commits. Setting up aliases add useful interactivity to common tools, enabling quick full searching at the prompt in addition to the usual tab completion. As an example, searching recursively for a file, presenting a list of matches, and opening the selected in vim, bypassing the list if just one match.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

fe() {
  local IFS=$'\n'
  local files=()
  files=(
    "$(rg --files | fzf-tmux \
          --query="$1" \
          --multi \
          --select-1 \
          --exit-0
    )"
  ) || return
  "${EDITOR:-vim}" "${files[@]}"
}

Home Theater API

Taking advantage of a Black Friday sale, I upgraded my living room home theater with a new Onkyo receiver. I purchased my previous receiver, also an Onkyo, in grad school and it has served me well. It was lacking in some modern features, being connected entirely analog and required speaker wire pass-through to drive the subwoofer that was added to the setup a couple of years ago. The new unit features several HDMI inputs, HDMI-ARC output, and networked services like Spotify and Chromecast. Connected via wifi there is a phone app that can control most features.

Many such consumer devices rely on purely cloud based services so it was great to discover the API allows control over the local network. I'm only just starting to explore. There is a great Python module for accessing the API including device discovery, onkyo-eiscp. An MQTT bridge, onkyo2mqtt, is promising, able to transmit messages upon device actions like volume adjustment. The former also offers a straightforward command line tool:

onkyo --host x.x.x.x audio-muting=on

Discovering this ability to adjust audio remotely, it was nice to find pychromecast allows some measure of control over the diminutive media players. Apparently the Chrome dev tools can help determine app specific commands.