Skip to content

Blog

New Year, new.. services?

While the Holiday season was a time filled with family joy, it was a busy time. Between packing presents and driving home for Christmas there was little time to work on projects. Such as this blog.

I took a longer than expected break from computers. And you know what? It was great! Taking care of my family and giving them the time they deserve was very fulfilling. I do like my role as husband and father.

Now that we all got back to work and Kindergarten, I started once again thinking about hobby-stuff. I do provide four services that require login to family. This number won't shrink. What is a better time to implement Single Sign-On than now? Well, yesterday of course! That's why I stood up a Keycloak instance and secured my first app with it. Setting up a docker-compose.yml wasn't as straightforward as I expected. This was the part that took me the longest. The examples are out of date and the official documentation does not provide the necessary bits in one place.

Eventually I pieced it all together, cherry picking parameters and variables from various places. After that, configuration was maybe not a walk in the park, but a much more pleasant experience. I followed the official guide and set up a child realm and client, the client being the webapp.

Basically its:

  1. Put Keycloak realm URL, client ID and secret into webapp

  2. Put link to webapp into Keycloak

Congratulations! You now can log-in to the app using SSO. If only it were this easy.. Now the accounts got merged? Squashed? Yes, based on the Username field in Keycloak, my admin account to the webapp got demoted and I no longer can log in using the old password. Word of caution here to anyone trying this at home. Do. Make. Backups!

I started the migration to SSO with the most recent app added to the homelab as it didn't hold any valuable data yet. I did it haphazardly, one might say I yolo'ed it, but in doing so I quickly discovered what the next steps will be:

  1. Revise the backup strategy (oh God why haven't I done it already?)

  2. Test disaster recovery

  3. Configure accounts carefully, with all required roles set in advance

  4. Migrate the less important apps to SSO

  5. After that, and ONLY after, enable SSO for immich and paperless-ngx

Progress was made. But why the heck does mkdocs render lists differently than Kate or Obsidian?!

A small update

This time I have set out to achieve two small things. I wanted my blog to feel a little bit more personal with a logo and favicon and on the rare occasion where I would like to share a link to this page, I would like to see those nice looking "cards" with title, short excerpt and picture, not an error message about some Open Graph info missing. Yes, I've learned today that Open Graph exists.

I fixed both things. I will, full of shame, admit that I have used an LLM to generate a basic icon/logo which I touched up in GIMP. The generation process was frustrating, though. The "AI" spat out unappealing graphics most of the time. You could immediately tell it was generated, be it style or plain retardation of the imagery.. Was it faster or better than just using an existing design from an icon pack? I am not sure, but no time savings were made.

My second issue was resolved by activating the social plugin and modifying the pipeline to install additional dependencies before building the site. After adding the site_description social cards started appearing properly when linking to my site. What I am missing from the mkdocs-material documentation is a clear indication where I need to put the Open Graph meta information for all pages inside my project. In posts I just yolo'd it and put description: beneath date:, but setting this manually for every blog post is not sustainable in the long run.

There probably is an automated way to make the description be the first paragraph of the post. I just haven't found it yet.

First milestone

Today marks a small but important milestone. The site got published!

I have set up repository mirroring and use GitHub Pages to serve it on my custom domain. I had to create the CNAME file inside my docs_dir for it to work, but it was all described in the documentation.

If for some reason GitHub goes down, the site is also published to GitLab Pages at random-string.gitlab.io. I can easily point my domain overe there if needed.

A few days later

I forgot how to git already. Getting back into my blog project took some time and a lot of willpower. I used a few evenings figuring out a new way for backups. I have learned how to manage BTRFS subvolumes and set-up automatic snapshots of /home and /mnt/dane.

In the future I plan to move my server's partitions from XFS to BTRFS and take advantage of send/receive.

The beginning

Today I have managed to set up a repository and started working with git. I still have to wrap my head around branching. The next challenge will be putting this site on GitHub Pages. Later on I want to automate the deployment process in GitLab. Am I mad? Perhaps, but I will learn a lot. Or so I hope..