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.

In a throwback to the problems I dealt with using AirPlay across VLANs, I recently jumped through similar hoops for Sonos speakers. There are many forum and blog posts out there that describe (or attempt to describe) how to make this work, however all of the ones I read suffered from one or both of these problems:

1. Their instructions had errors (eg, reversing the upstream and downstream interfaces when talking about multicast).
2. They don't have a diagram of traffic flow! Every network engineer knows that a diagram is a must when trying to understand how two systems are talking to each other.

This post will dive deep on what's happening on the wire when a Sonos controller (eg, your mobile phone running the Sonos app) tries to talk with the players (the speakers) on the network. The focus will be how to make this process work when those two devices are in different VLANs.

What you read below works successfully with Sonos Beam, Sonos Sub, and Sonos Move using the Sonos S1 app.

The AWS Cloud Development Kit (CDK) is an "open source software development framework to define your cloud application resources using familiar programming languages". When CDK launched in 2019, I remember reading the announcement and thinking, "Ok, AWS wants their own Terraform-esque tool. No surprise given how popular Terraform is." Months later, my friend and colleague Matt M. was telling me how he was using CDK in a project he was working on and how crazy cool it was.

I finally decided to give CDK a go for one of my projects. Here is what I discovered.

AWS CloudFormation is a service that lets you create a collection of related Amazon Web Services and third-party resources and provision them in an orderly and predictable fashion. A typical access control pattern is to delegate permissions for users to interact with CloudFormation and remove or limit their permissions to provision resources directly. You can grant the AWS CloudFormation service permission to create resources by creating a role that the user passes to CloudFormation when a stack or stack set is created. This can be used to ensure that only pre-authorized services and resources are provisioned in your AWS account. In this post, I show you how to conform to the principle of least privilege while still allowing users to use CloudFormation to create the resources they need.

I have a cron job that renews an SSL certificate from Let's Encrypt, and then restarts the smtpd daemon so that the new certificate is picked up. This all works fine--as proven by both the presence of a new, valid cert on disk, and smtpd successfully restarting--but cron never sends an email with the output of the job. What gives?