Drop #266 (2023-05-22): No Cause For Alarm

update-notifier; DIUN; webhook

As has been well-spoken by Alex Kamal, ace pilot of the Rocinante in “Nemesis Games” (one of my fav titles in The Expanse novels): “Things change, and they don’t change back.”

While many of us likely experience notification overload well-before noon on any given day, there are certain classes of notifications (or, “updates”) that are quite useful. One is that mobile device or laptop “critical update” you ignore for a few days before acquiescing to a reboot. You can thank The Great Maker you won't be subjected to a lecture about that in this Drop.

What you will be subjected to are three distinct ways to be notified that “something has changed”, with a promise that they are equally useful in their own contexts.

update-notifier

Photo by Prateek Katyal on Unsplash

Not all useful, modern notifications have to come in thin (height), rounded rectangle containers at the top of your watch/phone/laptop screen. In fact, having a handy “there's a new version of X and this is why you should update it” — with “X” being a valued command line utility (CLI) — can be a pleasant surprise, especially if there's a security-focused update

¹

.

If you use Node.js or thousands of other CLI apps, then you have already seen and used update-notifier. This NPM package that is used in Node.js (et al.) projects to notify users of updates to the project or package. This is especially useful for projects where updates can be frequent and users may not always be aware of the latest version.

It works in the background and will periodically check for updates to the package using it. It does this by sending a request to the npm registry and comparing the current version of the package with the latest version available in the registry. If an update is available, update-notifier will display a message to the user informing them of the update and providing instructions on how to update to the latest version.

Furthermore, it also works asynchronously, and on first use (and subsequent invocations) will (ofc) check for an update. If one is available, it will wait the specified updateCheckInterval in your notifier JSON config before notifying the user. This is done to not be annoying (imagine that!).

Incorporating it into your NPM package is dirt simple:

import updateNotifier from 'update-notifier';

updateNotifier({
  pkg: {
    name: 'my-awesome-package',
    version: '0.1.0',
  },
  updateCheckInterval: 1000 * 60 * 60 * 24, // one day
})
  .notify();

While you could just subscribe to various RSS feeds for update information, I'd bet update-prompt-on-use causes more folks to actually perform an update sooner. Always a good thing, especially for security updates.

DIUN

Photo by Luís Perdigão on Unsplash

I'm pretty horrible about keeping hobby Docker images up-to-date. I try to version pin Docker image pulls since I've been burned by :latest breaking things on me, but that also means missing out on new features and — you guessed it — security updates.

DIUN (GH) (Docker Image Update Notifier) is a CLI application written in Golang and can be used as a normal system binary or via a Docker image. It is designed to provide notifications when a Docker image is updated on any given Docker registry, and supports All The Platforms/Architectures™, including Linux, macOS, and Windows / amd64, i386, ARM, and others.

While you can just run it to see if there are image updates, it works best if you let it run in server mode, where it will regularly check for updates.

It groks that you may not want to be notified for every type of image update, and comes with robust filtering capabilities to ensure you aren't spamming yourself. Furthermore, it supports Docker-proper, Kubernetes (ugh), Swarm, Nomad, Dockerfile, and File providers. And, it meets you where you are in terms of notifications, sporting support for:

• Amqp

• Discord

• Gotify

• Mail

• Matrix

• MQTT

• Pushover

• Rocket.Chat

• Script

• Signal (REST API)

• Slack

• Teams

• Telegram

• Webhook

Given that it's a “watcher” process, who watches the watcher? DIUN itself provides enhanced logging features and supports health checks (via a separate process) to monitor itself, ensuring that your update monitoring is always functioning as expected.

I'm primarily using it to keep up with security updates, which I highly suggest y'all do as well.

webhook

Photo by Grace To on Unsplash

There were many notification channels mentioned in the last section, one of which was a “webhook”. I think most folks grok what those are by now, but in case not: a “webhook” is a method of augmenting or altering the behavior of a web page or web application with custom callbacks. These callbacks may be maintained, modified, and managed by third-party users and developers who may not necessarily be affiliated with the originating website or application.

In other words, a webhook is a way for an app to provide other apps with real-time information. A webhook delivers data to other apps as it happens, meaning you get notified immediately when something changes or some event occurs. This makes webhooks much more efficient for both the provider and the consumer, if your app can handle a lot of incoming HTTP traffic.

When a specified event occurs in the source site (also known as the “provider”), it triggers the webhook, sending an HTTP request to the URL specified by you when you set up the webhook (the “consumer”). This request will contain data about the event that just occurred.

If you use GitHub or other social coding sites, then you most certainly have encountered webhooks. You've also dealt with them if you use Slack, Teams, or other, similar chat apps.

While you can just have a plain ol' web server configured to deal with incoming webhooks, I've found webhook on a Tailscale public endpoint to be a great way to get local home server triggers for internet-based webhooks. It's a super simple Golang server that “aims to do nothing more than it should do”, which is:

• receive an incoming webhook request,

• parse the headers, payload and query variables,

• check if the specified rules for the hook are satisfied,

• and finally, pass the specified arguments to the specified command via command line arguments or via environment variables

It has robust support for trigger rules and great docs overall.

FIN

I hope everyone's Monday is going great! ☮

1. I said no lecture about “OS updates” in the preamble and nothing about continued nags to also do application updates.