Thomas Williams blog

Mermaid diagrams for Jekyll

2026-05-10T02:00:00+00:00

Mermaid https://mermaid.ai/ is “Markdown inspired” diagrams as code. With the diagram defined as text, special/proprietary software isn’t needed to create or edit diagrams. The text defining the diagrams can be edited by anyone - so can be kept up-to-date. Diagrams can also be version controlled, like any other code.

This matters because better diagrams improve documentation, and communication.

Mermaid supports a lot of different diagram types (flowcharts, Gantt charts, mindmaps, and org charts, among others). Mermaid syntax is supported in Confluence, GitHub, VS Code, MediaWiki, and more.

If you don’t want to fiddle with text, there’s online, free tools to visually create diagrams, which can then be exported to Mermaid syntax (though be aware, there’s perhaps not the level of fine-grained control that might be expected using afore-mentioned proprietary software like Visio or https://app.diagrams.net/, which is a trade-off for the simplicity of text).

Here’s a simple example of a flowchart diagram in Mermaid. The code block below results in the diagram underneath:

```mermaid
flowchart TD
  A(["Normal text and unicode characters 👤 ★"]) --> B("<strong>HTML</strong><br><em>format</em>")
  B -.-> C["`Or **Markdown** _format_`"]
  D@{ shape: text, label: "<small>See full syntax at <a href=https://mermaid.ai/open-source/syntax/flowchart.html>https://mermaid.ai/open-source/syntax/flowchart.html<a></small>" }
  style A stroke-width:2px
  style C fill:#FFE97F,stroke:#fc0,stroke-dasharray:3,color:#333
```

flowchart TD
  A(["Normal text and unicode characters 👤 ★"]) --> B("<strong>HTML</strong><br><em>format</em>")
  B -.-> C["`Or **Markdown** _format_`"]
  D@{ shape: text, label: "<small>See full syntax at <a href=https://mermaid.ai/open-source/syntax/flowchart.html>https://mermaid.ai/open-source/syntax/flowchart.html<a></small>" }
  style A stroke-width:2px
  style C fill:#FFE97F,stroke:#fc0,stroke-dasharray:3,color:#333

I use these sort of diagrams for quick, high-level system architecture. Rendered in a browser, text in the diagram is selectable and links can be clicked.

Of course, there’s a lot more than can be done with regards to styling & font, layout, dark mode etc. In the flowchart above, I use single upper-case letters to refer to “nodes”, with the displayed text separate (which makes connecting, referencing and styling nodes easier).

Some other useful Mermaid flowchart styling:

dotted lines on nodes: style <node> stroke-dasharray:3 (or even dots and dashes, see https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Attribute/stroke-dasharray)
node text color: style <node> color:<hex color code>
node background color: style <node> fill:<hex color code>
node border width: style <node> stroke-width:<number><unit e.g. "px", "pt">

Here’s how to add Mermaid to a Jekyll blog, based on https://stuff-things.net/2025/01/19/mermaid-diagramming-in-jekyll-in-2025/:

create a new file mermaid.html in the _includes directory
put the following code into mermaid.html:

<script type="module">
  /* latest version of Mermaid diagrams
     adapted from https://stuff-things.net/2025/01/19/mermaid-diagramming-in-jekyll-in-2025/ */
  import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid/dist/mermaid.esm.min.mjs';
  /* initialise Mermaid */
  mermaid.initialize({ startOnLoad: true, theme: 'default' });
  /* run Mermaid on the page, looking for code blocks with the class 'language-mermaid' */
  await mermaid.run({
    /* specify the CSS selector for Mermaid code blocks
       by default, Mermaid looks for elements with the class 'mermaid', but thanks to Jekyll there's
       "language-" in front when using triple-backtick code blocks */
    querySelector: '.language-mermaid'
  });
</script>

add the following lines to your Jekyll HTML head template (mine is in a file called head.html):

<!-- if "mermaid" flag is true, include snippet -->
{% if page.mermaid %}{% include mermaid.html %}{% endif %}

in the front-matter for a post, add the following to enable Mermaid:

mermaid: true

With the above in place, you can define a Mermaid code block in a blog post, and it will be rendered as a diagram.

Ten years of blogging

2026-05-03T02:00:00+00:00

Ten years ago, I started this blog.

It’s my third or fourth blog - in 2010, I retired my personal blog https://thomasswilliams.blogspot.com as well as my second technical blog on abandoned site “TheRuntime”, now only on archive.org (side note: 2010 was a busy year, I started studying a Masters degree).

In 2016 I started this blog with the aim to write at least one post a month.

Ten years on, I’ve written nearly 100 posts. I took a break between 2023 and 2025 as work was super-busy. But I always planned on coming back and documenting what I’d learned, in the hope that it could be a reference point for me, outlasting specific jobs, as well as help others.

The posts I’m most proud of are a series on learning R Markdown (Markdown and R code for data visualisation and interactive reports), a series on learning Leaflet (web-based map tiles with an Antarctic twist), my home networking evolution, and random developer & IT bits and pieces that reflect me - a curious learner.

There’s also tons of DBA-related posts from the day-to-day operational level, to the long-term view and product ownership level, that mirror my career journey.

I’m a firm believer that the act of writing is the best way to prove and improve writing quality. Writing as a skill is critical, and technology and computing are more exciting and dynamic than ever.

I hope to continue - as I have over the past 25 years of working in IT - documenting/clarifying/reflecting on whatever platform, for another 10 years.

#30DayChartChallenge: Trend change detection in R, from Strava runs

2026-04-25T02:00:00+00:00

This is my entry for the 2026 #30DayChartChallenge https://bsky.app/profile/30daychartchall.bsky.social; day 26 is all about trends.

I wanted to understand: when do trends change? So, based on a hunch and using Strava data, I fired up RStudio and set to work (Claude and ChatGPT helped with the code, especially the Strava API stuff).

The resulting R Markdown file and instructions are on GitHub, ready to plug in your Strava client ID and secret: https://github.com/thomasswilliams/r-strava-2026

TLDR: the R package “RegimeChange” provides detection of trend changes using a variety of approaches. I used the Pruned Exact Linear Time (PELT) default algorithm. Read on for the full story, or take a sneak peek at the chart, generated using Plotly (the red horizontal lines are the trend changes):

I don’t record all my runs in Strava, but runs over the last few months have felt faster and I hoped the data would reflect this. After a slow patch with an injury in mid-2025, I upped my running regularity to twice weekly (now, three times) and didn’t have much of a break during the Aussie summer in January 2026.

Back to the chart challenge: inspired by a Nicole Rennie post https://nrennie.rbind.io/blog/2022-07-18-mapping-a-marathon-with-rstrava/, my first step was gathering and filtering the data from the Strava API for the last 2 years. The 2-year timeframe should give enough data points to identify trends. I’m using just the first 5KMs of runs which are at least 5KM long, marked as a “run” in Strava, and have a 5KM time not slower than 50 minutes (e.g. faster than a walk). Variables are defined at the top of the code; to follow along (with RStudio and a Strava client ID and secret, easy to obtain even for free Strava users), open the R Markdown file in RStudio, install any missing libraries, enter your Strava client ID and secret on lines 54 and 55, then click Knit.

On the first knit you’ll be prompted to open a browser window and authenticate with Strava. Depending on your settings, the knitted HTML file will appear in RStudio’s viewer. It can then be opened in a web browser too.

I found the “RegimeChange” package simple to use and well documented, following the example from https://cran.r-project.org/web/packages/RegimeChange/vignettes/introduction.html, with the default algorithm. The raw analysis from detecting trend changes is included in the HTML output. In my case, two distinct trend “segments” were detected - a mean of 8 minutes, 53 seconds per KM up to March 2026, and a mean of 7:51 per KM since then. Exciting progress! And matches with how I thought my pace had potentially improved.

Over a few more iterations, I tidied up the chart, adding a moving average and tooltips, and also cached data from the Strava API to avoid hitting limits and speed up knitting (probably still needs work).

I had fun participating this year’s #30DayChartChallenge. I’m interested in how trend detection might work for other datasets. Hopefully others can use my code to detect trend changes in their own Strava data.

Improving R linting (2026 update)

2026-04-15T01:00:00+00:00

Linting helps catch potential issues in code before they cause problems, and helps keep coding style consistent, whether for yourself or as part of a team or project. Linting uncovers surprising issues: recently, I added lints which caught that I was passing the same parameter by name twice in a call - meaning one of the parameter values was silently ignored.

Previously, using lintr for R, I specified only lint rules I wanted (whitelist). Now, I include all lint rules, and then tune (or disable) rules I don’t care about (blacklist).

This has the advantage that, if new rules are added, running lintr would automatically includes the new rules.

My lint configuration is below. It suits my style when coding in R: explicitly scoped function calls preceded by name of library (e.g. “DT::renderDataTable” over “renderDataTable”), libraries loaded at top of each script for portability and reproducibility, spaces instead of tabs, double quotes for strings, line lengths less than 120 characters for readability, and more.

lintr is pretty particular about lint config file formatting, and will error if the config file isn’t correct. Don’t forget to leave a blank line at the end of the file.

To lint your R code from RStudio, install the lintr package, create a config file .lintr and add rules (or copy-paste my lint rules below), then run from the R console either lintr::lint(filename = "<file name>.Rmd") or lint the whole directory with lintr::lint_dir(). See the full lintr documentation at https://lintr.r-lib.org/reference/.

My .lintr file as at 2026:

linters: all_linters(
    # use all lint rules - customise some, and disable others (see below)
    # see linter details at https://lintr.r-lib.org/reference/index.html
    # --------- customised linters ---------
    # line lengths should be less than 120 characters
    line_length_linter(120L),
    # check for unused imports
    # allow packages referenced for namespace (e.g. pkg::function)
    # always allow dplyr
    unused_import_linter(
      allow_ns_usage = TRUE,
      except_packages = c("dplyr"),
      interpret_glue = TRUE
    ),
    # variables should be snake case
    object_name_linter(c("snake_case", "SNAKE_CASE")),
    # assignment should use specific operators (not equal sign)
    assignment_linter(
      operator = c("<-", "<<-", "%<>%")
    ),
    # consistent pipes
    pipe_consistency_linter(pipe = "auto"),
    # ---------- disabled linters ----------
    # lint rules are disabled by setting them to NULL
    # allow "stop" calls, used in Rmd database connection errors
    condition_call_linter = NULL,
    # not cyclomatic complexity
    cyclocomp_linter = NULL,
    # allow relative paths (expected by some of the javascript libraries)
    nonportable_path_linter = NULL,
    # allow "paste" and "paste0"
    paste_linter = NULL,
    # allow comparisons to empty strings for readability
    nzchar_linter = NULL,
    # allow one pipe commands
    one_call_pipe_linter = NULL,
    # allow redundant calls to "== TRUE" for readability
    redundant_equals_linter = NULL,
    # turn off "trailing blank lines"
    trailing_blank_lines_linter = NULL,
    # allow calls to "library" (helps with portability)
    undesirable_function_linter = NULL
  )
encoding: "UTF-8"

Linting can be ignored for specific lines of code. For example, if there’s a line of code longer than 12 characters, add # nolint: line_len to the end to have it ignored by lintr.

Going further: linting for R has room to improve. By comparison, linting in Python is a little more mature, and some issues can be automatically fixed.

There’s the possibility of better linting with LLMs, such as assessing metrics for code like complexity & readability, and perhaps new metrics that don’t exist yet. LLMs could (potentially) suggest better, newer ways to achieve the same outcomes, while still keeping consistency to a preferred style or team norms.

In any case - good luck with linting and finding those tricky issues!

Different SSH keys for different purposes

2026-04-06T01:00:00+00:00

I have different SSH keys for different purposes - one for GitHub, one for GitLab, Azure SSH, other servers etc. Keys for different accounts too - work or personal. Some Git hosting sites allow SSH keys for signing commits; a signing SSH key can be different than the authorisation SSH key.

Reminder: an SSH key is basically you. If someone has access to an SSH private key, they can impersonate you, and systems can’t tell the difference. SSH keys aren’t the problem, they’re great - but need to be secured, and differentiated. This post is about the latter.

Having specific keys helps with exposure if a key is copied without your knowledge, or decrypted, as well as rotating. Rotating SSH keys is considered best practice, and having a key that’s limited in scope makes it easier to rotate over a single key that accesses, well, everything.

Here’s how I do different SSH keys for different purposes, on Linux or Mac, as at early 2026.

But first:

naming: I suggest naming the key with it’s purpose and the year created, as well as the algorithm
passphrase: SSH keys should be protected with a passphrase, with the passphrase being different than your password

An example of creating a specific, named SSH key

As an example, I’ll generate an SSH key for Codeberg (a new, free Git hosting site) by running the following command:

ssh-keygen -t ed25519 -f ~/.ssh/codeberg_ed25519_thomas_williams_2026 -a 100 -C "Thomas Williams <https://codeberg.org/thomasswilliams>"

the key will use the “ed25519” algorithm, a strong algorithm recommended by Codeberg, Mozilla, GitHub and others (see this excellent guide at https://infosec.mozilla.org/guidelines/openssh, as well as other references at the bottom of this post)
the key will have a meaningful name - don’t leave it blank which will use the default name, potentially overwriting/destroying existing keys
I use my profile URL as a comment (I could use my e-mail address)
-a is rounds of derivation, making the key harder to brute-force

I enter a passphrase when prompted. If everything goes right, I now have two new files in my ~/.ssh directory “codeberg_ed25519_thomas_williams_2026” (private key) and “codeberg_ed25519_thomas_williams_2026.pub” (public key).

As there are now multiple keys in my ~/.ssh directory, I can specify which site or server uses which key in the ~/.ssh/config file as per https://stackoverflow.com/a/4246809. Doing this means I don’t need to pass the key file name to SSH commands:

# Codeberg
Host codeberg.org
  # for the specified host
  HostName codeberg.org
  # always uses "git" user
  User git
  # specify the key file for Codeberg
  IdentityFile ~/.ssh/codeberg_ed25519_thomas_williams_2026

I also need to add the public key part of the new SSH key to Codeberg - see their help at https://docs.codeberg.org/security/ssh-key/.

Once I’ve added the key to Codeberg, I can test that it works from a command line:

ssh -T git@codeberg.org

(If you have issues, make sure the ~/.ssh/config file is set to user read-write only, with no other access, by running: chmod 600 ~/.ssh/config. It may be worth reviewing permissions on ~/.ssh and ~/.ssh/authorized_hosts, as incorrect permissions can be a common cause of login problems.)

Because this key will be used for Git operations, I can also tell Git on a per-repo basis about the key, running the following from a command line in the repo directory:

git config core.sshCommand "ssh -i ~/.ssh/codeberg_ed25519_thomas_williams_2026"

Don’t forget to back up your SSH keys (password managers are a good option to do this to). Happy - and secure - SSH keying!

References:

Personalising a Linux command line (part 3)

2026-03-28T01:00:00+00:00

Over the last few posts I’ve outlined what I do when I first get access to a Linux server, changing settings so I’m comfortable (see part 1) and installing packages to become more productive (part 2).

Oh My Posh

For an even better prompt, I’m a fan of “Oh My Posh” https://ohmyposh.dev/. Once installed, my prompt looks like below, shown in a Python Git repository directory - with the Oh My Posh prompt displaying my username, the directory name, the Git branch and files needing commit, the current Python version (because I’m in a Python project directory with uv), and lastly the time it took to complete the previous command and whether the command was successful:

Other sections of the command prompt are hidden and shown as needed, depending on whether you’re in a Python, Node or other directory. There’s probably further surprises in the prompt I haven’t yet come across.

Here’s how I set it up:

save the install shell script from https://ohmyposh.dev/install.sh and run it in one command: curl -s https://ohmyposh.dev/install.sh | bash -s
install a nerd font with glyphs (for example, Meslo from https://www.nerdfonts.com/font-downloads) on the computer running your terminal software
pick a theme: I downloaded “jandedobbeleer.omp.json” from https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/jandedobbeleer.omp.json and saved it in my home folder (or you can copy-paste the contents from the web into a file with that name)
load Oh My Posh by adding to the end of .bashrc (on Mac) or .profile (Linux):

# run oh-my-posh and load local config file "jandedobbeleer.omp.json"
eval "$(oh-my-posh init bash --config ~/jandedobbeleer.omp.json)"

There are complete instructions for Windows, Mac and Linux - including all the myriad shells - at https://ohmyposh.dev/docs/installation/customize.

Now when I next log in, my prompt is extra-functional and futuristic!

(Hat tip to my original inspiration, in 2021, of Scott Hanselman’s post at https://www.hanselman.com/blog/my-ultimate-powershell-prompt-with-oh-my-posh-and-the-windows-terminal. Plus, there’s other alternatives too - such as Starship https://starship.rs/ or Oh My Zsh https://ohmyz.sh/.)

Closing thoughts

That’s it for now, for customising my Linux command line. A little effort can go a long way! Hopefully you found something of use; good luck with your own customisations, and let me know via a comment or on Bluesky of anything you do to Linux servers you manage.

The last two “Linux personalisations” things didn’t really fit with my other posts, so I’m tacking them onto the end:

Patching

Patching on an Ubuntu Linux server happens in 2 stages:

update sources: sudo apt update
upgrade packages: sudo apt upgrade -y

To upgrade between minor versions (like I needed to do recently, upgrading from Ubuntu 25.04 to 25.10), run sudo do-release-upgrade.

Terminal screensaver

OK, this is not a “must-have”, but lately I came across terminal screensavers. They’re a wonder of clever coding and animation, implemented as shell scripts. I particularly liked the “Matrix” screensaver at https://github.com/attogram/bash-screensavers/blob/main/gallery/matrix/matrix.sh. CTRL+C quits, and COMMAND+K clears the screen (at least it does on iTerm on a Mac, the key combination might vary depending on which terminal software you use).

Personalising a Linux command line (part 2)

2026-03-22T01:00:00+00:00

In my last post, I customised my Linux command line with 4 dotfiles. Putting the time into finding my way around the command line, and learning Linux commands, becomes more important on a Linux server because there’s no GUI.

I’ll continue tweaking in this post by modernising two classic commands I use daily, and adding two helper packages.

In part 3 I’ll tackle the big one: a super-powered prompt.

highlight

The highlight package prints the contents of a file to the command line, with automatic syntax coloring. Install highlight by running sudo apt install highlight. Then, add the below to the end of .bashrc to replace calls to cat with highlight:

# replace cat with highlight as per https://stackoverflow.com/a/27501509 (needs "highlight" installed)
if [ -f /usr/bin/highlight ]; then
  alias cat="highlight -O xterm256 --force"
fi

Make the change take effect immediately by running source ~/.bashrc.

Now, when I view a file with cat, I get colored syntax.

You can still run commands you’ve aliased on Linux by starting the command with a backslash “\” - for example, to run the original cat, type \cat.

eza

eza is a better directory listing. Following the directions at https://github.com/eza-community/eza/blob/main/INSTALL.md, I download from https://github.com/eza-community/eza/releases (ensuring the right architecture, in my case aarch64), unzip the download, copy the unzipped eza executable to my home directory, then run from my home directory:

To copy files, I use an SCP program, either WinSCP https://winscp.net/eng/download.php for Windows or MacSCP https://github.com/macnev2013/macSCP on Mac.

# make the downloaded file executable
chmod +x eza
# create the directory ~/.local/bin
mkdir -p ~/.local/bin
# move eza executable to ~/.local/bin
mv eza ~/.local/bin/eza

Lastly, I add to my .bashrc, below everything else:

# replace ls with eza, expects eza installed at below location
# change the parameters to suit - the set below shows hidden files, in long format,
# with color for different file types and icons too
if [ -f ~/.local/bin/eza ]; then
  alias ls='eza -lhag --color=always --group-directories-first --icons'
fi

As a result, when I list the contents of a directory with ls, I see the following output from eza:

The alias parts above are entirely optional, I use them as it saves me remembering another command.

Something else I like to do - as I come from Windows - is make directory navigation with cd case-insensitive. I do this by adding the line below to the bottom of .inputrc in my home directory, adapted from https://askubuntu.com/a/87066:

set completion-ignore-case On

fastfetch

fastfetch (https://github.com/fastfetch-cli/fastfetch) is a utility that does one thing - shows system information. I install it with sudo apt install fastfetch, then run it with fastfetch. On my Linux VM, I get the following:

I’ve found it helpful to have all this information in one place.

ncdu

ncdu is slightly different than the other packages in this post, as it’s an interactive console for file/directory sizes, similar to Treesize or WinDirStat on Windows.

Either download the right version from https://dev.yorhel.nl/ncdu, or install with sudo apt install ncdu. Run, showing percents, in KB/MB/GB (rather than KiB/MiB/GiB), and in dark mode:

ncdu --show-itemcount --show-percent --si --color=dark /

I use ncdu to identify space used. With ncdu running, browse the file system using the arrow keys and enter to move between directories; show help with “?”, and finally quit with “q”.

That’s it for part 2 - part 3, next, is where I power up my prompt.

Personalising a Linux command line (part 1)

2026-03-15T01:00:00+00:00

Most of the work on a Linux server happens at the command line. So, getting to know the Linux command line and ways to list, find, update, run, troubleshoot and manage programs is critical.

I customise my Linux command line to help standardise and modernise, and add functionality. I prefer unobtrusive background changes, incrementally tweaking over time. Although it can be time-consuming to research and incorporate new tools or ways of doing things, I’m often on the lookout for what others do via blog posts or lists like https://github.com/awesome-lists/awesome-bash, https://python.libhunt.com/, or https://selfh.st/weekly/ (to go even further, something like chezmoi at https://www.chezmoi.io/links/articles/).

This post is part 1 of quality-of-life changes I make when I first log in to a new Linux server. I primarily use bash (though I also have zsh set up on some machines):

.hushlogin
.inputrc
.vimrc
.bashrc

All these files live in my home directory - the starting directory when logging in. So, these changes only affect me.

Here’s what it looks like when I initially log in to a new Ubuntu 25.04 server:

.hushlogin

First, I hide the “banner” (that big wall of text in the screenshot above) when I log in by creating an empty file called .hushlogin in my home directory, from the command line:

touch .hushlogin

This is slightly better - next time when logging in, I’ll go straight to a prompt.

.inputrc

I use .inputrc for two minor tweaks to the command line: better history autocomplete, and clearing the current input. With the changes in place, if I start typing a command then press the up or down arrow key, the history will autocomplete based on what has been typed so far e.g. typing “vi” and pressing up arrow will go through the history of previous “vi” commands. Pressing ESC (the escape key) will clear the current line (I keep forgetting the real shortcut to do so).

I create .inoutrc in my home directory if the file doesn’t exist. I need to log out and back in again so it will be picked up. Edit with vi e.g. vi .inputrc:

# Respect default shortcuts.
$include /etc/inputrc

## arrow up
"\e[A":history-search-backward
## arrow down
"\e[B":history-search-forward
## esc = clear whole line
"\e": kill-whole-line

Once the above is copy-pasted to vi, I save the file by pressing ESC, then entering “:wq” (without the quotes).

.vimrc

Speaking of vi, I tend to use it because it’s always there, whether I’m using Ubuntu, Red Hat Linux, Debian, or even Solaris. My basic standard is to enable syntax highlighting.

Once again, I create .vimrc in my home directory if the file doesn’t exist and edit using vi (e.g. vi .vimrc):

syntax on

There’s plenty of references for .vimrc, for example https://linux101.dev/vim-editor/configure-vimrc/.

.bashrc

A lot can be done in .bashrc. I add the code below after whatever’s already in .bashrc (out of the box, the Ubuntu .bashrc is fairly comprehensive):

# set prompt, green username followed by blue current path
# based on Ubuntu default
PS1='\n[\[\033[01;32m\]\u@\h \[\033[01;34m\]\w\[\033[00m\]]\$ '

# ignore pwd, exit, quit, q etc. commands in bash history
HISTIGNORE="pwd:exit:quit:q:history:cls"
# add timestamps to history file (makes it easier to place certain commands on a date)
# doesn't affect arrow keys or "history" command
HISTTIMEFORMAT="%F %T "
# don't put duplicate lines or lines starting with space in the history
HISTCONTROL="ignoreboth"

# write to history immediately (not on logout) thanks to https://www.cherryservers.com/blog/a-complete-guide-to-linux-bash-history
PROMPT_COMMAND='history -a'

# don't write LESS history
export LESSHISTFILE=-

# increase history
HISTSIZE=5000
HISTFILESIZE=10000

After I’ve saved my changes to .bashrc in vi, back on the command line I run source ~/.bashrc to make the changes to .bashrc take effect straight away without needing to log out and back in.

My command line now looks a little cleaner with very little effort.

Personalising the Linux command line as I’ve demonstrated is simple and does not impact other users. In part 2, I’ll go further and change the directory listing command, the default “write a file to the screen” command called cat, and a couple other things - stay tuned.

Dockerizing R Markdown/Shiny

2026-02-27T01:00:00+00:00

I’ve been a fan of R Markdown (and Shiny) for nearly 3 years, and have written about it here on my blog many times. R Markdown is my go-to for analysis and reports that need anything more than a simple table.

Running R Markdown via Docker is a big help with deploying those analysis and reports for others to use.

While there are alternatives for deploying R Markdown — the most popular being Shiny Server — they add the hassle of matching R and package versions to the machine where the code was developed, may require IT help, and mean sharing disk, CPU, and memory with other apps on the same server. And there’s also licensing requirements & limitations for the free version of Shiny Server.

R Markdown on Docker avoids some of these issues; a single Docker container = a single app.

In this post I’ll go over running an R Markdown page in Docker called debug.Rmd that lists the R version, as well as installed packages & versions.

In a new directory, for example “r-markdown-docker-test”, create debug.Rmd as per below:

---
title: "debug.Rmd"
output: html_document
runtime: shiny
---

``` {r global, echo = FALSE, message = FALSE, warning = FALSE}
# load packages
# sessioninfo: R Session Information
# https://github.com/r-lib/sessioninfo
library(sessioninfo)
# details: R Package to Create Details HTML Tag for Markdown and Package Documentation
# https://github.com/yonicd/details
library(details)
# dplyr for piping with "%>%"
library(dplyr)
```

```{r, echo = FALSE, comment = NA}
# initially expanded environment and package versions from sessionInfo()
# requires "sessioninfo" and "details" packages
# adapted from https://cran.r-project.org/web/packages/details/vignettes/sessioninfo.html
sessioninfo::session_info() %>%
  details::details(open = TRUE)
```

You can find the complete code on GitHub at https://github.com/thomasswilliams/r-markdown-docker-test.

Running debug.Rmd from RStudio (after installing required packages) results in something like (on an M1 Mac as at Feb 2026):

Bringing in Docker

Now let’s Dockerize the R Markdown file (or any number of files in a folder), which requires Docker, naturally.

The Dockerfile below:

pulls the base Rocker Shiny Docker image (I experimented with a base R image and installing Shiny - it’s a lot of work, simpler to use rocker/shiny)
installs required packages (add whatever packages needed for R Markdown files e.g. DT, highcharter, bslib etc.)
copies R Markdown files from the current directory to the Shiny Server base directory in the container
- since only R Markdown files are copied, I didn’t bother with a .dockerignore file; suggest adding for R Markdown projects which include separate javascript & CSS files, images etc.
switches to the “shiny” non-root user
runs Shiny

# base R Shiny image, latest
FROM rocker/shiny

# install required R packages (Shiny already present)
RUN R -e "install.packages(c('dplyr', 'rmarkdown', 'sessioninfo', 'details'))"

# remove sample files from Shiny Server base directory
RUN rm -rf /srv/shiny-server/

# copy R Markdown files from this repo into Shiny Server base directory
COPY *.Rmd /srv/shiny-server/

# make use of in-built "shiny" user in image to run as non-root
# set permissions on copied files, so "shiny" user can read
RUN chown -R shiny:shiny /srv/shiny-server

# switch to the "shiny" non-root user
# when container runs, following commands run as this user
USER shiny

# expose Shiny port
EXPOSE 3838

# start Shiny Server (default)
CMD ["/usr/bin/shiny-server"]

Once the Dockerfile is saved in the project’s directory, alongside the R Markdown file, build the image from a command line in the same directory as Dockerfile:

docker build --platform=linux/amd64 --no-cache -t r-markdown-docker-test .

The built image can be run with:

docker run --platform=linux/amd64 -p 3838:3838 r-markdown-docker-test

With the container running, open a web browser to debug.Rmd at http://localhost:3838/debug.Rmd which will display something like:

Docker can be run on a server too; the built image can be outout to a tar file based on steps at https://www.howtogeek.com/devops/how-to-share-docker-images-with-others/.

An advantage with using Docker is being able to preview exactly what will be deployed, to make sure it works. It will run the same on your machine as any other. I’ve had times where a library version on Shiny Server was different to the development machine which caused a blank page to be shown, not even an error message - thus the original reason for debug.Rmd.

Hopefully this post gives options when planning to deploy R Markdown files.

Kerberos and SQL Server in 2026

2026-02-20T01:00:00+00:00

I spent a bit of time recently tracking down NTLM Event log warnings relating to SQL Server.

NTLM is an older Windows authentication protocol, largely superseded by Kerberos.

Kerberos is used when certain conditions are met; otherwise, Windows authentication silently falls back to NTLM. This is important in 2026 because Microsoft has announced that new versions of Windows desktop and Windows Server will no longer support NTLM.

I’m not the only DBA following up on NTLM - last week I read a blog post covering NTLM, Kerberos, and Service Principal Names (SPNs) at https://www.sqlfingers.com/2026/02/microsoft-is-killing-ntlm-heres-what.html (via Kevin at Curated SQL).

To ensure clients connect to SQL Server using Kerberos:

SQL Server must run under a domain account (the same account on all servers, if using Windows Clusters)
connections must use host names, not IP addresses
the client driver must support Kerberos
if using Availability Groups, two SPNs must be created manually for the Availability Group Listener like:

setspn -S HOST\<Availability Group Listener>:1433 <SQL Server domain account>
setspn -S HOST\<Availability Group Listener>.domain.name:1433 <SQL Server domain account> # FQDN

The second SPN creation command is for the Fully-Qualified Domain Name (FQDN) for the SQL Server Listener. You’ll need both, and the commands should be tweaked for your environment (and port). Say the SQL Server domain account is MYDOMAIN\SqlProd, and your listener is SQL-2022-LISTEN, the commands would look like:

setspn -S HOST\SQL-2022-LISTEN:1433 MYDOMAIN\SqlProd
setspn -S HOST\SQL-2022-LISTEN.mydomain:1433 MYDOMAIN\SqlProd # FQDN

That covers clients connecting to SQL Server. But what about servers SQL Server connects to?

Backup

If you back up databases over the network (and you should), SQL Server may authenticate using NTLM.

You can see this by enabling NTLM Event logging on your backup server in the registry by adding a DWORD AuditReceivingNTLMTraffic and setting the value to 1 under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 as per https://dirteam.com/sander/2022/06/15/howto-detect-ntlmv1-authentication/. Then, use Event Viewer and look for warnings under Microsoft > Windows > NTLM > Operational.

In my case, NTLM was being used because the backup server was referenced via a DNS CNAME. The fix was for a domain admin to manually register two SPNs for the CNAME, under the host:

setspn -S HOST\<CNAME> <host/target>
setspn -S HOST\<CNAME>.domain.name <host/target> # FQDN

For example, if my CNAME is backup, and the server the CNAME is pointing to is FILESERVER1, the commands would be:

setspn -S HOST\backup fileserver1
setspn -S HOST\backup.mydomain fileserver1 # FQDN

It may take some time for SPN changes to propagate through the domain (in my case, around 25 minutes).

You can list the SPNs, including the manual ones for CNAMEs, belonging to a host with:

setspn -L <host/target> # e.g. fileserver1

Alternatively, you can query for the SPN for the DNS CNAME using:

setspn -Q HOST\<CNAME>.domain.name # e.g. HOST\backup.mydomain

If the backup server changes and the CNAME is repointed, the SPN will need to be removed and recreated to maintain Kerberos authentication.

The other SQL Server–related NTLM warning came from a file share witness used by an Availability Group. Once again, a CNAME was in use, so the fix was the same - create two SPNs for the CNAME, one with the FQDN:

setspn -S HOST\<CNAME> <host/target>
setspn -S HOST\<CNAME>.domain.name <host/target> # FQDN

With those two issues resolved, there were no further NTLM warnings related to SQL Server.