DEV Community: Lucy Llewellyn

Configure automatic NFS Persistent Volumes on Kubernetes K3s

Lucy Llewellyn — Wed, 04 Aug 2021 01:56:50 +0000

Using NFS persistent volumes is a relatively easy, for Kubernetes, on-ramp to using the Kubernetes storage infrastructure.

Before following this guide, you should have an installed Kubernetes cluster. If you don't, check out the guide how to Install K3s.

Setting up the NFS share

We will share a directory on the primary cluster node for all the other nodes to access. I will assume that you want to share a filesystem mounted at /mnt/storage-disk.

Install the NFS service:

   sudo apt update && sudo apt install -y nfs-kernel-server

Edit the file /etc/exports:

   sudo nano -w /etc/exports

Add a new line at the bottom with the following content:

   /mnt/storage-disk *(rw,sync,no_subtree_check,no_root_squash,anonuid=65534,anongid=65534)

Save and exit the editor with ctrl+x followed by y to indicate that we want to save the file and finally enter to confirm.
Load the configuration we just wrote into the NFS server:

   sudo exportfs -a

Install nfs client onto each of the other nodes

On each of the other nodes, we need the nfs client to be installed or pods will fail to schedule and start. On k8s-2 and k8s-3 run:

sudo apt update && sudo apt install -y nfs-common

Configuring the NFS provisioner

We could create a Persistent Volume and Persistent Volume Claim manually, but there's an automated method using a Provisioner. This is a special configuration that takes our NFS share and automatically slices it up into Persistent Volumes whenever a new Persistent Volume Claim is created up till the provisioned storage space is exhausted.

To install the provisioner we'll first get helm because it simplifies the installation inordinately!

Install helm on the primary cluster node:

   curl -fsSL https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash

Configure helm to access the provisioner repository:

   sudo helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/

Using helm install the provisioner:

   sudo env KUBECONFIG=/etc/rancher/k3s/k3s.yaml \
   helm install nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \
     --set nfs.server=k8s-1 \
     --set nfs.path=/mnt/storage-disk

There are many options that may be set with the --set flag. Each option must be supplied with their own --set option.name=value parameter pair. For the full list of parameters see the configuration section of the helm chart readme for the NFS provisioner.

Creating a test deployment to verify the provisioner

Now we will test that the provisioner is working by creating a test claim and a test deployment that uses the claim.

Create and edit a file called test-claim.yaml:

   nano -w test-claim.yaml

Paste the following content into the editor:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: test-claim
   spec:
     storageClassName: nfs-client
     accessModes:
       - ReadWriteMany
     resources:
       requests:
         storage: 1Mi

The apiVersion must be set to v1 so that K8s knows which fields are acceptible.
The kind must be PersistendVolumeClaim to inform K8s that we are creating a PVC.
The metadata.name entry is an arbitrary name for the PVC but we will use it to tie the PVC to the pod in the following steps.
The spec.storageClassName must be nfs-client because this is what the default installation using helm sets up.
The spec.accessModes should be a list with a single item of value ReadWriteMany.

The available access modes are:
- ReadWriteOnce -- the volume can be mounted as read-write by a single node
- ReadOnlyMany -- the volume can be mounted read-only by many nodes
- ReadWriteMany -- the volume can be mounted as read-write by many nodes
The spec.resources.requests.storage should be a number suffixed with Mi, Gi, or Ti indicating Mebibytes (1024*1024 bytes), Gibibytes (1024*1024*1024 bytes), or Tebibytes (1024*1024*1024*1024 bytes). E.g. 5Gi would equal five Gibibytes or 5*1024*1024*1024 bytes. If there is insufficient space in the NFS share then this PVC will stay in a pending state.

Save and exit the editor with ctrl+x followed by y to indicate that we want to save the file and finally enter to confirm.
Create and edit a file called test-pod.yaml:

   nano -w test-pod.yaml

Paste the following content into the editor:

   apiVersion: v1
   kind: Pod
   metadata:
     name: test-pod
   spec:
     containers:
     - name: test-pod
       image: gcr.io/google_containers/busybox:1.24
       command:
         - "/bin/sh"
       args:
         - "-c"
         - "touch /mnt/SUCCESS && exit 0 || exit 1"
       volumeMounts:
         - name: nfs-pvc
           mountPath: "/mnt"
     restartPolicy: "Never"
     volumes:
       - name: nfs-pvc
         persistentVolumeClaim:
           claimName: test-claim

The apiVersion must be set to v1 so that K8s knows which fields are acceptible.
The kind must be Pod to inform K8s that we are creating a pod.
The metadata.name entry is an arbitrary name for the pod.
The spec.containers field takes a list of container definitions:
- The name field is an arbitrary name for the container.
- The image field is the docker-compatible container image name. Here we are using a container hosted by google called busybox with version 1.24.
- The command field is the command to run inside the container when it is launched.
- The args field is a list of arguments to pass to the command specified above.
- The volumeMounts field is a list of mount definitions for inside the container.
  - The name field in the mount definition is the name of the volume as configured in .spec.volumes.
  - The mountPath field tells K8s where to mount the filesystem from the volume into the container.
The volumes field is a list of volumes to make available for containers within this pod.
- The volume name field is an arbitrary name that we use to reference in the .spec.containers.volumeMounts.name field.
- The persistentVolumeClaim.claimName field is the name of a PVC. We configured this in our test-claim.yaml file's .metadata.name field, i.e. test-claim.

Save and exit the editor with ctrl+x followed by y to indicate that we want to save the file and finally enter to confirm.
Apply the claim and the pod definitions to the cluster:

   sudo kubectl apply -f test-claim.yaml -f test-pod.yaml

The container should now download its image, run and exit. Left behind will be a new folder called /mnt/storage-disk/default-test-claim-pvc-* where the * is a UUID. Inside this folder should be a single file called SUCCESS indicating that the PVC successfully provisioned, mounted into the container, and the container was able to write a file.

Install and access the K8s Web UI Dashboard on a K3s cluster

Lucy Llewellyn — Wed, 04 Aug 2021 01:52:54 +0000

While I don't find the dashboard very useful for configuring anything in the cluster, it can be helpful to find a resource you've lost track of or discover resources you didn't know were there.

Before following this guide, you should have an installed kubernetes cluster. If you don't, check out the guide how to Install K3s

Installing the dashboard

To install the dashboard we need to run the following one command on the primary cluster node (in my example, this is k8s-1). K3s installations require the command be prefixed with sudo:

sudo kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.3.1/aio/deploy/recommended.yaml

This URL includes the version number, so you will want to double check that it is up-to-date when following the instruction. The latest version will show up at the K8s dashboard latest release page.

Creating the admin user

Accessing the dashboard requires that we supply a token to authorise ourselves. This account is not created by the command above.

On the primary cluster node create a file called dashboard.admin-user.yml with the following content:

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: admin-user
     namespace: kubernetes-dashboard

I recommend using nano to create the file:

   nano -w dashboard.admin-user.yml

To save the file and exit nano once you've copied the contents into the terminal type ctrl+x followed by y to confirm that you want to save the file and finally enter.

When applied to the cluster this will create our user account called admin-user and store it into the kubernetes-dashboard namespace, which was created by the installation step above.

The apiVersion must be set to v1 so that K8s knows which fields are acceptible.
The kind must be set to ServiceAccount to tell K8s that we're attempting to create a user.

Also on the primary cluster node create another file called dashboard.admin-user-role.yml with the following content:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: admin-user
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: cluster-admin
   subjects:
   - kind: ServiceAccount
     name: admin-user
     namespace: kubernetes-dashboard

When applied to the cluster this will create a "role binding" to bind our user account to the cluster admin role.

The apiVersion must be set to rbac.authorization.k8s.io/v1 to tell K8s that we're using the RBAC API version 1. A different apiVersion will likely change the fields available for use below, so will break our attempt to apply to the cluster.
The kind field must be set to ClusterRoleBinding to tell K8s that we're attempting to create a Cluster Role Binding that binds an account to a cluster role.
The metadata.name entry is an arbitrary name for the role binding but it makes sense to name this the same as the user account that we're binding.
subjects list must include one or more items. Each item in the list must have a kind, name, and namespace field.
- The kind field must be set to ServiceAccount since that is what we used to create our admin-user.
- The name should be set to the same as that we used in the dashboard.admin-user.yml file, i.e. admin-user.
- The namespace should be set to the same name as that we used in the dashboard-admin-user.yml file so that K8s can find the correct service account, i.e. kubernetes-dashboard.
The roleRef configuration specifies the role that each user in the subjects list is assigned to.
- The apiGroup field must be set to rbac.authorization.k8s.io to tell K8s that we're referencing a role-based access control role.
- The kind field should be set to that of the accounts in the subjects list are granted the role of cluster-admin - This is a default role in K8s.

Apply these configurations to the cluster with the following command:

   sudo kubectl create -f dashboard.admin-user.yml -f 
dashboard.admin-user-role.yml

Accessing the dashboard

Accessing the dashboard is tricky because you need to both access over HTTPS, or via localhost (i.e. from the same machine). You also need to get a token to authorise your access with. I will show how to access remotely over HTTPS (do not do this if your cluster is on a public network!):

On the primary cluster node edit the kubernetes-dashboard service:

   sudo env EDITOR=nano kubectl edit service kubernetes-dashboard -n kubernetes-dashboard

Move the cursor down to the line that includes type: ClusterIP and change it to type: NodePort with the same indentation. (This is the configuration path .spec.type)
Save and exit the editor with ctrl+x followed by y to indicate that we want to save the file and finally enter to confirm.
1. On the primary cluster node run the following to determine the port number to connect to the Web UI:

   sudo kubectl get service kubernetes-dashboard -n kubernetes-dashboard

In my installation this prints:

   NAME                   TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)         AGE
   kubernetes-dashboard   NodePort   10.43.128.69   <none>        443:31235/TCP   126m

The important part is the PORT column which has the value 443:31235 here. The second number, after the colon (here it is 31235), is the port we will use to connect. The hostname is the primary node address. In my case this will mean an address of https://k8s-1:31235/. Load this address in your web browser and accept the warning about a self-signed security certificate to load the UI.

On the primary cluster node run the following to get your token:

   echo $(sudo kubectl -n kubernetes-dashboard get secret $(sudo kubectl -n kubernetes-dashboard get sa/admin-user -o jsonpath="{.secrets[0].name}") -o go-template="{{.data.token | base64decode}}")

Copy and paste the output into the field on the Web UI login screen.

You should now be able to navigate to the nodes item in the left-hand menu of the UI to see your nodes:

Installing k3s in a cluster of three nodes

Lucy Llewellyn — Wed, 04 Aug 2021 01:20:15 +0000

To get going with Kubernetes (K8s) we need to install a distribution of K8s. For this tutorial I will use K3s by Rancher Labs.

You should replace my username and node names in the instructions below. For reference, my username is dllewellyn, and my nodes are named as follows:

k8s-1
k8s-2
k8s-3

Start the first node

   ssh dllewellyn@k8s-1

On the first node run the K3s installation script that automates everything - enter your sudo password if you are prompted:

   curl -sfL https://get.k3s.io | sh -

Get the token for joining more nodes to the cluster - save this somewhere you can easily copy and paste:

   sudo cat /var/lib/rancher/k3s/server/node-token

Start the second node

   ssh dllewellyn@k8s-2

Install and join the node to the primary node we installed above - if your second node cannot resolve the primary node's name to its IP address then use the IP address directly - Replace mynodetoken with the node-token you saved above:

   curl -sfL https://get.k3s.io | K3S_URL=https://k8s-1:6443 K3S_TOKEN=mynodetoken sh -

K3S_URL is the URL of your primary server in the cluster.
K3S_TOKEN will be used to authenticate the new node when joining the cluster. It must match with the token in the file /var/lib/rancher/k3s/server/node-token on the primary server.

Start the third node

This is done exactly the same way as the second node, so the steps are omitted. Repeat the same steps you used for the second node, ensuring that you are in a session on the third node:

ssh dllewellyn@k8s-3

Getting started with Flutter on Ubuntu

Lucy Llewellyn — Tue, 02 Feb 2021 20:27:35 +0000

Recently there was an announcement from Ubuntu that the desktop team are working on a replacement for the Ubiquity installer. The really interesting part of the post by Martin Wimpress, head of the Ubuntu Desktop team at Canonical, is that the new installer will be built using Flutter.

Flutter is a cross-platform User Interface framework that can target Linux, macOS, Windows, Android, and iOS all from the same source code. I have been aware of Flutter for some time now but have been trepidatious in jumping in to sample the water, because I am completely unfamilier with the Dart programming language and was worried about making the time investment.

With the news from Ubuntu I decided that now is a good time to get my feet wet and find out what this new shiny is all about. To that end, I have been installed Flutter and managed to get the sample application running on Ubuntu! There were a few gotchas, however, so below I've summarised the important steps to get a fully functional toolchain set up:

Installing Flutter

First up, we install the Flutter Snap Package. Run:

sudo snap install flutter --classic

By default this will install the commands:

flutter
flutter.dart
flutter.openurl

We can reduce the typing required to call dart, along with reducing the cognitive load when translating any instructions that do not expect the flutter. prefix. Run the following to map flutter.dart to the name dart so you can call it without the prefix:

sudo snap alias flutter.dart dart

Next, we need the Android Studio. The instructions supplied by Google require you to download and extract a .tar.gz file to a place of your choosing. That's too much work. Instead, install the community-maintained Snap Package with:

sudo snap install android-studio --classic

Find the Android Studio icon in your desktop applications menu, such as the dash in Gnome or the K menu in KDE, or execute in the terminal:

android-studio

Run through the first-install wizard accepting all the defaults. We won't be using Android Studio for anything other than its ability to maintain the Android SDK and emulators.

Now, flutter needs to know the location of our Android Studio snap, or you will be unable to build an app even if you're not targetting Android, so run:

flutter config --android-studio-dir /snap/android-studio/current/android-studio

We need to accept the Android licenses to use Flutter, so run:

flutter doctor --android-licenses

Read through each license it presents (you're gonna read them, right?) and accept them with a Y keypress followed by enter when prompted.

If you are likely to be developing for Linux, macOS, or Windows in your Flutter projects, you need to update to the dev branch of Flutter and enable each toolchain. Run:

# switch to dev branch
flutter channel dev
# update Flutter to the latest dev branch revision
flutter upgrade
# enable Linux toolchain
flutter config --enable-linux-desktop
# enable macOS toolchain
flutter config --enable-macos-desktop
# enable Windows toolchain
flutter config --enable-windows-desktop

Note: while you can set-up your project for macOS and Windows support you must use those operating systems to actually build an app targeting each.

Finally, we check that everything is correctly set-up. Run:

flutter doctor

If everything is good, it'll output similar to below:

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel dev, 1.26.0-17.1.pre, on Linux, locale en_GB.UTF-8)
[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
[✓] Chrome - develop for the web
[✓] Linux toolchain - develop for Linux desktop
[✓] Android Studio
[✓] Connected device (2 available)

• No issues found!

Testing Flutter by building a sample

Create a new directory to hold our sample app. Run:

mkdir flutter-example
cd flutter-example

Now we must create the app structure. Run:

flutter create .

This will scaffold out a new Flutter app with support for each of the platforms that are enabled. By default the enabled platforms are Android, iOS, and Web. If you enabled the desktop platforms above then it will also scaffold out those.

The main application code is stored inside the lib/ folder, while each platform will have a respective folder to hold the native C and Java code. Normally you'd use Flutter plugins to enable native features and rely on coding your app in Dart. Flutter plugins can be discovered at pub.dev.

Test the app with:

flutter run -d linux

This will build and run the sample app.

It will also start a debugger server that you can connect to in your web browser; the URL will be in the output text when you run the app:

flutter run -d linux
Running "flutter pub get" in flutter-sample...                            392ms
Launching lib/main.dart on Linux in debug mode...
Building Linux application...                                           
Activating Dart DevTools...                                         4.5s
Syncing files to device Linux...                                    89ms

Flutter run key commands.
r Hot reload. 🔥🔥🔥
R Hot restart.
h Repeat this help message.
d Detach (terminate "flutter run" but leave application running).
c Clear the screen
q Quit (terminate the application on the device).
An Observatory debugger and profiler on Linux is available at:
http://127.0.0.1:38399/PRAhGqkGwN0=/

Flutter DevTools, a Flutter debugger and profiler, on Linux is available at:
http://127.0.0.1:9100?uri=http%3A%2F%2F127.0.0.1%3A38399%2FPRAhGqkGwN0%3D%2F

The debugging web page looks like this:

Wrap up

In this post, I showed how to install and configure Flutter and the Android toolchain, without hitting the issues that I encountered myself. I also showed creating and debugging a sample Flutter app, and enabling the toolchain for Linux, macOS, and Windows desktop apps.

Use GitHub Actions or any CI/CD based on Docker containers to build your Snap Packages

Lucy Llewellyn — Wed, 30 Dec 2020 20:54:46 +0000

When it comes to Snap Packages the ease of entry is incredibly low. This is especially true with the Snapcraft Build Service, which is hosted at Snapcraft.io. The Build Service ties into a Snap Package author’s GitHub account to automatically build a Snap Package from a linked repository. When the Snap Package has finished building the Build Service will then release the Snap into the ‘edge’ track.

The problem

The Build Service has the drawback that, while being quite easy to get started with, it is very restricted in its ability to perform customised release schedules and structures. Another problem is that developers often have their own processes already in place to build and test their app using services such as Travis CI or GitHub Actions. These services are much easier to program to tailor their behaviour than the Snapcraft Build Service.

I maintain many Snap Packages and have run-up against the limitations of the Snapcraft Build Service for several of them. The affected Snap Packages that are causing frustration include those where the Upstream project has several Release Types. One of these problematic Snap packages is OpenRA, which has two types of release: Stable and Playtest. A frequent feature request for the OpenRA Snap Package has been that I release the Playtests in addition to the Stable releases, but the Build Service has prevented me from achieving this goal.

With the readily available resource of services like Travis-CI and GitHub Actions, I have been investigating the possibility of building my Snap Packages using one of these. The Snapcraft Team have long provided a Container Image of Snapcraft in Docker Hub, but until now they have only been able to provide an AMD64 variant. Unfortunately, this means that there is limited scope for compiling Snap Packages using the Container Image for architectures other than the 64bit x86 platform.

The solution

Enter from stage right Docker Buildx, which can run Container Image Builds for multiple architectures. Container Images are built for the architectures specified at build time and tied into a single namespace via a Container Image Manifest on a Container Registry such as Docker Hub. When using GitHub Actions, you can get a fully functional Buildx setup to run your builds with the Docker Buildx Action. The Action utilises qemu user-mode emulation to transparently run the multiple architecture builds on GitHub Actions, which would normally be limited to the amd64 and i386 architectures.

Buildx

Step 1 of my master plan uses Buildx to release an experimental build of Snapcraft under my own Docker Hub namespace which is compiled for Core, Core18, and Core20 for all supported Snap Architectures (excepting s390x for the Core variant because there appears to be a BASH-related issue when combined with qemu-user.) My Snapcraft Container Image is on Docker Hub at diddledan/snapcraft.

Qemu

Now for the really fun part, and this is going to be a whirlwind: we have the readily available build of Snapcraft for all architectures in a convenient Container Image, but how do we use that to build our Packages for the Snap Store?

Hold onto your hats, because here we go... We can use qemu-user-static to execute the foreign-architecture containers built above to build for the Snap Store!

We simply need to wire-up the GitHub Actions or Travis-CI configuration, which configures qemu-user-static and runs our build. Below I’ll show my own GitHub Actions configuration:

name: Build and Release Snap

on:
  push:
    branches:
    - master

jobs:
  build-stable:
    runs-on: ubuntu-latest

    # Let's build for many architectures..
    strategy:
      matrix:
        architecture:
        - linux/amd64
        - linux/386
        - linux/arm64
        - linux/arm/v7
    steps:
    # Checkout the code of our Repository
    - uses: actions/checkout@v2

    # Do the build!
    - id: build
      run: |
        # Enable docker daemon support for --platform parameter
        echo '{"experimental": true}' | sudo tee /etc/docker/daemon.json > /dev/null
        sudo systemctl restart docker

        # Configure qemu-user-static
        docker run --rm --tty \
          --security-opt apparmor:unconfined \
          --cap-add SYS_ADMIN \
          multiarch/qemu-user-static --reset -p yes

        # Run snapcraft
        docker run --rm --tty \
          --security-opt apparmor:unconfined \
          --cap-add SYS_ADMIN \
          --device /dev/fuse \
          --volume /sys \
          --volume /sys/fs/cgroup:/sys/fs/cgroup:ro \
          --volume $GITHUB_WORKSPACE:$GITHUB_WORKSPACE \
          --workdir $GITHUB_WORKSPACE \
          --platform "${{ matrix.architecture }}" \
          --env PLAYTEST="${{ matrix.playtest }}" \
          diddledan/snapcraft:core18

        echo ::set-output name=snap::$(find $GITHUB_WORKSPACE -maxdepth 1 -type f -name "*.snap" | head -n1)

    # Release this Snap to the channel we choose.
    - uses: snapcore/action-publish@v1
      with:
        store_login: ${{ secrets.STORE_LOGIN }}
        snap: ${{ steps.build.outputs.snap }}
        release: beta

Store credentials for publishing

The only thing left is to add a STORE_LOGIN secret to the GitHub Repository with the contents of store-credentials.secret, which you generate with the following command in a Linux Terminal:

snapcraft export-login \
   --snaps="$SNAP_NAME" \
   --acls package_access,package_push,package_update,package_release \
   store-credentials.secret

Make sure you replace $SNAP_NAME with the name of your snap and you’ll be set.

Conclusion

And that is the last step; my plan is complete. With the build of Snapcraft in a Container Image for all Snap Architectures, combined with qemu-user-static, we can now build Snap Packages using GitHub Actions, Travis-CI, or any other competing Continuous Integration runner, for all architectures. We can now release to the Snap Store in whichever track we desire using rules that we choose and codify into our build setup.

That's it from me, folks. Now it's your turn to Snap something awesome using this simple setup and your choice of CI provider! I can't wait to see what you build.

GPG-sign your Git commits and remember your SSH key passwords in WSL2 including Yubikey PGP support

Lucy Llewellyn — Wed, 30 Dec 2020 20:40:39 +0000

This is a follow-up to my WSL2 hack enabling Systemd to run enabling all the awesome features such as service management and session management. The session management enables most graphical or GUI applications in the WSL2 Distro to function without issue when combined with an appropriate Windows-based X11 server such as X410, MobaXTerm or VCXSRV.

So, you're working away in your WSL2 distro and then you want to sign a GIT commit with your PGP key which is backed by a Hardware Security Module like a YubiKey. Or you want to SSH into a remote system using an SSH key that has a long and difficult to remember password. Both activities can be improved or enabled by using Windows-based "Agents". For PGP we can use GPG4Win's gpg-agent and for SSH we can use the SSH agent that is shipped with Windows.

Installation

We only need to install GPG4Win, because Windows comes with the SSH Agent out of the box. So, to install GPG4Win we'll use winget. In a CMD or PowerShell window run:

winget.exe install gpg4win

Loading your keys

Next we load your Private SSH or PGP keys or HSM-backed Public PGP keys into the Windows agents. For SSH keys this is easy; simply copy the keys to C:\Users\<your-username>\.ssh\.

For PGP keys, use the Start Menu to open Kleopatra. If you are using an HSM you only need the public key as a file or the fingerprint ID to lookup the public key on a key server. To import a file-based key select "File" and then "Import" (or press ctrl+I), locate your key file in the browser, and click "Open". To lookup a public key on a key server with the key ID select "File" and then "Lookup on server" (or press ctrl+shift+I). In the dialog that opens enter your key's fingerprint ID, click search, select the correct key from the list and finally click "Import".

Ensuring the agents start automatically

For SSH Agent this is easy to do with PowerShell. Open the run dialog by pressing win+r and type powershell into the text box and finally pressing ctrl+shift+enter to start it in a privileged mode. Now we type the following into the PowerShell window and then you can close it because we're finished there:

Set-Service ssh-agent -StartupType automatic
Start-Service ssh-agent

To start the GPG agent open a new unprivileged PowerShell window and run:

& 'C:\Program Files (x86)\GnuPG\bin\gpg-connect-agent.exe' /bye

However, that only starts the agent once for your current session. To get it started every time you login you can open a privileged PowerShell like we did with the SSH agent above and run:

Register-ScheduledJob -Name GPGAgent -Trigger (New-JobTrigger -AtLogOn) -RunNow -ScriptBlock {
    & "${env:ProgramFiles(x86)}/GnuPG/bin/gpg-connect-agent.exe" /bye
}

Tying the agents to WSL2

First you need your Distro to have the WSLUtilities installed. On Ubuntu these are already present. Follow the steps on the linked GitHub page for your Distro.

Next, we need socat if it isn't already installed:

sudo apt update
sudo apt install -yyq socat

Now, place the following code into a file in your Distro at /etc/profile.d/wsl2-ssh-gpg-agents.sh. This presumes that your Distro automatically parses files in /etc/profile.d:

NPIPERELAY_URL="https://github.com/NZSmartie/npiperelay/releases/download/v0.1/npiperelay.exe"

if [ -n "$WSL_DISTRO_NAME" ]; then
    APPDATA="$(wslvar appdata)"
    APPDATA="${APPDATA//\\/\/}"
    NPIPERELAY_WIN="$APPDATA/wsl2-ssh-gpg-npiperelay.exe"
    NPIPERELAY="$(wslpath "$NPIPERELAY_WIN")"

    if [ ! -f "$NPIPERELAY" ]; then
        curl -L -q -o "$NPIPERELAY" "$NPIPERELAY_URL"
    fi
    #####
    ## Autorun for the gpg-relay bridge
    ##
    SOCAT_PID_FILE=$HOME/.gnupg/socat-gpg.pid
    SOCAT_PID_FILE2=$HOME/.gnupg/socat-gpg.pid.2

    for GPG_SOCK in "$HOME/.gnupg/S.gpg-agent" "/run/user/$UID/gnupg/S.gpg-agent"; do
        if ! ss -a | grep -q "$GPG_SOCK"; then
            rm -f "$GPG_SOCK"
            mkdir -p "$(dirname "$GPG_SOCK")"
            setsid --fork socat UNIX-LISTEN:"$GPG_SOCK",fork EXEC:"$NPIPERELAY -ei -ep -s -a "'"'"$APPDATA"/gnupg/S.gpg-agent'"',nofork
        fi
    done

    #####
    ## Autorun for the ssh-relay bridge
    ##
    export SSH_AUTH_SOCK=$HOME/.ssh/agent.sock
    if ! ss -a | grep -q "$SSH_AUTH_SOCK"; then
        rm -f "$SSH_AUTH_SOCK"
        setsid --fork socat UNIX-LISTEN:"$SSH_AUTH_SOCK",fork EXEC:"$NPIPERELAY -ei -s //./pipe/openssh-ssh-agent",nofork
    fi
fi

Finishing up

You're done. Just restart your WSL2 session and you'll be able to use the GPG and SSH agents hosted on Windows from within the Linux environment. This also works for Yubikey-backed PGP keys!

I hope to return to this soon to automate the installation the way that Damion Gans did for the Systemd hack.

Keyoxide Proof

Lucy Llewellyn — Tue, 11 Aug 2020 22:46:09 +0000

This is an OpenPGP proof that connects my OpenPGP key to this dev.to account. For details check out https://keyoxide.org/guides/openpgp-proofs

[Verifying my OpenPGP key: openpgp4fpr:4c9cbfad0069d6799660bcd540c2d9580349ed21]

Lazy Loading images in WordPress

Lucy Llewellyn — Tue, 16 Jun 2020 22:11:53 +0000

While WordPress Core is working towards their own Native Lazy Loading of images, I have been using something for a while already to do the job. I'm sure I found this from, or was inspired by, someone else's code but I don't recall where. If it is your code, please leave a comment so that I may correctly attribute it.

Step one

The first step is to hook into the wp_get_attachment_image_attributes filter to override the in-built src, srcset, and sizes attributes set by Core. We rename these attributes to data-$attribute_name. The new image data doesn't do anything by itself. We must move it to the correct place using a small shim in the second code snippet below: (Both snippets may be placed into your theme's functions.php file)

<?php
add_filter( 'wp_get_attachment_image_attributes', 'lazyload_images', 99 );
function lazyload_images( $attr ) {
    $return = [];
    foreach ( $attr as $key => $value ) {
        switch( $key ) {
        case 'sizes':
        case 'src':
        case 'srcset':
            $key = "data-$key";
            break;
        }
        $return[ $key ] = $value;
    }

    $return['class'] .= ' lazyload';
    $return['loading'] = 'lazy';

    return $return;
}

Step two

For the second, and final, step, we print a small bit of JavaScript into the footer of our site to load a fallback script. Alternatively, we rewrite the data-$attribute_name attributes back to their original names for native lazy loading. This code detects at load time whether the browser supports native lazy loading, or we need to use something else to mimic it. In this case the fallback script we use is LazySizes.js:

<?php
add_action( 'wp_footer', 'native_lazyload_handler' );
function native_lazyload_handler() {
    ?>
    <script>
    if ('loading' in HTMLImageElement.prototype) {
        const images = document.querySelectorAll('img.lazyload');
        images.forEach(img => {
            img.sizes = img.dataset.sizes;
            img.src = img.dataset.src;
            img.srcset = img.dataset.srcset;
        });
    } else {
        // Dynamically import the LazySizes library
        const script = document.createElement('script');
        script.src = 'https://cdnjs.cloudflare.com/ajax/libs/lazysizes/5.2.2/lazysizes.min.js';
        script.async = true;
        document.body.appendChild(script);
    }
    </script>
    <?php
}

Last thoughts

You might recall, we also add the class name of lazyload in the first snippet. So, if the browser doesn't support native lazy loading then the LazySizes.js fallback loads. This uses the data-$attribute_name attributes unchanged. Those we also set in the first snippet.

If, however, the browser does support native lazy loading then we simply rewrite the data-$attribute_name back to their original names. Then we let the browser do its thing. In this case, we don't load any extra JavaScript.

For even faster load times we set the LazySizes script to the async load method. With this, the browser loads it asynchronously without blocking the page render. This means that the Time Till First Meaningful Paint is quicker because the browser doesn't wait for the script to load. Once LazySizes loads, or the attributes rewritten for Native Lazy Loading, then the images pop into place as soon as they are visible. Both browser native lazy loading and LazySizes 5.0+ support loading without the page jumping about as the images are loaded. To do this, they use the width and height attributes. These attributes indicate the correct aspect ratio of the image, which the browser and LazySizes use to cut out the right amount of space for the image.

Photo by Matilda Wormwood from Pexels