The legislation

Colorado legislation: SB26-051 Age Attestation on Computing Devices

California legislation: AB-1043 Age verification signals: software applications and online services

The Colorado legislation is mostly the same as CA from what I’ve read so I’m just going to highlight the points for CA.

“Operating system providers”

“Operating system provider” means a person or entity that develops, licenses, or controls the operating system software on a computer, mobile device, or any other general purpose computing device.

With this definition, anyone who forks nixpkgs could potentially fall under the category of “operating system developer” because that fork could be used as a source of truth to build NixOS. Clearly this bill did not have open source operating systems/development pipelines in mind. As implied by other users in this thread, I suspect the only real point of enforcement will be hardware vendors and their out-of-the-box operating systems.

MacOS

While MacOS doesn’t have anything rolled out yet, Apple will surely comply with this and bake it into MacOS. Perhaps this will enable Apple to go the route of Windows and force users on threat of death to login with an Apple account.

As a nixpkgs Darwin contributor, I’m sad about this, but am not surprised and will be exiting the Apple ecosystem even further.

“Covered application stores”

“Covered application store” means a publicly available internet website, software application, online service, or platform that distributes and facilitates the download of applications

So, in my view, nixpkgs probably falls into this “covered application store” category – but again, anyone can fork it, modify it, etc. – there’s no reasonable way to enforce this as literally anybody could fork nixpkgs, redistribute, modify, etc.

Constraints/requirements

Ages they care about:

(1) Whether a user is under 13 years of age.

(2) Whether the user is at least 13 years of age and under 16 years of age.

(3) Whether the user is at least 16 years of age and under 18 years of age.

(4) Whether the user is at least 18 years of age.

Thee assertions they make for operating system providers:

1. Provide a way for a user to indicate their age bracket in the operating system
2. Provide a way for a developer to consume the age of bracket of the user
3. The operating system/app store must enforce restrictions around apps and age limits (I’m assuming not allowing users to install apps that are not appropriate relative to their age)

Penalties

People – I’m guessing operating system developers – in violation of the title shall be subject to a fine:

not more than two thousand five hundred dollars ($2,500) per affected child for each negligent violation or not more than seven thousand five hundred dollars ($7,500) per affected child for each intentional violation

Due date in CA

This title shall become operative on January 1, 2027.

Specific Linux distributions discourse

Ubuntu: On the unfortunate need for an “age verification” API for legal compliance reasons in some U.S. states

Pop! OS: System76 Principal Engineer response

Note: Pop! OS is made by System76, which is based out of Denver, Colorado – therefore, they are uniquely impacted.

Arch Linux: California Age verification craziness

NixOS: Compliance with U.S. age verification laws

Even if your preferred Linux distribution isn’t based in the United States, this will surely have ripple effects with large corporations like Red Hat and Canonical contributing and maintaining much of the modern Linux applications and services that enable its widespread use.

Why this is stupid

First, it violates privacy, and doesn’t offer any meaningful protections for children. Applications greedy for user data will surely abuse the data about the verified ages of users (children and adults) on computers.

Second, open source operating systems can be forked by anybody and re-distributed. The legislation clearly isn’t designed to scale with something like NixOS.

Third, there’s no meaningful way to scale enough to actually enforce this for open source operating systems.

What this means

In theory, this means that anybody distributing an operating system could be liable for this (i.e. any one of the 18,000+ forks of nixpkgs on GitHub). In practice, I think this will be enforced against hardware vendors and the operating systems they bundle with brand new hardware.

But, as a US Citizen I consider this a big downgrade for my privacy.

Misc

I posted a less opinionated version of this on the NixOS Discourse post regarding this topic: Compliance with U.S. age verification laws

Obligatory note: none of my perspective represents my employer.

Relevant Home-Manager configurations for the curious:

• Todoman wrappers: github:heywoodlh/nixos-configs - home/base.nix#L12-L29
• Todoman configuration: github:heywoodlh/nixos-configs - home/base.nix#L613-L624
• GitHub CLI module: github:heywoodlh/nixos-configs - home/modules/gh.nix

TL;DR use these settings for CalDav/CardDav on iCloud

Remember to set up an App-specific Password for authentication.

• https://contacts.apple.com: Contacts
• https://caldav.icloud.com*: Calendar, Reminders

* In order to use the same calendars/reminders on iOS and other platforms, you must configure an external CardDav/CalDav account for iCloud on iOS. The built-in iCloud Reminders/Calendar that is setup after logging into doesn’t use traditional CalDav.

Why use iCloud?

I recently switched away from an iPhone as my daily driver to GrapheneOS on a Pixel 8. However, I still have an iPad and switch regularly between Linux and MacOS when I’m on a workstation. So, I wanted to use iCloud due to Apple’s (often overhyped) adherence to privacy but relying on endpoints that will work with clients that support CalDav and CardDav.

As a long-time Proton user, why not use Proton?

* Traditional CalDav and CardDav clients don’t work with Proton.

Proton offers a variety of end-to-end encrypted cloud services rivaling iCloud. However, Proton isn’t as portable since they break the protocols to ensure end-to-end encryption. While I think Proton is the superior suite of products from a privacy perspective, they are less functional for traditional protocols like CardDav and CalDav.

* Check out Ferroxide for a third-party, open source solution that exposes CalDav and CardDav endpoints that integrate with Proton.

Platforms and clients I’m using

Reminders, calendars

• Linux, MacOS: vdirsyncer, todoman
• Android: , [DAVx⁵](https://www.davx5.com)
• iOS*: Native clients/settings

* As stated in the first TL;DR in order for iOS to show the same reminders and calendars as the other platforms, you need to add an “external” CalDav account for iCloud since the built-in iCloud integration for Reminders and Calendars doesn’t use the same CalDav endpoint.

Contacts

• Linux, MacOS: vdirsyncer, khard
• Android: DAVx⁵
• iOS: Native clients/settings

Android setup with DAVx⁵

I won’t be going in-depth on Android setup, use the settings in the TL;DR at the beginning and use DAVx⁵’s wizard to set them up.

Tasks.org integration

Use the following article to setup tasks.org with DAVx⁵: tasks.org: DAVx⁵

Linux/MacOS configuration

Vdirsyncer configuration

Vdirsyncer is a tool for downloading CalDav and CardDav data locally.

Here is my configuration – using 1Password’s CLI for retrieving credentials – at the time of writing:

[general]
status_path = "/home/heywoodlh/.config/vdirsyncer/status/"

## Calendar/Reminders

[pair icloud_calendar]
a = "apple_local"
b = "apple_remote"
collections = ["from b", "from a"]

[storage apple_local]
type = "filesystem"
path = "~/.todo/apple"
fileext = ".ics"

# Reminder, this is not the iOS-provided iCloud integration
# All devices (i.e. Apple devices) who want to see this should be using caldav
[storage apple_remote]
type = "caldav"
item_types = ["VTODO"]
url = "https://caldav.icloud.com"
username.fetch = ["shell", "op item get '<some-item>' --fields label=username --reveal"]
password.fetch = ["shell", "op item get '<some-item>' --fields label=app-password --reveal"]

## Contacts

[pair icloud_contacts]
a = "apple_remote_contacts"
b = "apple_local_contacts"
collections = [["icloud_contacts", "card", "main"]]
conflict_resolution = "a wins"
metadata = ["displayname"]

[storage apple_local_contacts]
type = "filesystem"
path = "~/.contacts/apple"
fileext = ".vcf"

[storage apple_remote_contacts]
type = "carddav"
url = "https://contacts.icloud.com"
username.fetch = ["shell", "op item get '<some-item>' --fields label=username --reveal"]
password.fetch = ["shell", "op item get '<some-item>' --fields label=app-password --reveal"]

Once Vdirsyncer is configured, run the following to download data:

vdirsyncer discover
vdirsyncer sync

Khard configuration

Here is my khard configuration at the time of writing:

[addressbooks]
[[personal]]
path = ~/.contacts/apple/main

List all contacts with this command:

khard list

Aerc configuration

[protonmail]
address-book-cmd = khard email -a personal --parsable --remove-first-line %s
aliases = Spencer Heywood <*@protonmail.com>,Spencer Heywood <*@pm.me>, Spencer Heywood <heywoodlh@heywoodlh.io>
copy-to = Sent
default = INBOX
from = Spencer Heywood <spencer@heywoodlh.io>
outgoing = smtp+insecure://<some-user>%40protonmail.com@protonmail-bridge:25
outgoing-cred-cmd = op read '<some-item>'
source = imap+insecure://<some-user>%40protonmail.com@protonmail-bridge:143
source-cred-cmd = op read '<some-item>'

I use Protonmail Bridge over Tailscale for SMTP+IMAP.

Here is my Kubernetes deployment for Protonmail Bridge at the time of writing: protonmail-bridge.yaml

In accounts.conf

[protonmail]
from = Spencer Heywood <spencer@heywoodlh.io>
aliases = Spencer Heywood <*@protonmail.com>,Spencer Heywood <*@pm.me>
<snip>

This configuration will assume I want to use spencer@heywoodlh.io as my reply address (the default address for this custom domain) unless the recipient of the email is my protonmail.com email address or my additional pm.me address. Alternatively, you could provide the full address of your Protonmail addresses in the aliases section.

This is required because Protonmail has an irritating limitation on sending addresses.

BONUS

Aerc configuration at the time of writing: home/base.nix#programs.aerc

My Protonmail Bridge Kubernetes deployment at the time of writing: protonmail-bridge.yaml

This is mostly a reposting of my PR to nixpkgs: k3s: add intel gpu docs

Intel GPU Support in k3s

This post makes the following assumptions:

1. services.k3s.enable is already set to true
2. The Linux kernel running is modern enough to support your GPU out of the box
3. The desired driver is i915 – modify as needed for other drivers

Note: at the time of writing, I was using an Intel Arc A770 in k3s. The majority of this guide likely should work on other Kubernetes distributions, and will likely work identically for integrated graphics capabilities.

Enable the Intel driver in NixOS

Add the following NixOS configuration to enable the Intel driver (necessary on headless deployments):

services.xserver.videoDrivers = [ "i915" ];

After rebuilding the configuration, reboot the host for the GPU driver to be assigned to the GPU. Use the following command to ensure the GPU is using the i915 kernel:

sudo lspci -k

i.e. the output looks like this on a host with the Intel Arc A770:

❯ sudo lspci -k | grep -A 3 'Arc'
03:00.0 VGA compatible controller: Intel Corporation DG2 [Arc A770] (rev 08)
        Subsystem: ASRock Incorporation Device 6010
        Kernel driver in use: i915
        Kernel modules: i915, xe

Install Intel Node Feature Discovery (NFD) in k3s

Intel’s device plugin for kubernetes provides Node Feature Discovery (NFD). NFD allows for GPU capabilities on a node to be automatically discovered if a discrete GPU is installed and the Intel drivers have been properly assigned.

Documentation for Intel NFD installation is here for reference: Install with NFD

The following commands will install NFD in the cluster (assumes curl, jq and kubectl are all installed/configured):

# Use the latest release
export LATEST_RELEASE=$(curl -s https://api.github.com/repos/intel/intel-device-plugins-for-kubernetes/releases/latest | jq -r '.tag_name')

# Use Kustomize to deploy the configuration
kubectl apply -k "https://github.com/intel/intel-device-plugins-for-kubernetes/deployments/nfd?ref=$LATEST_RELEASE"
kubectl apply -k "https://github.com/intel/intel-device-plugins-for-kubernetes/deployments/nfd/overlays/node-feature-rules?ref=$LATEST_RELEASE"
kubectl apply -k "https://github.com/intel/intel-device-plugins-for-kubernetes/deployments/gpu_plugin/overlays/nfd_labeled_nodes?ref=$LATEST_RELEASE"

NFD should automatically apply relevant labels to your node. This can be verified with the following command:

kubectl get nodes -o yaml | grep gpu.intel.com | sort -u

Output should look similar to the following:

❯ kubectl get nodes -o yaml | grep gpu.intel.com | sort -u
      gpu.intel.com/device-id.0300-56a0.count: "1"
      gpu.intel.com/device-id.0300-56a0.present: "true"
      gpu.intel.com/family: A_Series
      gpu.intel.com/i915: "1"
      gpu.intel.com/i915_monitoring: "0"
      nfd.node.kubernetes.io/feature-labels: gpu.intel.com/device-id.0300-56a0.count,gpu.intel.com/device-id.0300-56a0.present,gpu.intel.com/family,intel.feature.node.kubernetes.io/gpu

Note: gpu.intel.com/i915: "1" indicates only one pod can use the GPU – see below for a fix.

Now, GPU-enabled pods can be run with this configuration:

spec:
  containers:
    resources:
      requests:
        gpu.intel.com/i915: "1"
      limits:
        gpu.intel.com/i915: "1"

Allowing more than one pod to use the GPU

In the default configuration, only one pod can use the GPU. To enable multiple pods to use the GPU, apply the following Kustomize patch:

patches:
- target:
    kind: DaemonSet
    name: intel-gpu-plugin
  patch: |
    - op: add
      path: /spec/template/spec/containers/0/args
      value:
        - -shared-dev-num=10

Or, manually edit the intel-gpu-plugin DaemonSet to run with -shared-dev-num=10 (or however many max pods can access the GPU), like so:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: intel-gpu-plugin
spec:
    spec:
      containers:
      - args:
        - -shared-dev-num=10

Verify the number has been applied like so:

kubectl get nodes -o yaml | grep gpu.intel.com/i915 | sort -u

i.e. in this configuration, up to 10 pods can use the GPU:

❯ kubectl get nodes -o yaml | grep gpu.intel.com/i915 | sort -u
    gpu.intel.com/i915: "10"

Test pod

This is a complete pod configuration for reference/testing:

---
apiVersion: v1
kind: Pod
metadata:
  name: intel-gpu-test
  namespace: default
spec:
  containers:
  - name: intel-gpu-test
    image: docker.io/ubuntu:24.04
    command: [ "/bin/bash", "-c", "--" ]
    args: [ "while true; do sleep 30; done;" ]
    resources:
      requests:
        gpu.intel.com/i915: "1"
      limits:
        gpu.intel.com/i915: "1"

Once the pod is running, use the following command to test that the GPU is available:

kubectl exec -n default -it pod/intel-gpu-test -- ls /dev/dri

If the GPU is available, the output will look like the following:

❯ kubectl exec -n default -it pod/intel-gpu-test -- ls /dev/dri
by-path  card1  renderD128

Delete the pod so as to not count against the GPU limit:

kubectl delete -n default pod/intel-gpu-test

Additional deployment examples:

Plex with Intel GPU passthru

Ollama with Intel GPU passthru

This is a reposting of a meeting from the Unix User Group I help run

Getting Started with Ansible

This tutorial will walk you through some basic Ansible principles. All resources used in this tutorial can be found here:

https://github.com/central-utah-lug/meetings/tree/main/2023/May/25

By the end of the tutorial, you will use Ansible to deploy a server on DigitalOcean, do some basic maintenance on the server, and destroy the server.

Requirements

Use my Docker container:

docker run -it --rm docker.io/heywoodlh/ansible-demo

In the Docker container, all of the playbooks in this post are located in the /ansible-demo/playbooks directory.

Additionally, the following packages are available in the container:

• ansible
• doctl
• edit (Microsoft Edit)
• nano
• vim

A DigitalOcean account:

• Create an API token with Read and Write permission to use for this tutorial (save it somewhere like a password manager): https://cloud.digitalocean.com/account/api/tokens

Deploy a server with DigitalOcean’s Ansible module

First, let’s create a new directory and move into it for all of our commands:

mkdir -p /tmp/ansible-demo
cd /tmp/ansible-demo

Install the Ansible DigitalOcean collection, using ansible-galaxy:

ansible-galaxy collection install community.digitalocean

Before we can run any Ansible things against DigitalOcean’s API, we need to set an API token environment variable for Ansible to use:

export DO_API_TOKEN="contents-of-api-token"

Deploy the server

Now, create a file at playbooks/create-server.yml with the following commands:

mkdir -p playbooks

cat >playbooks/create-server.yml <<EOL
---
- hosts: localhost
  tasks:

  - name: gather information about digitalocean ssh keys
    community.digitalocean.digital_ocean_sshkey_info:
    register: ssh_keys

  - name: set sshkey_pub_id when ansible-demo key exists
    set_fact:
      sshkey_pub_id: "{{ ssh_keys.data | selectattr('name', 'equalto', 'ansible-demo') | map(attribute='id') | first }}"
    ignore_errors: true

  - name: create ssh key without passphrase at /tmp/ansible-demo-id_rsa
    ansible.builtin.command: ssh-keygen -b 2048 -t rsa -f /tmp/ansible-demo-id_rsa -N ""
    when: sshkey_pub_id is not defined

  - name: read contents of /tmp/ansible-demo-id_rsa.pub
    ansible.builtin.command: cat /tmp/ansible-demo-id_rsa.pub
    register: sshkey_pub
    when: sshkey_pub_id is not defined

  - name: upload ssh key to digitalocean
    community.digitalocean.digital_ocean_sshkey:
      name: "ansible-demo"
      ssh_pub_key: "{{ sshkey_pub.stdout }}"
      state: present
    register: result
    when: sshkey_pub_id is not defined

  - name: set sshkey_pub_id when ansible-demo key exists
    set_fact:
      sshkey_pub_id: "{{ result.data.ssh_key.id }}"
    when: sshkey_pub_id is not defined

  - name: create a new digitalocean server
    community.digitalocean.digital_ocean_droplet:
      state: present
      name: ansible-demo
      size: s-1vcpu-1gb
      region: sfo3
      image: ubuntu-22-04-x64
      wait_timeout: 500
      ssh_keys: 
      - "{{ sshkey_pub_id }}" 
      unique_name: true
    register: my_droplet
EOL

Now, run the playbook:

ansible-playbook playbooks/create-server.yml

Add the server to inventory

Ansible uses something called “inventory” to track remote servers that you want to run tasks against. Now that the server is created, let’s create an inventory file manually (you can use Ansible to programmatically do this, but for the sake of learning, let’s do it manually).

Create an inventory file named hosts with the IP of the demo server with the following one-liner:

echo "ansible-demo ansible_host=$(doctl --access-token="${DO_API_TOKEN}" compute droplet list | grep ansible-demo | awk '{print $3}') ansible_user=root ansible_ssh_private_key_file=/tmp/ansible-demo-id_rsa" | tee hosts

Now, we can run Ansible playbooks against the ansible-demo server!

Test connectivity to the ansible-demo server defined in the inventory with Ansible’s ping module:

ansible ansible-demo -i hosts -m ping

Some simple playbook examples to run against your host

We will now create some example playbooks to run against the new ansible-demo server in our Ansible inventory.

Create a user

A common system administration task on remote servers is to manage users. So let’s create a new user named tempuser with Ansible.

Create a file at playbooks/adduser-tempuser.yml with the following commands:

cat >playbooks/adduser-tempuser.yml <<EOL
---
- hosts: ansible-demo
  tasks:
  - name: create tempuser 
    ansible.builtin.user:
      name: tempuser
      uid: 1050
      shell: /bin/bash
  - name: create /home/tempuser/.ssh
    ansible.builtin.file:
      state: directory
      path: /home/tempuser/.ssh
      owner: tempuser
      mode: 0700
  - name: use previously generated ssh key as ~/.ssh/authorized_keys file for tempuser
    ansible.builtin.copy:
      src: /tmp/ansible-demo-id_rsa.pub
      dest: /home/tempuser/.ssh/authorized_keys
      owner: tempuser
      mode: 0600
EOL

Now, let’s run the playbook, using the newly created hosts file as inventory:

ansible-playbook -i hosts playbooks/adduser-tempuser.yml

To ensure that this worked, let’s use Ansible’s ping module, but let’s supply a different user this time.

First, let’s supply an invalid user so we can see how it looks when this fails:

ansible ansible-demo -e "ansible_user=invalid-user" -i hosts -m ping

Now, let’s try with the new tempuser user that we created earlier:

ansible ansible-demo -e "ansible_user=tempuser" -i hosts -m ping

Install some packages

Another common systems administration task is to install packages. So, let’s use Ansible to ensure the latest version of a couple of packages is installed for anyone on the ansible-demo system to use.

Before we install the packages, run this command to see if the packages currently exist on the system (replace server-ip with the public IP address of your server):

ansible ansible-demo -i hosts -m ansible.builtin.command -a "dpkg -l" | grep -E 'emacs|neofetch|python3-pip'

The command should return nothing, meaning that none of the packages we are about to install are currently installed on the ansible-demo system.

Create playbooks/install-packages.yml with the following command:

cat >playbooks/install-packages.yml <<EOL
---
- hosts: ansible-demo
  tasks:
  - name: install latest version of various packages with apt
    ansible.builtin.apt:
      update_cache: yes
      pkg:
      - emacs
      - neofetch
      - python3-pip
EOL

Now, run the playbook:

ansible-playbook -i hosts playbooks/install-packages.yml

To be sure that the packages were actually installed, let’s run a command on the server to verify each of those packages exist:

ansible ansible-demo -i hosts -m ansible.builtin.command -a "dpkg -l" | grep -E 'emacs|neofetch|python3-pip'

Destroy the server:

Create destroy-server.yml with the following content to remove the SSH key and server created in create-server.yml:

cat >playbooks/destroy-server.yml <<EOL
---
- hosts: localhost
  tasks:

  - name: gather information about digitalocean ssh keys
    community.digitalocean.digital_ocean_sshkey_info:
    register: ssh_keys

  - name: set sshkey_pub_id when ansible-demo key exists
    set_fact:
      sshkey_pub_id: "{{ ssh_keys.data | selectattr('name', 'equalto', 'ansible-demo') | map(attribute='id') | first }}"
    ignore_errors: true

  - name: remove ssh key from digitalocean
    community.digitalocean.digital_ocean_sshkey:
      name: "ansible-demo"
      id: "{{ sshkey_pub_id }}"
      state: absent
    when: sshkey_pub_id is defined

  - name: destroy ansible-demo digitalocean server
    community.digitalocean.digital_ocean_droplet:
      state: absent
      name: ansible-demo
      wait_timeout: 500
      unique_name: true
EOL

Now, run the playbook:

ansible-playbook -i hosts playbooks/destroy-server.yml

Alternatively, these commands could be used to clean everything up with doctl:

doctl compute --access-token="${DO_API_TOKEN}" droplet delete $(doctl compute --access-token="${DO_API_TOKEN}" droplet list | grep ansible-demo | awk '{print $1}')
doctl compute --access-token="${DO_API_TOKEN}" ssh-key delete $(doctl compute --access-token="${DO_API_TOKEN}" ssh-key list | grep ansible-demo | awk '{print $1}')

Notification Infrastructure

It’s important for significant security events to be made visible to administrators.

NTFY

I use NTFY to receive push notifications – although, as described below, I mirror those notifications to Signal.

NTFY deployment in Kubernetes: ntfy.yaml

As an example, here is how I monitor all SSH login attempts on my NixOS servers with NTFY: sshd-monitor.nix

NTFY Signal Mirror

I wrote the following tool to mirror notifications I get in specific ntfy topics to Signal: github:heywoodlh/signal-ntfy-mirror

I won’t describe how it all works, but here’s the NixOS implementation for those willing to figure it out themselves: ntfy-signal.nix

The resulting Signal alert messages look like this:

Logging

Good logging infrastructure is a critical security component.

Syslog-ng

Syslog-ng, in my opinion, is the underrated GOAT of logging. It’s minimal, yet can do so much.

Syslog-ng deployment in Kubernetes: syslog.yaml

The deployment also contains configurations for the following two tools to quickly search the logs:

• logbash
• lnav

Here is how looking up failed SSH login attempts with my logbash deployment looks:

❯ logbash linux ssh-failed-login
/logs/linux/2025_07_23.log:Jul 23 21:30:56 ts-syslog-6d6kv-0 <86>1 2025-07-23T15:30:56-06:00 nix-nvidia sshd-session 2354768 - - Failed keyboard-interactive/pam for invalid user fakeuser from 192.168.1.48 port 63139 ssh2
/logs/linux/2025_07_23.log:Jul 23 21:30:56 ts-syslog-6d6kv-0 <86>1 2025-07-23T15:30:56-06:00 nix-nvidia sshd-session 2354768 - - Connection closed by invalid user fakeuser 192.168.1.48 port 63139 [preauth]
/logs/linux/2025_07_23.log:Jul 23 21:30:56 ts-syslog-6d6kv-0 <30>1 2025-07-23T15:30:56-06:00 nix-nvidia s7wypw6qzlva5z7m58zl2szjq7p0c1ks-sshd-monitor 2354781 - - {"id":"xvFYOYQpzn53","time":1753306256,"expires":1753349456,"event":"message","topic":"ssh-notifications","message":"Jul 23 15:30:56 nix-nvidia sshd-session[2354768]: Failed keyboard-interactive/pam for invalid user fakeuser from 192.168.1.48 port 63139 ssh2"}
/logs/linux/2025_07_23.log:Jul 23 21:30:56 ts-syslog-6d6kv-0 <30>1 2025-07-23T15:30:56-06:00 nix-nvidia s7wypw6qzlva5z7m58zl2szjq7p0c1ks-sshd-monitor 2354785 - - {"id":"hOCAbts9lJ6X","time":1753306256,"expires":1753349456,"event":"message","topic":"ssh-notifications","message":"Jul 23 15:30:56 nix-nvidia sshd-session[2354768]: Connection closed by invalid user fakeuser 192.168.1.48 port 63139 [preauth]"}

Syslog-ng to NTFY alert/notification

I want to draw special attention to the fact that syslog-ng can run actions on specific matches. This is especially powerful when you want certain log messages to trigger events.

In my case, I want specific logs to trigger NTFY alerts. I couldn’t find any reference examples when trying to set this up, so I hope this saves anybody wanting to do this some time.

Here’s a snippet from my syslog-ng configuration that triggers an NTFY notification on a match:

source unifi_remote {
  udp(ip(0.0.0.0) port(514));
};

destination ntfy {
  http(
    url("http://ntfy.default.svc.cluster.local/security-notifications")
    method("POST")
    user-agent("syslog-ng User Agent")
    headers("Title: syslog-ng alert ${HOST}")
    body("${ISODATE} ${MESSAGE}")
  );
};

# All noteworthy ssh events
filter ssh_events {
  message("(Failed password|Invalid verification code|Invalid user|Accepted publickey|Accepted password|Accepted keyboard-interactive|Failed keyboard-interactive).*");
};

# unifi ssh notifications
log {
  source(unifi_remote);
  filter(ssh_events);
  destination(ntfy);
};

Endpoint monitoring

I use a handful of tools for monitoring my servers and workstations.

Using FleetDM Policies for determining endpoint posture

FleetDM is an open source endpoint monitoring solution built around OSQuery. OSQuery is perhaps the only solution I know of wherein one can get the state of a machine without administrative shell access and with minimal invasion of privacy.

FleetDM deployment in Kubernetes: fleetdm.yaml

MacOS FleetDM configuration

Installation of the fleetctl-generated installer for MacOS, hosted on a web server in my Tailnet: base.nix

As a Nix-Darwin and Home-Manager here’s where I configure my Mac relevant to Fleet:

• Fleet installation: github:heywoodlh/nixos-configs – darwin/roles/base.nix#L62-77
• Defaults implementation: github:heywoodlh/nixos-configs – home/modules/darwin-defaults.nix

And, here’s how the Macs show up on Fleet after they are configured:

Linux configuration

NixOS configuration for OSQuery: osquery.nix

Ubuntu servers installing the FleetDM generated package with Ansible: security.yml

Vulnerability scanning

I have at least two solutions for vulnerability scanning at the time of writing.

Nuclei for web scanning

I use Nuclei from Project Discovery for automated vulnerability scanning in my cluster.

Nuclei deployment in Kubernetes: nuclei.yaml

The features in my deployment are the following:

• Automatic enumeration of Kubernetes services as targets for Nuclei to scan
• Upload of results to projectdiscovery.io’s dashboard

Flan Scan (nmap + vulners) for network vulnerability scanning

For a simple, less web-focused vulnerability scan, I use Cloudflare’s Flan scanner which is as a wrapper around nmap and the vulners script that produces a report of the findings.

Flan scan deployment in Kubernetes: flan-scan.yaml

Fprint + laptop fingerprint reader + clamshell on Linux’s problem

I have multiple Linux laptops with built-in fingerprint readers that I use with Fprint to login via my fingerprint on Linux. Clamshell mode (having the laptop closed but still usable with an external display, keyboard, and trackpad) with Fprint presents a very annoying default behavior: if you use Fprint for sudo (i.e. in a terminal), it will prompt you for a fingerprint when the laptop is closed and will not time out for about 20 seconds. This is very annoying! Additionally, I use 1Password’s system authentication option to be able to use my fingerprint to login to 1Password and it suffers from the same issue.

Brief NixOS plug:

At the time of writing, I have a pull request opened in nixpkgs to fix this: nixos/pam: option to disable fprint if laptop lid is closed

This is what the implementation looks like for my X13: nixos/hosts/x13/configuration.nix

I won’t cover in this post how to consume my branch in NixOS.

Script to detect laptop lid state: lid.sh

One could use something like this script to detect the state of the laptop lid:

#!/usr/bin/env bash

lid_state="/proc/acpi/button/lid/LID/state"

# Exit with failure if lid is closed, else true
grep -q closed ${lid_state} && exit 1; true

PAM configuration

Assuming lid.sh was placed at /opt/scripts/lid.sh, your PAM configuration /etc/pam.d/sudo might look like:

auth [success=ignore default=1] /usr/lib/aarch64-linux-gnu/security/pam_exec.so quiet /opt/scripts/lid.sh # fprintd-lid (order 11400)

This should be populated to each PAM configuration you’d like this to work.

For context/reference, here’s the realized configuration of /etc/pam.d/sudo on my NixOS machine – ignore the Nix store paths if you’re unfamiliar with NixOS:

# Account management.
account required /nix/store/g928dngdfy30jyi1cs2m2a5wfimxgnkr-linux-pam-1.6.1/lib/security/pam_unix.so # unix (order 10900)

# Authentication management.
auth [success=ignore default=1] /nix/store/g928dngdfy30jyi1cs2m2a5wfimxgnkr-linux-pam-1.6.1/lib/security/pam_exec.so quiet /opt/scripts/lid.sh # fprintd-lid (order 11400)
auth sufficient /nix/store/7kjh2p1pzbibr9cj08kbczr4vzh3dyxv-fprintd-tod-1.90.9/lib/security/pam_fprintd.so # fprintd (order 11500)
auth sufficient /nix/store/g928dngdfy30jyi1cs2m2a5wfimxgnkr-linux-pam-1.6.1/lib/security/pam_unix.so likeauth try_first_pass # unix (order 11700)
auth required /nix/store/g928dngdfy30jyi1cs2m2a5wfimxgnkr-linux-pam-1.6.1/lib/security/pam_deny.so # deny (order 12500)

# Password management.
password sufficient /nix/store/g928dngdfy30jyi1cs2m2a5wfimxgnkr-linux-pam-1.6.1/lib/security/pam_unix.so nullok yescrypt # unix (order 10200)

# Session management.
session required /nix/store/g928dngdfy30jyi1cs2m2a5wfimxgnkr-linux-pam-1.6.1/lib/security/pam_env.so conffile=/etc/pam/environment readenv=0 # env (order 10100)
session required /nix/store/g928dngdfy30jyi1cs2m2a5wfimxgnkr-linux-pam-1.6.1/lib/security/pam_unix.so # unix (order 10200)
session required /nix/store/g928dngdfy30jyi1cs2m2a5wfimxgnkr-linux-pam-1.6.1/lib/security/pam_limits.so conf=/nix/store/wn252azs7hgq9q1m6k4jlwclclswgwrh-limits.conf # limits (order 12200)

Conclusion

Using my lid.sh script in PAM to detect if your laptop lid is open should bypass your built-in fingerprint reader when your laptop lid is closed but will allow it when your lid is open.

I’ve been thinking about strategies that have helped me maintain momentum in my open source contributions and think they may help any new or existing person in the realm of open source. This isn’t as much a mental health post on how to avoid burnout, more of an unstructured list of hacks that have helped me over the years.

Disclaimers

Some disclaimers feel necessary before proceeding to temper expectations.

I am not claiming to be a model of mental health or a significant figure in the open source space. As a married person, my career has taken a toll on myself and my marriage. At points I struggle with managing healthy boundaries around my career and I think it will always be something to calibrate. My strategies may not work for everyone. Maybe I’ll publish this post and burnout the next day.

As with everyone on the internet, take my opinions and advice with a grain of salt and be confident that I know nothing. :)

You should be your target audience

If you write anything open source, do it for yourself before anyone else. Do not expect that anyone will actually care about your contributions. Write for yourself in the moment, yourself in the past, or yourself in the future. Write code and documentation for yourself to reference. For example, I’m writing this post with myself as the target audience. If nobody reads this, it’s an interesting thing for me to process for myself and by itself that is a win. Additionally, reading a post like this when I first started working toward my career would have been really entertaining to me.

Another example: contribute to projects that you use and implement features that you need. Chances are, if you need it, someone else needs it! And if nobody else needs it, it can be a reference for yourself and a potential brag to a future employer.

As I have gotten older, I have noticed that people doing things for a long period of time – no matter what it is – is impressive by itself. If you write for yourself consistently, it will be a self-contained achievement and will likely be interesting to others on its own!

Small contributions

It can be easy to get overwhelmed with all the grand contributions you anticipate making. Keep your scope small first and understand your own limits before you try to conquer the world.

Here are some examples of small contributions to start:

• Improve documentation on a tool you’re using (even if it’s only for you to read)
• Publish “Hello, world” projects as a reference for a language you’re learning
• For larger projects, break it down into tons of tiny tasks and accomplish one task at a time

If your tasks remain small, you can be done with that task when you eventually run out of dopamine/excitement for the larger project and revisit after a break.

Discoverability

I’ve found GitHub to be an incredible place for enabling the discovery of my own code for others as well as my own discovery of other projects. Most of my senior roles have used GitHub in some capacity, so it has been extra convenient to use.

An example demonstrating discoverability is my GitHub Stars list: heywoodlh GitHub Stars

Many people don’t like GitHub being “social media” – which I can understand. For me, though, I’ve been able to find community with strangers interested in similar projects and it has helped employers easily parse how active I am with coding when they can look at my GitHub profile.

Note: I think that GitHub alternatives like GitLab, SourceHut, Codeberg, etc. are absolutely incredible – don’t use GitHub if you prefer something else!

Reducing tech debt

For someone hoping to contribute to open source, reducing tech debt drastically reduces excessive mental load.

Tools

Many of the tools I use and my mentality around them are captured in this post:

heywoodlh tech stack

Specifically around mitigating burnout, I implement the following which really helps:

• Avoid visual overstimulation
• Live in the command line – a single pane of glass really helps me!
• Try to use keybindings to reduce mental overload and increase speed

Offload technical overhead

One of the most impactful changes for reducing my open source load has been using external platforms for mission critical tooling. Nothing is more stressful than a self-induced outage that you have to fix that blocks you from getting meaningful work done.

Here are some things I’ve offloaded to an external service that’s drastically reduced my stress:

1. Switching to Tailscale away from self-hosted Wireguard
2. Using GitHub Actions for regularly scheduled actions I always need to run
3. Using fly.io for network services that I need highly available
4. Publishing container images to Docker Hub instead of a private registry

I’m proud to report that with the above items, my homelab can go down with minimal impact to my immediate family (spouse and kids). But, I still (mostly) have as much control as I need.

Self-documenting as a lifestyle

As a person with a DevOps career, I definitely have more passion than a normal person about utilizing self-documenting tools such as Nix, Terraform, etc. I won’t belabor the point outside of saying: it helps to write projects you can read the code for to quickly understand what’s happening.

For tools or projects that aren’t inherently self-documenting by design, I try to write documentation for myself to read later when I’m working on a project because I forget everything. Documenting stuff sucks, but saves so much time when revisiting a project. At worst, too much documentation is not referenced – but I’ve found it’s usually difficult to ever come close to too much documentation.

Conclusion

I hope these tips help!

One note: I’m lame and try to target 60FPS on 1080p so I can conveniently stream over my network via Sunshine and Moonlight.

My Gaming Machine Specs

Operating System: NixOS Unstable, 6.11.2-zen kernel CPU: AMD Ryzen 5 5600G with Radeon Graphics GPU: Nvidia 3080 Ti Nvidia Driver version: 565.57.01 with nvidia-patch RAM: 32 GB Drive: 1TB NVMe Proton Version: Proton-GloriousEggroll 9-22 Game Version: 1.1.3 (Steam)

One final thing is that booting with the kernel parameter of mitigations=off to disable CPU mitigations seemed to make a big impact in my configuration. I won’t go into whether or not you should, this article was informative on about that topic: How to Disable CPU Mitigations on Linux

For more details on my NixOS setup, here’s the relevant config files:

• Host-specific configuration
• Nvidia-Patch implementation
• Sunshine, steam and KDE configuration
• Proton-GE installer package

Steam Launch Options:

DXVK_FRAME_RATE=60 PROTON_ENABLE_NVAPI=true %command% -xgeshadercompile -nothreadtimeout -NoVerifyGC

Note: change DXVK_FRAME_RATE=60 to your desired frame rate.

These options may be specific to GloriousEggroll Proton, so mileage may vary if you try a different Proton version.

Mods:

The only proper mod I’m using specific to performance is the base version of Optimized Tweaks S.2 - Improved Performance Reduced Stutter Lower Latency Better Frametimes

Configuration files

On Linux with Proton, these files can be found in this folder in your steam library: steamapps/compatdata/1643320/pfx/drive_c/users/steamuser/AppData/Local/Stalker2/Saved/Config/Windows

• Engine.ini:

; https://steamcommunity.com/app/1643320/discussions/0/4626980689722585014/
[SystemSettings]
r.DynamicGlobalIlluminationMethod=2
r.ContactShadows=0
r.Lumen.Reflections.Allow=0
r.MaterialQualityLevel=0
r.Nanite.MaxPixelsPerEdge=4
r.Shadow.CSM.MaxCascades=0
r.ShadowQuality=0
r.VolumetricCloud=0
r.Volumetricfog=0
r.OneFrameThreadLag=0

[/script/engine.renderersettings]
r.GraphicsAdapter=0
r.TextureStreaming=0
r.DepthOfFieldQuality=0
r.BloomQuality=0
r.FilmGrain=0
r.DisableDistortion=1
r.LensFlareQuality=0
r.Fog=0

[/script/engine.gameengine]
DisplayGamma=2.056000
GlobalNetTravelCount=6
bEnableMouseSmoothing=False
bViewAccelerationEnabled=False
bDisableMouseAcceleration=False

The r.OneFrameThreadLag=0 parameter seems to make a big difference with input lag when using frame generation.

In-Game Settings:

Preset: Medium

These are the settings I changed outside of the preset:

• Textures: High
• Hair: low
• Motion blur strength: 0
• Depth of field: low
• Light shafts: disabled
• Upscaling method: DLSS
• Upscaling quality: Performance

It also seemed to help my FPS just a bit to switch to Fullscreen Bordless instead of Exclusive Fullscreen.