DEV Community: Kevin Burns

Improving keyboard ergonomics through dual use keymapping

Kevin Burns — Tue, 23 Jul 2024 20:07:13 +0000

If you’ve followed the online Apple Community then you’ve probably heard of the hyper key. If not, the hyper key is where you map caps lock so that if you hold it down it acts as if you’re holding down ctrl+option+cmd+shift, giving you another “modifier” key. Some people go further by configuring it to act as hyper when held and used with another key and act as escape when you tap it.

I’ve seen a similar use case in the Linux VIM community where you use xcape to map caps lock as ctrl if held and used as a modifier and escape if tapped. I find this very useful and I have a hard time using a computer when it’s not setup this way.

Unfortunately, xcape only works for X11. When I moved to sway I had to find another solution. I’ve tried a few different options and I’ve settled on keyd.

keyd provides more options simply mapping a key to act in two different modes, but that’s what I use it for. I use the following config to have caps lock act as ctrl if used as a modifier and escape if not. Tab is also set to act as a super key if used as a modifier and tab if not. Right control is mapped as f13, which I use as a second modifier for shortcuts in sway.

[ids]
*
[main]
capslock = overload(control, esc)
tab = overload(meta, tab)
rightcontrol = f13

[alt]
tab = A-tab

[ctrl]
tab = C-tab

[shift]
tab = S-tab

The alt, ctrl, and shift modifiers are required to allow modifier+tab for windows management.

Project Homelab: Configuring proxmox with Ansible

Kevin Burns — Sat, 20 Jul 2024 16:45:21 +0000

I received 3 Minisforum MS-01 boxes earlier this week. I’ve set them up identically with the following configuration:

10GE SFP+ setup in a mesh using .5m DAC cables
2.5GE internal network
2.5GE external network
2TB Samsung 990 Pro drive for ceph storage (PCIe 4.0 x 4)
1TB Samsung 990 Evo for Proxmox storage (PCIe 3.0 x 4)
96GB Ram ( 2 x Crucial 48GB DDR5-5600 CT48G56C46S5) Running at 4800MHz

I’m not a fan of configuring my devices via GUI and I don’t like the idea of having to go through the setup motions again if I reinstall the system. Instead I’ve written some Ansible roles to handle the configuration of my cluster. I’ve added them to my ansible-homelab repo.

While there’s a lot of roles for Proxmox on the Ansible Galaxy, none of them stood out to me as ‘this is the one to use’. I wrote my own that is targeted for this specific setup. It will configure the following:

Disable the Proxmox nag screen in the web-ui
Configure the non-subscription apt repos
Configure unattended-upgrades to install upgrades and reboot the server once a week. The server reboot times are staggered so each one will reboot an hour apart.
Setup the network
Join the three nodes to a single cluster
Install and configure Ceph with 2 pools (kubernetes and pve) and 1 CephFS (iso)

I haven’t written any molecule testing for this yet. It’s a little more involved due to needing to expose some virtual disks and either install or have a preinstalled image created. I believe I’ll eventually implement this in Vagrant + QEMU.

Now that I have the basics configured I’ll need to setup email notifications, Let’s Encrypt TLS certs, and Tailscale. I’ll be using Amazon SES and Route53 for these services. My next task is to write the Terraform code to configure those.

Fix wezterm’s terminfo on arch

Kevin Burns — Sat, 20 Jul 2024 15:58:26 +0000

Arch Linux pulls the terminfo for wezterm from the ncurses package. This contains an older terminfo that doesn’t contain as many features. For example, neovim’s set title doesn’t work with this terminfo.

An easy way to fix this is to build the terminfo from wezterm’s github repo

curl https://raw.githubusercontent.com/wez/wezterm/main/termwiz/data/wezterm.terminfo | tic -x -

Wezterm QuickSelect

Kevin Burns — Tue, 09 Jul 2024 13:50:44 +0000

After using tmux for more than a decade, I’ve recently moved away from it and switched to using the multiplex features in wezterm. One of my favorite plugins for tmux is tmux-thumbs. This allowed me to write patterns using regex and press a shortcut to highlight those patterns. It would give me a set of quick keys I could type that would then either copy the text to my clipboard or paste it to the command line. This comes in very handy when using kubectl and dealing with pod names.

Wezterm has a similar feature called QuickSelect. The following config will create a LEADER-f shortcut for selecting the string and pasting it into the command prompt and LEADER-F to copy it to the clipboard.


local config = wezterm.config_builder()
config.keys = {
    {
        key = "f",
        mods = "LEADER",
        action = act.QuickSelectArgs({
            label = "paste",
            action = wezterm.action_callback(function(window, pane)
                local selection = window:get_selection_text_for_pane(pane)
                pane:paste(selection)
            end),
        }),
    },
  { key = "F", mods = "LEADER", action = act.QuickSelect },
}
config.quick_select_patterns = {
  "[a-z]+(?:-[a-z0-9]+)+-[a-z0-9]+",
}
return config

Project Homelab: Kubernetes the Complex Way

Kevin Burns — Sun, 23 Jun 2024 19:46:02 +0000

There’s a joke that Kelsey Hightower wrote Kubernetes The Hard Way because there isn’t an easy way. While this may be less true today, Kubernetes can still be incredibly complex. Kubernetes is essentially a platform for creating platforms. The core functionality doesn’t require a large amount of understanding. However, Kubernetes brings a lot of additional components. Its pods and services are compartmentalized in a microservices format. It doesn’t hide the operational aspects around deploying and maintaining network-accessible applications. These pieces, while not considered ‘core Kubernetes,’ are essential to understand in order to use it effectively.

Project Homelab

There are many good resources available for learning the basics of Kubernetes, such as the syntax, setting up pods and networks, and tying everything together. However, there’s much more to learn. I am redoing my homelab and will be starting a series of blog posts on the setup process. This includes:

Creating a reusable and shareable dev environment
Automating every aspect of the cluster using tools like Ansible, ArgoCD, and Terraform
Implementing Build pipelines using GitHub actions
Baseline services, such as service mesh, secret store, certificate management, logging, observability
Securing Kubernetes

I’ll be using a “bare metal” setup with VMs on top of Proxmox. There are different concerns when using Kubernetes on bare metal compared to the cloud. In the cloud, you can benefit from a managed Kubernetes cluster and offload state to cloud-based databases, allowing you to focus on stateless applications. On bare metal, you may need to run databases within the cluster.

Hardware

I’m trying to keep my setup small. For my initial setup, I’ll be using three machines:

A Raspberry Pi 4 8GB to run DHCP, DNS, installation images, and Authentication services
An Intel box with 64GB of RAM that will be used as a development / workstation machine.
An AMD box with 128GB of RAM that will run Proxmox for the Kubernetes VMs

What’s next

The initial setup requires quite a bit of preparatory work, sometimes called “yak shaving.” I’m not looking to create a bespoke Kubernetes cluster by hand. Instead, I will be automating as much as possible and providing a good developer experience for working with the automation.

In my next post, I’ll discuss setting up a Git repository for Ansible, including devcontainers, GitHub Actions, and pre-commit hooks. This will be used to manage the configuration of the Raspberry Pi and workstation nodes.

Two Ideas from the Lean Movement

Kevin Burns — Wed, 12 Jun 2024 20:10:03 +0000

It’s been 10 years since I first started learning about DevOps. I was in some airport waiting to go home from a pentest and I was looking through ruby and chef videos on youtube when I came across Jez Humble’s ChefConf 2015 Keynote and it blew me away.

I started my career as a Linux and Solaris sysadmin and moved into security consulting about a decade later. I must have heard some mention of DevOps before then. I had a copy of The Phoenix Project, but didn’t get that far into it. It reminded me too much of my old jobs and I didn’t want to read a book that mirrored my past experiences.

I’ve since watched countless hours of conference talks, attended multiple DevOps Days cons, and read multiple books on DevOps. This led me to the lean manufacturing movement and books by Demming and Goldratt. There’s two ideas that have stayed with me since I first heard them.

Taking Advantage of Technology Requires Change

Beyond the Goal is an amazing set of lectures from Eliyahu M. Goldratt. While there’s a few topics he goes over, the first one is the most applicable to my job. Dan North also did a talk on it in 2017 called How to Break the Rules, which provides more modern examples.

“Technology can bring benefit if, and only if, it diminishes a limitation” – Eliyahu M. Goldratt

Eliyahu starts off with this quote, then provides four questions we can ask ourselves relating to this.

What is the power of the technology?
What limitation does the technology diminish?
What rules enabled us to manage this limitation?
What new rules will we need?

The idea is that when we start working we find a set of limitations that we have. In order to deal with these limitations we create rules. These rules help us cope with the limitations and provide a framework we can use to handle them. Before teleworking became common we were limited to getting jobs that we could reasonable get to every workday. If there was a job in another state we normally had to move if we wanted to work there. With the rise of high speed internet and the numerous communication methods that we now have this limitation has diminished. Some jobs no longer require being there in person to complete. This allows us to change the rules to allow people the ability to work from home.

This also means that we should take a look at anything we implement and determine what it provides and what limitations does it diminish. Let’s say your team did integration testing once a month due to issues with the tech stack and the amount of hardware and cooperation required. It’s then decided that they want to bring in a platform team and develop a build pipeline that can do an end to end integration test every night. You’ve gone from being able to do this task 12 times a year, to 365 times. This is great news!

However, there are some questions you should ask yourself in this situation:

Did anyone look at what rules were in place due to only being able to do this once a month?
Did someone take a look at all the meetings and change approvals that were implemented to deal with the difficulty with the old way?
Were you able to change those rules to take better advantage of the technology?
If you don’t change how you perform your work to take advantage of the new technology, then what benefit did the new technology actually give you? It may not be needed for your day to day feature implementation side, but any time you change your teams workflow you should ask yourself Eliyahu’s four questions listed at the start of this section.

Provide Context, Not Solutions

“It is not enough to do your best; you must know what to do and then do your best” – W. Edwards Demming

There’s a common pattern I see all over. A system gets designed by managers and architects and then the solutions are handed down to the workers to implement. The people doing the implementation aren’t given the time or leeway to learn what they’re doing or how to do it. They’re not even given much context beyond the solution. Maybe they’ve never even been taught that they should have more than this. The solutions are created based on previous experiences and grand idea conference room designing. The design is implemented. Tested based on the prescribed solution. It goes into production and breaks. It isn’t designed to handle the scale, or it has a bad data model. Maybe the solution provided had nothing to do with what the problem actually was.

I’m not sure how anyone can expect someone to succeed if they don’t know what they’re doing. While this does relate to people needing to hone their skills outside of work, I’m mostly looking at it from the perspective of providing context and the ability to learn and experiment. People are not mindless machines designed to perform a singular task. They need to know why they’re doing a task. Management needs to provide context. Demming talks about this in one of his interviews.

Provide context, not solutions. By giving your employees the ability to grow and the opportunity to have their say in the work they perform, you’ll find greatness. They will generally be able to make better decisions because they are closer to the problem and have more hands-on information than the people who white boarded it 4 months prior to the start of the project.