Gaelan Lloyd

Published my second official WordPress plugin: E20 Page Tree

Thu, 28 May 2026 00:00:00 +0000

As I gave thought to becoming an officially-published WordPress plugin author, thinking about what I’d release, I decided that I’d start by publishing a small, relatively simple plugin. That became Quick Edit Post by ID. But that was just the starter project so I could figure out everything needed to publish a more complex tool, so I could iron out the kinks in my workflow.

For plugin #2, I decided to publish another tool that I’ve been adding to WordPress sites for years. It’s something I find valuable, and something that helps me in my day-to-day as a site admin. It’s a page tree visualizer with some powerful data export features. I gave the plugin a major overhaul, rewriting almost the entire thing from scratch. This is the third iteration of the plugin and the most polished. Had to get it all buttoned up and pretty to submit to the official WordPress plugin repo!

I think this plugin offers some handy features that I believe WordPress power users are sure to love.

The backstory

The default WordPress Pages screen is useful, but only just barely so. It’s difficult to use on larger sites and doesn’t provide any useful visualization of the site structure. Parent/child relationships are visible, but not always easy to deduce. Page templates are hidden unless you go looking for them. Drafts, scheduled pages, and pending review items can be easy to miss. And on many professional web teams, you’re often making project lists or analyzing the site page hierarchy, which means getting the site’s page structure into a spreadsheet. In WordPress core, there isn’t a simple, built-in way to do any of those things.

So, I built a small plugin for exactly that workflow.

Here it is: E20 Page Tree

Here’s a brief demo of the plugin in action:

The challenge I faced

A lot of WordPress sites use Pages as their primary site structure.

That works well, especially for sites with a clear information architecture: Home, section landing pages, subpages, policy pages, campaign pages, and so on. But once a site grows beyond a dozen or so pages, it’s difficult to get a mental model of the site’s page hierarchy from the WordPress dashboard.

As a web systems engineer, I often need to answer questions like:

What does the full WordPress page tree look like?
Which pages are nested under a given section?
Which pages use a certain page template?
Which pages have not been updated in a long time?
Are there draft or scheduled pages hiding somewhere in the structure?
Are there any orphaned pages lingering anywhere?
Are there any forgotten one-off or test pages that should be cleaned up?
Can I get this page hierarchy into a spreadsheet for cleanup, migration planning, or SEO review?

The normal Pages screen is fine for everyday editing. But when I’m doing content audits, technical SEO reviews, site migrations, information architecture planning, or editorial cleanup, I need a broader, structural view.

I want the site’s page tree, along with useful metadata, in one place.

Page Tree, to the rescue!

E20 Page Tree adds a new Page Tree screen under the WordPress Pages menu.

It shows the site’s page hierarchy in a clean, expandable tree view. Parent and child pages are visually connected, pages can be expanded or collapsed, and each row includes useful metadata right in the table.

The tree includes:

Page title
ID
Slug
Page template
Created date
Last modified date
Status
Quick edit and view actions

The status column uses a colored key, bringing fast attention to any pages that aren’t published:

P = Published
D = Draft
R = Pending Review
F = Scheduled

If the site uses a static homepage, it’s shown first, at the top, just where you’d expect the homepage to be in a sitemap. That’s a small detail, but it helps orient the rest of the structure.

Exporting the WordPress page tree

The part I find most useful is the export functionality. My page tree plugin includes several output formats:

A spreadsheet-friendly table
CSV
TSV

The table view can be copied and pasted directly into Excel, Google Sheets, LibreOffice Calc, or Numbers. The CSV and TSV tabs are useful if you want plain-text output for another tool, script, or manual processing step.

Having the sitemap in a spreadsheet is handy during content audits and migrations. Once the data is in a spreadsheet, with pages paired to their ID and metadata, you can filter by template, sort by modified date, review page depth, assign sections to team members, build a cleanup plan… or accomplish literally any number of jobs that pro teams do as part of long-term website operational maintenance.

Those were some of the main workflows I wanted to support. The interactive WordPress page tree is useful on its own, but the spreadsheet export turns the page tree into a practical planning tool that teams can use for any number of projects.

A focused plugin

Like my first plugin, this one is small and intentionally focused.

It only works with WordPress Pages right now. It does not try to become a full content inventory system, migration framework, editorial workflow manager, or SEO platform.

It just gives you a better WordPress page tree and makes it easy to copy that structure into a spreadsheet so you can do some serious work on your site.

The plugin has no external dependencies, and its CSS and JavaScript only load on its own admin page. Users need the edit_pages capability to access it.

My second official WordPress plugin

Publishing my first official WordPress plugin earlier this year was partly about learning the WordPress.org plugin submission process. As my second, larger published plugin, I learned more about what it took to get something more complex submitted. Next is the advertising process… spreading the word, so to speak.

My hope is that you’ll find this a useful tool and get some insights about your website that aren’t possible with the barebones WordPress backend.

E20 Page Tree is available now in the official WordPress plugin directory.

Meet "Good Boy," My Zero-Dependency FreeBSD Bootstrapper

Fri, 01 May 2026 00:00:00 +0000

I built a little tool that I’ve lovingly named Good Boy.

It is a tiny, zero-dependency bootstrapper for fresh FreeBSD installs, written as one plain sh script.

I made it over the last two days for my homelab, where I spin up jails often. I wanted a faster, simpler way to get these environments up and running.

Why’d I make this?

I’ve written provisioning scripts before, but they were always a little more complicated than I wanted.

In the name of being DRY, I had split things into multiple function files. Each playbook lived in its own file. Everything lived in a Git repo. That was clean, sure… but before you could do anything useful, you had to do lots of steps:

Install and configure Git
Generate SSH keys and add them to your Git account
Clone the repo
Install Bash
Then, you could get started

I wanted to make a simpler version. Something that could run on a baseline FreeBSD install with no extra dependencies. No Bash, no Git, no cloned repo. Just the native sh shell and the tools already available on the system.

The idea

Good Boy is one self-contained script.

All the playbooks live inside that one file. Supporting source files, like dotfiles or config files, can live somewhere remote… but only the script itself needs to be downloaded to kick things off.

That makes the script a little bigger and a little more obtuse initially, but it reduces the overall complexity dramatically.

All you need to get started (after customizing your script, of course…)

fetch https://example.com/good-boy.sh chmod +x good-boy.sh ./good-boy.sh base ./good-boy.sh user ./good-boy.sh famp 

One file, one command. Multiple playbooks. Good boy!

What it does

Right now, Good Boy is built around the things I tend to do on fresh FreeBSD systems. It has playbooks for baseline system setup, user setup, and initializing a FAMP stack.

The Base playbook runs package updates, installs my favorite utilities, configures doas, primes the locate database, and cleans up junk leftover from some VPS install snapshots.

The User playbook handles my user-specific setup: Shell aliases, dotfiles, SSH authorized keys, hushlogin, and generates an SSH key for the box.

The FAMP playbook installs and configures MariaDB, Apache, PHP and php-fpm… then ties everything together with a demo virtualhost.

Partially idempotent, in a “good-enough” way

Good Boy aims to be partially idempotent.

Some commands are safe to run again. There’s some built-in sanity checks, like whether files or directories already exist. Changed config files get backed up with a timestamp before being replaced.

However… some commands may be destructive if run repeatedly. So, use Good Boy with care.

Why not just use Ansible?

Good Boy is not trying to be Ansible or Salt. It’s not trying to be an enterprise configuration management platform. It’s not built to manage fleets of servers from a single pane of glass.

It’s meant to solve a smaller problem: Getting a fresh FreeBSD system from “brand new” to “ready enough.” It’s just a smol bootstrapper that does the tedious early setup work for you… and does it fast!

Closing thoughts

Good Boy started as an experiment to see if I could make a useful FreeBSD bootstrapper with zero dependencies, staying within the limitations of the built-in sh shell. It was a little fun labor of love for the last two days. And now I’m happy and proud to release it into the wild!

So far, Good Boy does exactly what I wanted: Makes fresh systems much faster and much less tedious.

Is it perfect? …No.

Is it production-grade enterprise configuration management? …Also no.

Does it sit, stay, and bootstrap a fresh jail without needing Git first? …Yes.

What a Good Boy!

Published my first official WordPress plugin: Quick Edit Post by ID

Wed, 25 Mar 2026 00:00:00 +0000

For about ten years, I’ve been adding a simple WordPress admin bar utility to the websites I work on. It’s a simple text entry field that allows you to jump directly into editing any ID-based item just by typing the ID and pressing Enter.

The challenge I faced

Some sites have posts or pages with very similar names. WooCommerce sites may have several duplicates of a given product, with different variations.

In these cases, the ID is always unique. The ID is the thing you can count on to reliably get you editing the proper item.

After working with a site for a while, you may start to memorize IDs, or maybe even have a little cheat sheet of the ones you work with the most. On many sites I work on, I’ll expose the WordPress post ID for items in HTML comments or data attributes so I can view the site source and quickly see which post ID a thing is related to.

Once you start looking at IDs, it helps to have a quick way to jump to edit an item by its ID. So, this little feature became a valuable power tool.

Quick Edit field, to the rescue!

Here it is! Quick Edit Post by ID (Admin Bar)

The entire plugin is just a few lines of code. It’s really quite simple. But it brings a lot of utility.

This plugin is handy for anyone who is working day-in and day-out on WordPress sites. E-commerce site merchandisers, content management teams, site admins, event staff… anyone interacting with existing posts often can benefit from this little addition to the WordPress admin bar.

Here’s a brief demo of the plugin in action:

My first official WordPress plugin

I’ve been adding this plugin to sites manually for years. But recently, I wanted to learn how to become an official WordPress plugin author.

There was a lot to learn:

Plugin naming conventions
Licensing considerations
Code validation and safety checks
Packaging the plugin for review
Communicating with the official plugin team
SVN
Making screenshots and animated example GIFs
Making a good-looking Readme

It was a challenging process, and rather stressful from a personal aspect… exposing your private work to the world, having your code running in environments you can’t control and you haven’t ever seen… But I learned a lot in the last couple weeks and am very excited to see if anyone else finds this tool helpful!

Choosing a note system: My Experience with Syncthing, BookStack, and Git

Wed, 18 Mar 2026 00:00:00 +0000

A close friend and I have an inside joke centering around someone asking her the vague question, "Where do you keep your files?"

Well… Certainly everyone has a unique answer to that question. I’ve been storing personal notes on my computer for years and years.

The manner in which I’ve stored those notes has gone through several phases:

TXT files stored locally on my computer (1990’s - 2015)
TXT files shared between computers via Syncthing (2015 - 2021)
Self-hosted BookStack on a FAMP-stack VPS (2021 - 2025 Q3)
Git-backed Markdown files with a local Forgejo and external Codeberg remotes (2025 Q3 - Present)

The recent move to Git-backed Markdown has felt like such a significant improvement over my prior systems that I felt like writing about it.

I had read posts that some folks were fond of this setup, but at first I was doubtful because I felt like I’d be stuck forever running tons of commit commands and dealing with merge conflicts. In actuality, that hasn’t been as big of an issue as I thought it would be. I’ve got some tips and tricks to speed up working with Git listed at the bottom of this post.

Some notes about my particular use case

Here’s some background information to give you context about how I’m using and interacting with these tools:

I’m the only user: Many knowledgebase platforms provide support for multiple users, and that adds layers of complexity. Since complexity leads to risk, that introduced anxiety. I’m looking for stability, simplicity, and a sense of being “at ease” when interacting with the overall system.
99% of my use happens at home: Since I work from home, only rarely do I need to access the information remotely. Do I really need to host complex infrastructure and have my data living offsite when the vast majority of my usage is done within my home LAN?

Thoughts on note-taking products

I flirted with Microsoft OneNote, Evernote, Ulysses, and several others.

All of these have nice interfaces, and some have cool and interesting features. However, I was never comfortable with any of them, because they all suffer from one or more of the following dealbreakers:

Paid software
Vendor lock-in
Telemetry
Part of bulky office suites
Data stored in an opaque format
Data synced to third-party sources I had zero control over
AI-littered interfaces
Private data used to train LLM models

Comparing TXT files in Syncthing, BookStack, and Git-backed Markdown files for storing personal notes

Ok, so let’s get down to it! I’m going to rate these three ways of storing and sharing content on a 0-5 scale:

5 being the highest marks for a particular measurement
1 being the lowest
0 means “this feature is not applicable or not available on the platform”

Here’s how I feel the platforms stack up:

Feature	Syncthing TXT	BookStack	Git-backed Markdown
Available on multiple devices	5 •••••	5 •••••	5 •••••
Ease of hosting and operating	3 •••	1 •	5 •••••
Knowledgebase features	2 ••	5 •••••	4 ••••
Usable on your work computer	3 •••	5 •••••	5 •••••
Mobile-friendly web interface	0 -	5 •••••	4 ••••
Revision control	2 ••	4 ••••	5 •••••
Data safety at rest	2 ••	3 •••	5 •••••
Content accessible if platform unavailable	5 •••••	0 -	5 •••••
Total ratings score	20/40 (50%)	28/40 (70%)	38/40 (95%)

Ratings, explained

Let’s go over each of the ratings in the table above.

Available on multiple devices

All three solutions are available on multiple devices. So, it’s a tie here.

Ease of hosting and operating

Syncthing is free. You can simply run the software on two or more personal computers to get your shares working, and it’s not too complex to set up. You don’t need to involve a dedicated “server” unless you want an always-on replica, or you want a remote device that’s available independently from your physical home location. Every so often I ran into bizarre conflicts with out-of-sync files, or remotes that would appear to be stuck syncing at “99% complete” forever, but otherwise Syncthing is reliable and works well. There’s some security risk as you are indeed hosting a service with externally-open ports.

BookStack has hosted options, but they’re costly for a personal knowledgebase for a solo user. If you choose to go self-hosted, BookStack requires a stunningly-complex setup to run:

You’ll need to build, manage, and operate a VPS instance.
Then, you’ll need to understand how to operate and maintain: SSH, ZeroTier†, Apache, PHP, MySQL, BookStack, Composer, Laravel, all the various and changing BookStack dependences, Let’s Encrypt, Cron. († Optional, but I recommend using it.)
If you choose to store your backups on AWS S3, you’ll need an AWS account and need to configure and operate AWS CLI.

Once BookStack is up and running, it’s easy to operate. But then, updates come along. From a long-term maintenance perspective, there are some further drawbacks:

Updating the platform is a challenge, as the ever-changing composer dependencies can get frustrating to work with over time. On more than one occasion, a required composer package wasn’t available on FreeBSD, or had issues running, causing platform updates to fail.
You are responsible to ensuring the platform is backed up, ideally to an off-site, third party source (like AWS S3). I was reasonably sure the backups were working, but I wasn’t ever able to feel fully at-ease knowing so much of my valuable personal information was teetering on a single point of failure.

Git-backed Markdown hosting is trivial and free on many platforms out there, like Codeberg, GitHub, etc. There’s nothing to maintain and no services to run. Just keep the git package up-to-date on your machine and interact with the files with your favorite text editor. If you want, you can self-host a Git instance on something like Forgejo. This setup is more secure than Syncthing, as there are no services listening on open ports.

Knowledgebase features

Syncthing text files have zero ability for cross-linking, showing images, etc. You could certainly use Markdown files here, editing them in an IDE much like I’ll talk about in a moment for Git-backed Markdown files… So in some ways this is a decent option. However, you won’t have the online read-only interface provided by a Git host, which adds a decent amount of utility.

BookStack wins here, hands-down. There are many useful features for organizing, formatting, and embedding rich content. I had some really slick HTML and CSS formatting on some pages.

Git-backed Markdown files don’t have many features per se, but if you’re viewing them in an IDE like VSCodium or VSCode, the Markdown will start to become more useful. Header levels, code blocks, and callout blocks help your content become more readable. And once published to a Git hosting platform, you’ll be able to browse the content in a read-only mode and see rich formatting, hyperlinks, and image support. I had to give up the ability to make some really custom HTML and CSS tweaks, but that was an OK tradeoff considering the other wins.

Usable on your work computer

Syncthing runs as a service on your local machine, and it needs to open port connections to peers. Most workplaces probably won’t want you installing a service like Syncthing on a work computer.

BookStack is accessible over the web, so it’s “just another website” to access.

Git-backed Markdown is probably A-OK to use on a work machine. If you’re geeky enough to want a personal knowledgebase with this setup, you probably have Git running on your work computer, too.

Mobile-friendly web interface

Syncthing is not suitable for personal knowledgebase content on a mobile device. It’s technically possible, and I do run the Syncthing client on my personal devices for media syncing (photos, mostly). But, editing text files on a mobile device is a tedious affair. Only true sadists need apply for this lifestyle.

BookStack has a fantastic web interface, and you can even edit on mobile devices.

Git-backed Markdown, if synced up to a publicly-accessible service like Codeberg, GitHub, etc., gives you a “good-enough” web interface that can show your content. You can even make changes to the content on mobile, which again is “good-enough” for basic changes on the go. I think BookStack’s editor wins over online Git edits here, so I rated it a bit higher.

Revision control

Syncthing can store copies of changed files, but you have to set up a revision scheme. In most cases, after a certain amount of time or number of revisions, older content is purged.

BookStack has very good revision control for pages. You can see a page’s history and revert to older versions right within the web interface.

Git-backed Markdown files wins in terms of revision control, with powerful features like blame and the UI’s of online repos. All changes from the beginning of the repo’s creation are stored on every machine that works with the repo.

Data safety at rest

Syncthing introduces a few subtle sources of risk for the data at rest:

When viewing a file, stray keystrokes could accidentally modify a file you’re simply reading. An accidental save would then change the file. Without a Git-style blame system, you might not notice until it was too late. This could be as simple as an errant key stroke or an accidental deletion of an entire section of content.
It’s possible for infection on a remote to silently spread to and corrupt local files on all replicas.

BookStack is a website that is typically operated in a publicly-accessible state (unless you lock it down with any number of methods). If the server is compromised, your data is at risk. If the server’s backups aren’t configured properly, your content is lost. You must be forever vigilant operating this setup, and that adds a slight mental tax to your life. I never felt that my data here was truly safe.

Git-backed Markdown is utterly immune to almost all disasters. Absolutely nothing can happen to plain-text files sitting on your machine. And in even the most spectacular failure scenarios, any machine with a repo clone becomes a point-in-time recovery backup of the entire state and history of the content.

Content accessible if platform unavailable

Syncthing and Git-backed Markdown content is available at all times, regardless of the platform’s operational status, so this is never a problem.

BookStack content is not accessible if the platform goes offline, leaving you in a serious bind. Most people will run a single instance of BookStack without a mirror, so there’s a painful single point of failure. Several times while updating BookStack or the various service dependencies, a wonky composer update or a random problem causing Apache or SSL certs to go haywire would make all of my notes inaccessible. At a time when I needed my notes the most, I couldn’t get to them. I had a pre-update ritual of opening up every page I thought I might need in separate browser tabs so that I could have my notes ready in case BookStack went offline. This felt like some sort of silly voodoo practice and I’m glad to no longer need to do that.

Summary thoughts

I was excited for the features that BookStack provided, but as I moved content into the platform I was left with a vague feeling of unease. Moving content into BookStack never left me feeling totally secure. I figured the platform itself was trustworthy, but what if the platform was discontinued? What if the server got hacked? What if my backups weren’t working and I was humming along with ever onlyone copy of my most precious data in existence?

I noticed as I began to move content out of BookStack and into Git that I started feeling a sense of security and safety. It felt safe because I knew nothing could ever happen to my files. I didn’t have to worry about backups to S3 failing or any number of other “silent killers” that could be of hidden risk. I know my content is cold and at rest, static and immutable unless manually invoked to change by my hand. And… knowing those changes are fully tracked over the content’s entire lifetime gives me a sense of quiet and ease that I truly value.

Appendix: Miscellaneous thoughts on the platforms

BookStack

If you’re working in the HTML editor, accidental presses of ESC or clicks outside the editor’s popup window will close the editor modal and cause you to lose any changes you’ve made. This happened to me more than once and was quite frustrating.
I have a lot of tabular content, and BookStack writes really pedantic HTML tables with width percentages on every cell in the table. It was ugly and obtuse to work with.

Git-backed Markdown

Rendered Markdown output is possible directly from within VSCodium or VSCode with the Mark Sharp extension from Jonathan Yeung. I can usually visually parse Markdown in edit mode just fine, but sometimes “you just want pretty.”
Obviously, you aren’t relegated to just storing Markdown files in a Git repo or a Syncthing share. You can add all sorts of content easily, including folders of source code for projects. I’ve also been storing the pure Markdown output of LLM conversations. Now everything is searchable and stored safely.

Tip: Save time making commits

Since this is a repo only used by me, I can get away with some shortcuts:

I don’t use PRs, I just work directly on main.
I don’t bother with descriptive commit messages unless there’s a major change.

I wrote a little helper alias gcp that allows me to quickly commit staged files with a boilerplate message.

alias gcp="git commit -m \"Updates\" && git push origin main" 

So yeah, my commit history looks like this…

d38be3a (HEAD -> main, origin/main, origin/HEAD, codeberg/main, codeberg/HEAD) Updates ce5e530 Updates b0f1bc3 CLEANUP OF MIGRATED CONTENT 9c0013d Updates 50c4354 Updates 9717e83 Updates baffaa0 Updates 2c64ee6 MAJOR REORGANIZATION bfcfb1f Updates c15075a Updates 22d6444 Updates 883f25c Updates eb4b504 Updates 679fe8c Updates ff28c48 Updates 6a7cc24 Updates 8bb9b71 Add old training files 51b09a0 Updates c6e9d53 Add archived notes faf8868 Updates 

…but it’s ok because tools like blame and the remotes’ web interfaces help me investigate any file histories or changes I’m interested in.

Tip: Host a local Forgejo instance

This is totally optional, but hosting a Forgejo instance locally is relatively easily (I operate a homelab with a local VM server). Day-to-day changes are pushed almost instantly, which keeps me in mental flow while working. At the end of each day, I push all changes out to a third-party remote for disaster recovery and to ensure I can access my notes while outside of my home.

How to create an IoT VLAN with OPNsense and TP-Link Omada (with IPv6 Prefix Delegation)

Wed, 04 Mar 2026 00:00:00 +0000

In this post I’ll be talking about the journey I went on to strengthen my home network by adding an isolated VLAN for IoT devices and properly assigning IPv6 addresses for all devices on my network.

This guide will cover: IPv6 prefix delegation; Creating VLAN interfaces in OPNsense; DHCP configuration; Router advertisements; Firewall isolation rules; Managed switch VLAN tagging; and Omada VLAN Wi-Fi configuration.

Introduction

I decided to tackle a project I had been putting off for a while: Building out a separate IoT VLAN for my home network.

Prior to this, I had been using Omada’s guest network for IoT devices in my home. But doing so caused me some headaches:

It prevented the devices on that network from talking to each other.
It was cluttered: Both visitor devices and IoT devices were part of the same WLAN.
It kept me from having full visibility into the network’s firewall rules and hid activity for those devices on my network.

The Omada guest network feature is great, and I want to keep using it for when I have visitors over. I want guests to have access to our Wi-Fi, but not to our home network. And I don’t want anything running on their devices to get to see anything on our trusted network. No funny business!

Instead of using the Omada guest network for IoT devices, creating a dedicated VLAN provides better firewall control, device visibility, and network segmentation.

On a personal note, prior to this I really didn’t know much about IPv6. Frankly, I just disabled it more often than not, because I didn’t want to deal with it. It turns out that giving each device on your network a truly-global address unlocks a lot of simplicity and allows services like ZeroTier, Syncthing, and other direct-connection services to work quickly without dealing with weird legacy workarounds like IPv4 NAT.

This project helped me learn a bunch about IPv6, too. It was a long and arduous project but I’m glad I hunkered down and tackled it!

Hardware used

In my home network, I have the following services and devices:

Xfinity/Comcast ISP (Residential cable)
Motorola Nighthawk CM2000 cable modem
OPNsense firewall/router running on an HP T730 thin client with an Intel I340-T4 NIC
MikroTik CSS318-16G-2S+IN managed switch
TP-Link Omada Wi-Fi APs (2x EAP610-v3, 1x EAP650-v1)
And a bunch of devices all connected in via ethernet and over Wi-Fi

Why you should put IoT devices on a separate VLAN

I’m fairly security-minded and want to help protect the devices on my network. Smart-home devices can offer useful functionality, but I don’t believe should have full access to my trusted home LAN. How many times have we heard news stories about botnets and other things running amok in things like Smart Light Bulbs?

IoT devices should be isolated from your trusted home network because many of them:

Receive infrequent security updates and/or run outdated firmware.
Do naughty things, like scan your network and phone home all sorts of telemetry.
Have glaring issues like using hardcoded admin credentials that can eventually be discovered and exploited.

Isolating IoT devices lets you use them for their convenience while preventing them from accessing your trusted network. That limits the damage blast radius in the event they’re compromised.

Before: The original network layout

Here’s the original network layout before I started.

For simplicity’s sake, I’m only illustrating the Wi-Fi parts of the network. In reality, there’s a bunch of hard-wired devices connected up to the network.
Network diagram icons courtesy of vrt-sheet-for-dia on GitHub, with a little of my own zhuzhing up.

As you can see, everything non-trusted was just all tossed onto the Omada guest WLAN. There wasn’t any way to segment the devices in any meaningful way… it was either an “Fully trusted” or “Guest only” setup.

Afterwards: The improved network layout

In the improved network layout:

IoT devices are now on their own VLAN’d WLAN, isolated from the home network. They can now see each other.
Physical network devices that are IoT related, or that I otherwise felt should be isolated (printers, etc.),are also tagged on the same VLAN to keep them isolated from the trusted network.

Network	VLAN	Purpose
Trusted network	1	Personal computers, phones, and tablets
IoT network	10	Smart-home devices, Ring home security devices, etc.
Guest Wi-Fi	n/a (Omada controlled)	Visitor devices

Get your ISP to provision you a /60 or /56 block of IPv6 addresses

As I started going through the process to enable VLANs in OPNsense, you’ll need to assign separate IPv6 address blocks for each VLAN. But this isn’t something you have full control over… these addresses aren’t something you can create yourself. They come from your ISP.

Your ISP probably delegates you a single /64 block of IPv6 addresses, because (a) it’s easy for them, and (b) most residential customers won’t need anything different as they’ll just have everything on one network anyway.

Your ISP may listen for and honor requests to issue different prefixes. Unfortunately for me, this wasn’t the case. No matter what I tried, I was only ever issued a single /64 network.

If you don’t have the /60 or /56 prefix delegation, you’ll get an error in OPNsense at the point where you enable the VLAN interface’s IPv6 Identity Association. You won’t be able to assign a Prefix ID and will get the error You specified an IPv6 prefix ID that is out of range.

Requesting the change from the ISP

Since this was only something my ISP could change, I had to work with them to request the change. This ended up taking the most time and being the most frustrating part of my journey. Working with Xfinity/Comcast’s Tier-1 support proved to be a challenge because they aren’t trained to help with IPv6 prefix delegation. Escalation paths with their support team are also tricky. I was told several times by support reps that, “The matter was being worked on and that I’d hear back from the team in 3-4 hours.” But after a day went by I had to follow up with support again, starting all over in the explanation each time. I had to repeat that cycle for several days before I got a ticket number for my request.

In total, it took about a dozen calls to Xfinity support over the course of one week to get this changed. Eventually, they did provision me a /60, and I was up and running!

Validating the prefix your ISP is issuing

To validate the IPv6 prefix you’re receiving, go to OPNsense and navigate to System > Log Files > General. Search for keyword prefix under log level Notice. Look at the most recent log entries and look at the last digits to see what network prefix you’re being issued. You want to see either /60 or /56.

dhcp6c_script: REQUEST on igb0 prefix now 2001:db8:1234:5670::/56 # Good dhcp6c_script: REQUEST on igb0 prefix now 2001:db8:1234:5670::/60 # Good dhcp6c_script: REQUEST on igb0 prefix now 2001:db8:1234:5670::/64 # Not good 

A /56 is good, too! That means you’re being issued 256 different network groups. I requested a /60 to be more conservative, as the 16 different networks provided by the /60 should be more than sufficient for my needs. I also wanted to be conservative with my request to Xfinity in case they pushed back on the larger allocation.

OPNsense VLAN setup

This section walks through the complete process of configuring a VLAN in OPNsense. We’ll create the VLAN interface, assign IPv4 and IPv6 networks, enable DHCP, and configure router advertisements so devices can obtain IPv6 addresses.

The steps below assume you already have:

A managed switch capable of VLAN tagging
Wi-Fi access points that support VLANs
An IPv6 prefix delegation from your ISP (see above)

Once your ISP is providing you a /56 or /60, you can continue actually setting up the VLANs on your network.

We’ll start by building that out in OPNsense, then roll out the VLAN elsewhere on the network.

Create the IoT VLAN in OPNsense

Within OPNsense, navigate to Interfaces > Devices > VLAN.

Device: (Leave blank, it’ll be auto-generated)
Parent interface: igb1 (LAN)
- (Or whatever your LAN interface is)
VLAN Tag: 10
- (I used 10 here, but you can use something different if you’d like. Just be sure you keep this value consistent with the steps later on in this guide.)
Description: (Something useful, like IoT Devices)

Add the new VLAN interfaces and enable them.

Assign the VLAN interface

First, add the new interface.

Navigate to Interfaces > Assignments.

Under Assign a new interface, find the new VLAN interface you created in the prior step. (For instance, vlan01).

Then, enable the interface.

Navigate to Interfaces > VLAN01.

Basic
- Enable interface = Checked
Generic
- IPv4 Config Type = Static IP
- IPv6 Config Type = Identity association
Static IPv4 Config
- IPv4 address = Provide an IP range here to use for the VLAN devices, like 192.168.10.1/24
IPv6 Identity Association
- Parent interface = WAN
- Assign Prefix ID = 1

If at this step you get the error “You specified an IPv6 prefix ID that is out of range,” then your ISP might be provisioning you a /64 IPv6 instead of the /60 or /56.

Configure DHCP for the VLAN

Adapt the values here to suit your needs. For this example, we’re using 192.168.10.1/24 as the address pool, and I’m giving .100-.254 to be open slots of the DHCP pool. We’ll keep .2-.99 for static IP reservations. You can of course change that allocation however you want!

Navigate to Services > Dnsmasq DNS & DHCP > DHCP ranges.

Interface = VLAN10
- Start address = 192.168.10.100
- End address = 192.168.10.254

Enable DHCP server/service on new interfaces

Navigate to Services > Dnsmasq DNS & DHCP > General.

Interface: LAN + Add new VLAN network (it’s a multi-select field)

Enable IPv6 router advertisements

Helpful hint: The default OPNsense configuration doesn't enable this for you on the LAN. Enabling this (even just for the LAN network) fixed a bunch of weird issues I was seeing on my network!

Next, we’ll enable router advertisements (which provides IPv6 routing and address information for devices on your network.

Navigate to Services > Router Advertisements.

Make an RA for the base LAN.

New:

Enabled = Checked
Interface = Your LAN
Mode = Assisted

Then, make an RA for each VLAN you created earlier.

New:

Enabled = Checked
Interface = VLAN10
Mode = Assisted

Create firewall rules

There’s a few schools of thought here on how you can secure the VLAN traffic. We’ll of course prevent the VLAN from initiating connections to the trusted network, but as far as outbound traffic goes, we could…

Prevent all outbound traffic on all ports and protocols, except on specific ports.
- The most secure, but the most time consuming to set up and maintain over time.
Allow all outbound traffic on all ports and protocols, except to protected networks and addresses.
- Secure as long as you are careful!

I wanted to naturally go with “total blacklist except what I specifically allow,” but then I realized I’d be forever maintaining the list of ports that need to be open for all these random IoT devices to operate. So, I opted for the second choice.

OPNsense allows for the creation of Aliases so we can assign a single place to store all the trusted network addresses and network interface names. Aliases can only hold items of a certain type, so we’ll be making three of them:

A list of all trusted networks.
A list of all trusted IP addresses.
A joint list combining all items in #1 and #2, which we’ll apply in the firewall rules.

First, we’ll create an Alias for networks to trust.

Navigate to Firewall > Aliases > Create.

Enabled = Checked
Name = TRUSTED_NETWORKS
Type = Network(s)
Content = __lan_network
Description = Specific networks to trust

Then, the Alias for IP addresses.

Navigate to Firewall > Aliases > Create.

Enabled = Checked
Name = TRUSTED_ADDRS
Type = Host(s)
Content = 192.168.1.1 (or your OPNsense router management IP), then the IP address of any other management devices or other things you want to block.
Description = Specific IP addresses to trust

Create an Alias to join those two.

Navigate to Firewall > Aliases > Create.

Enabled = Checked
Name = TRUSTED_COMBINED
Type = Network Group
Content = TRUSTED_ADDRS, TRUSTED_NETWORKS
Description = The combined group of all trusted entities

Next, we’ll set up the firewall rules.

Start by allowing traffic out of VLAN.

Navigate to Firewall > Rules > [Your VLAN Interface].

Add rule:

Action = PASS
Interface = [Your VLAN Interface]
Direction = IN
TCP/IP Version = IPv4+IPv6
Protocol = ANY
Source = [Your VLAN Interface] net
Destination = ANY
Description = Allow [Your VLAN Interface] out to any internet destination

Then, block traffic from the VLAN to the joint alias of protected network resources.

Navigate to Firewall > Rules > [Your VLAN Interface].

Add rule:

Action = Either REJECT or BLOCK (see note below)
Interface = [Your VLAN Interface]
Direction = IN
TCP/IP Version = IPv4+IPv6
Protocol = ANY
Source = [Your VLAN Interface] net
Destination = TRUSTED_COMBINED
Description = Block [Your VLAN Interface] to protected network entities

Then, move the block rule above the allow rule.

About the block rule:

Make sure that the block rule is ABOVE the allow rule.
Use REJECT if you want fast rejections upon accessing protected resources. That’s good for devices on internal networks so the devices don’t hang forever waiting to timeout when they hit the firewall. Use BLOCK if you just want devices trying to reach protected resources to never hear back. It’s more secure per-se, but could lead to long timeouts and possible network congestion from IoT devices waiting on hold.

Configure VLANs on your managed switch

We probably have different devices here, so you’ll need to follow whatever instructions your switch’s vendor provides for setting up the VLANs.

The most important parts are:

Set up a base VLAN for trusted traffic (I used VLAN 1).
Tag any physical ports for devices that must be VLAN’d (I put our network printer on the IoT VLAN.)
Tag any physical ports for Omada APs to have both VLAN 1 and 10.

Configure VLANs in TP-Link Omada

To get Wi-Fi devices onto this new VLAN, you’ll need to create a new WLAN for them. Use a completely separate, strong password for this network.

While setting up the new WLAN, under Advanced Settings, use:

VLAN = Custom
Add VLAN = By VLAN ID, 10

When you connect devices, check that their IPv4 addresses are part of the new VLAN range. You’ll also want to check the IPv6 addresses and see that their addresses are part of the VLAN’s group, indicated by the different prefix (in this case, b500 for devices in the trusted LAN, and b501 for devices in the IoT VLAN with prefix 1).

Device on Trusted LAN 2001:db8:100:b500::25 Device on IoT VLAN 2001:db8:100:b501::25 

Common problems/Troubleshooting

Error: “IPv6 prefix ID is out of range”

This usually means your ISP is only delegating a /64 IPv6 prefix instead of a /60 or /56. OPNsense requires a larger delegated prefix when assigning IPv6 subnets to multiple VLAN interfaces.

Solution:

Contact your ISP and request a /60 or /56 prefix delegation (see above).
Confirm the prefix using System > Log Files > General in OPNsense (see above).

VLAN Wi-Fi devices are not receiving IP addresses

Check the following:

The VLAN ID configured on the Omada WLAN matches the VLAN tag on the switch.
The switch port connected to the AP is configured as a tagged trunk.
DHCP is enabled for the VLAN interface in OPNsense.

IoT devices cannot see each other

Make sure Client Isolation is disabled on the VLAN WLAN in Omada.

Upgrade MariaDB from 10.6 LTS to 11.8 LTS on FreeBSD

Tue, 03 Feb 2026 00:00:00 +0000

Here’s my process to upgrade MariaDB from 10.6 LTS to 11.8 LTS on FreeBSD. It’s very straighforward. I’ll be adding in some safety checks along the way, like DB and config file backups, to help ensure this upgrade goes smoothly.

First, review the official upgrade notes. There have been some changes to be aware of, including my.cnf option deprecations that could throw errors after the upgrade.

Upgrade process

Launch a root console.

su -

Backup all databases:

mysqldump --all-databases > /root/mysql-upgrade-backup-$(date +%Y%m%d).sql 

Back up all config files:

tar -cvzf /root/mysql_config_backup_$(date +%Y%m%d).tar.gz /usr/local/etc/mysql 

Stop the MariaDB service:

service mysql-server stop

There’s no need to remove the old MariaDB packages. They’ll be automatically removed when the new version is installed.

Install the new version (this also installs the -client package):

pkg install mariadb118-server

You’ll see output like the following, showing the old packages will be removed. Enter y to proceed.

Checking integrity... done (3 conflicting) - mariadb118-client-11.8.5 [FreeBSD] conflicts with mariadb106-client-10.6.24 [installed] on /usr/local/bin/mariadb - mariadb118-client-11.8.5 [FreeBSD] conflicts with mariadb106-server-10.6.24 [installed] on /usr/local/bin/mariadb-dumpslow - mariadb118-server-11.8.5 [FreeBSD] conflicts with mariadb106-server-10.6.24 [installed] on /usr/local/bin/aria_chk Checking integrity... done (0 conflicting) Conflicts with the existing packages have been found. One more solver iteration is needed to resolve them. The following 5 package(s) will be affected (of 0 checked): New packages to be INSTALLED: libfmt: 12.1.0 [FreeBSD] mariadb118-client: 11.8.5 [FreeBSD] mariadb118-server: 11.8.5 [FreeBSD] Installed packages to be REMOVED: mariadb106-client: 10.6.24 mariadb106-server: 10.6.24 Number of packages to be removed: 2 Number of packages to be installed: 3 The process will require 52 MiB more space. Proceed with this action? [y/N]: 

Start the MariaDB service:

service mysql-server start

Run the post-install upgrade:

mariadb-upgrade

Inspect your sites and applications to validate the systems are working as intended!

Fix weird lag issues with Intel graphics on FreeBSD 14.3 with i915 driver

Thu, 13 Nov 2025 00:00:00 +0000

I noticed that my laptop’s minimal Xorg environment was suffering from a series of strange lag issues:

Typing delays: Typed characters would show up only after other characters were typed.
Screen refresh delays:
- Instead of showing immediately on hover, Openbox’s main menu submenus would only show after the cursor was moved around inside the parent item’s menu a bit.
- vim error messages like “No write since last change” wouldn’t show up until additional keys were pressed after :q<enter>. The computer sat motionless for more than 10 seconds and then only showed the error message after I pressed an arrow key!

These issues happened in MATE and Openbox, and even plagued basic tty consoles. It didn’t make sense, because the system was not under load and is utterly minimal (just plain-old Xorg running lightdm and Openbox with no other programs running). It’s a a Dell E7470 with an i5-6200U Skylake CPU with Intel HD Graphics 520… plenty of power for this DE.

The lag went away when booted into single-user mode, or if I disabled i915 and had Xorg use scfb.

After some hunting around, turns out that PSR (Panel Self Refresh) was to blame. Disabling PSR fixed the lag issues immediately. But, finding out the exact sysctl settings was tricky because they have to go under the compat.linuxkpi section, and they have a unique naming convention that wasn’t immediately apparent from the documentation I could find online.

The fix

In /boot/loader.conf, set:

# Disable PSR (panel self-refresh) compat.linuxkpi.i915_enable_psr="0" 

Reboot and check things out. That fixed it for me!

What’s PSR?

PSR is a power-saving feature that helps put the GPU into a low-power state if it believes nothing on-screen has changed and, thus, the screen doesn’t need a redraw. Apparently, the PSR implementation from Skylake-era systems was immature in hardware and in software, leading to buggy issues like this.

This setting to disable PSR is likely provided by some distros or pre-built environments… but since I’m rolling my own barebones Xorg environment, I had to learn about the setting the hard way!

How to rebuild a ZFS pool

Thu, 09 Jan 2025 00:00:00 +0000

I recently discovered that my server’s storage pool had much more capacity than it should, because I created a stripe pool across two disks instead of a mirror as I had originally intended.

Unfortunately, the only way to correct this is to destroy the pool and start over. With ZFS, it’s actually not as painful as it sounds, and with ZFS’s built-in checksumming and scrubbing features you can help ensure that your data transfers without a hitch.

I’ll admit, I’ve had to rebuild or recreate pools a few times now for various reasons. It almost feels like a right of passage as a sysadmin.

Here’s some tips to help you do this process safely and thoroughly. Please consider this a starting point for your own project… there might be some areas where you need to adapt these steps to better suit your individual circumstances. And hey, this is meant to be a friendly guide of tips and suggestions from one storage geek to another. So, be careful… and don’t sue me if you nuke your pool!

What you’ll need

A backup storage device with enough capacity to store the entire pool’s data. In my case, I had two spare drives laying around that were the same capacity as my pool, so I made a new temporary ZFS mirror pool using them.
A tested, working UPS. You’re already using one for this server, right?
(Optional) A second copy of your data. I did an rsync of all the actual files in my pool to another external drive, for yet one more layer of redundancy in case something messed up. No such thing as being too careful here!

Before you begin

I assume you have intermediate knowledge of ZFS. This guide doesn’t cover the deeper nuances of ZFS exhaustively. For instance, I assume you understand what tank is. I’ll do my best to walk you through the process below, but before you begin you might want to consider reading FreeBSD Mastery: ZFS by Michael W Lucas, or at a bare minimum the ZFS section of the FreeBSD Handbook.
Decide on how many snapshots you want to keep. I decided to not save all of my pool’s daily snapshots, and instead transfer a single point-in-time migration snapshot. Decide if you want to retain your daily snapshots or if this single snapshot is sufficient.
The transfer will take lots of time. It took about 5½ hours to transfer about 3.1 TB of data out of the pool, and another 5½ hours to transfer it back. Make sure that when you do this process you aren’t rushed and have ample time to do the job slowly and carefully.

Some additional thoughts

ECC RAM helped give me confidence in the transfer job. During the transfer, htop reported that the anonymous ARC cache was being used heavily to shuttle data around. I could hear the drive activity and confirm that there was a lot of read pre-fetching going on, and that when the copy commands ended the ARC took a few moments to “empty out” before the target drive stopped working. I know there’s a lot of debate out there about ECC RAM not being necessary for ZFS, but in this case with so much data flying back and forth through RAM, having ECC helped reassure me that that random bit flips wouldn’t happen and introduce issues. (I’m sure a ZFS expert could weigh in here and reassure me more about checksum validations that might happen during data transport… If you are one, please contact me!)
I avoided using USB drives and went direct SATA → SATA for speed and stability. I suppose there’s nothing wrong with using an external USB drive if you must, but if this is your primary storage pool then at least plug that drive into a UPS! Your goal is to minimize external issues and safeguard your data during this delicate process.
This pool only had datasets, but volumes work basically the same way. If you need to export data from volumes, the process is mostly the same. The instructions below focus on datasets only, but you could easily adapt this process to include volumes.

How to rebuild a ZFS pool

Stop services and cronjobs

First, stop anything running on the server that might allow access to the source pool. This includes file shares, FTP servers, external SSH connections by people other than you, etc.

Also, consider stopping any cronjobs on the system. Since this process may take several hours, you don’t want your nightly backup job or a weekly scrub kicking off in the middle of things.

Collect data

Let’s collect some data that will be handy to have as we work. Save the results of these commands somewhere.

Start out by exporting a list of all datasets, their sizes, and mountpoints.

zfs list -r tank

Export a list of just the dataset names to help build scripts to go over all the datasets. Also useful to have if you enjoy making checklists!

zfs list -o name -r tank

Save the result of these commands too. They’ll help provide context for the disk layout and mountpoint names, permissions, etc.

lsblk
ls -lha of the pool root directory
zpool status tank
Properties for the pool root zfs get all tank and all datasets (run this command for each dataset: zfs get all tank/dataset). Pipe that output to text files and keep that info for reference.

Set up the new temporary storage

Making another ZFS storage pool and dataset is best because the ZFS exports we’ll do below will almost certainly exceed the maximum filesize of many filesystems.

When building the new temporary storage pool, be sure to label the disks with gpart labels so that you can be absolutely sure about which disks you’re addressing. (DO NOT rely on /dev/ labels like ada0 to address your disks, as those labels may change across reboots.)

Create snapshots

Now it’s time to create snapshots of the datasets to capture the data as it exists at this point in time. For each dataset, run:

zfs snapshot tank/dataset@YYYY-MM-DD-MIGRATION

You can adapt that snapshot naming scheme to something meaningful to you. I like using the YYYY-MM-DD format because it sorts nicely, and then use a name in ALL CAPS so this important snapshot stands out when you’re looking through a list of hundreds of snapshots.

Transfer snapshots to the temporary storage

PRO TIP: Are you SSH'ing in to the box you're working on? If so, run the rest of these commands in a tmux session. This keeps the remote session running even if your network connection is interrupted.

Each snapshot now needs to be sent to the temporary storage drive. For each dataset, you’ll want to run:

zfs send tank/dataset@YYYY-MM-DD-MIGRATION > /mnt/temporary/dataset.zfs

As this process may take hours to run, consider batching up all of those commands in a shell script. This will allow you to leave the house, go to sleep, etc. while the job runs dutifully in the background.

Verify everything was copied

Use the list of datasets you wrote down earlier in the first steps of this process. Did you transfer all of them to the temporary storage location? Did you see any errors during the zfs send jobs? Do you want to send a second copy of the data somewhere, just in case? You could scrub the temporary location if you really want, but that’s probably overkill…

The point is, take your time here. Double- and triple-check everything, because we’re about to destroy the source pool. There’s no going back after that!

Destroy and rebuild the pool

First, you’ll want to export the source pool, to tell ZFS to stop using it.

zpool export tank

If that command gives you any guff about the pool being in use, make sure you’re not in a working directory inside the pool, that all services that might be using the pool are stopped, etc. Sometimes also the pool just takes a minute to free up before it can be exported, so try again after a minute.

If you’ve passed entire disks to ZFS, you’ll need to clear their labels to dissociate the disks from the pool.

Run this command on each drive, being very careful to supply the proper /dev/ names (or, try using GPT labels, etc.)

zpool labelclear /dev/x zpool labelclear /dev/y

Once the labels are cleared from the drives, you’re ready to create the new pool. Follow the steps appropriate to the pool setup you want.

In my case, I wanted a mirror of two disks, so I ran:

zpool create tank mirror /dev/label/x /dev/label/y

Before you proceed, check the status of the newly-created pool.

zpool status tank

Were you trying to make a mirror? Be sure right now, right this very instant, that the output looks like this:

pool: tank state: ONLINE config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 <-- ada0 ONLINE 0 0 0 ada1 ONLINE 0 0 0 

Make sure that line marked with the <-- arrow is there, otherwise you have a stripe! This is what bit me earlier… it’s very easy to miss.

After doing a sanity check on the pool architecture, set up any pool-specific settings, like: mountpoint, ACL settings, and other ZFS properties you want to configure at the pool level.

Transfer snapshots from the temporary storage

Now it’s time to repopulate the new pool with the snapshots you sent to the temporary storage. You’ll need to run this command for each dataset, so consider making a shell script, and make sure you’re executing it from within tmux if you’re working remotely.

cat /mnt/temporary/dataset.zfs | zfs receive tank/dataset

Once all the data is transferred, you’ll want to check and set:

Dataset properties
Mountpoints
Owners, groups, and permissions

You can use the information exported in the first few steps to ensure everything is set up as you had it.

Verify the pool data

At this point, I ran a scrub on the new pool to make sure everything was in order. Scrubbing my pool took 4½ hours, so this is another opportunity to let the system run unattended until it’s done.

Re-start services, cronjobs, and the server

Make sure you restart any services you shut off and any cronjobs you commented out earlier.

Once that’s done, give the system a reboot. It’s not absolutely necessary, but it helps validate that you have everything in order so you can prove that the next boot will succeed.

Remove the temporary storage drives and hang on to them for a bit until you are sure everything’s working.

All that’s left is to test your system, make sure the various services are working, and then you’re done – one more pool rebuild is now under your belt!

Announcing Bildaro, a self-hosted photo gallery

Mon, 11 Nov 2024 00:00:00 +0000

It’s been a busy past couple of days! An idea I had over the weekend spawned a new little project that I’m eager to share.

I’m excited to announce Bildaro: A new self-hosted, minimalist, teeny tiny, mobile-friendly photo gallery and image processor and uploader.

Bildaro is a small-footprint Jekyll blog that, when combined with AWS S3 and AWS Amplify, provides a simple, performant, serverless way to self-host your photo collection at a very low cost.

You retain control over the platform and your content, and your site visitors get a fast, streamlined, simple experience.

The small codebase is easy to understand and welcomes tinkering so you can adjust it to your needs:

30 lines of JS to power the image lightbox modal.
260 lines of CSS (Sass) that Jekyll will compile for you on build.
170 lines of code for the image processor and file uploader, written as a simple Bash script with no dependencies other than the tools it uses (imagemagick and aws cli via pip).
Other dependencies are minimal and are only needed if you want to run Jekyll locally (ruby and a few small Ruby gems).

And just to reiterate: The numbers above are not KB of code, they’re individual lines of code. Bildaro is smol.

Why a self-hosted serverless photo gallery?

Running your own web server requires expertise, takes considerable effort to get running, and requires an investment in long-term maintenance.

Many popular self-hosted solutions, like my previous all-time favorite Lychee, have grown into behemoths that require all sorts of dependencies just for a baseline install. And since they run on a live system exposed to the internet, you’ll have to be vigilant and keep current with updates to keep your system secure.

A static website: doesn’t require any maintenance, is practically immune to almost all of the typical vulnerability channels websites face because it doesn’t have any “moving parts,” and can be served quickly and at massive scale for very little money.

Why did I make Bildaro?

I’ve hosted a photo gallery in the past, but I was tired of maintaining it. I took it offline for a while to see if Dropbox would be sufficient. Turns out Dropbox is “just fine,” but it’s not an ideal experience. The web interface is heavy and bulky, full of log in dialogs, cookie notices, upsells, and now all this AI bullshit. It left me wanting to self-host again.

This past weekend I spun up a new web server to host Lychee, and it quickly became apparent that the project had just gotten really big for my rather basic needs. Composer, Laravel, Artisan, code linters, local development tools, CSS frameworks, Vue, Typescript, Font Awesome, gesture libraries… All in all about 400 MB of dependencies to download just to get started.

On top of that, don’t forget that you have the complexity of the baseline OS install to support the software stack in the first place. You’ll need Apache/nginx/lighttpd, PHP, and a database engine. Do you want MariaDB or SQLite? You have to keep all of these things updated. And backed up. Then there’s SSH, ZeroTier, Certbot and SSL certs and renewals, software dependencies…

That’s a lot of moving parts for something that feels so simple.

It got me thinking that there’s gotta be a better way.

My brain started turning:

My photo gallery website doesn’t change, except when I add or remove photos.
So if it rarely changes, why do I need a dynamically-generated, database-backed, full-blown web server running with dedicated CPU and RAM just to host a basic static site?
Could this be a static website in disguise? Should it have been one this entire time?

Jekyll to the rescue

Jekyll feels like an old friend. I’ve used the platform for years to create this blog, and other websites for business and hobbies. It’s a platform I know and trust. It’s performant and has powerful and useful features. It does a thing with focus and it does it well. And… it took on absolute superpowers when served with AWS Amplify.

As soon as I realized the photo gallery site could be static, the flood happened. Everything fell into place.

The photo albums can just be posts, with YAML data storing all of the images in the album along with some basic metadata.
The images can live on AWS S3, where they can take up as much space as I need, and it’ll cost next-to-nothing. They can be decoupled from the blog, so I don’t have to worry about working with the images in the repo.
AWS Amplify can host the Jekyll site in a serverless fashion, like I do with this site. And it’ll be served from a CDN edge, with more performance than I could ever get out of the web server. (Frankly, more performance than I’ll ever need for my simple site.) And best of all, I won’t have to manage a single thing.
I can write a simple Bash script to convert the source JPGs into web-optimized webp thumbnails and the display size variants, create the album zip download file for people that want it, have it export an image manifest, and even upload all the files to S3 for me.
Changes happen as repo commits and can trigger build events, updating the gallery site.
The site can just fucking sit there and serve and serve and serve for pennies until I’m ready to change it. Like how this blog does. No moving parts. No worrying about software updates, Certbot renewal triggers, or anything that comes with running your own server. Ever.

So, I got to work!

Bonvenon, Bildaro!

I wrote Bildaro in the course of two days. Two good “sit down and focus” sessions is all it took. It all came together very quickly, because the premise is so simple: Bildaro is basically a Jekyll blog, nothing more.

Albums are simply posts, and they contain a YAML list of the photos in the album. The view page simply iterates over those images and creates the photo gallery output. The image URLs get prepended with the S3 bucket URL. And even better, this file is generated from the Bash script. All you need to do is edit the title and the cover image, commit the changes, and Amplify takes care of the rest.

Example album _posts/2023-09-17-satsop-nuclear-plant.md

--- title: Satsop Nuclear Plant cover: DSC07949.jpg download_size: 4264 pictures: - DSC07949.jpg - DSC08116.jpg - DSC08264.jpg - DSC08378.jpg - DSC08392.jpg - DSC08403.jpg - DSC08426.jpg - DSC08429.jpg --- 

Since the page is static and written from scratch, it’s lightweight and performant. Check out these Pagespeed scores and see just how lightweight the gallery homepage is:

I’m sure there are other Jekyll photo galleries out there, but it felt so rewarding to write one for myself, from scratch. Tuned to do exactly what I need it to do, and nothing more.

“This is my gallery. There are many like it, but this one is mine.”

Bildaro is open source, released under the permissive MIT license. It’s given me great pleasure to write this little thing. You’re welcome to take it for a spin!

Take a look at my photo gallery to see it in action.

Fix macOS Finder problems with Samba file shares

Sat, 03 Aug 2024 00:00:00 +0000

Using MacOS’s Finder to work with large file share directories on my FreeBSD Samba server was sometimes giving me very strange, erratic behavior. It felt like the server had amnesia or was having hallucinations.

Symptoms included:

Directory contents would take a very long time to load.
Directory contents would disappear after browsing between sibling folders.
Directories would show the contents of different sibling folders.

The problem was really annoying and took me quite a while to figure out.

At first, I thought it was an issue with Finder. However, third-party file browsers like Commander One and Marta showed the same symptoms.

Since I built the file server myself, I assumed it must be a problem I inadvertently caused. However, Windows, Linux, Android, nor other FreeBSD clients didn’t suffer from these issues. Also, protocols other than SMB were not affected (FTP and SSH were working just fine).

Some articles online suggested that Samba itself was to blame, or that MacOS’s implementation of the Samba client was buggy. I even considered switching away from Samba to some other protocol, but that wouldn’t be ideal.

After doing a lot of reading and testing, I learned that Finder aggressively caches directory listings, and that cache system can be unreliable with large fileshares over Samba. And I also learned that out-of-the-box Samba configurations need to be tweaked slightly to improve connections for MacOS clients.

The fixes below were scoured from many places on the web, including Reddit posts, blog posts, Github repos, and a deep dive of the Samba configuration documentation. It took me a few months to track down the various configuration combinations needed, but now everything’s been working properly.

Server changes

On the server, make the following changes to your distribution’s Samba config file. On FreeBSD, the file is /usr/local/etc/smb4.conf:

[global] # Enforce a minimum of Samba v2 (Vista / Server 2008) for client connections min protocol = SMB2 server min protocol = SMB2 # Performance improvements use sendfile = yes ea support = yes directory name cache size = 2500 # Improve compatibility with Macs vfs objects = catia fruit streams_xattr fruit:aapl = yes fruit:nfs_aces = no fruit:zero_file_id = yes fruit:metadata = stream fruit:resource = stream fruit:encoding = native spotlight backend = tracker readdir_attr:aapl_rsize = no readdir_attr:aapl_finder_info = no readdir_attr:aapl_max_access = no fruit:model = MacSamba fruit:posix_rename = yes fruit:veto_appledouble = no fruit:wipe_intentionally_left_blank_rfork = yes fruit:delete_empty_adfiles = yes # 2026: No longer recommended as this causes Finder error -8062. # veto files = /.DS_Store/.Trashes/ # delete veto files = yes  # (OPTIONAL) If this server isn't sharing printers, # disable printer support to speed things up. load printers = no printing = bsd printcap name = /dev/null # NOTE: 'spoolss' is not a typo. disable spoolss = yes 

Spotlight searching of Samba shares is disabled by default, but you can add this line to each of your Samba share definitions in smb.conf to be absolutely sure:

[yourshare] spotlight = no 

Client changes

On the MacOS client computers, create /etc/nsmb.conf:

[default] # Disable SMB v1 protocol_vers_map=6 # Disable NetBIOS port445=no_netbios # Use NTFS streams if supported streams=yes # Disable directory caching dir_cache_max_cnt=0 dir_cache_max=0 dir_cache_off=yes # Disable packet signing signing_required=no # Disable multi-channel connections and prioritize the wired ethernet connection mc_prefer_wired=yes mc_on=no # Disable SMB session signing validate_neg_off=yes 

Applying the changes

Restart the Samba service on the server (FreeBSD: service samba_server restart)
Restart each client computer

When you reconnect to the server shares on your machines, these issues shouldn’t occur anymore.

Update 2026-04-28: Note on prior `veto files` configuration directives

Initially, I had configured Samba to prevent macOS clients from writing .DS_Store and other cruft to server shares to keep things clean and tidy. However, as of March 2026, I started encountering errors preventing folder copy operations from succeeding. See the solution below under Troubleshooting.

As this is a battle that I appear to have lost, and I can’t prevent the files from being written without causing errors, I’m considering writing a small cron job to purge all cruft files from my server shares on a regular basis.

Troubleshooting

When copying files from a macOS computer to the server, Finder reports the error “The operation can’t be completed because an unexpected error occurred (error code -8062).”: Finder reports this error when it isn’t able to write the .DS_Store files to the remote location. Disable the veto files and delete veto files configuration lines, restart Samba, and try again.

Gaelan Lloyd

Published my second official WordPress plugin: E20 Page Tree

The backstory

The challenge I faced

Page Tree, to the rescue!

Exporting the WordPress page tree

A focused plugin

My second official WordPress plugin

Meet "Good Boy," My Zero-Dependency FreeBSD Bootstrapper

Why’d I make this?

The idea

What it does

Partially idempotent, in a “good-enough” way

Why not just use Ansible?

Closing thoughts

Published my first official WordPress plugin: Quick Edit Post by ID

The challenge I faced

Quick Edit field, to the rescue!

My first official WordPress plugin

Choosing a note system: My Experience with Syncthing, BookStack, and Git

Some notes about my particular use case

Thoughts on note-taking products

Comparing TXT files in Syncthing, BookStack, and Git-backed Markdown files for storing personal notes

Ratings, explained

Available on multiple devices

Ease of hosting and operating

Knowledgebase features

Usable on your work computer

Mobile-friendly web interface

Revision control

Data safety at rest

Content accessible if platform unavailable

Summary thoughts

Appendix: Miscellaneous thoughts on the platforms

BookStack

Git-backed Markdown

Tip: Save time making commits

Tip: Host a local Forgejo instance

How to create an IoT VLAN with OPNsense and TP-Link Omada (with IPv6 Prefix Delegation)

Table of contents

Introduction

Hardware used

Why you should put IoT devices on a separate VLAN

Before: The original network layout

Afterwards: The improved network layout

Get your ISP to provision you a /60 or /56 block of IPv6 addresses

Requesting the change from the ISP

Validating the prefix your ISP is issuing

OPNsense VLAN setup

Create the IoT VLAN in OPNsense

Assign the VLAN interface

Configure DHCP for the VLAN

Enable IPv6 router advertisements

Create firewall rules

Configure VLANs on your managed switch

Configure VLANs in TP-Link Omada

Common problems/Troubleshooting

Error: “IPv6 prefix ID is out of range”

VLAN Wi-Fi devices are not receiving IP addresses

IoT devices cannot see each other

Upgrade MariaDB from 10.6 LTS to 11.8 LTS on FreeBSD

Upgrade process

Fix weird lag issues with Intel graphics on FreeBSD 14.3 with i915 driver

The fix

What’s PSR?

How to rebuild a ZFS pool

What you’ll need

Before you begin

Some additional thoughts

How to rebuild a ZFS pool

Stop services and cronjobs

Collect data

Set up the new temporary storage

Create snapshots

Transfer snapshots to the temporary storage

Verify everything was copied

Destroy and rebuild the pool

Transfer snapshots from the temporary storage

Verify the pool data

Re-start services, cronjobs, and the server

Update 2026-04-28: Note on prior `veto files` configuration directives