This is a note of gratitude.
A tad late. But better late than never :)

I decided to get involved with the Kubernetes community on a lark about four years ago.
I wanted to learn about containers and orchestration, and I thought learning via joining the upstream community was it.

I was wrong 😂
Life got in the way and I only finally got around to learning it all last December.

But the community was interesting and helpful.
I got to learn the terms of art, by osmosis.
I got to see how a large community functions, how a large software project was run.

And in time, I got to pitch in and help a bit as well.
I pitched in with the Release Team for v1.25 to gain a sense of how a release comes about.
And a couple of years ago, I saw my good friend (and frequent collaborator) Priyanka buckling a bit under the weight of the work, in the various roles she had assumed to help out in the community. I asked her if there was anyway I could help her, that did not involve meetings or talking to people 😂¹ And she asked me if I could pitch in and help with helping folks gain membership into various Kubernetes orgs on Github.

I ayed.

She taught me the ropes. And I became a Github New Membership Coordinator for the Kubernetes project.

And all of this history to say, I’m grateful to Priyanka for this serendipitous opportunity.
I fell in love with the work.
For someone who has had to face a lot of cynicism in his real world day job, it’s been a lot of joy, welcoming folks into the project. It’s one of the happier parts of my day, when I sit at the desk to process the requests that come in.

I’m also grateful to the Kubernetes as well as the overarching CNCF communities for recognising what I do, for two successive years.
I was the recipient of the Kubernetes Contributor award in 2024 and the CNCF’s, Chop Wood Carry Water award in 2025.
I’m both, honoured and humbled.
I hope to contribute to this community, a while longer :)

My last post in this section / category was in December.
There ought to be more, because I learn so much every week.
Even in December, the massive move I did, needs documenting. (at least for me, if not for your reading)

So the new plan is to cut the doing and the learning in half (or by a third). And use that time to write about what I learned.
I know this about myself. I write real good … sometimes. But to even get to that point, I have to write a lot of drivel.

So, in essence, welcome to the drivel :)
The posts will get more frequent, so if that bothers you or I write about things that aren’t what you came to read me for, I won’t hold it against you if you choose to unsubscribe. I need to be able to write for me. And this is the only place where I can.

If you do decide to stay and read, as always, I’m grateful. I truly am.

Update 2025-12-19: All done!

I just finished a move from one Hetzner VM to another.
The type of VMs are the same, in fact.
It’s just that the new VM and all the software on it are entirely software driven. I kept logging my progress in my notes, copy pasting the plan from day to day and ticking things off.
Now that it’s done and I still want to refer to it regularly, as the rest of the services come over, I wanted a place to keep it. And so this post, it is.

List of services that absolutely need to come over. Miscellaneous stuff later.

• the main domain
• french version of the website
• the mastodon archive
• the email distribution list
• miniflux for rss feeds
• joplin
• baikal
• discourse (no more discourse!)
• markdown editor (hedgedoc)
• anki
• huginn
• syncthing
• IRC: theLounge + znc (see if we can make do with a single service now (2025-12-15: we could!))
• kanboard
• Certs, Move them over, or figure out a way to generate and renew them via Ansible

The Big Point of The Big Plan

• Save time and energy. Managing all the disparate services I use is taking more and more of my time. I need to claim that back, while being able to use said services.
• Be gitops driven. Managing stuff gets easier. Tearing down things and rebuilding them gets easier
• Have most everything I use, be in a Kubernetes cluster.
• Be pragmatic enough to know that everything cannot be in a Kubernetes cluster and will have to live in the root VM
• Have Flux CD manage everything in the cluster
• Have Ansible Pull manage everything in the VM, acting as my single node. The point of doing this is not idempotency, rather to have everything in code; something that I can comment and uncomment and manipulate at will, something I can update at will and something that is documented. Never again will Future Jason have to scratch his head about, just how to go about doing something. (Long term note to self: Have the discipline to write tasks and drive everything with Ansible, despite the ease of “just doing it at the command line”)

The Big Plan (Done! 🎉🎉🎉)

• The plan is to redo the cluster again and do my own instance of
  • K3s
  • Sealed Secrets
  • Flux CD
  • Certmanager (Not using it)
  • Letsencrypt (using pre existing Letsencrypt certs)
  • Get Traefik Ingress to work
  • Figure out a way to get certs automatically into the cluster
• And once that is done, figure out an app to move (Miniflux or Hedgedoc?); 2025-12-03: Kanboard it is!
• Begin by moving (lifting and shifting in popular parlance) Kanboard to the cluster
  • Cert will probably be needed (Wildcard cert works now, just like it does without the cluster)
  • Convert a docker-compose to kubernetes manifests
  • Learn how to configure an app with code
  • Learn how to store data and back it up
  • Figure out secrets, if there are any (for now sealed secrets ok, figure out vault and vault injection later)
  • Learn how to tunnel through and reverse proxy
  • Make Kubernetes manifests work with flux
  • Figure out how to automate deployment of manual manifests
  • Figure out how to migrate there if there is any in an old app
  • Figue out how to automate updation of images in manual manifests
  • Get another app (Miniflux) deployed
  • Figure out what needs to happen as part of the lifecycle. What you want in the cluster, what stays out, do they intersect, how do updates of cluster happen? VM (node) updates as well?
  • Then begin to think along the lines of Live Deploys. Prototype locally and once it works, migrate to production immediately
  • Convert Kubernetes manifests to Helm Charts (optional, based on energy)
• Go live! Git is source of truth. Two repos.
  • One for the Main node and its update
    • Terraform will provision node and install package, setup firewall
    • Figure out how to get Terraform to get the node talking to the git forge
    • Structure repo, copy every thing node related there, and make sure stuff gets updated periodically and if possible, idempotantly, via ansible pull and a systemd timer
  • The other one for k3s and flux
    • Convert everything I have done locally to run on prod. Add more steps as you do them below

Unrelated. Long term. Optional. Just here so that I remember

• Get Moi publish script running
• Redo Huginn Scenarios

It no longer serves that need for me.
For a long time, the way the app worked aligned with the way I want to read. Earlier this year though, the developer decided to take the app in a different direction, with a different reading experience. The older app is still available as Reeder Classic, but only a few months of use have shown me that the app is basically abandoned. The attention to detail is obviously now being applied to the new app.

Enter ReadKit.
I had used it briefly during the Google Reader apocalypse when every feed reader was scrambling to find new backends to sync to. Reeder similarly had switched to local only mode and was taking a while before it supported other services.
ReadKit in the meanwhile already had support for Feedwrangler, and so I switched to it until Reeder came back to speed.

And I’ve switched to it for the foreseeable future.
It looks beautiful!
It does everything I want, shows everything the way and want and behaves just the way I want it to. The only knock I have against it, is that it does not feel as fluid as Reeder does. But that’s nothing compared to the constant launch and relauch dance, I have to do with Reeder nowadays. Consistency and stability matter a lot to me.
Even better, it syncs natively with Miniflux, the service I use to actually fetch and read RSS feeds on my Linux desktop. No more Google Reader API!

This is a list of all my categories (with one of them expanded, click for a larger view)

and this is a list of unread articles in a feed, alongside one that is open (once again, click to enlarge if you want to see details)

That gnawing feeling has now gone away from the back of my brain.
The experience of reading and catching up with the world is once again a glorious experience thanks to ReadKit.

One thing that bit me when I was trying to expose my apps to the world when working on the home cluster, is that Kubernetes on bare metal—I was using Kind at the time—expects to talk to a load balancer service, which then talk to an actual load balancer. Which if you are using bare metal, you won’t usually have.
I had to then go expose a “NodePort” to gain access from outside.

So to expose my stuff in as “real world” a way as possible, we need to:

1. Either install a load balancer implementation like MetalLB. OR
2. Use a Kubernetes distribution that has a load balancer implementation built-in, like K3s.

I chose option 2 and used K3s, because I am, as they say in popular parlance, using Kubernetes at the edge.¹
In which case, I prefer to have as many batteries built-in as possible.

Problem

My main SSD is too small to hold all my kubernetes and K3s shenanigans. (It’s only about 512gb) So I need a way to move my K3s data folder out to my big HDD.

Solution

K3s supports having a custom data directory, by letting me specify a data-dir.
I decided to specify it in the K3s config file at /etc/rancher/k3s/config.
If it isn’t there (as it wasn’t in my case), just create one. You’ll need to do this as the root user.
This is what I now have in there.

data-dir: /BIGHDD/rancher/k3s

And then, I …

1. Created a rancher directory in my big hard disk. (root owns it)
2. Ran rsync as the root user: rsync -a /var/lib/rancher/k3s/ /BIGHDD/rancher/k3s/
3. Started up my cluster again with a sudo systemctl start k3s

I have a post in one section of my site, say notes and miscellanea
That is my canonical post.
But I also need it to show up in the work section of my site, possibly with a another name.
A Hugo alias in the yaml front matter does not work, since both sections exist and Hugo gets confused.

Solution

1. Make sure layouts/redirect/single.html exists within your Hugo folder structure and it contains just this line …

{{- template "alias.html" (dict "Permalink" .Params.target) -}}

2. Create your orginal post as usual
3. Then go create a post in your other¹ section with the following metadata:

---
title: <Your title here>
#date autogenerated by my archetype. if missing, add date
date: 2025-11-06T08:30:54+05:30 
type: redirect
target: <url-to-redirect-to>
summary: <Optional text, that will appear in the sectiones listing page>
---

4. The date field is critical. The post might not appear where you expect it, if it’s absent.
   If not date, then you might need to use weight. One of the two is needed.
5. In my case, the metadata looked like this:

---
title: "The Plan for My New Hetzner VM"
date: 2025-11-06T08:30:54+05:30
type: redirect
target: /nm/2025-11-06/
summary: Alone and helpless, like you've lost your fight 
---

6. Done! You can see an entry for “The Plan for My New Hetzner VM” in my work section as you see in the pic below. Clicking that will redirect to the actual post in my Notes and Miscellanea section!

7. Tada 🎉

I had started this series, to catalogue my journey learning Rust whilst doing David Beazley’s, Ruckus course.
And just like that, it’s over! 😂 The course is done, and I am already missing Dave and my fellow journey folk, Rodica, Yadu, Marko, Upul, Gabriela, and Eugene!
I never thought the end would be so bittersweet.

Worth it financially?

Yes! Oh, dear God, yes!
To begin with, I never thought that Dave’s courses were expensive. Yes, they cost money, but he’s given so much away for free, that I was willing to save up and put my money where my mouth was.
I also think, I’ve figured out Dave’s schtick with the idea of what he teaches.
Take something, something hard, (Write a compiler? Figure out distributed consensus in networked systems? The big ideas and paradigms in computing?); something that would take an average Joe, 4-6 months (or a college semester) to learn, and then compress it down to anything from a couple of days to a work week. Compress the time that is … not the knowledge.
Having that much knowledge dowloaded into your head in that short a time frame, is what (to use a Dave-ism) makes your brain explode.
And now having actually done it, I’m now swinging around to the price is just right or “He actually undercharges a bit” camp.
This is bloody addicting. I’m just going to save up and do them all as and when I can over time. Like Neo answering Tank’s, “How about some more?”, with a Hell yes!

Worth it for the knowledge I gained?

Have I already said, Oh, dear God, Yes?! Doubly so, here!
Learning it myself, I realised that Rust had paradigms, teasing me at the edge of my vision, which I couldn’t quite see, frustrating my attempts to learn the language.
Python (C/OOP) is my ur-language. Having that, made it easy to learn Go. Rust turned out to be a different beast altogether. Having the big ideas of Rust laid bare and then explained thoroughly was therefore, such an eye opening experience. And I learned it while doing something else, that is inherently hard. Dave makes it easy though, like I describe below.

I just wanted to learn Rust. I didn’t really want to write a small programming language.
But doing that, made me learn Rust without even realising it. He’s that good. The pedagogical method is that good.
Most big ideas were in there. Ownership and borrowing, check. Compare and contrast how things are done in other languages, double check. Macro magic, check and triple check.
The course was more focussed on the why of Rust, more than the more easily discoverable, how.
A fascinating mental model was looking at Rust like Earth. An inner strict core, surrounded by a more relaxed, friendlier outer shell.

Daily work was tremendously, mentally taxing. In a good way.
Dave keeps saying that minds explode due to the material. But no good Sir, that is not true!
To Dave I say, “’Tis thou, Dave, who dost cause the explosions of brains!”
He starts with an innocent problem, something seemingly innocuous, and then lays his trap.
Simple solutions are shown not to work, teensy yet ghastly exceptions show up to trip you, dreadful scenarios that you’d never imagine, lie beneath the surface. And your mind gets wound up so tight, that when Dave finally has had his fun, takes pity on us and shows us the solution, it naturally goes, Boom!

I cannot wait, to have my brains exploded once again :)

Am I done with this series?

No.
I jumped into the deep end of the pool, by attempting to learn Rust with a hard project at the same time.
So while I’ve learned a lot, there’s plenty of work to do.
While the others could do their programming exercises quickly, I have seriously lagged behind.
With the notes I’ve made and the resources that I have access to, I will attempt to redo this week myself over the coming months and write about it, and ponder, struggle, work through it here.

Dave as teacher and all round good egg

The man puts in tremendous amounts of work.
Every bit of the course, is planned and structured meticulously and then he just riffs off of the ideas.
There was a collaborative Github repo ready and waiting, there were video recordings ready as soon as the day was done.
Dave never pretends to have all the answers. 99% of the time, he does and hides it well, so we do the thinking, but the few times he didn’t, he let us know and then came back to us with answers and thoughts either in the next session or the next day.
Unfailingly polite, kind and generous to a fault, he fostered an extremely collaborative environment, in which, even when there were other folks much more learned and experienced than I; I never felt like a dunce. I never felt spoken down to.
All my kooky ideas were evaluated, and then Dave would point out why doing something like what I suggested wouldn’t quite work or why stuff would crash and burn or why what I suggested doing eeny, meeny, miny, moe was in fact, pretty good.
I learned not just what, not just how, but also why.
And I learned it all in a place that was nice, and friendly, and warm, and kind.

Dave, thank you for all you do! I’m very grateful!

I signed up for the latest cohort of David Beazley’s, Ruckus.
The basic idea, behind Ruckus is to write a small interpreter in Rust!

Why?

From the Ruckus page:

This course tackles Rust by stepping back and thinking about it from the standpoint of a “programming languages” project. If Rust is really so different, how would you go about finding out how? Suffice to say, building a programming language will cut right to the heart of the matter.

This is exactly how I learned Python. Only it took me an inordinately long time. And I didn’t even realise that I was doing it that way. While most of my friends were happy just using Python, I could not quite do it right, because I had no fundamentals¹, and since my background has been tech support, hardware and people management, I needed to unlearn a ton of stuff.

I’m cautiously hoping Ruckus will help me do the same with Rust, only in a turbo charged manner.

Rust fascinates me. And I quite like my journey to its doorstep.
I learned writing for myself with Python. But when it came time to sharing my tiny projects with friends and family, I was a bit stumped.
I learned Go, just so I could give them a binary and then instruct them with a “just run this.”
And while that solved my distribution problem, Go’s type system made me realise, just how well suited a typed language is for collaboration.
Which brings me to Rust. Long term, this is the language², I would love to write for performant code, because Rust’s big picture features (safe, performant, easy to distribute) are exactly what I want for all my tiny bits and bobs.

Which in turn brings me back to Ruckus.
Getting a teensy peek at how everything works underneath, while at the same time, getting a firm handle on the language seems like a fun challenge.
I also wanted to try what Cal Newport, calls a grand gesture in Deep Work:

The concept is simple: By leveraging a radical change to your normal environment, coupled perhaps with a significant investment of effort or money, all dedicated toward supporting a deep work task, you increase the perceived importance of the task. This boost in importance reduces your mind’s instinct to procrastinate and delivers an injection of motivation and energy.
[…] The dominant force is the psychology of committing so seriously to the task at hand. To put yourself in an exotic location to focus on a writing project, or to take a week off from work just to think, or to lock yourself in a hotel room until you complete an important invention: These gestures push your deep goal to a level of mental priority that helps unlock the needed mental resources. Sometimes to go deep, you must first go big.

Make no mistake, my current state is that of an enthusiastic, ignorant newbie. How hard can it be? I’m woefully unprepared for what might come. The only thing I know, is that I don’t know. I fully expect to be like the wolf above, losing my mind, howling at the moon and generally creating a ruckus.

I’ve never updated my Emacs packages until recently, because Emacs is where all my writing happens, and so I’m justifiably paranoid.
But then some packages stopped working, due to various circumstances¹ and an update solved it.

So I’ve decided to update my packages once a quarter, so that I don’t lose days yak shaving when something goes wrong and I handle breakage on my terms and not the machine’s.

As far as package management goes, I want to keep things simple.
In fact, I still haven’t graduated to use-package or straight.el because my package needs are few and conservative². And so, while there are automatic update options out there, I’ll just stick to updating them manually, every quarter.

Ergo, this is the checklist I’ll use next time onwards …

1. Stop emacs user service, systemctl --user stop emacs
2. Backup emacs folder in ~/.config
3. Start emacs manually (not the service).
4. M-x package-refresh-contents
5. M-x package-upgrade-all
6. Problems? Quit emacs. Revert backup folder.
7. In the end, start emacs user sevice, systemctl --user start emacs

There’s an Org mode task, scheduled quarterly, so that I won’t forget.

I’d gotten this working earlier and wanted to post it up.
And then promptly forgot about it.
Until today that is, when I wanted to make changes to it.

Here it is for posterity.
The newest change is that the action now runs every six hours.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

name: Build and Deploy Janusworx website
on:
  schedule:
    - cron: '0 */6 * * *'
  workflow_dispatch:
  push:
    branches:
      - main

jobs:
  build-and-deploy:
    runs-on: intel # make sure there are runners tagged "intel" on your network or replace this with something of your own

    env:
      HUGO_VERSION: ${{ vars.HUGO_VERSION }}
    steps:  
      - name: Install wget & rsync
        run: apt-get update && apt-get install wget rsync -y

      - name: Install Hugo
        run: |
          wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \
          && dpkg -i ${{ runner.temp }}/hugo.deb
      
      - name: Checkout the website repo
        uses: actions/checkout@v4
        with:
          submodules: recursive
          fetch-depth: 0
      
      - name: Build website with Hugo
        env:
          HUGO_ENVIRONMENT: production
          TZ: Asia/Kolkata
        run: |
          hugo \
            --gc \
            --minify
            
      - name: Install SSH key
        run: |
          mkdir -p ~/.ssh
          echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_ed25519
          chmod 600 ~/.ssh/id_ed25519
          echo "${{ secrets.SSH_KNOWN_HOSTS }}" > ~/.ssh/known_hosts
          chmod 644 ~/.ssh/known_hosts

      - name: Deploy website with rsync
        env:
          REMOTE_HOST: ${{ vars.REMOTE_HOST }}
          REMOTE_USER: ${{ vars.REMOTE_USER }}
          REMOTE_PATH: ${{ vars.REMOTE_PATH }}
        run: |
          rsync -avz --delete public/ $REMOTE_USER@$REMOTE_HOST:$REMOTE_PATH

Notes:
It needs a few variables set, in the repo (repo->Settings->Actions->Variables), which are the details I need (Hugo version, Remote Host IP, Remote path to copy the built output to, and the Remote user to use for SSH) to push via rsync to the host.
Hugo version is in there, because Hugo breaks things all the time, so I upgrade cautiously.

It also needs a couple of secrets, set in the repo (repo->Settings->Actions->Secrets) to enable rsync to copy. (SSH_KNOWN_HOSTS and SSH_PRIVATE_KEY). Also best if this is a dedicated private key just for copying. Running ssh-keyscan "your-host-name-or-ip" > known_host_data.txt should dump the data you’d need for SSH_KNOWN_HOSTS

With the changes I made today, the workflow can publish

• on demand
• every 6 hours
• every time I commit to the repo

I added time based publishing, so that I could publish future dated posts as and when the time rolls around.
With this, I think I’m done tinkering with my blog, with the exception of moving it out of my home network and out on to my VM, so that I can truly publish from anywhere. That is a big heft for me currently and a job for future Jason.

1. To paraphrase Robin’s own point. Most people don’t care.¹

If it runs Minetest, then it’s fine.

aka “If it does the thing, I want it to do, without too much cognitive overhead, I’ll use it.”
Learning the skill, so I can do this task, is definitely not what the world at large wants to do. Nor do I imagine, do most folk have the time and the bandwidth. iTunes (and Netflix) when they launched², were the prime examples of this. Convenience and ease of use trumps Free. Also by that same token, VLC is probably one of the most installed and used video players in the world, not because they are FOSS, but because they make it easy to install and use.

2. Some people feel strongly about having control over what they do, over their data. Those folks were those I found easiest to move to Free software, because it aligned with what they wanted.

3. Support costs are about the same.
   If a small business chooses to use free software, the cost of supporting it, if stuff breaks, (specially if it’s business critical³) probably is about the same as paying for the proprietary version. The fact that paying and getting it fixed benefits the world at large is lost on most. Or maybe it’s something, we Free Software evangelists could learn to to better. Robin promises his team, first-level support, but what happens when he goes on to better opportunities and is no longer around?

So I agree with most of what Robin says, with just one caveat.

People aren’t afraid of change. Atleast not the kind of change, Free Software poses.
People just don’t have the time and the energy to deal with change, with everything else happening in their lives.
Free software is just not as important to them, as it is to us. That is all.⁴

1. Why did you make the blog in the first place?

I write for me mostly. Because writing helps me think. My thoughts are too scattered otherwise. I can’t not write. I’ve always written. Privately, publicly, there’s always been some place where I’ve jotted things down.

2. What platform are you using to manage your blog and why did you choose it?

I use Hugo to generate the site, which I host on my own Hetzner VM. I use it because I outgrew my previous tool, Nikola, which still holds a dear place in my heart. While Hugo is enormously complex, it is also deceptively simple enough to get started with. And it’s fast. That’s what I love about it. It lets me write. It does not get in my way. It lets me preview what I’m doing with its live server. And it’s unbelievably fast.

3. Have you blogged on other platforms before?

I’ve been writing in some form or other since the late 90s. So … yea :)
Livejournal, Blogger, self hosted Wordpress, wordpress.com, Posterous, Tumblr, self hosted Wordpress, self hosted Ghost, Nikola and now Hugo. It’s been quite a ride!

4. How do you write your posts?

I write them in Emacs (in Markdown, using Markdown Mode) on my desktop, with Hugo Server running alongside giving me a preview of what things will look like. Once I commit it to my self hosted Forgejo instance, an action publishes the site automatically

5. When do you feel most inspired to write?

I never do. I write because it helps me function. And yet, it always feels like a chore.

6. Do you publish immediately after writing or do you let it simmer a bit as a draft?

I always publish it immediately. I almost never write something that is deeply thought out, that needs to stand the test of time. It’s the process, the writing, the putting words out of my mind, through my fingers down to paper, that leads to the result, the thought, the opinion, the aha, the insight. So I’m never quite done. Which means if I ever wait for finished, the post will never get published. The moment I publish something, is invariably the moment something needs changing. So I just go back and edit it. I never notify folks about updating things on the first day. If I ever edit something much later than a day or two, then I do.

7. Your favorite post on your blog?

None. All. They’re my thoughts, so depending on my mood, they’re either worthless or priceless gems!

8. Any future plans for your blog? Maybe a redesign, changing the tag system, etc.?

Not really. For all my wandering, I’ve only ever moved when my tools outgrew me¹, or I outgrew my tools. For now, Hugo does all I ask of it, without getting in the way. The day that changes, will be the day I move.

I’ll ask Priyanka, Sreeram, Sandeep, Pradhvan, Rahul, Bhavin, Elia, Mandar, Saptak, Farhaan, Robin and Kushal to share more, if they have the time, energy and the inclination.

Folks, who’ve answered my call to arms! Go read their answers too!

• Robin
• Elia

For e.g. https://janusworx.com/blog/using-hugo-variables-to-help-with-mailto-links-in-hugo/ …
was now at, https://janusworx.com/work/using-hugo-variables-to-help-with-mailto-links-in-hugo/

After searching a bit, I found that Hugo supported aliases. For me, it would redirect the original /blog path url to its new location
Ass I had to do, was add an aliases: ["/blog/old-post-slug"] line to each post’s metadata.¹
Line 4 in the snippet below shows, what I added to fix the post above.

1
2
3
4
5
6
7
8

---
title: "Using Hugo Variables to Help With Mailto Links in Hugo"
date: 2024-05-30T18:17:35+05:30
aliases: ["/blog/using-hugo-variables-to-help-with-mailto-links-in-hugo"]
categories: ["work"]
tags: [100WordHabit, Dgplug, Hugo]
summary: Shortcodes! Hugo Variables in Shortcodes!
---

I did not want to do this by hand for 800+ posts.
One stroke of luck for me, was that I let Hugo use its default behaviour of generating url slugs from the file names. So even if the category slugs had changed (from /blog to /work or from /blog to /personal), the url slugs would stay the same. Which meant, I could whip up a script to run through all my markdown posts and add the alias line.
So I did.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

from pathlib import Path

INPUT_FOLDER = Path("old-posts-folder")
OUTPUT_FOLDER = Path("modified-posts-folder")

for each_file in INPUT_FOLDER.iterdir():
    with open(each_file, 'r') as file_to_read:
        alias_derived_from_file = each_file.stem
        contents_as_list = file_to_read.readlines()
        contents_as_list.insert(3, f"aliases: [\"/blog/{alias_derived_from_file}\"]\n")
        with open(Path(OUTPUT_FOLDER, each_file.name), 'w+') as file_to_write:
            file_to_write.writelines(contents_as_list)

It takes all the posts from my old folder, inserts the alias line and puts them into a new folder.² In essence, take each file, figure out the url slug from the file name, read in the contents as a list, insert my alias at position 3 (fourth actually. zero based indexing) of the list (below the title and date) and then write it all out to a new file.

I ran it, published the site and then went to check on the old urls with bated breath.
Hurrah, it all worked :)

1. Launch Terminal
2. Launch Tmux
3. Split it into three windows err … panes.
4. Go to the top left pane and launch Hugo server
5. Switch to the right pane and then launch Emacs with whatever new post I want to write today.

So of course, a Rube Goldberg-esque, tiny bash-pipey monster took form. It now resides, chained to an alias, hssx¹ in my .bash_aliases file

1
2
3

alias hssx='cd /path/to/my/hugo/folder && \
xdotool windowsize $(xdotool getactivewindow) 100% 100% && \
tmux new-session \; split-window -h \; select-pane -l \; split-window -v \; select-pane -U \; send-keys "hugo serve" C-m \; select-pane -R'

1. The first line switches to my hugo folder
2. The second calls xdotool and maximises the terminal window
3. And the last line is a series of instructions to the tmux command. I’ve split it below for readability.

tmux new-session \; #Tmux start a new session
split-window -h \; # Split the window into two vertical panes
select-pane -l \; # Switch to the left pane
split-window -v \; # Split that into two horizontal panes
select-pane -U \; # Select the upper pane
send-keys "hugo serve" C-m \; # Type in `hugo serve` followed by Enter
select-pane -R # Select the right pane

Like Dale Carnegie says,

Shut off the past! Let the dead past bury its dead. Shut out the yesterdays which have lighted fools the way to dusty death.

The load of tomorrow, added to that of yesterday, carried today, makes the strongest falter. Shut off the future as tightly as the past.

The future is today. There is no tomorrow. The day of man’s salvation is now.

Waste of energy, mental distress, nervous worries dog the steps of a man who is anxious about the future. Shut close, then the great fore and aft bulkheads, and prepare to cultivate the habit of life of day-tight compartments.

So I want then, my Org Mode to do show me, only the things, I have on my plate today.

And Org is nothing if not adaptable. org-agenda-span is the variable that controls what the Agends shows me. According to the docs,

This variable can be set to any number of days you want to see by default in the agenda, or to a span name, such a day, week, month or year.

So that’s what I did. This little snippet went into my init file

;; Set Agenda to show a day as the default timespan, instead of a week
(setq org-agenda-span 'day)

Et voilà!

Now that I use my local machine to draft all my posts, desktop Emacs makes everything easier … with one exception. It swallows up a lot of my Espanso expansions.

My current bugbear is that it will not render a = when expanding.
I know this is entirely something that I brought on myself, and neither Emacs or Espanso in isolation will have issues.

My workaround after rummaging through Espanso’s documentation was to set the backend to use xdotool, in my config. (~/.config/espanso/config/default.yml)

x11_use_xdotool_backend: true

One downside now is that it no longer jumps back to a predefined location in the snippets where I’ve defined such a thing. No matter. I use them rarely and I’ll figure something out later. (Alongside why desktop emacs won’t render markdown expansions sometimes as well)

For now, most of my expansions work. Hurrah!

I needed to do this for my stream of consciousness / wip / progress notes in the Notes and Miscellanea section I did not want to disable the whole section, because some posts, I do want to leak out.

What it boiled down to was getting the RSS template to ignore sites with some parameter set in the front matter. Most posts on the web do a rss_disabled: true or something to that effect.

Joe Mooring over on the Hugo Discourse logically pointed out that I’d want such posts to be disabled in the sitemap as well, so I’d do well to just piggy back off of that.

So all I had to do was set the following in the my front matter

sitemap:
  disable: true

and then configure the embedded RSS template¹ to just range through pages that didn’t have that parameter set, like so …

{{- range where $pages "Sitemap.Disable" "ne" true }}

The original line would’ve been something like

{{- range $pages }}

You’ll need to create a new feed file by copying the contents of the embedded template to a file called rss.xml in the layouts/_default/ directory

Once that’s done, all should be hunky dory.
Posts with this frontmatter, will now no longer appear in RSS feeds or the sitemap.
To make things simpler, I edited this sections archetype, so that the next time I create a new Notes & Miscellenea post, all of this metadata is already set for me.

I never had the time to deal with my Espanso¹ hijinks until today.
While it worked perfectly, when I installed it all those years ago, when I migrated over from the Mac, Espanso itself has changed and evolved over the years.
It took over my old configuration like a champ and mostly worked, with the exception of a few shortcuts; ones that I frequently used 😂

Emacs was one application of mine that never quite worked right with Espanso.
I’d frequently get timed out waiting for reply from selection owner whenever I tried expansions in there. Typing :joy to get 😂 would work in every other program, but no joy with Emacs, in additon to plenty of other expansions err … not expanding.

All my browser url expansions would not expand properly either, with mangled expansions most of the time.

So today I dove in to the docs, and realised two things.
1. My emacs needed a longer time out
2. Espanso now tries to identify the kind of text, and maybe those were causing my issues?

Emacs

I realised I needed a longer clipboard threshold, only for Emacs.
So I created an App specific configuration, just for Emacs to use and gave it said option. Here’s what the contents of my espanso/config/emacs.yml look like

filter_class: 'Emacs'
clipboard_threshold: 10000

Rich Text Expansions

That helped with a lot of expansions in Emacs, but not with my joy expansion.
And not with stuff that were links and oh … links! and html! and markdown! Could those be the culprits?²
The docs mention that Espanso now has rich text support
What that means, is that the trigger nows supports two new keywords html and markdown in addition ye ole replace So I changed most of my affected shortcuts to either of those two keywords; markdown for most everything and html for linky stuff. Here’s what my beloved joy looks like now …

matches:
  - trigger: ":joy"
    markdown: 😂

And those two things did it! Every shortcut expands everwhere! What joy 😂

(Romeo and Juliet, Act 2, Scene 2)

Right now I’ve set up pull mirrors for all the projects I love.

Next step is to figure out how to automate my Hugo blog deployment and more importantly; having all my posts in source control.

I want to slowly increase my French vocabulary, so I got this comprehensive frequency word deck from Shared Decks section of the Anki website.

I keep forgetting to look it up during the day, after my morning session and the only way I can get those stubborn words¹ to stick in my mind, is if I keep doing the deck 4–5 times a day.

I know! With all my newfound devops/python skills, could I figure out a way to remind myself to do it? Turns out I can! :)

I already use Pushover, to get notified of darn near anything.²
And I read enough of Anki’s add-on documentation to know I could whip something up.
So a bit of searching on the net, a bit of jiggery pokery with Claude, and some spelunking through Anki’s source code and forums later, I present to you … anki-push-u!³

As long as your Anki’s running, this little add-on will find cards due, at the interval you tell it to, and then notify you wherever you have Pushover running!
No more forgetting due cards!

Find the add-on and instructions over at Github.

If you look at the site today, you’ll see that ye olde blog section has disappeared.
I’ve replaced it with three sections, Work, Personal and Reading.
I’ve done this primarily for me.

While I want all my writing in one place, I want them organised in piles that correspond with the three major modes of my brain.
Work to hold everything I consider work.
Reading for the bookworm in me.
And finally personal for everything else.

The problem (my problem, in my mind) with the old blog was too much mental whiplash when I read the blog. I would go from poetry to docker to antifragility to photos with every turn of the page.
I didn’t like it.
Ergo, the reorganisation.

So now, whenever I am browsing my posts in the work section, I see only tech, and computers and docker and programming and all that good stuff.
Same with the personal stuff and the reading.

How does this affect you, my kind and gentle reader?

1. If you are a subscriber to the email list, nothing changes. I know I’ve been lax with updates, but hopefully this reorg should break up the log jam and help me write more.
2. If you just come here to the site, once in a while to read through, hopefully, you’ll find it easy just like me, to read posts without too much cognitive whipsawing.
3. And finally, if you subscribe via RSS, you my friend are probably affected.
   The main feed, with all articles, still remains the same, so if you drink from the firehose, nothing changes.
   If you’re subscribed to a tag specific feed, like Emacs or DGPLUG, nothing changes.
   The only change is that the blog feed has disappeared. In its place are three spanking new feeds, representing my new sections.
   • The Work Feed
   • The Personal Feed
   • The Reading Feed
4. And that about does it. Happy Reading!

Update, 2024-08-20:
Added a missing step, to install the qBittorrent files to their relevant places
Also, it had to happen. No releases for close to three months and then just as I learn to compile, a new version has to release the very next day 😂
It gave me a chance to test my notes. It hardly took me a few minutes to get the new release in place. So all is good!

I wanted to always have the lastest stable version of qBittorent on my Pi.
So today, I sat down and followed the project’s excellent instructions and got it running.
I did however stray off the beaten path a teensy bit¹.
I didn’t want a gui and I wanted to be able to control it with systemd.

So here’s my checklist for next release. I’m currently running Bookworm on my Pi 5

1. In case you run into problems, compile instructions are here: https://github.com/qbittorrent/qBittorrent/wiki/Compilation-Debian,-Ubuntu,-and-derivatives

2. Do all off this after switching to root. (or sudo)

3. Install build tools
   sudo apt install build-essential cmake git ninja-build pkg-config libboost-dev libssl-dev zlib1g-dev libgl1-mesa-dev

4. Install Qt dependencies (qtbase5-private-dev is not part of the instructions, but compile will fail if you don’t include it)²
   sudo apt install --no-install-recommends qtbase5-dev qtbase5-private-dev qttools5-dev libqt5svg5-dev

5. Qt requires Python at runtime, so: sudo apt install python3

6. Install the libtorrent library. I compiled from source. Check page for fresh instructions, if stuff here doesn’t work

   git clone --recurse-submodules https://github.com/arvidn/libtorrent.git
   cd libtorrent
   git checkout RC_2_0 # or a 2.0.x tag
   cmake -B build -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_INSTALL_PREFIX=/usr/local
   cmake --build build -j4 # the -j4 is to do on four cores at once. my addition.
   sudo cmake --install build
   

   If you ever want to uninstall libtorrent, then don’t delete this main folder. The build process would have created a install_manifest.txt in the build folder. So you can then uninstall with: sudo xargs rm < install_manifest.txt

7. Get qb source: https://www.qbittorrent.org/download.

8. Unzip: tar xzvf qbittorrent-4.6.5.tar.gz and then cd qbittorrent-4.6.5/

9. Create Build configuration (disabled GUI and enabled systemd. Those aren’t part of the defaults)
   cmake -G "Ninja" -B build -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_INSTALL_PREFIX=/usr/local -DGUI=OFF -DSYSTEMD=ON

10. Build cmake --build build

11. Install all the files to their relevant locations cmake --install build

12. Install service to run for a specific user.

    systemctl daemon-reload
    systemctl enable qbittorrent-nox@<some-user>.service
    systemctl start qbittorrent-nox@<some-user>.service
    

13. We’re done.

So I’m building some margin into my life.
And the only thing I can talk about work wise, is the familiarity I am trying to gain as part of the career pivot.
The Devops Stuff.
The only thing that is career adjacent to all the stuff I did as a sysadmin and then consultant. So hopefully lots of boring stuff about exciting tech as I try to build new mental models, to fit over old ones.

Problem though, is what do I write?
I don’t have a good spin on most computer devops stuff. I don’t know what to say.
So for now, they probably will be, just like I point above, boring progress logs.
Mostly consistent, to give me accountability.
And hopefully, I’ll find a voice.

On the personal front, books, reading, art, language, poetry, photography and other posts will continue. Those are what make my soul sing :)

After which I go to the file which needs to contain my link, and select my text that I’ll want converted into a link (“inserting a link” in org speak. In my case, the top file in the screenshot below).
I select the Misc Brain Dump part of the “Look at the Misc Brain Dump” task and hit
C-c C-l
It then switches me to a buffer that shows the links that Org currently has stored, with the minibuffer prompting me to choose one

I use the arrow keys to choose the one I want, hit return and it creates the link for me.

Here, I’ve switched away from my brain dump. (I’ve closed the file in fact)

I click the link in my tasks file and …

It opens right up, at the exact location I want. Woohoo!

And just like everything else with Org, it’s plain, simple, elegant, text functionality.
I examined the link and it was a borg standard Org link, with the link having the header tacked on the end, like so …
file:brain-dump.org::*Misc Brain Dump¹

And now after close to two years, I’m moving off Jellyfin to Emby.
The only reason being its iOS client.
It still has a lot of growing up to do, and I’ve reached the end of my tether trying to adjust to its foibles.
I cannot turn the phone off, else the music goes off.
I cannot switch away from the Jellyfin app, else the music goes off.
If I get a call, then the app sorta-kinda loses its mind and I have to kill it and relaunch it.

All I want from my music player is to be a good audio citizen on iOS. Connect to the server, read my songs, play my music. And do it in the background.

While I am sympathetic to the priorities of the open source Jellyfin team, I am not getting any younger and my hour long walks are the only time I get to enjoy my music.

So … I moved.

Setting the stage

• There had to be two instances of Emby running. I don’t want my video online and so I don’t want it exposed
• Video is secondary anyway. So that had to be the second container. The main one is Music.
• Music needs to be accessible from anywhere on the web.

Doing it

• I already had docker running and installed, along with Nginx
• Jellyfin has better documentation. So I used their guide to reverse proxy Nginx to the Emby service that would come up. All I had to do, was put in my SSL cert paths correctly and change the variable jellyfin to embymusicserver (along with the rest of the require settings.)
• I created a folder to hold Emby’s docker compose file. I modified the container name to embymusicserver and gave the path to mount for its config and another one that pointed to my music folder. Pretty straightforward. (I had already changed the ports earlier on the video emby instance to 8097 & 8921 to avoid conflicts with Jellyfin, so I did not have to touch that.)
• Assigned ownership recursively to the user that would run the container.
• Did a docker compose up to see if everything came up ok. And then tore it down
• And finally, once again, adapted my old Jellyfin systemd script to ensure I could have it start and stop with the system

In hindsight, there was no way to pull all of this off in an hour, if it wasn’t for Docker and Emby’s image. Now I realise why containers are taking over the world.

And thank you for all you do, Jellyfin. I shall return as soon as the app gets more useful.

I’ve been using Pedro Santana’s, nifty little Nemo action to help me do just this.
Once installed, all I need to do is select my files, right click on them and then create a new folder, like so …

The one remaining wrinkle, being that when you’re completely keyboard driven, you still need to come down a couple of steps with the arrow keys or switch to the mouse.
When doing this with close to 250+ files, this quickly gets tedious.
Stack Overflow to the rescue.

Turns out that all I needed to do was add an _ in front of the letter, I wanted to use to activate my little action from the context menu.
My original action went …

[Nemo Action]

Active=true

Name=Create new folder with selection 
...

I decided to use the n in selection. N for new folder. Easy to remember! So with this tiny change …

Name=Create new folder with selectio_n 

I get to do this!

I can select, get the context menu, hit n, type in the folder name and done!
It’s still a lot of work when there’s lots of files, but there’s a seamless flow to the entire process.