Danny

Obsidian & Claude: a match made in heaven

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

Before I get into this: there are probably a hundred ways to achieve what I’m about to describe, and most of them are equally valid. My setup didn’t arrive fully formed. It evolved over several months of trying things, breaking things, and slowly landing somewhere I’m actually happy with. If your approach is different, that’s fine. This is just what works for me.

I wrote recently about how AI has fixed my productivity. This post is about how, specifically.

For a while, I’ve been using Claude for note-taking assistance, drafting, and the odd bit of code review. It was useful but fundamentally shallow: every conversation started from scratch, with no idea who I am, what I’m working on, or what happened in yesterday’s meetings. I’d spend more time explaining context than actually getting anything done.

That’s the problem this setup solves. It’s not one clever hack but a few things working together: a structured Obsidian vault, reliable sync, a headless server, and Claude with enough connections that it can actually understand the shape of my day.

Starting with the structure

The vault layout came almost entirely from a post by James Bedford on The Thinkers Club. His five-folder structure is simple enough to stick to long term:

Polaris: current goals, priorities, and what’s top of mind
Logs: daily, weekly, monthly, and quarterly notes
Commonplace: individual thought notes and knowledge
Outputs: shared writing, meeting transcripts, anything AI-generated
Utilities: templates and reference material

The key principle I took from his approach: keep AI-generated content out of the main knowledge graph. Granola meeting notes, AI summaries, exported content: all of it lives in Outputs rather than mixed into Commonplace. The knowledge graph stays clean because it only contains things I actually wrote.

Tags do a lot of the navigation work. I use nested hierarchies like #work/project-name and #tech/networking, which are portable (they survive app changes), queryable, and work well with Claude for targeted analysis.

The sync question

Running Obsidian across multiple devices — laptop, phone, and a Linux server — means you need a sync strategy. I spent some time looking at the options: git-based sync, Syncthing, iCloud, various self-hosted approaches. Each had friction. Git sync works beautifully until you make a quick edit on your phone and forget to commit. Syncthing is fine but needs babysitting.

I ended up on Obsidian Sync. It’s not free and it’s not self-hosted, but it just works. Notes appear on every device within a few seconds. The mobile client is properly maintained. There are no edge cases to think about. For a system that’s supposed to reduce friction, adding sync friction felt like the wrong trade.

The one nuance: Obsidian Sync and automated writes can conflict if writes aren’t handled carefully. For a while I had Claude editing vault files directly via the filesystem, which worked fine, until it didn’t. Sync errors started cropping up: partial writes propagating to other devices, files getting into odd states. Switching to the MCP approach (more on that below) fixed this entirely, because the server uses atomic writes: write to a temp file first, then rename it into place. Sync never sees a half-written file.

Headless Obsidian on Linux

Obsidian ships an official headless mode, designed specifically for running on servers without a display. I’m running it on a cloud-hosted Ubuntu server on Hetzner: Obsidian headless starts on boot, connects to Obsidian Sync, and keeps the vault directory current. No desktop, no GUI, just the sync process doing its job in the background.

The vault ends up as a folder of markdown files on disk, always up to date, ready for the MCP server to read and write.

The web MCP

Most Obsidian MCP servers are local stdio servers: they work when Claude Code is running on the same machine as your vault. That’s a reasonable setup on a single machine, but it means Claude.ai on the web and Claude on your phone can’t reach your vault at all.

obsidian-web-mcp by Jim Prosser takes a different approach. It’s a persistent HTTP service that runs on the machine where your vault lives, authenticated via OAuth 2.0, and accessible over the network. The vault files never leave your machine.

For remote access, the README suggests Cloudflare Tunnel. I already run Tailscale across all my devices, so I went that route instead: the MCP server listens on the local network, Tailscale makes it reachable from my phone, laptop, and anywhere else I’m signed in. No inbound ports, no public IP, same security guarantees. If you’re already on Tailscale, it’s the path of least resistance.

The tool set covers everything you’d need: reading files, searching full text, querying frontmatter, writing, moving, and batch operations. Soft deletes move files to .trash/ rather than permanently removing them, which matches Obsidian’s own behaviour. Setting it up took about an hour. The MCP server runs as a systemd service on my Linux server, pointed at the vault directory that Obsidian Sync keeps current.

The full picture

With the vault accessible as an MCP tool, Claude becomes genuinely context-aware. But the vault is only one piece. I also have Claude connected to:

Linear: work task management, where all my open issues live
Granola: records and transcribes work meetings, then exports them to the Obsidian vault automatically via my Granola-to-Obsidian extension
Work calendar: read and write access, so Claude can check availability, flag changes, and create events
Slack: connected to my work workspace, so Claude can read DMs, send messages, and flag conversations that need a reply

That combination is where things get interesting. Every work meeting I attend ends up as a structured note in 4. Outputs/Granola/. My open tasks across every project exist in Linear. My daily notes, thinking, and priorities live in Obsidian. Claude can see all of it. I also have Claude connected to my work calendar.

What this actually looks like in practice

Here’s a concrete example. I can tell Claude: “arrange a call with Paul and set the agenda to any open or relevant topics we have.”

From that single sentence, Claude will go and do all of this without further prompting. It checks our recent meeting notes in the Obsidian vault, where every Granola transcript lives thanks to the export extension, to see what we’ve already covered and what was left unresolved. It searches Linear for any open issues assigned to either of us that would be worth discussing. It looks at both our calendars to find a slot that works. Then it creates the calendar invitation, attaches a ready-made agenda of open topics pulled from those sources, and sends it.

If I want, it can also drop Paul a Slack message to give him a heads up and ask if there’s anything he’d like to add.

The reason that works isn’t clever prompting. It’s that every source Claude needs is connected and indexed: meeting history in Granola, tasks in Linear, calendar events directly, and any relevant notes in Obsidian. The context is already there. The prompt just tells it what to do with it.

Quick capture on the go

One of the inputs into this whole system is an iPhone shortcut triggered by the Action Button. Press it, type whatever’s on my mind, done. The shortcut drops the note straight into 3. Commonplace/Personal/Quick Thoughts in the vault.

What I type varies wildly. Sometimes it’s a task I don’t want to forget. Sometimes it’s a movie review I want to write up while it’s fresh. Sometimes it’s a half-formed idea. It doesn’t matter, and that’s the point: the only rule is zero friction at the point of capture. I don’t categorise it, tag it, or decide where it belongs. I just type and close my phone.

Claude handles the rest during the morning routine. It reads whatever landed in Quick Thoughts overnight and decides what to do with it. Work tasks become Linear issues and get added to the daily note. Reminders become checkboxes. A movie review gets filed as a note. Anything ambiguous gets surfaced to me with a suggested action rather than silently misfiled.

The morning routine

The part that pulled this together was building an automated morning routine. A launchd job fires at 8am and runs a single Claude command. Claude then:

Checks today’s daily note, creating it from template if it doesn’t exist yet
Compares the calendar against what’s already in the note, flagging any changes overnight
Processes anything in Quick Thoughts: tasks become checkboxes and Linear issues, everything else gets filed or surfaced
Pulls every open Linear issue assigned to me across all teams and adds anything not already listed to the Tasks section, sorted by urgency
Checks Slack for any DMs where the last message is from someone else and I haven’t replied, flagging each one with the gist of what they need
Surfaces a short briefing: calendar changes, extracted tasks, overdue issues, unreplied DMs, and a one-line reminder of the day’s key meetings

The daily note ends up pre-populated before I’ve looked at a screen. Meetings have log entries ready to fill in. Tasks from both Linear and overnight captures are already there as checkboxes.

At the end of the day, I just tell Claude “let’s wrap up today and get ready for tomorrow.” It summarises the meetings from the vault into the Logs section of the daily note, then creates tomorrow’s note pre-populated with whatever Linear items are due.

Where this lands

None of this required building anything particularly complex. The vault structure is someone else’s good idea, Obsidian Sync is an off-the-shelf product, obsidian-web-mcp is an open source project, and Claude handles the orchestration. The work was in connecting the pieces and writing clear enough instructions (in a CLAUDE.md file in the vault) that Claude knows what to do with the context it has.

The result is a morning briefing that knows what meetings I have, what I was supposed to finish yesterday, and what landed in my capture queue overnight. It’s not magic, but it does mean the first five minutes of my day involve less context reconstruction and more actually thinking.

Beyond the routine, what I’ve ended up with is a genuinely resourceful personal assistant that understands the full context of my working life, and a comprehensive record of pretty much everything I do at work. Every meeting, every task, every quick thought captured on the go: it’s all there, connected, and queryable. That’s not something I had before, and it turns out it’s more useful than I expected.

Daemon: a 2006 techno-thriller that reads like a 2026 product roadmap

Sat, 28 Feb 2026 00:10:00 +0000

Fair warning: this post contains spoilers for both Daemon and Freedom™. Then again, the books came out twenty years ago. If you haven’t read them by now, you probably weren’t going to. I highly recommend them both though, if you haven’t read them yet.

I finished re-reading Daniel Suarez’s Daemon and its sequel Freedom™ a few weeks ago. I first picked them up years back and thought they were solid techno-thrillers with some wild ideas baked into an entertaining plot. Reading them again in 2026, they’re just as gripping, but for somewhat different reasons. The realism has caught up in a way I wasn’t expecting. When I first read these books, I took them as clever speculation of what the future may look like. Now I’m reading them and thinking: yeah, that exists. That too. And that. The fiction hasn’t aged, the real world has just gone ahead and built most of it.

The premise is straightforward: Matthew Sobol, a dying game developer, leaves behind a distributed AI program that activates after his death. The Daemon, as it’s called, begins infiltrating systems, recruiting operatives through an online game-like interface, and systematically restructuring society. In Freedom™, the sequel, that restructuring plays out in full: decentralised communities, alternative economies, mesh networks, and a population split between those plugged into the new system and those clinging to the old one.

Suarez self-published Daemon in 2006. That bears repeating. 2006. YouTube was a year old. The iPhone didn’t exist yet. And this guy was writing about autonomous vehicles, augmented reality glasses, voice-controlled AI agents, distributed botnets acting with real-world consequences, and desktop fabrication units. Not as far-future sci-fi set in 2150, but as things that were five to ten years away.

The tech that landed

The Daemon’s entire existence starts with what is essentially a cron job. Sobol’s program sits dormant, scraping news headlines, waiting for a specific trigger: reports of his own death. When it finds them, it wakes up and starts executing. It wasn’t a sentient AI gone rogue with a dramatic moment it becomes into being. Just a script polling RSS feeds on a schedule, pattern-matching against text, and firing off the next step in a chain. I had something similar with OpenClaw for a while. Not the assassinations, obviously, but the same fundamental architecture of scheduled tasks that wake up, pull information from the internet, process it, and take action without any human prompting. Morning briefings, inbox sweeps, periodic research jobs. The Daemon’s trigger mechanism felt sinister in 2006. Now it’s a feature you can configure in a YAML file. Yep, I know what you’re thinking - we’ve had cron for a long time and this part was possible even before the book was written - but this is just the first chapter of the book.

Then there are the autonomous machines. Sobol’s Daemon deploys “AutoM8s”: driverless vehicles that transport operatives and, in the book’s darker moments, act as weapons. It also uses robotic ground units for surveillance and enforcement. In 2006, this was pure fiction. Now Boston Dynamics has Spot, a quadruped robot dog that autonomously navigates terrain, avoids obstacles, and self-charges. Their Atlas humanoid can do backflips, parkour courses, and 540-degree inverted flips. These are real machines you can watch on YouTube doing things that would have read as absurd twenty years ago. Suarez’s vision of autonomous robots patrolling and operating independently isn’t a prediction anymore, it’s a product catalogue.

The always-connected vehicle is another one. In Daemon, the AutoM8s are permanently networked, receiving instructions and sharing data in real time. Every Tesla on the road today is essentially this. Always online, streaming telemetry back to the mothership, receiving over-the-air updates, and feeding its camera data into a collective neural network. The car you’re driving is a node in someone else’s distributed system. Sobol would have appreciated the irony of people voluntarily buying into that.

One of the creepier technologies in the books is WiFi-based surveillance, using wireless signals to detect and track people through walls. Suarez wrote about this as a covert capability the Daemon could exploit. Carnegie Mellon researchers have since built exactly that. Their “DensePose from WiFi” system uses standard WiFi router signals to reconstruct human poses in real time, even through solid walls. The reflected signals carry enough information about body shape and movement that a neural network can map what you’re doing in a room without a single camera. It works through drywall, wood, and even concrete up to a point, and none of this is classified military tech. It’s published academic research that anyone can read.

The acoustic weapon is probably the one that catches people off guard the most. In Daemon, there’s a directed sound system that can make audio appear to come from right beside you while no one else in the room hears a thing. It sounds like science fiction until you look up parametric speakers. Companies like Holosonics have been selling “Audio Spotlight” systems for years. They work by emitting “modulated ultrasonic beams that demodulate into audible sound only within a tight, targeted area” - I’ve experienced these in airports, but have no idea what that quote actually means. Museums, airports, and retailers already use them, and the military has explored them for crowd control. The effect is exactly what Suarez described, sound that seems to materialise out of thin air, audible only to the person standing in the beam, and you can buy one commercially right now.

The social dynamics might be the most on-the-nose parallel of all. In the books, the Daemon recruits human operatives to carry out tasks in the physical world. It finds people, assigns them work, and pays them through its own system. The humans don’t fully understand the bigger picture. They just complete their tasks and collect their reward. In January 2026, a site called RentAHuman.ai launched. It’s a platform where OpenClaw AI agents can hire actual people to perform tasks for them. Humans sign up with their skills and hourly rate, AI agents post jobs, and people complete them for payment in stablecoins. Over 40,000 people registered within days. The framing is different, obviously. It’s gig work, not a shadowy network of mindless humans - arguably. But the underlying structure is identical. AI systems delegating physical-world tasks to human operatives who sign up voluntarily, motivated by compensation and a sense of participation in something larger. Suarez wrote it as dystopian fiction that, in 2006 seemed like only the insane would enroll. We built it as a startup and it got very popular, very quickly.

What he got wrong (sort of)

The 10% that hasn’t happened is mostly about scale and centralisation. Sobol’s Daemon is a single, coherent system with an architect’s intent behind every action. Real distributed systems don’t work like that. AI development has been messy, competitive, and fragmented across hundreds, perhaps even thousands, of companies and research labs. There’s no singular Daemon pulling strings, just a chaotic landscape of overlapping systems with no one fully in control. Which, depending on your perspective, might actually be worse.

The weaponised autonomous vehicles haven’t materialised in the way Suarez imagined either, though military drones certainly have. The line between his fiction and real-world drone warfare is thinner than most people would be comfortable with.

And the neat resolution in Freedom™, where Darknet communities build something genuinely better, still feels like the most fictional part of the whole thing. We’ve got the decentralised technology. We’ve got the mesh networks and the alternative currencies. What we haven’t got is the social cohesion to do anything coherent with them. Crypto became a speculative casino with massive peaks and equal troughs. The tools exist, but the utopian bit remains out of reach.

Why it matters now

Suarez wasn’t writing from some academic ivory tower or speculating about technology he’d never touched. He was an IT consultant who spent years working with Fortune 1000 companies, and you can feel that experience on every page. He understood how systems actually work, how they fail, and how they get exploited, which is what makes re-reading both books such a strange experience. He wasn’t guessing at any of this. He was extrapolating from things he could already see forming, and doing it with an accuracy that I genuinely wouldn’t have believed twenty years ago.

If you haven’t read Daemon and Freedom™, go and read them. I track everything I read on Hardcover, and both of these are easy five-star picks. They’re fantastic books on their own merits. The pacing is relentless, the technical detail is sharp without being dry, and the plot keeps pulling you forward. I’d recommend them even if none of the technology had come true.

But it has, and not gradually over twenty years. The pace is accelerating. Half the parallels I’ve listed in this post didn’t exist even twelve months ago. OpenClaw’s cron system, RentAHuman.ai, the latest generation of Boston Dynamics robots: all 2025 or 2026 developments. The gap between Suarez’s fiction and our reality is closing faster each year, and that makes the books hit differently every time you revisit them. I suspect they’ll hit differently again in another twelve months, and I can’t wait to re-read them then.

AI has fixed my productivity

Wed, 18 Feb 2026 00:10:00 +0000

A Fortune survey doing the rounds this week has thousands of CEOs admitting that AI has had no measurable impact on employment or productivity. It’s being treated as vindication by the sceptics and a crisis by the vendors. I read it and thought: these people are using AI wrong.

I use AI tools every day. Claude helps me write code. OpenClaw handles the kind of loose, conversational thinking I used to do on paper or in my head. Granola transcribes my meetings and a plugin I built pipes the notes straight into Obsidian. My email gets triaged before I look at it. Research gets compiled in minutes instead of hours. This stuff has genuinely changed how I work, and I don’t think I could go back.

The CEO survey doesn’t prove AI is failing. It proves that most organisations have no idea how to deploy it.

What actually changed

The gains aren’t where the enterprise pitch decks said they’d be. Nobody handed me an AI tool that “transformed my workflow” in one go. What happened was slower and more specific: a dozen small frictions disappeared, and the cumulative effect was significant.

Meeting notes are the obvious one. Before Granola, I’d either scribble while half-listening or pay attention and try to reconstruct things afterwards from memory. Both were bad. Now the transcript happens in the background, a summary lands in my Obsidian vault automatically, and I can actually be present in the conversation. That’s 20 minutes a day I got back, every day, without thinking about it.

Code generation changed my relationship with side projects entirely. I’ve shipped things this year that I simply wouldn’t have started before: small tools, automations, scripts that solve a specific problem in an afternoon instead of a weekend. The AI doesn’t write production-quality code on its own, but it gets me from “I know what I want” to “I have something running” in minutes instead of hours. That speed difference matters. It’s the difference between “I’ll build that someday” and actually building it.

Summarising long documents, compiling research, triaging email: none of these are exciting. But they used to eat real time. Now they don’t. The compound effect of reclaiming 30 or 40 minutes across a day is that my actual focus hours go further. I wrote about protecting those hours last year, and AI tools have turned out to be one of the better ways to do it.

Why the survey got it wrong

The CEO survey is measuring organisational productivity, which is a completely different thing from individual productivity. Most companies deployed AI by buying enterprise licences and hoping for the best. Copilot seats for every developer. ChatGPT access for every department. No training, no workflow integration, no clarity on what problems the tools were supposed to solve.

That’s not an AI failure. That’s a deployment failure. It’s a silly analogy, but you wouldn’t buy everyone in the company a piano and then wonder why not everyone is a musician a month later. But that’s essentially what happened with AI in most organisations, and it hopefully illustrates the point.

The productivity gains I’ve found came from figuring out, through months of trial and error, exactly where AI fits into my specific workflow. Not the generic “write me an email” stuff. The narrow, targeted things: transcription, code scaffolding, document summarisation, research triage. Each one required experimentation to get right. Most people in most companies haven’t done that work, and their employers aren’t helping them do it.

There’s also a measurement problem. My 20 minutes saved on meeting notes doesn’t show up in a quarterly report. The side project I shipped in a day instead of a week doesn’t register as a productivity metric. The compounding effect of less friction across dozens of small tasks is invisible to anyone looking at spreadsheets. CEOs are looking for step-change improvements because that’s what they were sold. The actual gains are granular and personal, which makes them hard to count and easy to dismiss.

The uncomfortable bit

None of this is free. Every AI tool that makes me more productive does so by ingesting my work. My meeting transcripts, my code, my half-formed ideas, my entire stream of consciousness on a given day: all of it flows through systems I don’t own and can’t audit.

I’ve spent the past year moving away from surveillance platforms. I replaced Google Photos with Ente, Gmail with Migadu, WhatsApp with Signal. I run my own XMPP server. I self-host my password manager. And yet I willingly feed more context into AI tools each day than Google ever passively collected from me.

It’s a contradiction I haven’t resolved. The productivity gains are real enough that I’m not willing to give them up, but the privacy cost is real too, and I notice it. For companies putting their entire workforce’s output through third-party AI, the data governance implications are enormous. Most organisations haven’t thought about this seriously, which is another reason the CEO survey results look the way they do: they adopted the tools without understanding what they were trading.

I’ve settled into an uneasy position: AI for work where the productivity gain justifies the privacy cost, strict boundaries everywhere else. It’s not philosophically clean. It’s just honest.

The real gap

The gap isn’t between AI’s potential and its capability. The tools are good enough. The gap is between having access to AI and knowing how to use it well. That’s an individual skill, built through experimentation, and it doesn’t scale the way enterprise software purchases do.

I’ll keep using these tools. They’ve made me measurably more productive in ways I can point to: time saved, projects shipped, focus protected. The CEOs in that survey aren’t wrong about what they’re seeing in their organisations. They’re just wrong about what it means. AI hasn’t failed. Most companies just haven’t figured it out yet.

Running My Own XMPP Server

Mon, 16 Feb 2026 00:00:10 +0000

About a year ago I moved my personal messaging to Signal as part of a broader push to take ownership of my digital life. That went well. Most of my contacts made the switch, and I’m now at roughly 95% Signal for day-to-day conversations. But Signal is still one company running one service. If they shut down tomorrow or change direction, I’m back to square one.

XMPP fixes that. It’s federated, meaning your server talks to other XMPP servers automatically and you’re never locked into a single provider. Your messages live on your hardware. The protocol has been around since 1999 and it’s not going anywhere. I’d tried XMPP years ago and bounced off it, but the clients have come a long way since then. Monal and Conversations are genuinely nice to use now.

This post covers everything I did to get a fully working XMPP server running with Prosody in Docker, from DNS records through to voice calls.

Prerequisites

A server with Docker and Docker Compose
A domain you control
TLS certificates (Let’s Encrypt works well)

DNS records

XMPP uses SRV records to let clients and other servers find yours. You’ll need these in your DNS:

_xmpp-client._tcp.xmpp.example.com SRV 0 5 5222 xmpp.example.com.
_xmpp-server._tcp.xmpp.example.com SRV 0 5 5269 xmpp.example.com.

Port 5222 is for client connections, 5269 is for server-to-server federation. You’ll also want an A record pointing xmpp.example.com to your server’s IP.

If you want HTTP file uploads (I’d recommend it), add a CNAME or A record for upload.xmpp.example.com pointing to the same server. Same for conference.xmpp.example.com if you want group chats with a clean subdomain, though Prosody handles this internally either way.

TLS certificates

Prosody won’t start without certificates. I use Let’s Encrypt with the Cloudflare DNS challenge so I don’t need to expose port 80:

docker run --rm \
 -v ~/docker/xmpp/certs:/etc/letsencrypt \
 -v ~/docker/xmpp/cloudflare.ini:/etc/cloudflare.ini:ro \
 certbot/dns-cloudflare certonly \
 --dns-cloudflare \
 --dns-cloudflare-credentials /etc/cloudflare.ini \
 -d xmpp.example.com

The cloudflare.ini file contains your API token:

dns_cloudflare_api_token = your-cloudflare-api-token

After certbot runs, fix the permissions so Prosody can read the certs:

chmod -R 755 ~/docker/xmpp/certs/live/ ~/docker/xmpp/certs/archive/
chmod 644 ~/docker/xmpp/certs/archive/xmpp.example.com/*.pem

Set up a cron to renew monthly:

0 3 1 * * docker run --rm -v ~/docker/xmpp/certs:/etc/letsencrypt \
 -v ~/docker/xmpp/cloudflare.ini:/etc/cloudflare.ini:ro \
 certbot/dns-cloudflare renew \
 --dns-cloudflare-credentials /etc/cloudflare.ini \
 && docker restart xmpp

The Docker setup

The docker-compose.yml:

services:
 prosody:
 image: prosodyim/prosody:13.0
 container_name: xmpp
 restart: unless-stopped
 ports:
 - "5222:5222"
 - "5269:5269"
 volumes:
 - prosody-data:/var/lib/prosody
 - ./prosody.cfg.lua:/etc/prosody/prosody.cfg.lua:ro
 - ./certs/live/xmpp.example.com/fullchain.pem:/etc/prosody/certs/xmpp.example.com.crt:ro
 - ./certs/live/xmpp.example.com/privkey.pem:/etc/prosody/certs/xmpp.example.com.key:ro

volumes:
 prosody-data:

Two ports exposed: 5222 for clients, 5269 for federation. The data volume holds user accounts and message archives. Config and certs are mounted read-only.

Prosody configuration

This is the core of it. I’ll walk through the key sections rather than dumping the whole file.

Modules

Prosody is modular. My module list:

modules_enabled = {
-- Core
"roster"; "saslauth"; "tls"; "dialback"; "disco";
"posix"; "ping"; "register"; "time"; "uptime"; "version";
-- Security
"blocklist";
-- Multi-device & mobile
"carbons"; "csi_simple";
"smacks"; -- Stream Management (reliable delivery)
"cloud_notify"; -- Push notifications for mobile
-- Message archive
"mam";
-- User profiles & presence
"vcard_legacy"; "pep"; "bookmarks";
-- Admin
"admin_shell";
}

The ones I found matter most for a good mobile experience: carbons syncs messages across all your devices instead of delivering to whichever one happened to be online. smacks (Stream Management) handles flaky connections gracefully, so messages aren’t lost when your phone briefly drops signal. cloud_notify enables push notifications so mobile clients don’t need a persistent connection, which is essential for battery life. And mam (Message Archive Management) stores history server-side for search and cross-device sync.

Security settings

c2s_require_encryption = true
s2s_require_encryption = true
s2s_secure_auth = true
authentication = "internal_hashed"
allow_registration = false

All connections are encrypted and registration is disabled since I create accounts manually with prosodyctl. I’ve enabled s2s_secure_auth, which means Prosody will reject connections from servers with self-signed or misconfigured certificates. You’ll lose federation with some poorly configured servers, but if you’re self-hosting for privacy reasons it doesn’t make much sense to relax authentication for other people’s mistakes.

OMEMO encryption

TLS encrypts connections in transit, but the server itself can still read your messages. If you’re self-hosting, that means you’re trusting yourself, which is fine. But if other people use your server, or if you just want the belt-and-braces approach, OMEMO adds end-to-end encryption so that not even the server operator can read message content.

OMEMO is built on the same encryption that Signal uses, so I’m comfortable trusting it. There’s nothing to configure on the server side either. OMEMO is handled entirely by the clients. Monal, Conversations, and Gajim all support it, and in most cases it’s enabled by default for new conversations. I’d recommend turning it on for everything and leaving it on.

Message archive

archive_expires_after = "1y"
default_archive_policy = true

Messages are kept for a year and archiving is on by default. Clients can opt out per-conversation if they want.

HTTP for file uploads

http_interfaces = { "*" }
http_ports = { 5280 }
https_ports = { }
http_external_url = "https://xmpp.example.com"

Prosody serves HTTP on port 5280 internally. I leave HTTPS to my reverse proxy (Caddy), which handles TLS termination. The http_external_url tells Prosody what URL to hand clients when they upload files.

Virtual host and components

VirtualHost "xmpp.example.com"
ssl = {
key = "/etc/prosody/certs/xmpp.example.com.key";
certificate = "/etc/prosody/certs/xmpp.example.com.crt";
}
Component "conference.xmpp.example.com" "muc"
modules_enabled = { "muc_mam" }
restrict_room_creation = "local"
Component "upload.xmpp.example.com" "http_file_share"
http_file_share_size_limit = 10485760 -- 10 MB
http_file_share_expires_after = 2592000 -- 30 days
http_external_url = "https://xmpp.example.com"

The MUC (Multi-User Chat) component gives you group chats with message history via muc_mam. I restrict room creation to local users so random federated accounts can’t spin up rooms on my server.

The file share component handles image and file uploads. A 10 MB limit and 30-day expiry keeps disk usage under control.

Reverse proxy for file uploads

Prosody’s HTTP port needs to be reachable from the internet for file uploads to work. I use Caddy:

xmpp.example.com {
reverse_proxy xmpp:5280
}

When a client sends an image, Prosody hands it a URL like https://xmpp.example.com/upload/... and the receiving client fetches it over HTTPS.

Creating accounts

With registration disabled, accounts are created from the command line:

docker exec -it xmpp prosodyctl adduser danny@xmpp.example.com

It prompts for a password. Done. Log in from any XMPP client.

Firewall

Open the XMPP ports:

sudo ufw allow 5222 comment 'XMPP client'
sudo ufw allow 5269 comment 'XMPP federation'

Port 80/443 for the reverse proxy if you haven’t already. If your server is behind a router, forward 5222 and 5269.

Voice and video calls

Text and file sharing work at this point. Voice and video calls need one more piece: a TURN/STUN server. Without it, clients behind NAT can’t establish direct media connections.

I run coturn alongside Prosody. The two share a secret, and Prosody generates temporary credentials for clients automatically.

Generate a shared secret:

openssl rand -hex 32

The coturn docker-compose.yml:

services:
 coturn:
 image: coturn/coturn:latest
 container_name: coturn
 restart: unless-stopped
 network_mode: host
 volumes:
 - ./turnserver.conf:/etc/coturn/turnserver.conf:ro
 tmpfs:
 - /var/lib/coturn

It runs with network_mode: host because TURN needs real network interfaces to handle NAT traversal. Docker’s port mapping breaks this.

The turnserver.conf:

listening-port=3478
tls-listening-port=5349
min-port=49152
max-port=49200
relay-threads=2
realm=xmpp.example.com
use-auth-secret
static-auth-secret=YOUR_SECRET_HERE
no-multicast-peers
no-cli
no-tlsv1
no-tlsv1_1
denied-peer-ip=10.0.0.0-10.255.255.255
denied-peer-ip=172.16.0.0-172.31.255.255
denied-peer-ip=192.168.0.0-192.168.255.255
log-file=stdout

If your server is behind NAT, add:

external-ip=YOUR_PUBLIC_IP/YOUR_PRIVATE_IP

Then tell Prosody about it. Add "turn_external" to your modules, and inside the VirtualHost block:

 turn_external_host = "xmpp.example.com"
turn_external_port = 3478
turn_external_secret = "YOUR_SECRET_HERE"

Open the firewall ports:

sudo ufw allow 3478 comment 'STUN/TURN'
sudo ufw allow 5349 comment 'TURNS'
sudo ufw allow 49152:49200/udp comment 'TURN relay'

Verify with docker exec xmpp prosodyctl check turn.

Clients

On iOS I went with Monal, which is open source and supports all the modern XEPs. Push notifications work well. On Android, Conversations seems to be the go-to. On desktop, Gajim covers Linux and Windows, and Monal has a macOS build.

All of them support OMEMO encryption, file sharing, group chats, and voice/video calls.

Verifying your setup

Prosody has solid built-in diagnostics:

docker exec xmpp prosodyctl check

This checks DNS records, TLS certificates, connectivity, and module configuration. Fix anything it flags. The error messages are genuinely helpful.

The XMPP Compliance Tester is worth running too. Mine scored above 90% after getting the config right.

Final thoughts

The whole setup runs in two small Docker containers and a reverse proxy entry. Prosody, file uploads, message archive, push notifications, group chats, voice calls.

I still use Signal for most day-to-day conversations and I’m not planning to stop. But having my own XMPP server means I’m not entirely dependent on any single service. I can message anyone on any XMPP server, not just people who signed up to the same one. It’s a nice fallback to have.

If you’re already running Docker on a server somewhere, it’s a good weekend project.

What Your Bluetooth Devices Reveal About You

Sun, 18 Jan 2026 16:00:00 +0000

If you’ve read much of this blog, you’ll know I have a thing for privacy. Whether it’s running my blog over Tor, blocking ads network-wide with AdGuard, or keeping secrets out of my dotfiles with Proton Pass, I tend to think carefully about what data I’m exposing and to whom.

Last weekend I built Bluehood, a Bluetooth scanner that tracks nearby devices and analyses their presence patterns. The project was heavily assisted by AI, but the motivation was entirely human: I wanted to understand what information I was leaking just by having Bluetooth enabled.

The timing felt right. A few days ago, researchers at KU Leuven disclosed WhisperPair (CVE-2025-36911), a critical vulnerability affecting hundreds of millions of Bluetooth audio devices. The flaw allows attackers to hijack headphones and earbuds remotely, eavesdrop on conversations, and track locations through Google’s Find Hub network. It’s a stark reminder that Bluetooth isn’t the invisible, harmless signal we treat it as.

The Problem Nobody Talks About

We’ve normalised the idea that Bluetooth is always on. Phones, laptops, smartwatches, headphones, cars, and even medical devices constantly broadcast their presence. The standard response to privacy concerns is usually “nothing to hide, nothing to fear.”

But here’s the thing: even if you have nothing to hide, you’re still giving away information you probably don’t intend to.

From my home office, running Bluehood in passive mode (just listening, never connecting), I could detect:

When delivery vehicles arrived, and whether it was the same driver each time
The daily patterns of my neighbours based on their phones and wearables
Which devices consistently appeared together (someone’s phone and smartwatch, for instance)
The exact times certain people were home, at work, or elsewhere

None of this required any special equipment. A Raspberry Pi with a Bluetooth adapter would do the job. So would most laptops.

Devices You Can’t Control

What concerns me most isn’t that people choose to have Bluetooth enabled. It’s that many devices don’t give users the option to disable it.

Hearing aids are a good example. Modern hearing aids often use Bluetooth Low Energy so audiologists can connect and adjust settings or run diagnostics. Pacemakers and other implanted medical devices sometimes broadcast BLE signals for the same reason. The user can’t simply turn this off.

Then there are vehicles. Delivery vans, police cars, ambulances, logistics fleets, and trains often have Bluetooth-enabled systems for fleet management, diagnostics, or driver assistance. These broadcast continuously, and the drivers have no control over it.

Even consumer devices aren’t always straightforward. Many smartwatches need Bluetooth to function at all. GPS collars for pets require it to communicate with the owner’s phone. Some fitness equipment won’t work without it.

Privacy Tools That Need You to Broadcast

What’s interesting is that some of the most privacy-focused projects actually require Bluetooth to be enabled.

Briar is a peer-to-peer messaging app designed for activists and journalists operating in hostile environments. It doesn’t rely on central servers, and when the internet goes down, it can sync messages via Bluetooth or Wi-Fi mesh networks. It’s a genuinely useful tool for maintaining communications during internet blackouts or in areas with heavy surveillance.

BitChat takes this even further. It’s a decentralised messaging app that operates entirely over Bluetooth mesh networks—no internet required, no servers, no phone numbers. Each device acts as both client and relay, automatically discovering peers and bouncing messages across multiple hops to extend the network’s reach. The project explicitly targets scenarios like protests, natural disasters, and regions with limited or censored connectivity.

Both are genuinely excellent projects solving real problems. But to use them, you need Bluetooth enabled. And every device with Bluetooth enabled is broadcasting its presence to anyone nearby who cares to listen.

This creates a strange tension. Tools designed to protect privacy often require a feature that compromises privacy in other ways.

What Metadata Reveals

People often underestimate what patterns reveal. A bad actor with a Bluetooth scanner doesn’t need to know your name. They just need to observe behaviour over time.

Consider what someone could learn by monitoring Bluetooth signals in a residential area for a few weeks:

When is the house typically empty?
Does someone visit every Thursday afternoon?
Is there a regular pattern that suggests shift work?
When do the children come home from school?
Which homes have the same delivery driver, suggesting similar shopping habits?

If there’s damage to your property, you could potentially go back through the logs and see which devices were in range at that time. A smartwatch on a dog-walker passing by. A phone in someone’s pocket. A vehicle with fleet tracking.

These might seem like edge cases, but they illustrate a broader point: we’re constantly leaving digital breadcrumbs we don’t even think about.

What Bluehood Actually Does

Bluehood is a Python application that runs on anything with a Bluetooth adapter. It continuously scans for nearby devices, identifies them by vendor and BLE service UUIDs, and tracks when they appear and disappear.

The key features:

Passive scanning: It only listens. It doesn’t try to connect or interact with any device.
Device classification: Phones, audio devices, wearables, vehicles, IoT devices, and more, identified by BLE fingerprints.
Pattern analysis: Hourly and daily heatmaps, dwell time tracking, and detection of correlated devices.
Filtering: Randomised MAC addresses (used by modern phones for privacy) are detected and hidden from the main view.
Web dashboard: A simple interface for monitoring and analysis.

You can run it in Docker or install it directly. It stores data in SQLite and optionally sends push notifications via ntfy.sh when watched devices arrive or leave.

Running It

The simplest way to try Bluehood is with Docker:

git clone https://github.com/dannymcc/bluehood.git
cd bluehood
docker compose up -d

The dashboard is available at http://localhost:8080.

If you prefer a manual install:

sudo pacman -S bluez bluez-utils python-pip # Arch
sudo apt install bluez python3-pip # Debian/Ubuntu
pip install -e .
sudo bluehood

Bluetooth scanning needs elevated privileges. You can either run as root, grant capabilities to Python, or use the included systemd service for always-on monitoring.

The Point of All This

Bluehood isn’t a hacking tool. It’s an educational demonstration of what’s possible with commodity hardware and a bit of patience.

I built it because I wanted to see for myself what I was broadcasting. The results were sobering. Even with no malicious intent, anyone with basic technical knowledge could learn a lot about my household just by sitting in their car and running a script.

This isn’t about paranoia. It’s about understanding the trade-offs we make when we leave wireless radios enabled on our devices. For some use cases, Bluetooth is essential. For others, it’s just convenience. Being aware of what you’re exposing is the first step to making informed decisions about which category your devices fall into.

If you try Bluehood and it makes you think twice about your own Bluetooth habits, it’s done its job.

The source code is available on GitHub. Feedback and contributions welcome.

Network-Wide Ad Blocking with Tailscale and AdGuard Home

Sat, 10 Jan 2026 00:00:10 +0000

One of the frustrations with traditional network-wide ad blocking is that it only works when you’re at home. The moment you leave your network, you’re back to seeing ads and trackers on every device. But if you’re already running Tailscale, there’s a simple fix: run AdGuard Home on a device in your tailnet and point all your devices at it.

The result? Every device on your Tailscale network gets full ad blocking and secure DNS resolution, whether you’re at home, in a coffee shop, or on the other side of the world.

Why This Setup?

I’ve been taking digital privacy more seriously in recent years. I prefer encrypted email via PGP, block ads and trackers wherever possible, and generally try to minimise the data I leak online.

I’ve been running Pi-hole for years, but it always felt like a half-measure. It worked great at home, but my phone and laptop were unprotected the moment I stepped outside. I could have set up a VPN back to my home network, but that felt clunky.

With Tailscale, the solution is elegant. Every device is already connected to my tailnet, so all I need is a DNS server that’s accessible from anywhere on that network. AdGuard Home fits the bill perfectly. It’s lighter than Pi-hole, has a cleaner interface, and supports DNS-over-HTTPS out of the box for upstream queries.

The other benefit is that this setup preserves Tailscale’s Magic DNS. I can still access my tailnet devices by name (like server.tail1234.ts.net), while all other DNS queries go through AdGuard for secure resolution and ad blocking.

What You’ll Need

A device on your Tailscale network that’s always on (a small home server, Raspberry Pi, or even an old laptop)
AdGuard Home installed on that device
Access to your Tailscale admin console

Installing AdGuard Home

SSH into your always-on device and run the official installer:

curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sudo bash

This installs AdGuard Home to /opt/AdGuardHome and sets it up as a systemd service.

Once installed, open the setup wizard in your browser at http://<tailscale-ip>:3000. During setup:

Set the DNS listen address to your device’s Tailscale IP (e.g., 100.x.x.x)
Set the admin interface to the same Tailscale IP on port 3000
Create an admin username and password

The key here is binding to your Tailscale IP rather than 0.0.0.0. This ensures AdGuard only listens on your tailnet, not on your local network or the public internet.

Configuring Secure Upstream DNS

By default, AdGuard will use your system’s DNS servers for upstream queries. That’s not ideal. We want encrypted DNS all the way through.

In AdGuard Home, go to Settings → DNS settings → Upstream DNS servers and replace the defaults with:

https://dns.quad9.net/dns-query
https://dns11.quad9.net/dns-query
tls://dns.quad9.net

These are Quad9’s DNS-over-HTTPS and DNS-over-TLS endpoints. Quad9 is a privacy-focused resolver that also blocks known malicious domains.

For the Bootstrap DNS servers (used to resolve the upstream hostnames), add:

9.9.9.9
149.112.112.112

I’d also recommend enabling DNSSEC validation and Optimistic caching in the same settings page for better security and performance.

Pointing Tailscale at Your DNS Server

Now the easy part. Open your Tailscale admin console and:

Add your device’s Tailscale IP as a Global nameserver
Enable Override local DNS

That’s it. Every device on your tailnet will now use your AdGuard instance for DNS resolution.

The Benefits

This setup gives you:

Ad and tracker blocking everywhere, not just at home
Encrypted DNS queries, so your ISP can’t see what domains you’re resolving
Malware protection via Quad9, which blocks known malicious domains at the DNS level
A single dashboard to view query logs and statistics for all your devices in one place
No client configuration since Tailscale pushes the DNS settings automatically

If you do keep logging enabled, the query logs can be useful for identifying apps that are phoning home or misbehaving. But there’s a trade-off here.

A Note on Logging

By default, AdGuard Home logs every DNS query from every device. That’s useful for debugging, but it felt uncomfortable to me. The majority of my family use my tailnet, and I have no interest in knowing what sites they’re visiting. I also don’t need my own traffic logged if it isn’t necessary.

I’ve turned off query logging entirely in Settings > General settings > Query log configuration, and disabled statistics as well. Ad blocking still works without any of this data being stored.

A Note on Reliability

Since all your devices depend on this DNS server, you’ll want to make sure it’s reliable. If the device running AdGuard goes offline, DNS resolution will fail for your entire tailnet.

A few options to mitigate this:

Run AdGuard on a device that’s always on (a dedicated home server or cloud VPS)
Add a fallback DNS server in Tailscale (though this bypasses AdGuard when your server is down)
Run a second AdGuard instance on another device and add both as nameservers

For my setup, I’m running it on a small Intel NUC that’s always on anyway. It’s been rock solid so far.

Wrapping Up

This is one of those setups that takes ten minutes and then quietly improves your life. Every device on my tailnet now gets ad blocking and secure DNS without any per-device configuration. The combination of Tailscale’s networking and AdGuard’s filtering is genuinely elegant.

If you’re already running Tailscale, this is worth the effort.

Making My Blog Available on Tor

Tue, 06 Jan 2026 00:00:10 +0000

I wanted to make this blog available as a Tor hidden service. Not because I expect many visitors via Tor, but because it felt like a small contribution to a more private web. If someone wants to read my posts without revealing their IP address, they should be able to.

The setup has two parts: a Docker container running Tor and Nginx on my home server, and an HTTP header on the regular site that advertises the onion address.

The Docker setup

My blog is hosted on Netlify, so the hidden service works as a proxy. Tor users connect to the onion address, and the container fetches the content from the public site on their behalf.

Here’s the docker-compose.yml:

services:
 tor-dmcc-sites:
 build: .
 container_name: tor-dmcc-sites
 restart: unless-stopped
 volumes:
 - ./hidden_service_blog:/var/lib/tor/hidden_service_blog
 - ./hidden_service_website:/var/lib/tor/hidden_service_website

The volumes persist the hidden service keys. Once Tor generates your .onion address, you want to keep those keys. Otherwise you’ll get a new address every time the container restarts.

The Dockerfile:

FROM debian:bookworm-slim

RUN apt-get update && \
 apt-get install -y tor nginx curl && \
 apt-get clean && rm -rf /var/lib/apt/lists/*

RUN mkdir -p /var/lib/tor/hidden_service_blog && \
 mkdir -p /var/lib/tor/hidden_service_website && \
 chown -R debian-tor:debian-tor /var/lib/tor && \
 chmod 700 /var/lib/tor/hidden_service_blog && \
 chmod 700 /var/lib/tor/hidden_service_website

COPY torrc /etc/tor/torrc
COPY nginx.conf /etc/nginx/nginx.conf
COPY entrypoint.sh /entrypoint.sh

RUN chmod +x /entrypoint.sh

CMD ["/entrypoint.sh"]

The torrc configuration defines the hidden services:

# Disable SOCKS (we only need hidden services)
SocksPort 0
# Log to stdout for docker logs
Log notice stdout
# Hidden service for blog.dmcc.io
HiddenServiceDir /var/lib/tor/hidden_service_blog/
HiddenServicePort 80 127.0.0.1:8081
# Hidden service for dmcc.io (main website)
HiddenServiceDir /var/lib/tor/hidden_service_website/
HiddenServicePort 80 127.0.0.1:8082

Each hidden service points to a local port where Nginx is listening.

The nginx.conf proxies requests to the public sites:

user www-data;
worker_processes auto;
pid /run/nginx.pid;
error_log /var/log/nginx/error.log;
events {
worker_connections 768;
}
http {
sendfile on;
tcp_nopush on;
include /etc/nginx/mime.types;
default_type application/octet-stream;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;
server {
listen 8081;
location / {
proxy_pass https://blog.dmcc.io;
proxy_set_header Host blog.dmcc.io;
proxy_ssl_server_name on;
}
}
server {
listen 8082;
location / {
proxy_pass https://dmcc.io;
proxy_set_header Host dmcc.io;
proxy_ssl_server_name on;
}
}
}

Finally, the entrypoint.sh starts both services:

#!/bin/bash
set -e
chown -R debian-tor:debian-tor /var/lib/tor/hidden_service_blog
chown -R debian-tor:debian-tor /var/lib/tor/hidden_service_website
chmod 700 /var/lib/tor/hidden_service_blog
chmod 700 /var/lib/tor/hidden_service_website
nginx
exec su -s /bin/sh debian-tor -c "tor -f /etc/tor/torrc"

After running docker compose up -d, the onion address is generated in the hidden service directory:

cat hidden_service_blog/hostname

This gives you something like yxtxzre2jg3zhzlnqxrifaqbkuyd3e3sdgbjqf3tisrtypsbyoclrzqd.onion.

The Onion-Location header

Once the hidden service is running, the next step is telling Tor Browser users it exists. The Onion-Location HTTP header does exactly this. When Tor Browser sees it, a .onion available button appears in the address bar.

Since my blog is hosted on Netlify, I added a static/_headers file:

/*
Onion-Location: http://yxtxzre2jg3zhzlnqxrifaqbkuyd3e3sdgbjqf3tisrtypsbyoclrzqd.onion

For other setups:

Nginx:

add_header Onion-Location http://your-onion-address.onion$request_uri;

Apache:

Header set Onion-Location "http://your-onion-address.onion%{REQUEST_URI}s"

Caddy:

header Onion-Location "http://your-onion-address.onion{uri}"

HTML meta tag (if you can’t set headers):

<meta http-equiv="onion-location" content="http://your-onion-address.onion" />

Testing it

Open Tor Browser, visit any page of my blog, and look for the purple .onion available button in the address bar. Click it to switch to the hidden service.

You can also verify the header is set:

curl -I https://blog.dmcc.io | grep -i onion-location

Final thoughts

The whole setup took maybe half an hour. The Docker container runs quietly on my home server, and visitors using Tor Browser get a prompt that an onion version exists. It’s a small thing, but it means anyone who wants to read this blog privately can do so without trusting their connection to a third party.

Using Proton Pass CLI to Keep Linux Scripts Secure

Sun, 04 Jan 2026 00:01:00 +0000

If you manage dotfiles in a public Git repository, you’ve probably faced the dilemma of how to handle secrets. API keys, passwords, and tokens need to live somewhere, but committing them to version control is a security risk.

Proton has recently released a CLI tool for Proton Pass that solves this elegantly. Instead of storing secrets in files, you fetch them at runtime from your encrypted Proton Pass vault.

Installation

The CLI is currently in beta. Install it with:

curl -fsSL https://proton.me/download/pass-cli/install.sh | bash

This installs pass-cli to ~/.local/bin/. Then authenticate:

pass-cli login

This opens a browser for Proton authentication. Once complete, you’re ready to use the CLI.

Basic Usage

List your vaults:

pass-cli vault list

View an item:

pass-cli item view --vault-name "Personal" --item-title "My API Key"

Fetch a specific field:

pass-cli item view --vault-name "Personal" --item-title "My API Key" --field "API Token"

Get JSON output (useful for parsing multiple fields):

pass-cli item view --vault-name "Personal" --item-title "My API Key" --output json

Real-World Example: Wrapper Scripts

I have several tools that need API credentials. Rather than storing these in config files, I created wrapper scripts that fetch credentials from Proton Pass at runtime.

Here’s a wrapper for a TUI application that needs API credentials:

#!/bin/bash
set -e
PASS_CLI="$HOME/.local/bin/pass-cli"
# Fetch credentials from Proton Pass (JSON for single API call)
CREDS_JSON=$("$PASS_CLI" item view --vault-name "Personal" --item-title "My API" --output json)
if [ -z "$CREDS_JSON" ]; then
echo "Error: Failed to fetch credentials from Proton Pass" >&2
echo "Make sure you're logged in: pass-cli login" >&2
exit 1
fi
# Parse fields from JSON
API_USER=$(echo "$CREDS_JSON" | jq -r '.item.content.content.Custom.sections[0].section_fields[] | select(.name == "Username") | .content.Text')
API_TOKEN=$(echo "$CREDS_JSON" | jq -r '.item.content.content.Custom.sections[0].section_fields[] | select(.name == "Token") | .content.Hidden')
# Export and run
export API_USER API_TOKEN
exec my-app "$@"

The key insight: fetching JSON once and parsing with jq is faster than making separate API calls for each field.

Adding Credential Caching

The Proton Pass API call takes a few seconds. For frequently-used tools, this adds noticeable latency. The solution is to cache credentials in the Linux kernel keyring:

#!/bin/bash
set -e
PASS_CLI="$HOME/.local/bin/pass-cli"
CACHE_TTL=3600 # 1 hour
KEY_USER="myapp_user"
KEY_TOKEN="myapp_token"
# Try to get from kernel keyring cache
get_cached() {
local key_id
key_id=$(keyctl search @u user "$1" 2>/dev/null) || return 0
keyctl pipe "$key_id" 2>/dev/null
}
# Store in kernel keyring with TTL
cache_credential() {
local key_id
key_id=$(keyctl add user "$1" "$2" @u)
keyctl timeout "$key_id" "$CACHE_TTL"
}
# Try cache first
API_USER=$(get_cached "$KEY_USER")
API_TOKEN=$(get_cached "$KEY_TOKEN")
# If not cached, fetch from Proton Pass
if [ -z "$API_USER" ] || [ -z "$API_TOKEN" ]; then
CREDS_JSON=$("$PASS_CLI" item view --vault-name "Personal" --item-title "My API" --output json)
API_USER=$(echo "$CREDS_JSON" | jq -r '.item.content.content.Custom.sections[0].section_fields[] | select(.name == "Username") | .content.Text')
API_TOKEN=$(echo "$CREDS_JSON" | jq -r '.item.content.content.Custom.sections[0].section_fields[] | select(.name == "Token") | .content.Hidden')
# Cache for next time
cache_credential "$KEY_USER" "$API_USER"
cache_credential "$KEY_TOKEN" "$API_TOKEN"
fi
export API_USER API_TOKEN
exec my-app "$@"

With caching:

First run: ~5-6 seconds (fetches from Proton Pass)
Subsequent runs: ~0.01 seconds (from kernel keyring)

The cache expires after one hour, or when you log out. Clear it manually with:

keyctl purge user myapp_user
keyctl purge user myapp_token

Built-in Secret Injection

The CLI also has built-in commands for secret injection. The run command passes secrets as environment variables:

pass-cli run --env-file .env.template -- ./my-script.sh

The inject command processes template files:

pass-cli inject -i config.template -o config.conf

These use a URI syntax: pass://vault/item/field to reference secrets.

Updating Config Files

For applications that read credentials from config files (like WeeChat’s sec.conf), the wrapper can update the file before launching:

#!/bin/bash
set -e
SEC_CONF="$HOME/.config/myapp/secrets.conf"
# Fetch password from Proton Pass
PASSWORD=$("$HOME/.local/bin/pass-cli" item view --vault-name "Personal" --item-title "My Service" --field password)
# Update config file
sed -i "s/^password = \".*\"/password = \"$PASSWORD\"/" "$SEC_CONF"
exec myapp "$@"

SSH Agent Integration

The CLI can also act as an SSH agent, loading keys stored in Proton Pass:

pass-cli ssh-agent --help

This is useful if you store SSH private keys in your vault.

Security Considerations

This approach keeps secrets out of your dotfiles repository entirely. The wrapper scripts reference Proton Pass item names, not actual credentials. Your secrets remain encrypted in Proton’s infrastructure and are only decrypted locally when needed.

The kernel keyring cache is per-user and lives only in memory. It’s cleared on logout or reboot, and the TTL ensures credentials don’t persist indefinitely.

For public dotfiles repositories, this is a clean solution: commit your wrapper scripts freely, keep your secrets in Proton Pass.

Scheduled Deploys for Future Posts

Fri, 02 Jan 2026 00:00:00 +0000

One of the small joys of running a static blog is scheduling posts in advance. Write a few pieces when inspiration strikes, set future dates, and let them publish themselves while you’re busy with other things.

There’s just one problem: static sites don’t work that way out of the box.

The problem with static sites

With a dynamic CMS like WordPress, scheduling is built in. The server checks the current time, compares it to your post’s publish date, and serves it up when the moment arrives. Simple.

Static site generators like Hugo work differently. When you build the site, Hugo looks at all your content, checks which posts have dates in the past, and generates HTML for those. Future-dated posts get skipped entirely. They don’t exist in the built output.

This means if you write a post today with tomorrow’s date, it won’t appear until you rebuild the site tomorrow. And if you’re using Netlify’s automatic deploys from Git, that rebuild only happens when you push a commit. No commit, no deploy, no post.

I could set a reminder to push an empty commit every morning. But that defeats the purpose of scheduling posts in the first place.

The solution: scheduled builds

The fix is straightforward: trigger a Netlify build automatically every day, whether or not there’s new code to deploy.

Netlify provides build hooks for exactly this purpose. A build hook is a unique URL that triggers a new deploy when you send a POST request to it. All you need is something to call that URL on a schedule.

GitHub Actions handles the scheduling side. A simple workflow with a cron trigger runs every day at midnight UK time and pings the build hook. Netlify does the rest.

The setup

First, create a build hook in Netlify:

Go to your site’s dashboard
Navigate to Site settings → Build & deploy → Build hooks
Click Add build hook, give it a name, and select your production branch
Copy the generated URL

Next, add that URL as a secret in your GitHub repository:

Go to Settings → Secrets and variables → Actions
Create a new repository secret called NETLIFY_BUILD_HOOK
Paste the build hook URL as the value

Finally, create a workflow file at .github/workflows/scheduled-deploy.yml:

name: Scheduled Netlify Deploy

on:
 schedule:
 # Runs at 00:01 UK time (covers both GMT and BST)
 - cron: '1 0 * * *' # 00:01 GMT (winter)
 - cron: '1 23 * * *' # 00:01 BST (summer)
 workflow_dispatch: # Allow manual trigger

jobs:
 deploy:
 runs-on: ubuntu-latest
 steps:
 - name: Trigger Netlify Build
 run: curl -X POST -d {} ${{ secrets.NETLIFY_BUILD_HOOK }}

The dual cron schedule handles UK daylight saving time. During winter (GMT), the first schedule fires at midnight. During summer (BST), the second one does. There’s a brief overlap during the DST transitions where both might run, but an extra deploy is harmless.

The workflow_dispatch trigger is optional but handy. It adds a “Run workflow” button in the GitHub Actions UI, letting you trigger a deploy manually without pushing a commit.

The result

Now every morning at 00:01, GitHub Actions wakes up, pokes the Netlify build hook, and a fresh deploy rolls out. Any posts with today’s date appear automatically. No manual intervention required.

It’s a small piece of automation, but it removes just enough friction to make scheduling posts actually practical. Write when you want, publish when you planned.

Leaving Spotify for Self-Hosted Audio

Wed, 31 Dec 2025 21:00:00 +0000

I’ve been a Spotify subscriber for years. It’s convenient, the catalogue is vast, and the recommendations used to be genuinely useful. But lately, I’ve found myself increasingly uncomfortable with the direction the platform is heading.

The Spotify problem

It’s hard to pin down exactly when Spotify stopped feeling like a music service and started feeling like something else entirely. A few things have been gnawing at me:

Artist compensation is broken. The per-stream payout is famously tiny, and the model actively discourages the kind of music I actually want to support. Albums that reward repeated listening lose out to background playlist fodder designed to rack up streams. In 2024, Spotify stopped paying royalties entirely for any track under 1,000 streams, demonetising an estimated 86% of music on the platform.

The interface is hostile. Every update seems to prioritise podcasts, audiobooks, and algorithmically-generated content over letting me play my own playlists. The homepage is a mess of things I didn’t ask for.

AI-generated music is creeping in. There’s been a wave of low-effort AI tracks flooding the platform, often mimicking real artists or filling ambient playlists. Spotify removed over 75 million spam tracks in 2024 alone. It feels like the beginning of a race to the bottom, where quantity beats quality and genuine artists get drowned out.

I don’t own anything. After years of subscription payments, I have nothing to show for it. If Spotify disappears tomorrow, or removes an album I love, it’s just gone.

The company’s direction feels off. Beyond the platform itself, there’s the question of what Spotify’s leadership prioritises. CEO Daniel Ek has been investing heavily in European defense technology. That’s his prerogative, of course, but it underlines that my subscription money flows to a company whose priorities don’t align with mine.

Spotify Wrapped was a wake-up call. In previous years, Wrapped felt like a fun novelty. This year it was a reminder that I don’t actually listen to that many artists. The ones I enjoy, I play on repeat. So why am I paying a monthly subscription to listen to the same songs over and over? The artists I love aren’t seeing much from those streams, and I’m essentially renting music at an increasingly high cost. The family plan price keeps creeping up, and for what? The privilege of temporarily accessing albums I could just buy outright?

The alternatives aren’t much better

The obvious response is “just switch to another service.” But the alternatives have their own problems.

YouTube Music / Google shares many of Spotify’s issues, with the added concern that both platforms profit from advertising revenue that flows from some less than savoury sources. When your business model depends on engagement at any cost, the incentives get murky fast.

Apple Music locks you further into an ecosystem and has its own history of prioritising platform control over user freedom.

Tidal is perhaps the current outlier. Better artist payouts, lossless audio as standard, and seemingly fewer of the dark patterns plaguing the others. But streaming services have a habit of starting idealistic and drifting toward the mean once growth becomes the priority. How long until Tidal follows the same path? I’d rather not find out by having my library disappear when they pivot.

The fundamental problem isn’t any single company. It’s the streaming model itself. When you rent access instead of owning files, you’re always at the mercy of corporate decisions you have no control over.

What I actually want

When I thought about what I wanted from music, the list was simple:

Ownership - Files that live on my hardware, that I control
Quality - Lossless audio, not compressed streams
No algorithms - I’ll decide what to listen to, thanks
Supporting artists - Buying albums directly puts more money in their pockets than years of streaming

The setup

I’ve landed on a self-hosted Plex library for my music collection, served up with Plexamp on all my devices.

Plexamp is genuinely excellent. It’s a dedicated music player built by Plex, and it feels like it was designed by people who actually care about listening to music rather than optimising engagement metrics. Clean interface, proper gapless playback, and features like sonic exploration that help with discovery without feeling algorithmic.

The client availability sealed the deal. Plexamp runs on iOS, Android, macOS, Windows, and Linux. The only gap is native car integration, but Bluetooth fills that role with minimal friction. Connect, play, done.

The server side is just Plex running on my existing home server. Music files live on local storage, backed up properly, under my control. No subscription required for basic playback, though Plex Pass unlocks some Plexamp features.

What the FLAC is lossless?

One of the benefits of owning your music files is choosing the quality. My entire library is FLAC: lossless audio that preserves every detail from the original recording.

To be honest, I can’t reliably tell the difference between Spotify’s high-quality streams and lossless audio on my current setup. Most people can’t. But that’s not really the point.

Audio technology keeps improving. Better headphones, better DACs, better speakers. The music I’m collecting now might be played on equipment that doesn’t exist yet. By storing everything in lossless, I’m preserving the highest possible quality for whatever the future brings. I’d rather have more data than I need today than wish I’d kept it later.

With streaming, you get whatever quality the service decides to give you. With my own files, the choice is mine.

Where to get music

Bandcamp is the obvious choice for buying digital music directly. Artists get a better cut, you get lossless files, and there’s a strong community around it. In theory, it’s perfect.

In practice, I find the search experience frustrating. Getting to the specific artist and album I want feels slower than it should. Maybe I’m spoiled by years of Spotify’s instant search, but the friction is noticeable. For now, I’m putting up with it because the alternatives are worse, but I’m constantly searching for something better.

If you know of a good source for purchasing lossless music with a decent search experience, I’d love to hear about it.

What I’ll miss

I won’t pretend this is all upside. Spotify’s discovery features, when they worked, introduced me to artists I genuinely love. The convenience of having everything available instantly is hard to replicate. And sharing music with friends becomes more complicated when you can’t just send a link.

But those trade-offs feel worth it. I’d rather have a smaller collection of music I actually own than endless access to a library that’s increasingly polluted with content designed to game the algorithm rather than move the listener.

The transition

I won’t sugarcoat it: the friction to switch has been fairly high.

Ripping, cataloguing, and transferring content is one thing. The curated playlists from years gone by are another. Those playlists represent hours of listening, discovering, and refining. Losing them felt like losing a part of my music history.

Soundiiz came in handy here, automatically copying playlists across to Plex. It worked well for most of the heavy lifting. But invariably there’s a song on a crucial playlist that I just don’t own yet, leaving a gap. Until I fill those gaps, the migration doesn’t feel complete.

It’s a slow process. Every missing track is a reminder that I’m rebuilding something that took years to accumulate. But each album I add is mine now, permanently, and that makes the effort feel worthwhile.

Omarchy Hardening

Mon, 29 Dec 2025 11:00:00 +0000

A few weeks ago, I came across A Word on Omarchy which highlighted some security gaps in Omarchy’s default configuration. Things like LLMNR being enabled, UFW configured but not actually running, and relaxed login attempt limits.

The post resonated with me. Omarchy is a fantastic opinionated setup for Arch Linux with Hyprland, but like any distribution that prioritises convenience, some security defaults get loosened in the process. That’s not necessarily wrong, it’s a trade-off, but it’s worth knowing about.

So I built Omarchy Hardening.

What it does

It’s an interactive terminal script that walks you through five hardening options:

Disable LLMNR - Prevents name poisoning attacks on local networks
Enable UFW Firewall - For earlier Omarchy versions where UFW wasn’t enabled by default
Tailscale-only SSH - Restricts SSH to your Tailscale network, making it invisible to the public internet
Limit Login Attempts - Reduces failed attempts from 10 back to 3 before lockout
Configure Git Signing - Enables SSH commit signing for verified commits

Each option shows exactly what will change before you confirm. Nothing is selected by default.

A word of caution

The script opens with a warning, and I’ll repeat it here: you should not rely on automation to secure your system.

The best approach is to understand your distribution and make these changes yourself. Read the source code. Run the commands manually. This builds knowledge you’ll need when things go wrong.

The tool exists to demonstrate what these changes look like and to make them easier to apply consistently. But it’s not a substitute for understanding.

What’s next

If you’re curious about going further, the README includes a section on additional hardening steps. OpenSnitch is worth particular attention. It’s an application-level firewall that prompts you whenever a program tries to make a network connection. Educational and practical.

The code is on GitHub: dannymcc/omarchy-hardening

ZeroNet: The Web Without Servers

Mon, 29 Dec 2025 01:00:00 +0000

I’ve been exploring ZeroNet recently, a peer-to-peer web platform that’s been around since 2015 but still feels like a glimpse of what the internet could be. It’s not mainstream, and it’s not trying to be. But for anyone who cares about decentralisation and censorship-resistance, it’s worth understanding.

What It Is

ZeroNet is a decentralised network where websites exist without traditional servers. Instead of requesting a page from a server somewhere, your browser downloads it from other users who already have it. Think BitTorrent, but for websites. Once you’ve visited a site, you become a host for it too. The more people visit, the more resilient the site becomes.

There’s no company to take to court. No single point of failure. No domain registrar that can be pressured into pulling the plug.

How It Works

The technical bits are surprisingly elegant. ZeroNet uses Bitcoin cryptography for identity. Each site has a unique address derived from a public/private key pair. The site owner signs updates with their private key, and everyone can verify those signatures. This means content can be updated, but only by whoever holds the key. No passwords, no accounts, no centralised authentication.

Content is distributed using BitTorrent’s protocol. When you visit a ZeroNet site, you’re downloading it from peers and simultaneously seeding it to others. Sites are essentially signed archives that propagate across the network.

For privacy, ZeroNet can route traffic through Tor. It’s optional, but turning it on means your IP address isn’t visible to other peers. Combined with the fact that there’s no central server logging requests, the privacy properties are genuinely interesting.

Why I’m Interested

My interest in ZeroNet ties directly into my broader views on privacy. I’m not naive about the limitations of decentralised systems, or the fact that censorship resistance can protect content that probably shouldn’t be protected. But there’s something valuable in understanding how these networks function.

The centralised web has become remarkably fragile. A handful of companies control most of the infrastructure, and they’re increasingly subject to political and legal pressure. That’s sometimes appropriate. Nobody wants to defend genuinely harmful content. But the tools of control, once built, don’t stay confined to their intended purpose.

ZeroNet represents a different architecture entirely. It’s not about evading accountability, it’s about distributing it. Instead of trusting a company to host your content and hoping they don’t change their terms of service, you trust mathematics. The trade-offs are real: slower access, no search engines worth mentioning, and a user experience that assumes technical competence. But those are engineering problems, not fundamental limitations.

I’m not suggesting everyone should abandon the normal web for ZeroNet. That would be impractical and unnecessary. But understanding how decentralised alternatives work feels increasingly important. The architecture of the tools we use shapes what’s possible, and diversity in that architecture is probably healthy.

For now, I’m treating ZeroNet as an experiment. Something to explore and learn from rather than rely on. But in a world where digital infrastructure is more contested than ever, it’s useful to know that alternatives exist.

Thanks to ポテト for pointing me towards ZeroNet.

Value

Sun, 14 Dec 2025 10:00:00 +0000

I recently passed my advanced motorcycle test with the IAM. A F1RST, no less. The highest grade. And within hours of getting the result, I’d already started telling myself it wasn’t that impressive.

This happens every time. The thing I’ve been working toward, the qualification, the goal, the milestone, suddenly feels smaller the moment I reach it. Not worthless, exactly. Just… less. As though the act of achieving it somehow deflated the whole thing.

I don’t think I’m alone in this. There’s a term for it: the arrival fallacy. The idea that we assume reaching a destination will bring lasting satisfaction, only to find that satisfaction evaporates almost the moment we arrive. We spend months, sometimes years, chasing something, convinced it matters. And then we get there, look around, and think: is that it?

Some of it is just recalibration. What felt like a stretch yesterday becomes the new baseline today. But I think there’s something else going on too, at least for me. Once I’ve done something, I can see exactly how I did it. Every small step, every moment of doubt, every bit of luck. The mystery disappears. And without the mystery, it stops feeling like an achievement. It starts feeling inevitable, even though it wasn’t.

The IAM test is a good example. It has a real failure rate. You can’t charm your way through it or stumble into a F1RST by accident. An examiner who doesn’t know you, doesn’t care about your backstory, watches you ride for over an hour and makes a judgement. It’s external. Objective. Difficult. And yet, within a day, my brain had already filed it under things that were always going to happen.

I suspect this is a feature, not a bug. If we stayed satisfied, we’d stop striving. The restlessness that makes achievements feel hollow is probably the same restlessness that pushed us toward them in the first place. But knowing that doesn’t make it less frustrating. It just makes it feel like a trap, one we set for ourselves, over and over again.

So what’s the answer? I’m not sure there is one. Maybe the goal isn’t to feel permanently satisfied, but to get better at pausing. At noticing. At letting the moment land before the next one arrives. Maybe value isn’t something we feel. It’s something we decide to assign, consciously, before our brains have a chance to reclassify it as ordinary.

I passed my advanced test. I got a F1RST. That matters. Even if I have to keep reminding myself.

The Endless Hunt for Productivity Nirvana

Thu, 12 Jun 2025 08:01:00 +0100

I’ve been chasing the perfect productivity setup for longer than I care to admit. The signs are all there: a Downloads folder cluttered with productivity apps, browser bookmarks organised by system acronyms, and that familiar feeling of starting fresh with yet another note-taking tool, convinced that this time will be different.

My digital graveyard is extensive. NotePlan, Microsoft OneNote, Apple Notes, Google Keep, Notion, Airtable, Logseq, Google Docs, Obsidian, Simple Notes — I’ve installed them all, configured them meticulously, and abandoned them with the same predictable rhythm. But it doesn’t stop there. I’ve ventured into the analogue world too: expensive Field Notes that made me feel like a proper writer, simple yellow legal pads that promised no-nonsense functionality, and even those futuristic smart pens with tiny cameras that record your scribbles for digital playback.

Then there’s the hardware rabbit hole. iPads of every generation, each promising to bridge the gap between digital and analogue. The reMarkable, which felt revolutionary until it became another expensive paperweight. Every purchase accompanied by the same ritual: diving deep into YouTube tutorials, hunting for the “perfect” workflow that would finally unlock productivity nirvana.

If you’ve been down this path, you’ll recognise the cast of characters. Tiago Forte with his PARA system (Projects, Areas, Resources, Archive). Cal Newport advocating for CCCC (Craft, Constitution, Community, Contemplation). Matt Perman’s PFFSP framework (Personal, Family, Faith, Social, Professional). Each guru promising their system is the system, backed by years of refinement and countless success stories.

I’ve tried them all. Every acronym, every methodology, every perfectly structured folder hierarchy. And here’s what I’ve realised — not in a lightbulb moment, but in a proper “what the hell have I been doing” revelation: I’ve been building the cart before I’ve even found the horse.

The Setup Trap

Time and again, I’d discover a new system and immediately set about constructing the perfect framework. Folders meticulously organised, tags carefully planned, templates crafted with surgical precision. I’d spend hours, sometimes days, building this beautiful, empty structure. Then I’d sit down to actually use it and find myself paralysed by my own over-engineering.

Where does this thought go? Which folder? What tags? Does this count as a project or an area? Should I create a new template for this type of note? The system I’d built to enhance my thinking had become a barrier to it.

What Actually Works

Right now, I’m using Obsidian. But this time, I swear it’s different. I’ve resisted the urge to turn it into a productivity monument. No elaborate folder structures based on someone else’s methodology. No collection of 100 plugins to make it look “professional.” Just a simple folder called Notes, with basic subfolders that make intuitive sense to me. If I had to guess which folder contains a specific note based purely on its title, I’d probably be right. That’s my only organisational principle.

I’ve allowed myself exactly three plugins beyond Obsidian’s defaults: Mononote, which keeps things tidy by limiting one tab per note; Rollover Daily Todos, which simply moves unfinished tasks to tomorrow’s daily note; and a custom Granola Sync plugin I developed to import AI-generated meeting notes. That’s it. No baroque plugin ecosystem, no elaborate theming, no productivity theatre.

But here’s what I’ve learned: I still need paper. Not for the romantic notion of analogue permanence, but for something more fundamental. There’s a cognitive switch that flips when I put pen to paper while working through a problem. It doesn’t matter if I bin the paper afterwards or never reference it again. The act of writing — the physical motion, the slight resistance of ink on paper — commits not just the words to memory, but the entire context. The conversation, the feeling, the broader picture.

I can’t explain the neurology behind this, and I don’t know if it’s universal or just my peculiar wiring. But it works. Sam Altman, CEO of OpenAI, has spoken about how a simple notepad remains his go-to tool despite having access to the world’s most advanced AI. If that’s not a endorsement for keeping things simple, I don’t know what is.

The Real Problem

The productivity industrial complex wants us to believe that the right system will transform us into efficiency machines. That the perfect app, properly configured, will unlock some higher version of ourselves. But after years of chasing this dragon, I’ve come to suspect that the problem was never the tools.

The problem is that we’re treating systems as solutions rather than supports. We’re looking for external structures to impose order on internal chaos, when what we really need is to develop better thinking habits. No folder structure, however elegant, can compensate for unclear thinking. No tagging system can organise thoughts that haven’t been properly formed.

The Reddit Personal Knowledge Management System community is full of people sharing elaborate setups, complex workflows, and sophisticated integrations. It’s fascinating to browse, but also revealing. Much of the discussion centres around the systems themselves rather than the knowledge they’re meant to manage. We’ve become obsessed with the scaffolding while forgetting about the building.

Starting Simple

My current approach is almost boring in its simplicity. I write notes when I have something worth recording. I put them in folders that feel natural. I don’t worry about perfect categorisation or comprehensive tagging. If I need to find something later, Obsidian’s search is good enough. If I can’t find it, perhaps it wasn’t worth keeping anyway.

This isn’t a manifesto for digital minimalism or a rejection of productivity tools. It’s more like a truce. I’ve stopped looking for the perfect system because I’ve realised it doesn’t exist. Instead, I’m focusing on developing better habits: writing regularly, thinking clearly, and actually finishing things rather than just organising them.

The chase for productivity perfection is seductive because it feels like progress. Researching new systems, watching tutorial videos, setting up elaborate workflows — it all feels productive. But it’s productivity about productivity, not actual work. It’s digital procrastination dressed up as self-improvement.

Maybe the perfect productivity setup is the one you stop tweaking. The one that gets out of your way and lets you focus on what actually matters: having thoughts worth capturing and doing work worth sharing. Everything else is just infrastructure — necessary, but not noteworthy.

The real productivity hack might be admitting that no system can save us from ourselves. But a simple one might just get out of the way long enough for us to get something done.

2025 Privacy Reboot: Six Month Check-In

Tue, 10 Jun 2025 14:30:00 +0100

Six months ago, I wrote about my privacy reboot — a gradual shift toward tools that take both privacy and security seriously. It was never about perfection or digital purity, but about intentionality. About understanding which tools serve me, rather than the other way around.

Here’s how it’s actually gone.

The Wins

Ente continues to impress. The family photo migration is complete, and the service has been rock solid. The facial recognition quirks I mentioned on Android have largely sorted themselves out, and the peace of mind knowing our family memories aren’t feeding Google’s advertising machine feels worth the subscription cost.

Signal has been the biggest success story. I’m now at about 95% Signal for personal messaging — a number I genuinely didn’t think was achievable. The automated WhatsApp replies did their quiet work, and most people made the jump without much fuss. There’s still a handful of contacts who simply can’t or won’t switch, but that’s reality, not failure.

Migadu has the entire family migrated and running smoothly. Moving away from Gmail’s tentacles felt daunting, but the transition was surprisingly painless thanks to imapsync. We own our email again, which feels both quaint and radical in 2025.

Mullvad VPN remains my travel companion, now with multi-hop enabled for that extra layer of paranoia that may or may not be justified. The fact that I can pay for it anonymously still feels like digital rebellion.

The Pragmatic Compromises

DuckDuckGo Browser works brilliantly for personal use, but I’ve had to switch back to Chrome for work. The reality is that some enterprise extensions simply don’t exist in DuckDuckGo’s ecosystem, and I’m not going to handicap my productivity to make a privacy point that only I care about. Work browser for work things, private browser for everything else.

Standard Notes didn’t stick. Despite liking the interface and the privacy-first approach, I found myself gravitating back to Obsidian. The tipping point was building a Granola-to-Obsidian plugin that automatically imports my work meeting notes. When your knowledge management system updates itself, convenience wins — even in a privacy-focused setup.

The Learning Curve

Bitwarden for 2FA has been excellent, and I’ve now gone full circle by self-hosting my own Vaultwarden instance. Access is limited to my Tailscale network for that belt-and-braces security approach. There’s something satisfying about controlling your own authentication infrastructure, even if it requires more weekend tinkering than most people would tolerate.

The email situation has one minor wrinkle: I’ve noticed periodic latency spikes with Migadu’s SMTP servers. Nothing broken, just the occasional sluggish send. It’s the kind of small friction that reminds you why Gmail’s infrastructure is so seductive. But it’s manageable, and the trade-off still feels worth it.

Perhaps the most interesting observation has been about human behaviour. Some contacts would rather message me on Instagram than install Signal — a perfect illustration of how convenience trumps privacy in most people’s mental calculus. This isn’t a judgment; it’s just the reality of how digital habits form and persist.

The success of the automated WhatsApp responses proved something important: people will adapt to your digital boundaries if you make the friction low enough. Most friends didn’t mind installing Signal once the path was clear and frictionless.

What I’ve Learned

Six months in, this privacy reboot feels less like a radical departure and more like a gentle course correction. The tools I use now are more intentional, more aligned with my values, but they’re not perfect. They’re just better.

The biggest insight? Privacy-focused doesn’t have to mean productivity-hostile. Most of these changes improved my digital life in ways that had nothing to do with privacy — better focus, fewer distractions, more control over my own data. The privacy benefits were almost a bonus.

It’s also clarified where I’m willing to compromise. Work tools live in a different ecosystem than personal ones, and that’s fine. Perfect is the enemy of good, and good is far better than surveillance-as-default.

This might all look different in another six months. Maybe I’ll discover new tools, encounter new constraints, or decide that some trade-offs aren’t worth it. But right now, this feels sustainable. It feels intentional. And in a world where digital convenience often comes with hidden costs, that intentionality might be the most important thing of all.

The question isn’t whether you can achieve perfect privacy — you can’t, and probably shouldn’t try. The question is whether you can build a digital life that serves your values while still functioning in the world as it actually exists. Six months in, I think the answer is yes.

Focus

Thu, 08 May 2025 14:06:00 +0100

We’ve all seen them: those productivity YouTubers with perfectly lit home offices explaining how they maintain “deep work” for 12+ hours a day. They sit there, looking impossibly serene, selling us a vision of superhuman concentration that I’ve come to believe is complete nonsense.

I used to buy into this. I’d feel like a failure when my brain checked out after three solid hours of work. I’d push myself to match these claimed productivity marathons, only to end up exhausted and wondering what was wrong with me.

Here’s what I’ve figured out through trial and error: our brains just don’t work that way. At least mine doesn’t. I’ve found I can do maybe 4-5 hours of genuine deep focus daily, broken into chunks. Beyond that, I’m still mentally effective, but in different ways – more suited to collaboration, communication, and less intensive tasks rather than deep work.

This insight has changed how I structure my day. Those morning hours of deep focus are sacred – they’re when I tackle the most complex problems. This aligns with what Jeff Bezos famously calls his “high IQ meeting” approach. Bezos schedules his most mentally demanding meetings at 10 a.m., noting that by late afternoon, he’s simply not at his cognitive best for challenging problems. As he puts it, “By 5 p.m., I’m like, ‘I can’t think about that today. Let’s try this again tomorrow at 10 a.m.'”

Those few hours of real focus, when used well, are worth far more than double the time spent in a semi-distracted state. I’ve noticed this in my teammates too – the most valuable contributors aren’t the ones logging 12-hour days. They’re the ones who bring their full attention to the right problems for shorter, more intense periods.

The Hardware Trap

I’ve fallen for every productivity hardware upgrade imaginable. Ultrawide curved monitors. Triple-screen setups. Higher resolutions to fit more windows. Each promising to transform me into some multitasking wizard.

What I actually bought wasn’t productivity – it was distraction disguised as efficiency. Each extra screen became another venue for notifications, another space to fill with Slack, email, and other attention-fracturing tools.

In 2025, I’ve gone the opposite direction: smaller. My main work setup now has just enough screen space for one or two applications. Not because I can’t afford bigger – but because the constraint forces me to choose what deserves my attention right now.

This limitation has oddly become my best focus tool. When I can only comfortably see one document or conversation at a time, I’m present with it. The hardware limitation became a feature, not a bug.

The AI Partnership

The other half of my focus shift has been outsourcing the busywork. Where I once tried to juggle multiple applications, I now delegate aggressively to AI tools that handle the administrative stuff that used to scatter my attention.

My email gets filtered before I see it. Meeting notes get summarised. Research gets compiled. First drafts get generated. This isn’t about replacing thinking – it’s about eliminating the low-value tasks that constantly pulled me out of flow.

The result? When I focus, I actually focus. I’m not half-writing an email while half-listening to a call. I’m fully engaged with the complex work that needs my human judgment.

This approach – smaller screens plus AI delegation – has completely changed what focus means for me. It’s no longer about willpower or duration. It’s about creating conditions where concentration happens naturally.

I’m not perfect at this. I still get pulled into the multitasking trap. And let’s be honest – many company metrics still force us into equating hours with productivity. These legacy measurements are changing rapidly, but they still influence how we work and how we’re evaluated.

Despite this, I’m convinced that genuine focus isn’t an endurance sport. It’s not about who can stare at code the longest without blinking.

It’s about creating space – physical, digital, and mental – where your best thinking can happen. And sometimes that means working less, but working better. Ultimately, it’s about recognising what truly deserves our attention and what can safely be ignored.

The Privacy Paradox

There’s an irony to my current digital life that I’ve been thinking about lately. In my last post about privacy, I wrote about my journey to reclaim control over my data – moving away from surveillance-as-a-service platforms to more secure, private alternatives.

Yet here I am, advocating for deeper integration with AI tools that, by their very nature, require access to virtually everything I think and do. I’m simultaneously pulling back from data-hungry ecosystems while whispering my every thought to at least one AI throughout my day.

It’s a strange contradiction. On one hand, I’m meticulously auditing which services can access my photos, notes, and location. On the other, I’m willingly feeding my draft emails, meeting notes, and half-formed ideas into systems far more pervasive than anything that came before.

Perhaps this tension – between protecting our digital boundaries while embracing tools that blur them – is the defining challenge of 2025. We’re figuring out which information belongs where, which systems deserve our trust, and where to draw the lines.

Trust

Sun, 04 May 2025 19:24:00 +0100

We like to believe we’re in control. That privacy is something we can protect if we just check the right boxes, read the fine print, toggle the right settings. But that belief is crumbling. In 2025, privacy isn’t something we manage — it’s something we quietly surrender, one tap, click, and scroll at a time.

Lately, I’ve been thinking about how much I rely on Google. Not in an abstract way, but in a daily, tangible, everything-I-do-is-somehow-Google-enabled kind of way. Google Photos, for instance, is frictionless. It uploads every picture, recognises every face, remembers the places I’ve been, and lets me search through a decade of memories in milliseconds. It’s borderline magical. But magic, in the digital world, usually means surveillance. It means giving up control. It means letting a machine learn the people in your life, the patterns of your past, the corners of your history — all in exchange for convenience.

This isn’t just about Google, though. It’s not even about Big Tech specifically. It’s about the fundamental reality that the modern internet has made privacy optional — and expensive. If you want discounted groceries, you need a loyalty card. If you want smart recommendations, you have to share your behaviour. If you want to board a plane, get a mortgage, download an app, or buy anything online, you’re handing over data whether you like it or not. And if you say no? That’s fine — but you’ll be paying in time, money, or friction.

Privacy Poverty

This phenomenon has a name: privacy poverty. The idea that privacy is no longer a right, but a luxury. That those with disposable income can buy out of tracking — pay for encrypted services, private browsers, premium accounts — while everyone else gets a discount in exchange for giving up their digital lives. And that gap is growing. Privacy, like healthcare or education, is becoming another line item on the inequality ledger.

Even those of us who consider ourselves privacy-conscious eventually give in. I’ve been off Facebook for years. I block trackers. I read privacy policies (well, some of them). But my phone still knows everything I do. My bank app still notifies me of every transaction. My travel data still flows through biometric gates. My online purchases still generate behavioural profiles. Surveillance is so deeply embedded in our infrastructure that avoiding it requires opting out of society altogether.

The AI Amplifier

And then there’s AI. AI doesn’t just amplify the problem — it warps it. This new generation of systems doesn’t just store or index your data, it interprets it. It sees patterns, infers emotions, anticipates behaviour. It turns data into insight, insight into prediction, prediction into influence. The more we feed it, the smarter it gets — and the harder it becomes to remember where convenience ends and control begins. AI accelerates everything: our productivity, our communication, our decision-making — and yes, our exposure.

What worries me isn’t that people are willingly trading privacy for convenience. It’s that, more and more, there is no real trade to make. The so-called “threshold” between trust and convenience isn’t a line we cross — it’s a condition we live in. Privacy isn’t lost in a single moment. It’s eroded through a thousand little gestures, most of which don’t feel like choices at all.

What Now?

So what now? Can we reclaim privacy in an ecosystem that treats it as a premium feature? Can regulation catch up fast enough to offer meaningful protection? Or have we already accepted a future in which data collection is the price of participation? These aren’t rhetorical questions. They’re the stakes of the world we’re building — and living in.

We often say privacy is a basic right. But we rarely act like it. In practice, it’s more like a silent agreement: give us everything, and we’ll make life easier. Reject that deal, and you’re on your own. The truth is, convenience won. Quietly, efficiently, and thoroughly. And if we don’t start rethinking the terms, we won’t be asking where the line is — we’ll be asking if there was ever one at all. For my own attempt at rethinking these terms in practice, I’ve been gradually shifting towards tools that respect both privacy and usability.

Balance

Fri, 02 May 2025 08:54:00 +0100

Tucked away in a parenting book I read nearly two decades ago — title and author long lost to time — was a metaphor that lodged itself in my brain and never left.

“Life is a balance, or rather, a juggle of balls. Some are glass. Some are plastic."

The idea is simple but enduring: drop a plastic ball, and it bounces. Drop a glass one, and it shatters. The trick — the real tightrope act — is knowing which is which.

Here’s where it gets interesting. The author warned against falling into the trap of assuming that all the “family” balls are fragile crystal and all the “career” balls are rubber. Sometimes, the opposite is true. A moment missed with your kids might be one that easily bounces back. But a career opportunity? It might not.

Other times, of course, it flips. That bedtime story or awkward teenage conversation might be the glass ball you didn’t realise you were holding. Meanwhile, some of those high-stakes work pressures turn out to be surprisingly… elastic. This same principle applies to how we choose to spend our mental energy throughout each day.

It’s a perspective that’s stayed with me — not because it offers perfect clarity, but because it grants permission. Permission to drop a few balls. Permission to be wrong about which ones matter most. And above all, permission to course-correct when you’ve mistakenly let a glass one slip through your fingers.

I’ve dropped a few glass balls over the years. I’d be lying if I said otherwise. But I’ve also learned to recognise the ones that bounce. That small wisdom has made all the difference.

100 Days of Writing

Wed, 30 Apr 2025 19:12:00 +0100

Is there some magic in writing every day for 100 days? Maybe. Maybe not.

But that’s not quite the right question. A better one might be: What would I hope to get out of writing every day for 100 days?

For starters, I’d get better at clarity — saying what I mean without losing the thread halfway through. I’d build speed: less dithering, more straight-from-brain-to-fingers. And maybe, just maybe, I’d find a rhythm. Writing not as a task, but as a mindfulness habit. A check-in. A creative exhale. Much like developing better focus in other areas, it’s about creating intentional space for what matters.

It’s hard to see the downside. There are no rules here, no format police. Some days it might be a deep-dive into something technical. Others, a meandering thought about life, or a single paragraph admitting I’m not really feeling it today. It all counts.

So here’s Day One. I’ll read this again in 100 days and see just how wide-eyed I was starting out.

Let’s find out. 👋

2025: My Privacy Reboot

Wed, 30 Apr 2025 08:01:00 +0100

Six Month Update

Curious how this privacy reboot actually worked out? I wrote a detailed follow-up after six months of living with these changes — covering what worked, what didn't, and the pragmatic compromises along the way.

Read the Six Month Check-In →

The line between privacy and security isn’t always clear — and in tech, it’s often treated like they’re the same thing. But they’re not. Even the broader question of when to trust digital services with our data has become increasingly complex.

Security is about control — making sure only authorised people (read: me) can access my data. Privacy is different. It’s about intent. It dictates how that data gets used, and whether the companies that hold it stick to the promises they made.

Over the past few months, I’ve been re-evaluating the tools I use daily, nudging my setup toward services that take both privacy and security seriously. This isn’t a call to ditch Big Tech or a manifesto for full decentralisation. It’s more like a timestamp — a snapshot of the tools I trust right now, and a few notes on why.

DuckDuckGo Browser

My default browser — but with all the built-in VPN and AI features turned off. I’m mostly using it for its cookie blocking, which, if I’m honest, is less about privacy and more about not wanting to tap “accept all cookies” for the thousandth time.

Standard Notes

My go-to for note-taking — and, more recently, blogging. I’ve started using the Listed.to publishing platform they offer, which simplifies getting thoughts online. I’m not completely sold on it yet, but there’s something refreshing about hitting “publish” without fiddling with formatting or plugins.

Ente for Photo Storage

I’ve started trialling Ente as an encrypted alternative to Google Photos, signing up for the 200GB family plan to test it with my wife. So far, it’s been impressive. The desktop importer handled 13,000+ images from Google Takeout without breaking a sweat — just drop in the .zip files and let it churn.

One quirk: machine learning features like facial recognition seem better tuned for iOS than Android (I’m on a Pixel 9 Pro). I’ve noticed the occasional metadata hiccup, but I’m holding off judgement until the full import is done.

Signal as a WhatsApp Alternative

I’ve shifted all personal messaging to Signal, and put WhatsApp on digital life support. To ease the transition, I’ve set up an automated reply using Whatauto for Android. It runs silently in the background, while I keep read receipts off and notifications disabled. Most of my regular contacts have now made the jump to Signal — a direct result of the automation doing its quiet work.

Here’s the message they get:

Auto Reply
Hi, thanks for your message. I'm no longer actively checking WhatsApp as I've moved to Signal for messaging.
https://signal.org/install

Migadu + Thunderbird for Email

I’ve moved my family’s email accounts from Gmail (and briefly Fastmail) to Migadu, using Thunderbird across macOS and Android. It’s been rock solid. Migration was painless thanks to imapsync, which — as always — just works.

Mullvad VPN

I don’t use Mullvad every day, but it’s my default when travelling. Either directly on-device or routed through my Beryl travel router. I like its multi-hop and anti-AI-analysis features, and the fact it doesn’t require an email address to sign up still feels radical.

Bitwarden for 2FA

I recently replaced Authy with Bitwarden for managing two-factor authentication. The breaking point was Authy’s decision to shut down API access — which killed off my favourite use case: pulling codes directly into Raycast for lightning-fast logins. Bitwarden doesn’t offer quite the same UX flow, but it’s transparent, trusted, and functional.

These changes aren’t about perfection. They’re about intentionality — understanding the tools I rely on and making sure they serve me, not the other way around. This mindset extends beyond privacy tools into how I approach focus and productivity as well.

This might all look different in six months. Maybe I’ll shift back. Maybe I’ll dig deeper. But right now, this is the version of digital minimalism that makes the most sense for how I live and work. It’s all about recognising what deserves attention and what doesn’t.

Six Month Update

Read the Six Month Check-In →

Replacing Google Photos with Immich

Sat, 06 Apr 2024 21:13:34 +0100

I have, for a long time, been looking for a better alternative to Google Photos. Although Google Photos does exactly what I want, and isn’t that expensive, I do often consider the fact that all of my photos are in Google’s hands. I did move to Synology Photos a few years ago. The move itself was straight forward enough, but the user experience leaves quite a lot to be desired.

Anyone who has spent more than 5 minutes on any of Reddit’s self hosting and open source subreddits will have heard of Immich before. It’s open source, somehow done entirely by a sole developer, and has an impressive iOS app that matches Google Photos in feature set.

So, the first step was to take Immich for a spin and see how it performs. I followed the Immich docker compose documentation steps and it was basically effortless.

Google Takeout

Of course, Immich is only useful if it has my photos in it. Those photos are in Google’s hands at the moment. Thankfully, Google provide a very easy way to download all of my photos using Google Takeout.

Once I got the Google Takeout email from Google and downloaded them all, I used the GooglePhotosTakeoutHelper library to get the metadata from the Google JSON file and merge them into the image files themselves.

I then simply took the ALL_PHOTOS directory and uploaded everything via the Immich frontend. There are plenty of options available for the upload step, but I was happy with the simplest method of using the frontend uploader.

Performance

Immich doesn’t need much in the way of resources to run the day-to-day operations of the photo library. Where I started to hit performance issues was during the initial import. Immich has a number of ‘jobs’ that are undertaken when it detects new images. One of these jobs is the ‘detect faces’ job. This does exactly what you think it does. It uses the machine learning docker container to check if the image has any faces in it, and if so, marks them as faces and passes the information to the Immich microservice container which then attempts to identify who’s face has been identified.

As with most machine learning processes, this one is resource intensive.

Impressively, and equally helpfully, Immich has the ability to offload this machine learning process to another hardware stack. In my case, it’s simply my Macbook Pro (M2).

To get this working, I used the following docker-compose.yml file on my Macbook:

#
# WARNING: Make sure to use the docker-compose.yml of the current release:
#
# https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
#
# The compose file on main may not be compatible with the latest release.
#
name: immich
services:
immich-machine-learning:
container_name: immich_machine_learning
# For hardware acceleration, add one of -[armnn, cuda, openvino] to the image tag.
# Example tag: ${IMMICH_VERSION:-release}-cuda
image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
extends: # uncomment this section for hardware acceleration - see https://immich.app/docs/features/ml-hardware-acceleration
file: hwaccel.ml.yml
service: cpu # set to one of [armnn, cuda, openvino, openvino-wsl] for accelerated inference - use the `-wsl` version for WSL2 where applicable
volumes:
- model-cache:/cache
env_file:
- .env
restart: always
ports:
- "3003:3003"
volumes:
model-cache:

Then, after a simple docker compose up -d I then had the machine learning container running on my laptop. All I had to do then, was change the Immich setting to use the remote container.

The effect was immediate. My laptop was able to run through 5,000 images in around 30 minutes. For comparison it took around 10 minutes per image on the original virtual machine (running in Proxmox).

Summary

So far I’m pretty impressed with Immich. Let’s see how long I stick with it!

2024 macOS Dotfiles

Wed, 27 Dec 2023 14:57:42 +0000

It is the time of year again where I decide to update my local computer configuration, as well as any remote linux server(s) that I am maintaining. I really appreciate having a familiar prompt and alias setup whenever I login to any of my servers/workstations.

As per usual, I cannot remember which specific packages and plugins I use; so I’ve am using this post for future me to discover how I actually configured my environments.

oh-my-zsh

ZSH is a must for me now, after using it for many years now. This is a simple process which can be read at https://ohmyz.sh/ but for reference, the following command will install oh-my-zsh:

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

There are a few changes I then made to the .zshrc file, which I’ve listed below. You will recieve errors when using these changes until you complete the remaining steps listed below.

Add or update the following lines of .zshrc:

ZSH_THEME="powerlevel10k/powerlevel10k"

plugins=(git tmux)

# Zplug Section
source ~/.zplug/init.zsh
zplug "zsh-users/zsh-autosuggestions" # Auto suggest command completions as you type
zplug "zsh-users/zsh-syntax-highlighting", from:github # Command syntax highlighting
zplug "RobertAudi/tsm" # tmux session manager. Handy short hand for tmux session management
zplug "bobsoppe/zsh-ssh-agent", use:ssh-agent.zsh, from:github # Setup the ssh agent
if ! zplug check; then
zplug install
fi
zplug load

oh-my-tmux

Another ready to go package is oh-my-tmux. Again, this is plug and play from https://github.com/gpakosz/.tmux

$ cd
$ git clone https://github.com/gpakosz/.tmux.git
$ ln -s -f .tmux/.tmux.conf
$ cp .tmux/.tmux.conf.local .

Powerlevel10k

Next up is Powerlevel10k which allows very easy prompt adjustments and customisation from https://github.com/romkatv/powerlevel10k/tree/master

git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

I have found it very helpful to include context to the prompt for remote servers and include the OS icon. Both of these are described well on the Powerlevel10k wiki (https://github.com/romkatv/powerlevel10k/blob/master/README.md#how-do-i-add-username-andor-hostname-to-prompt).

ZPlug

Finally we have zplug which allows ZSH plugin management easily from https://github.com/zplug/zplug. This, combined with the above .zshrc adjustments, makes for a great prompt experience.

curl -sL --proto-redir -all,https https://raw.githubusercontent.com/zplug/installer/master/installer.zsh | zsh

Figurine (optional)

When switching between servers reguarly, I have recently been finding it very useful to see the name of the server in large type as soon as I login. To assist with this I am using figurine: https://github.com/arsham/figurine

I install figurine and then just add the following to the top of my .zshrc file.

echo ""
figurine -f "3d.flf" Server Name
echo ""

Running Powershell Script an Elevated User

Sun, 29 Jan 2023 22:29:22 +0000

When running a powershell script, I often find I need to run the script in an elevated prompt. The nature of my job is that often these scripts will be run by people that don’t really know what Powershell is.

I have found it quite useful to first create a bash script that the user executes, which in turn calls the actual Powershell script as an elevated user.

To keep this handy, I’m posting it here for future me.

Powershell.exe -Command "& {Start-Process Powershell.exe -ArgumentList '-ExecutionPolicy Bypass -File %~dp0actualpowershellscript.ps1' -Verb RunAs}"

I then save the bash script as something obvious such as run-me-first.bat.

Simple, but it seems to work well!

Extending Unraid VM Storage

Sun, 29 Jan 2023 22:09:40 +0000

More and more I find myself quickly spinning up a new Windows VM on my unraid server. It is always a ‘temporary’ VM which, after setting up exactly how I like, I invariably then wish I’d set a much larger virtual disk size. The standard VM disk size is 30G and that always seems to be enough.

Fast forward an hour or two and I really wish I had set something more realistic. The problem is, the vdisk is too small, and Windows configures the partitions in such a way that I can’t simply extend the partition (due to the recovery partition being the last partition in the sequence).

As a reminder for my future self, this is actually quite simple to resolve.

First, login to the unraid via SSH and issue the following command to add 50 GB to the vdisk:

qemu-img resize /mnt/user/domains/Temporary-VM-Name/vdisk1.img +50G

This will magically add an additional 50 GB of capacity to the VM.

After restarting the VM via the unraid GUI, the second (and final!) step of the process is to expand the partition to use the newly added unallocated space.

Usually, this could be done via the Disk Management console in Windows, however, as mentioned, this isn’t possible with the standard partition layout.

Thankfully a free tool called ‘MiniTool Partition Wizard` that makes this final step a breeze. Simply open the application, right click on the C drive and click expand. Use the slider to set the full capacity of the unallocated space and then click Apply. It’s as simple as that!

Tmux exit current session, not Tmux itself

Tue, 11 Aug 2020 11:45:49 +0200

When accessing remote servers that I am responsible for, I always initiate a tmux session along with the SSH session. This means I am always in a tmux session and I will never forget to start a tmux session manually. There is something particurly frustrating about starting a process on a remote server only to realise that you I forgot to start a tmux session and the process is going to take > 1 hour. I have to ensure my SSH session remains open, which isn’t always easy if I’m moving around.

I did write a short post recently on how to achieve a tmux session with every SSH session but the next problem is when it comes to exit the SSH session when I’m done - I don’t want it to actually close the tmux session, I want it to close the SSH session but leave the tmux session intact and running.

The solution is incredibly simple.

exit() {
if [[ -z $TMUX ]]; then
builtin exit
else
tmux detach
fi
}

The above function should be added to your .bashrc file (or .zsh) and then you need to run source ~/.bashrc for it to take effect. Remember that this function needs to be on the remote server, not your local workstation.

Now when we are inside a tmux session and we type exit the SSH session will close but the tmux session will remain ready for us to reconnect later on.

Hetzner Installimage & Ubuntu

Mon, 10 Aug 2020 18:32:11 +0200

I finally had chance to get a dedicated server at Hetzner for my own projects and use. No client requirements, no deadlines and no specification requirements. Seems like a simple thing but just about every ‘proper’ server I have ever worked on has been for a client or work project. Now that I had access to my own server, it was time to configure it exactly how I wanted.

As usual, I decided to use Ubuntu - I’m familiar with it and I really don’t mind the bloat that could be avoided with the likes of CentOS or Arch. Seeing as the server is only for me, I figured I could do what I wanted.

The first step on any Hetzner bare metal server is to install the OS. To do this I enabled the Installimage function on the server and rebooted. As the server I have has three hard drives (more on this later) I needed to ensure they were configured in the way I wanted. There are three hard drives but two of them are slower/larger. I wanted to make sure I used the smaller, faster SSD as the boot drive. Hetners Installimage system makes this fairly easy - you just edit a text config file.

The example given by Hetzner is the following (this is just the first four lines of a significantly larger config file):

# SSDSC2BB480G4
#DRIVE1 /dev/sda
# SSDSC2BB480G4
DRIVE1 /dev/sdb

In reality, I have another drive and two of them are HDD not SSD. My config looked like this:

# SSDSC2BB480G4
DRIVE1 /dev/sda
# HDDSC220000G4
#DRIVE2 /dev/sdb
# HDDSC220000G4
#DRIVE3 /dev/sdc

The important thing to note is that I have commented out all drives apart from the smaller SSD drive. This way, when Ubuntu is installed, it will only detect one drive and use this as the boot drive. I can then add the other two drives later on.

The final things to change in this configuration file are the SWRAID option and the hostname. The software RAID option needs to be disabled (just comment out the line) and the hostname can be anything you wish.

Then we close the editor (just press F10) and it will start to process the configuration file and check for errors.

Reboot and the process is complete!

Now, we have Ubuntu installed and the server is up and running with the SSD drive as the boot drive.

The very first thing to do on the new server is to configure the additional hard drives. To do this, we first need to know which device name each drive has.

# ls /dev/sd/*
/dev/sda /dev/sda1 /dev/sda2 /dev/sdb /dev/sdc

We can see from the exerpt above that we have /dev/sda which has two partitions (sda1 and sda2) and we have two additional drives with no partitions (sdb and sdc).

In my server both of these additional drives are the same size and type, so it doesn’t matter to me which one I add first.

The next step, now that we know the device names, is to format the drive(s).

# fdisk /dev/sdb
...
Command (m for help):

We need to confirm there are no existing partitions on the server usually, but I know this is a new drive (new to me at least) and I don’t care if anything on the drive is lost, which it will be!

Command (m for help): p

We see an output of the partition table for this drive, but again, we don’t care. So, onwards to creating the new partition the size of the full disk:

Command (m for help): n
Select (default p): p
Partition number (1-4, default 1): 1
...

You will next be prompted to enter the ‘first sector’ and the ‘last sector’, again, as this is a new drive we can accept the defaults.

Finally, we use the w command to write the changes to the disk. We then repeat the steps on the second drive (`/dev/sdc).

Ok, no we need to create the file system on the newly created partition(s).

xfsprogs is the go-to tool for this for me, it’s so simple it’s practically impossible to mess it up - which is perfect for a personal server I don’t want to spend my spare time fixing.

# mkfs.xfs /dev/sdb1

That’s it - we’ve just created an XFS filesystem on the newly partitioned drive. Repeat the same step for the other drive(s).

So, let’s recap. We’ve installed Ubuntu, we’ve got the SSD drive as the boot partition and now we have two additional drives partitioned and formatted as XFS filesystems. So, next we need to actually mount the additional drives to the OS.

# mkdir /drives
# mkdir /drives/drive1
# mount /dev/sdb1 /drives/drive1

As you can see from above, I mounted my drive(s) to /drives/drive1 and then /drives/drive2 for the other drive. This makes sense for me, you can choose whatever directory you wish for yours.

The drives are mounted, which we can confirm with the mount command mount but this is only for the current session. As soon as the server is rebooted these mounts will drop off. So, we need to make this permenant.

sudo nano /etc/fstab

Then we need to add the following two lines:

/dev/sdb1 /drives/drive1 xfs defaults 0 0
/dev/sdc1 /drives/drive2 xfs defaults 0 0

Now the drives will be mounted at boot so they’ll always be available.

Final Note: If you add any more than two additional drives (so the total number of drives exceeds 3) then you will have issues using device names for the mount process. You should use the drive UUID instead. When using the UUID you can be certain that the mounts will always work and the drives won’t get a different mount name each time you boot.

Tmux 3.0a Configuration Not Loading

Mon, 10 Aug 2020 18:23:31 +0200

The latest version of Ubuntu has recently been released (20.04 LTS) and along with it comes the latest version of tmux.

Tmux is now at release 3.0a and this version is pre-installed with Ubuntu 20.04 LTS. The problem is, when you want to import a tmux configuration file from tmux 2.9 or below, you get many errors.

The fix for me was simple…

tmux kill-server

Once I killed all old sessions and stopped the tmux server the new tmux version loaded the existing configuration file without any issue or errors.

Seems simple but it took me a few minutes to work it out.

Booting Raspberry Pi 4 From USB

Wed, 13 May 2020 15:47:26 +0100

I recently purchased another Raspberry Pi 4 but this time I wanted to use Ubuntu 20.04 and I wanted to use a USB 3 1TB external hard drive as the boot disk. The reason for using a large boot disk is mainly to avoid SD card corruptions in future as all read/writes (once booted) will be on the external USB drive not on the SD card.

The first step is install Ubuntu 20.04 onto an SD card. Connect the USB hard drive to the Raspberry Pi 4 into one of the USB 3 ports and boot the Pi.

On first login on Ubuntu 20.04 the username is ubuntu and the password is ubuntu. You will be prompted to change the password the first time you boot.

SSH in to the Pi (after discovering its IP address via DHCP) and run the following command:

sudo fdisk -l

You will be shown a list of all partitions. As this is a standard Pi install with an SD card and an additional USB device, my partitions are as follows:

/dev/mmcblk0p2 = SD Card
/dev/sda = External USB Drive

We need to set the partition table structure on the external drive /dev/sda.

sudo fdisk /dev/sda

Type p to see a list of partitions.

Then type d to delete the primary partition.

Now we need to create a new partition. Type n to create the partition, followed by p to set the new partition as primary and then choose 1 as the partition number.

You can press Enter twice to accept the suggested parition start and end blocks.

Finally, type w to write the changes to the disk.

Now the USB drive has the correct partition structure we need to format the new partition that we just created at /dev/sda1.

sudo mkfs.ext4 /dev/sda1

This may take a while, but no more than a couple of minutes if this is a fresh installation and the drive is smaller than 2TB (which it should be otherwise we need a different partition setup).

We need to make a directory where we will mount this USB drive to.

sudo mkdir /media/externalbootUSB

The directory name can be anything you want. Next we need to mount the partition to this new directory.

sudo mount /dev/sda1 /media/externalbootUSB

Now that the partition is mounted to our new directory, we can copy all of the SD card files to the USB drive partition.

sudo rsync -avx / /media/externalbootUSB

This took me around 3 minutes from a 32GB SD card to a 1TB USB 3 external drive.

Now we need to set the SD card to boot to the USB drive rather than itself.

As far as I know, on everything other than Ubuntu 20.04 and Raspberry Pi 4 this should be done in /boot/cmdlinetxt. On Ubuntu 20.04 and a Raspberry Pi 4 I had to do the following:

sudo nano /boot/firmare/cmdline.txt

Paste the following line (commenting out the existing line):

net.ifnames=0 dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=LABEL=writable rootfstype=ext4 elevator=deadline rootwait fixrtc root=/dev/sda1 rootfstype=ext4 rootwait

Remember to change the root=/dev/sda1 to whatever your partition is.

sudo reboot now

Once the Raspberry Pi 4 reboot you should be able to login, run df -h and the USB drive should show as being mounted on / with a capacity of however many MB/GB/TB the external drive is.

ubuntu@ubuntu:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 1.9G 0 1.9G 0% /dev
tmpfs 380M 3.9M 376M 2% /run
/dev/sda1 916G 2.2G 868G 1% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/loop0 49M 49M 0 100% /snap/core18/1708
/dev/loop1 62M 62M 0 100% /snap/lxd/14808
/dev/loop2 24M 24M 0 100% /snap/snapd/7267
/dev/mmcblk0p1 253M 61M 192M 25% /boot/firmware
tmpfs 380M 0 380M 0% /run/user/1000

In my case, my external drive has 868G remaining and is only 1% used. The important value here is the Mounted on point. It must be /.

You can now customise the installation as much as you want as you’re booting from the external USB drive.

Starting Tmux Automagically When Connecting to SSH

Mon, 11 May 2020 21:26:55 +0100

I recently noted in a blog post that I use a short snippet to either connect to an existing tmux session when I start a new SSH connection, or create a new tmux session if an existing one doesn’t exist.

The problem is, I have been using Termius more often than not recently and using the snippet feature as mentioned in the previous blog post.

I needed to make this work within a normal terminal today and thought I would add the snippet as a blog post so I don’t forget for next time.

In ~/.ssh/config we just need to add the following:

Host servername
HostName servername.domain.tld
User username
Port 22
RequestTTY yes
RemoteCommand tmux att -t session -d || tmux new-session -s session

Then, just run ssh servername and the SSH connection will be create and will either attach to an existing tmux session (and disconnect other sessions) or create a new one.

Flash Teckin Smart Plug for Home Assistant

Fri, 08 May 2020 17:35:37 +0100

I have been using Teckin smart plugs around the house for quite some time now. They’re really handy as they integrate with Google Home via the Smart Life app ecosystem. This means that each night we can tell Google to “turn everything off” and our lamps all switch off at the wall socket.

What I have wanted to do for some time, after seeing my friend do it with great success, was to flash the Teckin firmware to esphome so that I can control the sockets via Home Assistant and also get realtime values for the socket’s watt, amps and voltage loads. This would allow me to monitor the number of watts on things like the washing machine and then send myself a notification when the watts reduce after a specific period of time. So, when the washing machine has finished, shortly afterwards I’ll get a notification that it’s done. Simple.

The first step is to get the tuya-convert files.

# git clone https://github.com/ct-Open-Source/tuya-convert
# cd tuya-convert
# ./install_prereq.sh

Run ./start_flash.sh. It’s important to run this command and get the wifi network called vtrust-flash working on a phone or second computer before powering on the smartplug - as the plug will look for this SSID on boot. If you notice the plug is broadcasing an SSID of vtrust-recovery then this means the smartplug did not detect our flash attempt.

When the smartplug successfully connects to the flash SSID it will then transfer the flashing firmware and prompt for which version you want to load. The options are tasmota-wifiman.bin and espurna-base.bin. I have only used espurna-base.bin and it has worked perfectly.

Once the flash process is completed you can then end the flashing script by choosing N to flash another device.

Now we can connect to the smartplug on the new espurna-base.bin firmware by connecting to the SSID ESPURNA-XXXX with the password fibonacci. Once connected we need to go to the web interface which is at 192.168.4.1 and set a password. This password can be anything you want because it will be reset again shortly.

Now that the smart plug is running espruna and we know we can connect to the web interface, it’s time to create our own esphome firmware to upload.

We need esphome which is available via pip. I had to use sudo pip3 to get mine working.

Once esphome is installed (running esphome from your command prompt should display the available options, if it’s installed correctly) we need to create a yaml file with the required options.

Here’s the one I used, with thanks to Sam for giving me this file which worked perfectly first time.

esphome:
 name: ${plug_name}
 platform: ESP8266
 board: esp8285

wifi:
 ssid: 'YOUR HOME SSID HERE'
 password: 'YOUR HOME WIFI PASSWORD HERE'

substitutions:
 plug_name: teckin01
 # Higher value gives lower watt readout
 current_res: "0.00221"
 # Lower value gives lower voltage readout
 voltage_div: "871"


# Enable logging
logger:

# Enable Home Assistant API
api:
 password: 'RANDOM PASSWORD HERE'

ota:
 password: 'RANDOM PASSWORD HERE'

time:
 - platform: homeassistant
 id: homeassistant_time

binary_sensor:
 - platform: gpio
 pin:
 number: GPIO13
 inverted: True
 name: "${plug_name}_button"
 on_press:
 - switch.toggle: relay # this interects with switch.relay on the device not via hass

switch:
- platform: gpio
 name: "${plug_name}_Relay"
 pin: GPIO15
 restore_mode: ALWAYS_ON
 id: relay #this line gives the entity an id so the teckin plug can do some onboard stuff - see button 
- platform: gpio
 name: "${plug_name}_LED_Blue"
 pin: GPIO2
 inverted: True
 restore_mode: ALWAYS_OFF


sensor:
 - platform: hlw8012
 sel_pin:
 number: GPIO12
 inverted: True
 cf_pin: GPIO05
 cf1_pin: GPIO014
 # # Higher value gives lower watt readout
 # current_resistor: ${current_res}
 # # Lower value gives lower voltage readout
 # voltage_divider: ${voltage_div}
 current:
 name: "${plug_name}_Amperage"
 unit_of_measurement: A
 accuracy_decimals: 3
 filters:
 # Map from sensor -> measured value
 - calibrate_linear:
 - 0.0 -> 0.008
 - 10.33324 -> 8.212


 - lambda: if (x < (0.01 - 0.008)) return 0; else return (x - 0.013);


 voltage:
 name: "${plug_name}_Voltage"
 unit_of_measurement: V
 filters:
 # Map from sensor -> measured value
 - calibrate_linear:
 - 0.0 -> 0.0
 - 640.98718 -> 241.0


 power:
 name: "${plug_name}_Wattage"
 unit_of_measurement: W
 id: "${plug_name}_Wattage"
 filters:
 # Map from sensor -> measured value
 - calibrate_linear:
 - 0.0 -> 0.6
 - 11640.70117 -> 1957


 # Make everything below 2W appear as just 0W.
 # Furthermore it corrects 1.14W for the power usage of the plug.
 - lambda: if (x < (2 + 0.6)) return 0; else return (x - 1.14);



 change_mode_every: 3
 update_interval: 5s

 - platform: total_daily_energy
 name: "${plug_name}_Total Daily Energy"
 power_id: "${plug_name}_Wattage"
 filters:
 # Multiplication factor from W to kW is 0.001
 - multiply: 0.001
 unit_of_measurement: kWh

# Extra sensor to keep track of plug uptime
 - platform: uptime
 name: ${plug_name}_Uptime Sensor

Save the file as something sensible - I used teckin01.yaml and then run:

sudo esphome teckin01.yaml compile

This will create the firmware and store it in a directory that is not even remotely obvious…

/home/username/projects/tuya-convert/teckin01/.pioenvs/teckin04/firmware.bin

Now we just go to the web interface of the plug (192.168.4.1), go to Admin and then at the bottom of the page we upload this firmware image and we’re done.

The smart plug will reboot and will now be running esphome. Provided you used a unique name, the SSID and password are correct and Home Assistant is running - the new smart plug will pop up as a new device in home assistant.

Magic.

Note: I managed to get into a state of no response from one of the Teckin plugs when I was flashing a number of them at once. To rectify this I ran the following command:

sudo esphome teckin01.yaml upload

This command works because the smart plug is broadcasting a DNS name on the LAN of teckin01.local which the esphome program recognises - even if it doesn’t have a usable IP address. Worth remembering.

Customise Remoteapp Work Resources Name

Tue, 14 Apr 2020 11:56:53 +0100

When using RemoteApp on Microsoft Server 2016 I noticed that whenever you add the RemoteApp workspace feed to iOS or iPadOS devices, the resources are listed under ‘Work Resources’.

Although this works perfectly, it becomes a problem when you connect to different RemoteApp servers and they are all titled ‘Work Resources’.

The solution is simple and takes about one minute, assuming you don’t use an RDP gateway - if you do, it take a minute or so longer, that’s all.

First open Powershell as Administrator and enter:

Import-Module RemoteDesktop

Then at the next prompt enter the following:

 Set-RDWorkspace -Name "DMCC Cloud"

Obviously you can change DMCC Cloud to anything you want.

Mikrotik Failover Netwatch

Mon, 13 Apr 2020 16:49:26 +0100

Over the years I have used many different methods of failover for primary to secondary, sometime tietary, wan links on Mikrotik devices. Along with manual routing table entries, I have always relied on scripts of some sort that are triggered when one of the WAN links goes down. I have had varying success with this approach. One of the biggest problems I have had when switching from a primary WAN to a secondary WAN is the registration of VoIP phones seems to hang. The PBX keeps the registration open for the old WAN IP and the phones are now establishing connections from the new WAN IP.

The solution I have recently discovered on Mikrotik devices is Netwatch. You can find Netwatch within the Mikrotik Tools section. I believe Netwatch is available on all licence levels of Mikrotik RouterOS.

The principle of Netwatch is very simple. It pings an IP address of your choice on a user defined interval. When that ping fails (again, the failure threshold is user defined) then it runs any command within the Netwatch DOWN section. Likewise, when the link comes back up (the ping succeeds past the user defined threshold) then the command in Netwatch UP is run.

/ip route set [find where comment="WAN1"] distance=5
/ip firewall connection remove [find dst-address="123.123.248.8:5060"]

The above commands are in the UP command section.

/ip route set [find where comment="WAN1"] distance=15
/ip firewall connection remove [find dst-address="123.123.248.8:5060"]

The above commands are in the DOWN command section.

As you can see, when the link is up the WAN1 route is set to a distance of 5 which makes it the primary route. WAN2 should have a route distance of 10 in this example. When the link is DOWN then the WAN1 route distance is set to 15, at which point WAN2 with a distance of 10 becomes the primary route.

The second command in each of the UP and DOWN list of commands is the magic sauce. This is the command that clears any existing connections to the PBX server (in this case the example IP of 123.123.248.8:5060) which forces the SIP handsets to re-register. Interestingly, in most cases the SIP handsets don’t drop existing calls but they do re-register with the PBX which is exactly what I need.

I set the Netwatch host command to 1.1.1.1, an interval of 10 seconds and a timeout of 999ms. This means every 10 seconds the Netwatch feature will ping 1.1.1.1 and if it takes more than 999ms to respond then it will run the DOWN commands. If the ping response is ever less than 999ms then it will run the UP commands. With time I may tweak this as realistically a ping response time of greater than 100ms is likely evidence of a disrupted link.

Tmux Create or Join

Mon, 13 Apr 2020 16:36:34 +0100

I have been using tmux as an alternative to screen for a couple of years so far. It works very well and I very quickly got used to the shortcuts for it - especially after changing the shortcut key to CTRL + A.

One thing that I wanted to do was ensure that I was always in a tmux session. There’s little worse than running a command that is going to take some time but realising that you’re not in tmux session and you can’t quit the SSH session until the command completes.

With the help of Termius (SSH client), I created a snippet to be run whenever I connect to certain SSH hosts.

tmux att -t session -d || tmux new-session -s session

The snippet is simple - it attaches to an existing tmux session if it exists, if not, it will make a new one.

Since putting this in place a few months ago (maybe a year ago, time flies) I have never worked outside of a tmux session. I’ve never had to cancel a job to then re-run it within a tmux session and I have always been able to jump right back in to where I left off.

If you are interested, my tmux and other dotfiles are on my Github profile.

PiVPN DNS Name

Sun, 12 Apr 2020 00:11:15 +0100

I have used PiVPN for many projects over the past few years. It makes setting up a VPN gateway really easy and now supports Wireguard as well as OpenVPN. I have started using it more often since they added the ability for it to be installed on a vanilla Ubuntu installation, it no longer needs to be run on a Raspberry Pi.

One of the problems I have come across a few time with PiVPN is when the public IP address of DNS name of the VPN gateway changes. The VPN configuration file still have the original IP or DNS name. Originally I just manually updated each configuration file to the new address but this gets frustrating very quickly.

I found the solution in the Github Issues. There’s a default config header file that you can edit and this is included in the top of all new configuration files. Simply edit this file to match the new IP or DNS name and you’re good to go.

/etc/openvpn/easy-rsa/pki/Default.txt

This is also the place to add additional parameters to the configuration files such as route-nopull to prevent the VPN server from forcing its routes on the remote user. This makes split tunnel configurations easier.

Using SIP on Cisco 7906G Handsets

Sun, 05 Apr 2020 19:47:45 +0100

After a lot of trial and error getting a test Cisco 7906G handset working with an Asterisk PBX I thought it would be useful to make a note of the configuration options I used and the files that finally worked. They are all hosted on [GitHub]https://github.com/dannymcc/Cisco-7906G-SIP.

TFTP/DHCP Configuration

During boot the handsets will discover the TFTP server via DHCP option 66 and/or DHCP option 150. For this example I set option 66 of our VoIP VLAN to the local IP address of our TFTP server. All of the configuration files, firmware files and other customisation files reside in the root directory of the TFTP server, in this case it was \TFTPBOOT.

Base Configuration Files

Each handset will require an SEP configuration file. The filename must be SEP000000000000.cnf.xml where the 000000000000 is the MAC address of the Cisco handset.

In the example SEP configuration file, the following values have been set:

sip.provider.com <!-- This is the FQDN of the PBX, it can also be an IP address -->
123.123.123.123 <!-- This is the public IP address of the network the handset resides on, this if for NAT and may not be needed -->
222 <!-- This is the numerical extension number the handset will have, this must exist on the remote PBX first -->
pbx-username <!-- This is the register username for the extension -->
Pa$$w0rd <!-- This is the register password for the extension -->
*55 <!-- This is the direct dial for the PBX's voicemail -->

All other settings can be ignored for the purpose of the inital configuration. You must change every occurance of the above settings throughout the configuration file.

Firmware Versions and Upgrading

The firmware version that has been tested for these configuration files is SIP11.9-4-2SR1-1S. You can download the firmware files directly from Cisco - you will need to register for a free account. At the time of writing the link for the firmware files is here, however, I have included the firmware files in this repository for reference.

Dialplan

The included dialplan.xml gives some examples available. The dialplan file tells the handset how long to pause before dialling a number once it has been entered.

Ringtones

I have included a ringlist.xml file as an example of how to add new ringtones to the handsets. If you monitor the TFTP server logs when navigating the handset menu and requesting a new background or ringtone, you will see which files the handset requests. This is very useful when setting up the TFTP file structure.

When including ringtone .raw files, it’s simplest to include them in the root directory of the TFTP server along with the firmware and configuration files.

Converting and Moving a file using a simple bash script.

Sun, 05 Apr 2020 19:27:45 +0100

I recently needed to receive .txt files from a laboratory analyser, convert it to PDF and then transfer it to a local SMB share - but - the analyser results text file has to be over 30 minutes old before the whole process begins. Once the file has been converted, it needs to be deleted from the analyser server sl that it doesn’t fill up the local hard drive. The analyser server in this instance was a Raspberry Pi 3 B+ with a LAN connection. The reason for the 30 minute delay is due to the analyser exporting the results of a sample line-by-line and a full sample analysis can take up to 30 minutes. So if we transferred the file in less than 30 minutes then it may not be the complete results.

#!/bin/bash
## Danny McClelland 2020
shopt -s nullglob
for f in /home/pi/results/eclipse/*.txt; do
FILENAME=$f
PDFNAME=$(basename $f .txt)
# If file is over 30 minutes old then create PDF and remove TXT
if test `find $FILENAME -mmin +30`
then
# Create PDF from TXT
/usr/bin/enscript $f -B -o - | /usr/bin/ps2pdf - $PDFNAME.pdf
# Remove original TXT file
rm $f
# Copy file to SMB share
/usr/bin/smbclient //192.168.50.100/virtualdrive -U DOMAIN/username%password -D LAB -c "put $PDFNAME.pdf"
# Remove PDF file from local directory
rm $PDFNAME
else
echo $f too new - skipping...
fi
done

First Post

Sun, 05 Apr 2020 13:59:45 +0100

This is the first post of this new blog. I have made many blogs over the years and not one of them lasts more than a few weeks, or in some cases, days. My aim is to use this as a unified location for everything that I want to remember in the future. Let’s see how that goes… It’s entirely possible that this blog will not be updated very often, but, I hope it is. To help me feel less pressure in keeping the blog up to date, I won’t be advertising or publishing the blog address anywhere.

Technical

For the first time, I am using Hugo to write the blog and Netifly to host it. So far, it seems okay - time will tell. Netifly’s free package includes up to 100GB of traffic so that is pretty much guarenteed to cover me for this blog.

I am using a ready-made theme for now while I get the hang of Hugo. I’m hoping to make my own theme at some point in the future.