The architecture of the infrastructure-as-code (IaC) tooling you use will determine the level to which your IaC definitions are exposed to bit rot.

This is a maxim I have arrived at after working with multiple IaC tool sets, both professionally and personally, over the last few years. In this blog post, I will explain how I arrived at this maxim by describing three architectural patterns for IaC tools, each with differing levels of risk for bit rot.

The AWS CLI is a tool set that lets you manage your AWS resources. The CLI comes in two versions which, at the time of this writing, are developed concurrently: version 1 and version 2.

Internally, the AWS CLIv1 and v2 are quite different. Version 2 pulls in AWS libraries--libraries which are used across the AWS SDK ecosystem--rather than reinventing the wheel when it comes to common tasks, such as talking to Amazon S3. Running AWS CLIv2 on your operating system of choice requires building and installing these common AWS libraries.

I contributed changes to s2n-tls, aws-lc, the Python runtime, some build tooling, and various other libraries. As a result, the AWS CLIv2 now builds and runs on OpenBSD.

To make installation simple, I've created an OpenBSD port for CLIv2 and its dependencies. Instructions for installing the port are below.

"Software is eating the world." Have truer words ever been spoken other than these words by Marc Andreessen?

I've recently been immersed in a number of home automation projects (lights, heating/cooling, presence detection, and more). I was reflecting on what made all of these automations possible: the drastic increase in the amount of software present in the home. As I was reflecting on this, I realized how different my house is in this respect compared to the house I grew up in.

Now, I'm not saying I'm old. More like, the rate of digitization in the world around us has happened at such a pace that even in my short lifetime, the changes have been deep and wide.

This blog post is a tour of things in my house that are software operated that were not software operated in the house I grew up in. For my purposes here, I define "software operated" as any device that has software or firmware that is upgradable either by me or through an over-the-air process that the device or its cloud service initiates. I'm leaving out "obvious" items like laptops, tablets, and mobile phones.

An introduction to Amazon EC2 credentials

When you assign an Identity and Access Management (IAM) role to an Amazon Elastic Compute Cloud (EC2) instance, the short-term credentials for the role are made available via a web service known as the Instance Metadata Service (IMDS). The IMDS provides an HTTP endpoint for retrieving instance metadata such as the instance IP address, AWS Region the instance is running in, the Amazon Machine Image used to launch the instance, and the access key, secret access key, and session token associated with the instance's IAM role. The AWS documentation describes how to retrieve instance role credentials from IMDS. If you've seen or used the http://169.254.169.254 or http://fd00:ec2::254 endpoints, then you've seen/used IMDS.

Retrieval of instance role credentials from IMDS is the mechanism by which the AWS CLI and SDKs learn the credentials belonging to the instance's IAM role without you having to configure anything on the instance. Quoting the IAM documentation:

The AWS SDKs, AWS CLI, and Tools for Windows PowerShell automatically get the credentials from the EC2 Instance Metadata Service (IMDS) and use them.

This is great! It means you can start using the AWS CLI, SDKs, or Tools for Windows PowerShell on an EC2 instance without having to configure any credentials.

However, like most nice things, IMDS can be exploited and used in unintended ways. This blog post will explain how EC2 credentials can be retrieved from IMDS, removed from the EC2 instance, and used outside of EC2. This post will also explain some ways to mitigate this activity.

Passwords suffer from an inherent risk: whoever possess the password inherits the privileges granted by that password. If the possessor is the intended person, then all is good. Otherwise, all is not so good because it means an unintended person has access to the system the password is guarding.

You have:

1. A Roomba vacuum. (I was working with an i-series when I wrote this. Maybe this applies to other models as well.)
2. A firewall or router between your Roomba and your mobile device. (Maybe the two are on different wifi networks as would be the case if you have a network set aside for IoT devices.)
3. An iRobot app that gets stuck at Verify password when setting up the Roomba.

A colleague of mine recently quiped, "'The perimeter' in AWS is actually defined by Identity and Access Management (IAM)." After some reflection, I think my colleague is spot on.

This is a retelling of a presentation I gave at work. In it, I describe a mechanism I've started using to raise the quality of artifacts I check into version control.

I've written before about how I use MediaWiki for taking notes and as one of my study tools. This has worked well for many years. But a problem started to develop: while I wrote my technical notes in MediaWiki, I wrote my day-to-day notes (books I want to read, notes from podcasts I listen to, and even my weekly planner) in Notion. This meant I had to use different apps for reading/writing in each tool, remember two different markup languages, and couldn't (cleanly) link pieces of content between the two. The final straw was realizing how much more effort I had to expend to maintain my MediaWiki instance; I just didn't have the time or will to keep up with new releases not to mention maintain the server itself.

For these reasons, I decided to move all of my MediaWiki content to Notion and unify all of my notes. But this revealed a new problem: there was no tooling to automate this. So I created my own. Here's how it works.

A friend of mine recently had a solar panel system installed on his acreage. Besides being interesting because of the renewable/green aspect of the project, the system itself—from SolarEdge—is actually highly digital.

• A mobile app is used for commissioning the system.
• SolarEdge operates a cloud service which collects telemetry from the system and reports various performance metrics in a user-friendly dashboard.
• The inverters can connect to the IP network and provide a means to collect telemetry from them directly.

The last point interested me the most because any time a device exposes its data or a control connection, it means there's an opportunity to integrate it with other software. In this case, I wanted to create my own dashboard to display (near) real-time performance data for the system.

Whereas other blogs and articles on this topic describe how to monitor a single inverter system, this post will describe how I built a performance dashboard for a multi-inverter system.