Tyblog

If you’re a NixOS user, knowing what will change on your system when performing updates can be tricky. We can make the experience better!

You can build your own voice assistant to avoid the questionable privacy consequences of bringing an Alexa or Google Assistant into your home. In this post I’ll explain how I did it using commodity hardware without any need for network communication outside of my own private LAN. Even more stunning, the voice recognition doesn’t suck and it may actually be useful to you.

Here’s a free product idea for the ambitious and morally flexible reader:

Docker is the de facto solution for packaging most server-side applications these days. The technical merits of Docker are nifty – cgroups and other mechanisms are certainly useful – but there’s one particular aspect of running an application in Docker that has been unequivocally beneficial for the industry: concretely defined inputs and outputs.

This blog post is about benchmarking Caddy against Nginx and their respective performance metrics as reverse proxies. Be forewarned: I was very thorough and there are tons of graphs and tables in here. I didn’t want to make any mistakes! Nobody is allowed to make mistakes on the Internet.

About a year ago my Framework laptop arrived. Finally, after fretting constantly about finding hardware that I would feel good about supporting, here it was: first-class Linux support, best-in-class maintainability, and a company that seemed pretty concerned about sustainability. Is it the year of the Linux Desktop? Am I hallucinating? Is there a gas leak in my house?

I have poor command-line hygiene. When I fever-dream a useful pipeline into existence, I very seldom commit it to a shell configuration somewhere. Rather, I let fzf dredge it up sometime later when I need it. My functions are not documented, have hideously short names and variables because I tend to code golf, and are specific to the use-case-at-the-time and not general.

I’ve since decided that this is the optimal approach.

Remember when we all used to commit secrets to source code repositories? In the bygone software engineering paleolithic era, public cloud key management services didn’t exist and neither did OSS solutions like Vault. Managing sensitive credentials has gotten much better over the years, and there’s very little reason to ever even store passwords or tokens in plaintext files any more.

My little lab can afford some experimental allowances given that I’ll never (hopefully) breach the “thousands of hosts” mark. One experiment that paid off recently was ditching Traefik v1 for a hybrid setup that uses Nomad, consul-template, Caddy, and wireguard in order to provide the HTTP routing layer for my services.

If you’re like me, you: have to look up Dockerfile quirks each time you write one, never know whether a container you exec into will have bash, sh, or whatever other shell, and are never sure which container init is currently the best practice. I definitely still don’t know what the hell Moby is.

Overall, packaging applications into Docker container images isn’t very ergonomic, and the “repeatable” part isn’t all that reliable (have you ever run into outdated distribution repositories? It’s annoying). That said, container primitives are cool and useful - resource constraints like cgroups are nice, and the fundamental principle of shipping your entire runtime is definitely good for deployment consistency. Let’s mess around with other ways to build executable artifacts to toss into a container orchestration system or workload scheduler.

I use a lot of software tools for my job - and personally, for that matter. Some live in the forefront of my brain, like emacs. Others live in the background, like my terminal (alacritty). Some of these background tools do their jobs so well and so reliably that I can sometimes forget that they’re humming away for me every day, without any hassle to fix or maintain them.

These days, I almost exclusively run Arch Linux in my homelab and personal machines. Had I the brain cells to spare, I’d try and get NixOS running on ARMv7, but in the meantime, a mix of vanilla x86_64 Arch and Arch Linux ARM is my chosen flavor just to keep things consistent. I’ve run Arch as my primary server OS for almost a decade now, and although I’m sure some will balk at the idea, I’ve found that the distribution has performed wonderfully for me, even in contrast to traditional “server” distributions like CentOS. It sounds counterinuitive, but the simple model of Arch Linux has, overall, helped mitigate some maintenance burdens.

I often think back to previous years about the best movies, games, and books that I find and wish I had recorded them somewhere. For 2019, I’m finally doing it - so here’s my biased, semi-organized, and somewhat late list of media that I really loved from 2019!

My blog post about ssh is still the most frequently read content on my blog four years later. I’ve collected enough shell tricks that it’s about time for one of these type of posts about my favorite software tool of all time: the shell.

A few months ago I rebuilt my router on an espressobin and got the itch to overhaul the rest of my homelab. While I could pick up some post-market AmaFaceGooSoft equipment for a typical high-power x86 lab, I decided to put the devops mantra of a distributed, fault-tolerant architecture to work and see how far I could get with lots of small, cheap, low-power machines instead.

In a nutshell, I’m running ~20 ARM-based single-board computer cluster that drives a container-scheduled application runtime (Nomad) backed by distributed storage (GlusterFS) with service discovery in place (Consul) to provide me with a platform to run all my applications and services with a mostly self-configured HTTPS (Let’s Encrypt) front end (Traefik). Vault, Prometheus, and a bunch of supporting applications are also deployed in order to make operating this setup secure, easy, and eminently scalable.

After my Asus N66U kicked the bucket, I considered a few options: another all-in-one router, upgrade to something like an EdgeRouter, or brew something custom. When I read the Ars Technica article espousing the virtues of building your own router, that pretty much settled it: DIY it is.

I’ve got somewhat of a psychological complex when it comes to rolling my own over-engineered solutions, but I did set some general goals: the end result should be cheap, low-power, well-supported by Linux, and extensible. Incidentally, ARM boards fit many of these requirements, and some like the Raspberry Pi have stirred up so much community activity that there’s great support for the ARM platform, even though it may feel foreign from x86.

I’ve managed to cobble together a device that is not only dirt cheap for what it does, but is extremely capable in its own right. If you have any interest in building your own home router, I’ll demonstrate here that doing so is not only feasible, but relatively easy to do and offers a huge amount of utility - from traffic shaping, to netflow monitoring, to dynamic DNS.

I built it using the espressobin, Arch Linux Arm, and Shorewall.

I read a lot of tech success stories, but most of them revolve around building out or creating cool stuff. Last week, I had a catastrophic disk failure, and all I wanted was to find some recorded notes about disk recovery in Linux with ZFS. This is a record of my experience to illustrate the strength and maturity of ZFS on Linux and potentially help anyone in a similar situation in the future.

systemd: it’s the init system that (some?) love to hate.

Full disclosure: I find systemd a little overbearing, although by no means would consider myself militantly anti-systemd. It has obvious advantages, and although I’m at philosophical odds with it at some levels, I see no reason why everybody shouldn’t understand it a bit better - especially now that most people will need to deal with it on their favorite distros.

I recently (finally!) finished the Advent of Code challenges using Haskell. I’m still a Haskell wannabe, but the suite of problems provided an interesting backdrop for a number of Haskell concepts that I wanted to share.

The long-form retrospective is here; if you want to see a condensed collection of a few Haskell toolchain by-products, check out my shorter summary under GitHub pages.

I recently used systemd, HandBrake, and some simple scripts to digitize a large collection of physical media (for personal, archival use.) In this post I’ll go through systemd features that made this easier and cover all the components that make the automated pipeline work.

Honeypots are rad. Their uses are varied, but I’ve used my own mostly for research (and entertainment.) It’s been running for over a year now, and I thought it would be worthwhile (and interesting) to summarize my findings.

This is just a short blip for people running Docker on CentOS who have encountered problems accessing containers from outside the localhost.

There are many subtle joys associated with working almost exclusively in the command line all day: tab completion, a simple interface, and unix pipes.

OpenSSH is an incredible tool. Though primarily relied upon as a secure alternative to plaintext remote tools like telnet or rsh, OpenSSH (hereafter referred to as plain old ssh) has become a swiss army knife of functionality for far more than just remote logins.

I rely on ssh every day for multiple purposes and feel the need to share the love for this excellent tool. What follows is a list for some of my use cases that leverage the power of ssh.

Have I got your attention? It’s a sensationalist title, but this is important and developers/administrators still get it wrong.

Both online and professionally, I encounter technical people still turning to traditional hashing algorithms like SHA or, Schneier forbid, MD5 when making decisions about scrambling user credentials. Even this recent question on Stack Overflow Exchange has yielded inaccurate answers. While choosing something like SHA-256 with salt isn’t necessarily a bad decision, it’s not the right decision – which, when it comes to cryptography, is critical to maintain the integrity of the system as a whole.

Last weekend I participated in a capture-the-flag event sponsored by Bishop Fox and ran by students at BYU. Following the event I decided that it may be fun to try and crack the scoring software itself – so I’ve written up the process here to explain how I put the exploit together.

Docker is an interesting cgroups-based virtualization alternative that uses containers to deploy applications.

Vim is an excellent text editor. I’ve used it for many years and like most vim users, have collected a fairly large collection of settings in my .vimrc and learned how to grok my vim usage effectively through a lot of trial and error.

To that end, I’ve tried to assemble a useful overview of my experience with vim.

A while back I finally got my 512MB revision 2 model Raspberry Pi to successfully run OpenELEC. The picture to the right shows it running, using a shared network mount to access all of my media files.

Some folks requested a write-up detailing how I put everything together, so I’m going to try and provide a generalized walkthrough for those with the initiative to do something like this. Although I’m not assuming you’re a Linux guru, there’s some technical aspects to this - but it’s worth the effort.

Putting together all the moving pieces to get this blog to work the way I wanted took a little while. In the interest of sharing how I did it in case this helps others, I thought I’d share the approach I took.

This is, hopefully, the beginning of my personal blog entries. I’ve started to blog several times over the years and only gotten this far. We’ll see how this attempt turns out.

I want to write my personal thoughts on here, technical discussions about computing, and pictures of cats in top hats if I have the resources to spare.

My email address is at the bottom of the site. If you want to give me any sort of feedback, go for it.