MacOS - Kamil Banach

Building multi-architecture container images on GitLab CI

Wed, 01 Jul 2026 19:58:23 +0000

Turns out that macOS on Apple Silicon is pretty popular right now. Especially among software engineers. From a ‘works on my machine’ perspective - one operating system among many developers - it greatly simplifies support. However Apple Silicon is not x86-64, but ARM64. Fortunately, many of the widely used images, especially published in public registries like Docker Hub, provide variants for different architectures.

Unfortunately, for internal images, we only had the amd64 version because those were built on the amd64 GitLab runners. As a result, performance for macOS users was… bad due to emulation.

While the easiest solution would be to add a new runner with an arm64 processor and build images on it, I wanted to avoid that. I did not want to spin up a new runner that would be used very rarely (a couple of times a year). I did not want to build them locally and push them to our registry either - that would be boring and ugly, and require somebody with a dedicated device to build them. And allowing that person to push images directly to the registry is a no-go from a security perspective as this would bypass the proper code review and CI process.

So I searched for a solution using emulation.

And I found one! Using the cross-platform emulator collection distributed using Docker images available at tonistiigi/binfmt. It registers QEMU emulators with the host kernel through binfmt_misc.

So, below are the steps needed to run building multi-platform container images in GitLab CI (GitLab Runner with the Docker executor) with Buildah¹.

1. Install the required emulation support

To install emulation that will be also available to containers, I needed to run (to install only the emulation support for ARM64²):

docker run --privileged --rm tonistiigi/binfmt --install arm64

After that, I verified if everything is working using the following command:

docker run --rm --platform linux/arm64 alpine uname -m

It should print the following:

aarch64

Note that registration is not persisted between reboots. The Docker image does not install any host service to reapply registration on boot.³

2. Update GitLab Runner configuration

The next step is to update the configuration of the GitLab Runner using the Docker executor and relax some of its security restrictions.

Since this weakens container isolation, do it at your own risk. At minimum, make sure this is a controlled runner that executes only trusted jobs.

[[runners]]
# ...other configuration ommited...
 [runners.docker]
 # To allow running buildah in the container
 security_opt = ["seccomp:unconfined", "apparmor:unconfined"]

Is it 100% secure? Nope.

However, for our self-hosted runner it was an acceptable trade-off compared to building images manually on a developer’s machine.

Spinning up a dedicated ARM64 runner would provide native builds (which would be faster). Yet considering that it would be used at most a couple of times a year, it would also add operational overhead and increase infrastructure costs.

3. Configure the image step using Buildah

Last but not least, the a GitLab CI job. As mentioned at the beginning I used Buildah and its support for building images for different CPU architectures⁴.

I store the images in GitLab Registry, so the first step (in before_script) is to log in to the registry. Then the job builds the image for specified CPU platforms and pushes manifest with platform-specific images to the registry.

images:multiplatform:
 stage: images
 image: quay.io/buildah/stable
 variables:
 IMAGE_DIRECTORY: "myimage"
 IMAGE_NAME: "corp/myimage"
 IMAGE_VERSION: "1.2.3"
 STORAGE_DRIVER: vfs
 BUILDAH_FORMAT: docker
 BUILDAH_ISOLATION: chroot
 before_script:
 - echo "$CI_REGISTRY_PASSWORD" | buildah login -u "$CI_REGISTRY_USER" --password-stdin "$CI_REGISTRY"
 script:
 - buildah build
 --platform=linux/amd64,linux/arm64
 --manifest "$CI_REGISTRY_IMAGE/${IMAGE_NAME}:${IMAGE_VERSION}" 
 "${IMAGE_DIRECTORY}"
 - buildah manifest push --all "$CI_REGISTRY_IMAGE/${IMAGE_NAME}:${IMAGE_VERSION}" "docker://$CI_REGISTRY_IMAGE/${IMAGE_NAME}:${IMAGE_VERSION}"

You may ask: why so many variables? To make the job easy to reuse. All I need to do to add a new image is to create a new directory with Dockerfile or Containerfile and create a new entry in .gitlab-ci.yml.

That is all - now all developers can benefit from prebuilt images that have native performance on Apple Silicon. :-)

Previously I used kaniko, but it is not maintained anymore. There was even a situation where, for a few hours, the images disappeared from the public registry. ↩︎
All available emulators can also be installed using all instead of specifying the architecture. ↩︎
This small exercise is left to the reader (yes - you!). :-) ↩︎
As long as the host provides emulation support for a different architecture. More details are available in the documentation. ↩︎

Using Cloudflare Tunnel to expose a local dev app

Tue, 06 Jan 2026 20:35:52 +0000

Since I reinstalled the OS and have fewer apps installed, it is a good moment to rebuild my workflow and drop a couple of old habits.

Previously, to access the local app from the internet (for example, to receive a webhook), I used the ngrok service¹. But on a fresh system, I did not have the app installed, so I have looked at alternatives - what I can use instead of it². Especially since I have Podman already installed.

In the end, I discovered that I can use Cloudflare Tunnel with containers, so I gave it a spin - and it worked flawlessly!

tl;dr: Magic sauce is to set host.containers.internal (or host.docker.internal for Docker) to target host.

First things first - we need a Cloudflare account with some domain and Cloudflare One. Free plan for both is okay.

Once we have the required accounts, we can navigate to Network -> Connectors in Cloudflare One to create a new tunnel. Select Cloudflared as a tunnel type (as we need only one direction access - from the internet to our service) and name the new tunnel.

Then can select the environment as Docker to have a command like this (THE_TOKEN will be replaced with your token - this is secret, do not share!): docker run cloudflare/cloudflared:latest tunnel --no-autoupdate run --token THE_TOKEN

We can run it to see if it is working (a message will appear in the UI). After that, we can go to ‘Route tunnel’ and ‘Published applications’ (when we edit, it will be ‘Published application routes’) and configure it to your needs.

In the screenshot below, I have a configuration that will point my-subdomain.example.com to localhost:5000.

And that is all. After starting the container (with a proper token), my service is exposed as needed.

ngrok is nice, but I wanted to have something without an additional executable installed ↩︎
I could also set up nginx and use SSH for that purpose, but this time I wanted to not set up anything on the VMs. ↩︎

Export and import secret GPG keys from backup

Mon, 05 Jan 2026 12:33:34 +0000

When installing a new distro¹, I installed it on a new disk - leaving the previous disk as a ‘backup’. What I forgot to do (to be honest, I hadn’t thought about it) was exporting the GPG keys that I use, e.g. to sign commits.

I did not want to copy the .gnupg directory from the old disk, as I imported a lot of public keys for example, to verify downloaded files. I no longer need them - I want only my private keys.

I figured out a way to export them from the backup and import them to the local keyring. Below are the steps and the explanation. :-)

tl;dr: the magic sauce is --homedir parameter. It tells GnuPG to use that directory as its home (keyring, config, etc.) instead of the default one. This way, we can point GnuPG at the backed-up files and use them as if they were in place for a regular setup.

1. Copy from the backup to the home directory

Copy the .gnupg directory from backup to the home directory. This is to ensure that these will not be overridden by mistake.

For the latter steps, I assume that those are copied to ~/gnupg/.gnupg (gnupg is a directory in the home directory).

2. Verify that keys are there

Then verify that the secret keys are there:

gpg --homedir=~/gnupg/.gnupg --list-secret-keys

It should show secret keys that are available in the keyring.

3. Export keys from the backup

After that, I can export them to a file keys.key in the current directory. A passphrase for each private key needs to be provided for successful export.

gpg --homedir=~/gnupg/.gnupg --export-secret-keys > keys.key

4. Import keys from the file

As those are exported, they can now be imported. Same as previously, passphrases need to be provided:

gpg --import keys.key

Every key will be printed out (public and secret pair) with the summary. For example:

(...details are removed ;-)...)
gpg: Total number processed: 3
gpg: imported: 3
gpg: secret keys read: 3
gpg: secret keys imported: 3

5. Verify and cleanup

To verify, we can run gpg --list-secret-keys - it should print out the details of the keys that we just imported. As for cleanup - remove the copied data and keys.key file - those are not needed anymore!

And that is all - now I can use my GPG keys to sign Git commits, just like I did on the previous machine!

I installed Fedora KDE 43. I must say that it works quite well! ↩︎

Fixing suspend after login in KDE in clamshell mode

Tue, 30 Dec 2025 19:55:27 +0000

My working setup is basically clamshell mode - the laptop is closed and placed vertically, with two external monitors, a mouse, and a keyboard.

On a fresh Fedora KDE 43 install, this caused a weird issue - right after logging in, the system immediately suspends, and I have to wake it up. Tweaking the UI settings (Power Management) did not resolve the issue.

I tried a bunch of solutions I found online, but most of them did not work. The main reason was that many comments pointed to /etc/systemd/logind.conf, but on my setup, that file did not exist. The default config lives under /usr/lib/systemd/logind.conf, and the recommended way to override it is via a drop-in in /etc/systemd/logind.conf.d/.

The working solution is to create /etc/systemd/logind.conf.d/ignore-lid-switch.conf and add the following lines:

[Login]
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore

While searching, I also found a neat way to inspect the effective systemd configuration: systemd-analyze. For example, to check what the configuration is for logind.conf, I can run systemd-analyze cat-config systemd/logind.conf.

And that is all - after restarting systemd-logind or rebooting, everything works as expected.

Adding SSH keys on autostart in KDE (for IntelliJ)

Mon, 29 Dec 2025 11:09:03 +0000

Recently, I wanted to give Fedora (KDE flavour) a try, so I installed it on a new disk. After copying all dotfiles (including SSH keys and Git configuration¹), turning on saving SSH keys passwords to KWallet (and unblocking it on login) and checking if everything works - and it worked flawlessly² - I turned off the PC.

The next day, as soon as I wanted to push the changes to the project, I was greeted by an unexpected pop-up:

The what? I have checked git from the console - everything is working as expected. So what happened? Turns out that IntelliJ (along with running git) expects the key to be loaded, but it is not. And it cannot load it without providing a password - it does not use the ‘ask pass’ tool (in my case - ksshaskpass).

So I decided to fix it in the simplest way ever - by adding a small script to autostart that will add keys that I expect to be loaded. Adding them works without providing passwords, as those are provided by KWallet and ksshaskpass.

To do so, I did the following - first, I created a directory to store all my ‘autostart scripts’:

# Create .run directory
mkdir -p ~/.run/

Then I have created the script add-ssh-keys.sh in .run using following snippet³:

# Add create add-ssh-keys.sh to add ssh keys
cat << EOF > ~/.run/add-ssh-keys.sh
#!/bin/sh
SSH_ASKPASS=/usr/bin/ksshaskpass
ssh-add ~/.ssh/id_ed25519 </dev/null 2>/dev/null || true
EOF

By default, it adds only the .ssh/id_ed25519 key, but it can have more lines - just add another ssh-add ~/.ssh/file_with_private_key.

To make sure that it will be runnable, let’s make it executable:

chmod +x ~/.run/add-ssh-keys.sh

After creating the script using the code above, I can add it to autostart using Settings → Autostart (using ‘Login Script…’ option):

And that is all. After the login, the SSH keys that I want to be available are added (and passwords are fetched from KWallet) to the SSH agent. Thanks to that, IntelliJ is not asking me for a password anymore!

My Git configuration uses subfolders to select proper emails and user names - all described in one of the previous posts ↩︎
I’m quite amazed how nice it looks and how smoothly Fedora KDE works! ↩︎
Snipped uses cat << EOF > file that allows putting multiline data into a file - all content until EOF is put into the file. Which is nice. ↩︎

Creating bucket automatically on local MinIO with Docker Compose

Tue, 01 Apr 2025 20:15:00 +0100

I’m a fan of making things easier. If something can be automated, we should do it, as it simplifies things and prevents errors. And questions like ‘why it is not working?’ or ‘have you set up X/Y/Z?’.

So let’s see how ~10 lines of YAML in Docker Compose can simplify configuring (creating buckets and directories) local S3-compatible storage!

You can omit the step-by-step description and go straight to the final code.

Base Docker Compose

For the S3-compatible storage, my friends selected MinIO, as it works out of the box for the simple case. The Docker Compose file with configuration looked like this¹ (yes, the user and password are so obvious!):

## Below 
services:
 minio:
 image: "quay.io/minio/minio:RELEASE.2025-03-12T18-04-18Z"
 ports:
 - "127.0.0.1:9900:9000"
 - "127.0.0.1:9901:9001"
 command: [ "server", "--console-address", ":9001", "/data" ]
 environment:
 MINIO_ROOT_USER: minioAccessKey
 MINIO_ROOT_PASSWORD: minioSecretKey

However, after starting it up, the creation of the buckets was manual. Which takes time and is easily to forget about - until you want to run stuff and it fails to work due to lack of the bucket.

I was pretty sure that it is possible to automate (and did not want to create the buckets from the app code). And indeed it is - there is a mc² (which seems like an abbreviation of MinIO Client - its name). The question remains - how to run it locally, after the start of storage?

Fortunately mc has its own docker image available and I can use depends_on to make sure that it will start after the storage is set up.

Service configuration for creating buckets

The below configuration creates a new service createbuckets that depends on minio service. It has overwritten entrypoint³ that runs command (using bin/sh -c) that does the following:

sleeps for 5 seconds - just to make sure that minio service started;
adds configuration for the local MinIO;
creates bucket my-bucket with some-directory;
creates bucket my-other-bucket;
exits with 0 - exit code that means basically “ok, exited with success”;

Addiotionally if it fails (so exit with non-0 exit code) it will restart, thanks to on-failure restart policy.

services:
# <chomp> - here is the above mino service
 createbuckets:
 image: quay.io/minio/mc:RELEASE.2025-03-12T17-29-24Z
 depends_on:
 - minio
 restart: on-failure
 entrypoint: >
 /bin/sh -c "
 sleep 5;
 /usr/bin/mc alias set dockerminio http://minio:9000 minioAccessKey minioSecretKey;
 /usr/bin/mc mb dockerminio/my-bucket/some-directory;
 /usr/bin/mc mb dockerminio/my-other-bucket;
 exit 0;
 "

And basically, that is all that is required to create the buckets and folders within them. mc tool can be also used with other S3-compatible storages.

Final Docker Compose

The final Docker Compose looks like this - feel free to copy and adjust. ;-)

services:
 minio:
 image: "quay.io/minio/minio:RELEASE.2025-03-12T18-04-18Z"
 ports:
 - "127.0.0.1:9900:9000"
 - "127.0.0.1:9901:9001"
 command: [ "server", "--console-address", ":9001", "/data" ]
 environment:
 MINIO_ROOT_USER: minioAccessKey
 MINIO_ROOT_PASSWORD: minioSecretKey

 createbuckets:
 image: quay.io/minio/mc:RELEASE.2025-03-12T17-29-24Z
 depends_on:
 - minio
 restart: on-failure
 entrypoint: >
 /bin/sh -c "
 sleep 5;
 /usr/bin/mc alias set dockerminio http://minio:9000 minioAccessKey minioSecretKey;
 /usr/bin/mc mb dockerminio/my-bucket/some-directory;
 /usr/bin/mc mb dockerminio/my-other-bucket;
 exit 0;
 "

After starting it with docker compose up it begins minio service, then createbuckets which waits 5 seconds and creates two buckets - my-bucket with directory some-directory and my-other-bucket.

That is all - small configuration (a little more than 10 lines of code), but great improvement in setting up local environment!

Remember to put the hostname in port mappings, otherwise it will open this port in your firewall! For details see Networking overview → Published ports manual page ↩︎
A pretty nice tool to work with the s3-compatible storage like MinIO, documentation available here: https://min.io/docs/minio/linux/reference/minio-mc.html ↩︎
Overriding entrypoint allows us to run anything we want in the context of the Docker image. ↩︎

Restricting access to specific Docker images in Nexus

Thu, 21 Nov 2024 12:32:00 +0100

Once upon a time¹, the company I work for decided to migrate all Docker images from a hosted registry to a self-hosted one. The main requirement, in line with the Principle of Least Privilege², was to restrict service accounts to access only their designated images. This ensures that every project could only access its own images.

Since we were already using Nexus ³ as our private NPM registry, we decided to configure it for this use case as well. I had also configured something similar before, using the raw repository type. In the mentioned case, we published runnable JARs (builds per customer) to Nexus and allowed end users to download them with dedicated accounts⁴.

Setting up a new registry was straightforward, but restricting access to specific images required more effort - in fact a deeper understanding of Content Selectors⁵.

Steps and assumptions

The steps below assume that we have admin access to Nexus and a working Docker registry:

Configure Content Selectors for login and image access.
Create privileges based on the created Content Selectors.
Create the role with new privileges and apply them to the user.

And that’s it! :-)

To achieve this, we need to configure Content Selectors⁵ that will allow us to:

use the docker login command.
pull only the selected images (any tag).

To allow logging into the repo we will need the following content selector - it matches the path that is used by the docker login command:

path == "/v2/"

So the content selector could look like this:

Apart from allowing us to log in, we need to allow access to selected images. To allow all images in the following path we will use =^⁶ to match all paths that start. Assuming that our image is sonatype/nexus3 then we need to create a selector:

path =^ "/v2/sonatype/nexus3"

Which translates to the following Content Selector:

We could merge both into the one with the or operator. Keeping them separate allows the first selector (for login) to be reused multiple times.

2. Creating privileges

As a next step, we need to create new privileges - each for the newly created content selector. Both privileges should be configured for the read action, as we only need read-only access.

In the screenshots below I select my Docker registry with the name docker, but nothing stops us from selecting here (All docker repositories).

After that, we can go to the last step which is… creating a role and assigning it to our service account!

3. Creating the role and assigning it to the user

Now we will create the role (with type Nexus role) and we will apply previously created privileges:

Then, cherry on the top, we will add that role to our service account:

That’s all. Now we can grab the login and password for our service account, log in and pull the images. Which is perfect for pulling images from the registry on the Kubernetes cluster. :-)

End notes

In a few steps, we have configured limited access to selected Docker images in our self-hosted registry. Even if that solution was nothing extraordinary, it allowed us to migrate from the hosted repository and have more control over image access.

Worth noting that it was a prerequisite to set up Nexus as a proxy in front of our GitLab instance - but this is the story for another time.

6 months ago, but in IT it is like decades, riiight? ↩︎
Principe Of Least Privilege means that the access shall be as limited as can be. ↩︎
Yes, Sonatype Nexus Repository OSS, as it is free to use and allows to store maven and NPM artifacts! ↩︎
raw repository as we do not want to expose the Maven repo structure. In the end, we dropped that way of distribution as we moved to providing Docker images. ↩︎
The documentation for Content Selectors can be found here ↩︎ ↩︎
That operator =^ looks like an emoticon, isn’t it? ↩︎

Exposing local app (like Home Assistant) with autossh

Fri, 09 Feb 2024 23:20:00 +0100

For the last 3 years to manage my ‘smart home’ (a couple of lights, heating, some sensors) I have been using Home Assistant running on Dell Wyse Z90D7¹. And to be honest - it is a great piece of code which works without issues since then. But after the month of using it² I wanted to have it available through a mobile app - for example, to turn on the heating before I come back. Or make sure that, after leaving for groceries, a bathroom door is open so my cat can use his litter box. ;-)

I looked over the ways to expose Home Assistant online and found some services³, but in the end decided to make something my own. To do it I decided to use the things I already know and have - SSH, nginx and remote server in the cloud.

Despite the fact I wanted to tinker with it by myself I was lazy and searched for tools that would allow me to maintain a stable SSH tunnel. After a short research, I found one that fits perfectly my needs - autossh⁴.

Using autossh (that runs on top of the SSH) I can be sure that the SSH tunnel will be there. Even if the terminal restarts or it will lose network for a couple of minutes (or days) - autossh will restart the connection.

So I set it up and connected all the required stuff and it has worked without any issues⁵ since then.

So, no more introduction - below are step-by-step instructions on how to do it by yourself!

Steps outline and assumptions

To access service using SSH tunnel we will need a service and remote server that allow us

Exposing the application is pretty straightforward and can be described in a couple of steps:

install autossh,
create a user on the local server (this is the server you have at home) and create a pair of SSH keys,
create a user on the remote server (this is the server on the public internet, like VPS) and add the previously created key as an authorized one,
test SSH connection,
create a service to run and restart autossh on the local server,
configure reverse proxy on the remote server.

For the post, I assume the Linux distribution is Ubuntu Server (both local and remote server) and you have root rights on it (to configure accounts and reverse proxy).

1. Install `autossh`

Installing autossh on Ubuntu is straightforward:

$ sudo apt install autossh

2. Terminal: Create user and key pair

Create a new account with username autotunnel on the local server, then log in to this account:

$ sudo useradd -m -s /bin/bash autotunnel
$ sudo su -l autotunnel

Then log in to it on the server and create a new SSH key pair - it needs to be created without a password:

$ ssh-keygen -t ed25519 -C "autotunnel"

With default options public key will be by default saved in ~/.ssh/id_ed25519.pub.

3. Remote: Create a user and add the public key to the authorized ones

Commands as above:

$ sudo useradd -m -s /bin/bash autotunnel
$ sudo su -l autotunnel

After logging in you need to copy the value from terminal ~/.ssh/id_ed25519.pub into remote ~/.ssh/authorized_keys, and set proper permission to that file:

$ echo "ssh-ed25519 AAAAlotofletters autotunnel@tarkin" > ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys

4. Test connection!

After setting accounts and keys you need to test the connection. You can do that by simply connecting using SSH from the local server to the remote server:

$ ssh autotunnel@remote-tld

If you are trying to log in for the first time - and as this is a fresh account it probably will be the first time - you will need to confirm the authenticity of the remote host:

The authenticity of host 'remote-server.example.com (XX.XX.XX.XX)' can't be established.
ED25519 key fingerprint is SHA256:anotherAlotOfLetters.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Validate the key ⁶ and if it is correct - continue connecting. After a couple of seconds, you should be logged into the server.

If not - something bad happens or something is misconfigured - for sure it is worth checking if the SSH server allows authenticating with public keys!

5. Create a service to run and manage the connection

To make sure that the connection will start on the local server restart we can create a service that will be enabled and started. To edit file /etc/systemd/system/autotunnel.service ($ sudo nano /etc/systemd/system/autotunnel.service) and type the following content into it:

[Unit]
Description=Keep a tunnel to 'remote-server.example.com' to expose service from localhost:8123
After=network-online.target


[Service]
Type=forking
User=autotunnel
ExecStart=/usr/bin/autossh -f -M 8124 -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -N -R 32100:localhost:8123 autotunnel@remote-server.example.com
ExecStop=/usr/bin/pkill -9 -u autotunnel
Restart=always

[Install]
WantedBy=multi-user.target

The above configuration assumes that we will run the service with user autotunnel. Because you already tested the connection and the key does not require a password there are no additional, manual, steps needed to make a connection.

autossh in the same way as plain ssh will create a tunnel from port 32100 on remote-server.example.com to local 8123 port (it is defined by -R 32100:localhost:8123 part of ExecStart). The only (but crucial!) difference is that it will make sure that the connection will be there. If your local server suddenly becomes unavailable then it will try, continuously, to connect again.

Then reload services, enable and run service type:

$ sudo systemctl daemon-reload
$ sudo systemctl enable autotunnel.service
$ sudo systemctl start autotunnel.service

After a couple of seconds, we should be able to see that the service is running by typing $ sudo systemctl status autotunnel.service.

6. Reverse proxy

To expose the service on the remote server we can use for example Caddy or nginx. For the latter, the full example is available in a post How to expose local service using nginx and SSH. The only required change is the port change - in the linked example we are using 8080 and above we need 32000.

In the case of the Home Assistant, it is required to allow Internet access in System -> Network based on the external domain and port (configured e.g. with nginx as above).

End notes

And that is all - thanks to that solution I can expose any local service (like the mentioned Home Assistant) without requiring static IP, dynamic DNS and so on. I am very happy to have the possibility to turn on the heating before coming home or have an instant notification about water leaks.

A beast with an AMD processor, 4GB of RAM and 120GB SSD! But it cost me less than 200 Złoty (~40 Euro). ↩︎
That is correct - writing this post took me… a few hours typing and three years as an ‘I should write about that’ idea. ↩︎
For Home Assistant there is a service provided by the creators of Home Assistant called Nabu Casa. If you want to offload this to somebody and support the authors - this is the way to go! ↩︎
Description, download and other stuff available here. It should be also available in the repository of any Linux distro. ↩︎
Well, the remote server (VPS) is hosted by OVH and was turned off during the fire in a data centre (SBG), but that is a force majeure. ↩︎
For example using the command ssh-keygen -lf <(ssh-keyscan localhost 2>/dev/null) on the remote server and verifying the checksum (source: StackExchange) ↩︎

When JavaScript regex can surprise you - a silly bug story

Wed, 15 Feb 2023 10:25:00 +0100

Recently one of my customers let me know that they have probably a bug in their app. They want me to look into it - so I jump into “Sherlock, the bug hunter” mode and start snooping!

The misbehaving feature was some kind of search. It takes an input, a Javascript regular expression and as an output returns true if regex was satisfied - and false otherwise.

The feature was pretty simple on the code side - the search function looked similar to the one below:

var search = function(regex, text) {
 if (regex && regex.test(text)) {
 return true;
 }
 return false;
}

So we can see that the heart of it was a simple regex.test call.

The bug report stated that misbehaving example was regex /pony/g and text this is a pony and not a horse - we have 100% sure that pony is in this sentence. To check if everything was working correctly I opened console in Chrome Developer Tools, loaded the search function and check its result:

// Below returns true
search(/pony/g, "this is a pony and not a horse");
// this also returns true!
search(/pony/g, "this is a pony and not a horse");
// ... five runs later
// eh? still returns true!
search(/pony/g, "this is a pony and not a horse");

What is going on?! Every run of this function returns the correct and expected value.

But wait… the regex and text was passed using variables from somewhere else. Let’s put them in the variables and try to run the function multiple times again:

var regex = /pony/g
var text = "this is a pony and not a horse";
search(regex, pony); // returns true as expected
search(regex, pony); // returns false :O
search(regex, pony); // returns true - what a trickery!
search(regex, pony); // returns false - wut?!

And now we have a problem - despite the fact we should get true every time we sometimes get false instead.

The answer to this weird behaviour is in the… documentation. Quick look at the RegExp.prototype.test() on mdn web docs and we have found the culprit:

JavaScript RegExp objects are stateful when they have the global or sticky flags set (e.g., /foo/g or /foo/y). They store a lastIndex from the previous match

And the latIndex property is described as:

The lastIndex data property of a RegExp instance specifies the index at which to start the next match.

We have the global option in our regex - and that was the reason that it behaves in a not expected manner. Similar results will be if our test text were this is a pony and second pony - it will give us true for the first and the second search (as we have two ponies!) and false for the third one.

The solution for this issue was simply to reset the lastIndex property of regex if something was found

var search = function(regex, text) {
 if (regex && regex.test(text)) {
 // reset lastIndex property to make sure
 // that next test will start from beginning
 regex.lastIndex = 0;
 return true;
 }
 return false;
}

That’s all folks! One line, resetting one property, is all that was needed to fix the issue.

What is the takeaway from this issue? When in doubt and especially when working with regexes - read documentation. It can save you a lot of time. :-)

Accessing Kubernetes cluster using SSH tunnel

Mon, 12 Dec 2022 20:35:00 +0100

Whether we want it or not adoption of Kubernetes is growing. It can be set up as a managed solution (all major cloud providers provide such products) or we can set it up by yourselves. No matter if we select the former or the latter - we would like to make it as secure as it can be.

One of the solutions to make the Kubernetes cluster more secure is to hide a control plane (to be more specific - kube-apiserver) behind a firewall. That means cluster management is not available from the Internet.

That creates problems with accessing it. We can SSH to a server that is in the same network and run kubectl commands from there, but this is a nuisance which we want to avoid. Fortunately, SSH tunnels came with help in that case (not for the first time!) - we can create a tunnel to the server in the same network and pass all traffic to the cluster through it!

To do it we can run the command:

$ ssh our-gate.example.com -L 16443:10.0.10.2:443

In the command, we’re assuming that:

our server is available with the domain our-gate.example.com,
the cluster is in the same local network as the server and its control plane is available at 10.0.10.2 IP address,
we want the tunnel to be available at port 16443.

Now we need to replace IP address / hostname of cluster in ~/.kube/config to point to local tunnel. To do this we will open aforementioned file and replace put https://127.0.0.1:16443 in clusters.cluster.server property:

apiVersion: v1
clusters:
- cluster:
 certificate-authority-data: <long string with CA data>
 # line below was something like https://our-public-address-of-cluster.example.com or just local IP like https://10.0.10.2 
 server: https://127.0.0.1:16443 
 name: my-k8s-cluster

After that we can try to run a command like kubectl cluster-info:

~ > kubectl cluster-info
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
Unable to connect to the server: x509: certificate is valid for our-public-address-of-cluster.example.com, 10.0.10.2, not 127.0.0.1

It fails, but why? It is because we want to connect to 127.0.0.1 but API (securely server over https) is responding with a certificate issued for different domain / IP address. Fortunately solution for that is simple which is to put clusters.cluster.tls-server-name property with one of the valid values from the error message - in our case it can be 10.0.10.2.

Our final configuration will look like this:

apiVersion: v1
clusters:
- cluster:
 certificate-authority-data: <long string with CA data>
 server: https://127.0.0.1:16443
 tls-server-name: 10.0.10.2
 name: my-k8s-cluster
contexts:
- context:
 cluster: my-k8s-cluster
 user: admin
 name: my-k8s-cluster
current-context: my-k8s-cluster
kind: Config
preferences: {}
users:
- name: admin
 user:
 token: <some-fancy-token>

And now running cluster-info command will gives us what we expect:

~ > kubectl cluster-info
Kubernetes control plane is running at https://10.0.10.2:16443
GLBCDefaultBackend is running at https://10.0.10.2:16443/api/v1/namespaces/kube-system/services/default-http-backend:http/proxy
KubeDNS is running at https://10.0.10.2:16443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Metrics-server is running at https://10.0.10.2:16443/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy

Yay! Now we can use kubectl, helm and other software that uses configuration from ~/.kube/config from our local machine!

And a small “bonus” (and also describing it to the future myself) - accessing Kubernetes in GCP (GKE) through Identity Aware Proxy:

$ gcloud compute ssh "some-instance" --zone "$ZONE" --project "$PROJECT" --tunnel-through-iap --ssh-flag="-L 16443:10.0.10.2:443"

That is it - the SSH tunnel again saves the day! :-)

MongoDB sequences (auto-increment) - The Java Way

Fri, 02 Dec 2022 22:30:00 +0100

One of the missing elements while using MongoDB is lack of the auto-increment fields, commonly called sequences (e.g. in PostgreSQL). For MongoDB Atlas (managed MongoDB solution) there is a posibility to mimic this feature using database triggers (as mentioned on MongoDB page).

tl;dr: Full code available at my Github - elwin013/mongodb-sequences.

But what about self-hosted database? Unfortunately, there are no triggers there (or I’m not aware of them :-)), so we need to improvise and make that happen with custom code.

To make this work we will create a collection called sequence which will have documents with two fields describing the sequence:

_id with a name,
value with a value.

The code will be relying on MongoDB’s document write atomicity. Linked documentation says:

A findAndModify operation on a document is atomic

In the case of the Java Mongo driver, our operation is findOneAndUpdate. We will be searching for exactly one document with the selected id (name of the sequence), increment value and return that document after the update. Let’s do it!

Below is Sequence record (it can be replaced with the classic POJO if we need to run code on e.g. Java 11 or 8).

import org.bson.codecs.pojo.annotations.BsonId;

public record Sequence(@BsonId String name, Long value) {}

Worth mentioning is the @BsonId annotation - this annotation will make field name an id field (_id) for document in collection. So our document will have two fields - _id (which will contain sequence name and will be mapped to name field in code) and value with value.

Now we can write code to update (increment) and return sequence value. We also want to be sure that the document always is created (update and insert, so upsert) and will be returned after creation. To achieve that we will customize options of findOneAndUpdate request:

var options = new FindOneAndUpdateOptions()
 .upsert(true)
 .returnDocument(ReturnDocument.AFTER);

And the cherry on the top - findOneAndUpdate operation:

 var seq = db.getCollection("sequence", Sequence.class)
 .findOneAndUpdate(
 Filters.eq("important_sequence"),
 Updates.inc("value", 1),
 options
 );

The code above will search for a document with id important_sequence, increment the document’s value field by one and return the document - exactly what we need. And if the document doesn’t exist - it will be created and seq.value() will give us 1.

We can always change the value of sequence using similar code (Updates.set instead of Updates.inc) - but we need to set it to 0 if the next value needs to be 1.

And that is all - we have sequences in MongoDB without any additional tools! Feels great! :-)

Full code available at my Github - elwin013/mongodb-sequences - including record class, DAO and some fancy tests using TestContainers to test code using MongoDB on Docker.

Reading JWT token claims without a library

Fri, 14 Oct 2022 14:49:00 +0100

Almost everybody who works on web apps knows what JWT (JSON Web Token) is. They become pretty popular and are now widely used.

Without going into details (which can be read e.g. at jwt.io/introduction) JWT is built from three parts divided by dots:

header.payload.signature

The middle part, payload, is interesting for us. It contains claims, which are statements about an entity (e.g. the user) and some additional data.

For purpose of this post we will use an example token from jwt.io (click on the link to open it in the debugger!) which looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The payload in the token is just a base64 encoded JSON object. That means we can decode it and load this JSON string into the dictionary to have easy access to properties.

There is only one tricky part here - base64 padding! The payload in the JWT is alfa-numeric only, there is no = character. To be sure that it will be decoded properly we need to add max padding (==) to the payload string - it will be ignored if not needed. But if we will not have it there (but it is expected to be) - decoder will throw an error.

To sum up all above stuff in simple lines of code in Python:

import base64
import json

# Assuming the token is in the token variable 
token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9." \
 "eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ." \
 "SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"

# Split by dot and get middle, payload, part;
token_payload = token.split(".")[1]
# Payload is base64 encoded, let's decode it to plain string
# To make sure decoding will always work - we're adding max padding ("==")
# to payload - it will be ignored if not needed.
token_payload_decoded = str(base64.b64decode(token_payload + "=="), "utf-8")
# Payload is JSON - we can load it to dict for easy access
payload = json.loads(token_payload_decoded)
# And now we can access its' elements - e.g. name
name = payload["name"]

# Let's print it - it should show "John Doe"
print(name)

You can run it in the browser on Replit (Reading JWT token without library on Replit) or locally with Python 3.

And that’s all. It is pretty simple, isn’t it?

And it feels great to be able to do it without any additional tools! :-)

How to customize Jetty in Spring - Custom Error Handler

Tue, 21 Jun 2022 14:41:00 +0100

Last week we found out that in some cases our application is showing redundant data on error - for example stacktrace. It happens when there was an error which was handled by the application container which was Jetty. For example, sending a header like X-FORWARDED-PORT: some-not-numeric-value causes NumberFormatException and shows a full stacktrace.

We’ve looked over the documentation and see that we could hide stacktrace in default error handler. Instead of that, we decided to replace it with a custom one. That allows us to put an additional logging logic and customize the output. And this is a short description of how to do it. ;-)

To implement the custom error handler we can extend org.eclipse.jetty.server.handler.AbstractHandler and override handle method. On the code snippet below there is an example handler. For sake of clarity it returns always simple text (content-type text/plain) with code, error message and URL used.

We can extend it by adding additional logic like different responses based on headers from the client, additional logging and so on. :-)

package pl.net.banach.customizeJetty;

import java.io.IOException;
import java.io.OutputStreamWriter;
import java.io.PrintWriter;
import java.nio.BufferOverflowException;
import java.nio.ByteBuffer;
import java.nio.charset.StandardCharsets;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.eclipse.jetty.http.MimeTypes;
import org.eclipse.jetty.io.ByteBufferOutputStream;
import org.eclipse.jetty.server.Dispatcher;
import org.eclipse.jetty.server.Request;
import org.eclipse.jetty.server.handler.AbstractHandler;
import org.eclipse.jetty.util.StringUtil;

public class CustomJettyErrorHandler extends AbstractHandler {

 @Override
 public void handle(String target, Request baseRequest,
 HttpServletRequest request,
 HttpServletResponse response)
 throws IOException, ServletException {


 try {
 // Get error message, sanitize it, just in case.
 String message = StringUtil.sanitizeXmlString(
 (String) request.getAttribute(Dispatcher.ERROR_MESSAGE)
 );

 // Get error code that will returned
 int code = response.getStatus();

 var charset = StandardCharsets.UTF_8;

 // Get writer used
 var buffer = baseRequest.getResponse().getHttpOutput().getBuffer();
 var out = new ByteBufferOutputStream(buffer);
 var writer = new PrintWriter(new OutputStreamWriter(out, charset));

 // Set content type, encoding and write response
 response.setContentType(MimeTypes.Type.TEXT_PLAIN.asString());
 response.setCharacterEncoding(charset.name());
 writer.print("HTTP ERROR ");
 writer.print(code);
 writer.print("\nMessage: ");
 writer.print(message);
 writer.print("\nURI: ");
 writer.print(request.getRequestURI());


 writer.flush();
 } catch (BufferOverflowException e) {
 baseRequest.getResponse().resetContent();
 }

 baseRequest.getHttpChannel().sendResponseAndComplete();
 }
}

When we have the error handler ready then it registering it is easy. To do this we will create a custom configuration which implements WebServerFactoryCustomizer with @Configuration annotation. In a customize method we will create a customizer and add a newly created error handler.

Seems simple, but be sure to put this configuration class in a package that is scanned by Spring @ComponentScan annotation!

package pl.net.banach.customizeJetty;

import org.springframework.boot.web.embedded.jetty.JettyServerCustomizer;
import org.springframework.boot.web.embedded.jetty.JettyServletWebServerFactory;
import org.springframework.boot.web.server.WebServerFactoryCustomizer;
import org.springframework.context.annotation.Configuration;

@Configuration
public class JettyConfiguration
 implements WebServerFactoryCustomizer<JettyServletWebServerFactory> {

 @Override
 public void customize(JettyServletWebServerFactory factory) {
 JettyServerCustomizer customizer = server -> {
 server.setErrorHandler(new CustomJettyErrorHandler());
 };
 factory.addServerCustomizers(customizer);
 }
}

And that’s all - from now all errors that go to Jetty (application server) will be handled by our custom handler. :-)

How to expose local service using nginx and SSH

Fri, 25 Mar 2022 20:20:00 +0100

One of my colleagues needs to expose the local running app to an external service. There were simple constraints - the domain name under which service was exposed cannot change (because it needs to be whitelisted) and need to be a subdomain of the company domain.

They already have some virtual machines for developers with external IP adresses and SSH access running. I’ve proposed using them to solve this task - below you can find the solution that can be applied.

What will be needed:

publicly available server (external IP) with (GNU/)Linux and nginx (for this post I’m assuming it is Ubuntu),
user and permissions to change nginx configuration (sudo/root),
SSH access for that server,
some domain name, for example - some.domain.tld - pointing to the server external IP.

Let’s start with configuration - in /etc/nginx/sites-available/some.domain.tld write:

server {
listen 80;
listen [::]:80;
gzip on;
server_name some.domain.tld;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_redirect off;
proxy_set_header Host 127.0.0.1;
proxy_set_header X-Original-Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}

This configuration will proxy requests for some.domain.tld to the local port 8080 on the server.

To enable it we need to link this configuration to sites-enabled directory using command:

ln -s /etc/nginx/sites-available/some.domain.tld /etc/nginx/sites-enabled/some.domain.tld

and restart nginx - systemctl restart nginx. Now under domain some.domain.tld visitors will see an error page with the message “bad gateway” - all because on 8080 port there is nothing.

Now, with the power of a ssh tunnel, we will make this 8080 port on remote server will point to some port on our local machine.

To expose our local service we can use the command:

ssh -N -R $PORT_ON_SERVER:localhost:$LOCAL_PORT $LOGIN@$SERVER

where:

$PORT_ON_SERVER is the port which we forward request to on server,
$LOCAL_PORT - local port on dev machine where something is running,
$LOGIN and $SERVER are the username and address of the server running proxy.

Assuming that username is alice, the server is available under some.domain.tld domain and our local service is available under port 4502:

ssh -N -R 8080:localhost:4502 alice@some.domain.tld

And that’s all - after opening the domain in the browser we will see our local service. And anybody on the Internet can also view it, so watch out! ;-)

How to prevent running script if there are changes in local Git working space

Fri, 30 Jul 2021 09:49:00 +0100

Recently I spent some time making improvements around deploying an application. Some of them are bash scripts automating some boring actions. All of them has one common part - should not be run if there are any changes (staged or not) in the local Git repository (working tree). Fortunately, it is simple to incorporate checks like this into scripts!

To get the information about staged (added with git add) and not staged files we will use git diff command. Without any parameters, it will give us detailed information of what changed. That is a bit too much than our needs, so we will use --stat flag to get only statistics - path to file and the number of lines added and removed:

# ~/repository> git diff --stat
unstagedFile.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

For staged files we will use very similar command - it will be git diff --stat but with --cached flag:

# ~/repository> git diff --cached --stat
stagedFile.txt | 1 +
1 file changed, 1 insertion(+)

Both commands will return empty strings when no changes. We will use that information to show the message and stop (exit) script. In the end, script will look like this:

#!/bin/bash

# Fill up variables
STAGED_CHANGES=`git diff --cached --stat`
NOT_STAGED_CHANGES=`git diff --stat`

# Check if there are any staged but not committed changes
if [ ! -z "$STAGED_CHANGES" ]
then
 # Show message
 echo -e "You have staged, but not committed changes. Not releasing!"
 # And exit with non-zero code
 exit 1;
fi

# Check if there are any not staged
if [ ! -z "$NOT_STAGED_CHANGES" ]
then
 # Show message
 echo -e "You have not staged and not committed changes. Not releasing!"
 # And exit with non-zero code
 exit 1;
fi

## Anything else we need to do! ##

This script:

run commands mentioned above,
store results in variables,
if any of those variables are not empty - show the message and exit script with non-zero return value.

Why non-zero return value? Because by default 0 is treated as “everything was OK” and any other value means “error”. This allows to chain commands like doSomething && doMagic - in that case, doMagic will run only if doSomething return exited with 0.

Bonus stuff - we can make output red using some magic numbers which we can put in a script (in echo command):

#!/bin/bash
RED_START="\033[1;31m"
RED_END="\e[0m"

echo -e "Normal message!"
echo -e "${RED_START}Normal message but in RED!${RED_END}"

The result of the script above will look like this:

And that’s all folks! If you find this post useful - let me know! :-)

How to put pom.xml version and build date in properties?

Fri, 04 Jun 2021 21:27:55 +0100

While working on webapp API in Java I need to send the app version and the build date to the frontend. But how to make this?

As my API build is based on maven I thought about getting version from pom.xml file. So, let’s make it this way!

Solution! Almost…

I need to put in the pom.xml file configuration responsible for resources filtering:

<build>
 <!-- clipped -->
 <resources>
 <resource>
 <directory>src/main/resources</directory>
 <filtering>true</filtering>
 </resource>
 </resources>
</build>

And in the app.properties properties which will be replaced during build:

build.version=${pom.version}
build.date=${timestamp}

After the build my app.properties is filled with expected data:

Now I can access version from POM and last build in Java app easily!

And fin^H^H… another problem?

Everything works smoothly, I can get the version from the pom.xml and also the build date. But… a favicon is now broken! What?!

Frontend is deployed along with backend (using Javalin static files feature and files were loaded from resources folder.

It turns out that the resource filtering plugin processe favicon.ico (in fact all .ico files) and broke them by saving them incorrectly. So I need to exclude those files from filtering!

Final solution

Final configuration in the pom.xml looks like in snippet below.

It processing all files in src/main/resources except all .ico files. But I want .ico in resource folder - so I need add them but without filtering (processing them).

<build>
 <!-- clipped -->
 <resources>
 <resource>
 <directory>src/main/resources</directory>
 <filtering>true</filtering>
 <excludes>
 <exclude>**/*.ico</exclude>
 </excludes>
 </resource>
 <resource>
 <directory>src/main/resources</directory>
 <filtering>false</filtering>
 <includes>
 <include>**/*.ico</include>
 </includes>
 </resource>
 </resources>
</build>

And that’s all - everything is now OK ;-)

Why my session is not persisted?! Another story of (de)serialising...

Thu, 14 Jan 2021 09:00:00 +0100

Yep, that’s another story of “always check if serialising and de-serialising works as expected”. And some kind of reminder for future-me if I forgot about this! ;-)

Session of logged users seems to be a pretty easy topic, yep? For sure it is! What if you want to share that session between different instances of your app? That seems quite easy too - let’s store it in a database and you’re good to go.

Need and sort of “background”

For my last project, I’m using a simple web framework called Javalin, which runs default on Jetty. And after making PoC I’ve come across of topic “single user using many app instances”. Fortunately, there is even tutorial about it on Javalin page (here). I’ve checked it, wrote a bit code aaaand… it is not working as expected!

Problem

When enabled saving session into database and user was… logged out instantly! Error 401 was sent from the secured resource and frontend was redirecting to the login which invalidates session (which, in fact, was desired behaviour). But the question is - why this 401 was sent if the user logged in correctly?

After debugging and looking into saved session object in database I’ve found out that there is NO USER DATA THERE!

Wait, what? I’m sure that I’ve put that data into the session. It works if the session was in memory!

Let’s see how writing and reading values into session looks in Javalin:

// saving value
ctx.sessionAttribute("mystery", "I like trains");

// and reading value to the "value" variable
var value = ctx.sessionAttribute("mystery");

Pretty simple, yep? And this is how saving user details was in my app:

var userDetails = new UserDetails();
// ... filling up data and saving to session
ctx.sessionAttribute("USER", userDetails);

Looks the same… and not working. But mystery above works, so what the heck is going on?!

Solution!

You might already know because I’ve already written it in the beginning - serialisation. Session store (from class JDBCSessionDataStoreFactory) didn’t know how to save object with user details to the database. So it simply ignores it. And the rest of the app didn’t work because there was no user data, so no info about user roles, so no cookies and big “NONONO”.

So, solution was simply to serialise and de-serialise it, for example as a JSON. For that I’ve used Jackson mapper:

// yep, simple com.fasterxml.jackson.databind.ObjectMapper
var objectMapper = new ObjectMapper();

// serialize before saving to session
var userDetails = new UserDetails();
// ... filling up data and saving to session
ctx.sessionAttribute("USER", objectMapper.writeValueAsString(userDetails));

// and reading it in some other place
String userDetailsStr = ctx.sessionAttribute(USER_SESSION_KEY);
var userDetails = objectMapper.readValue(userDetailsStr, UserDetails.class);

And everything started to work smoothly and as expected!

Takeaways

I will repeat myself from the beginning - always check if serialising and de-serialising works as it should. And additionally - check if data is saved. That can save a lot of work and time. :-)

Git config based on current (sub)folder

Sun, 29 Nov 2020 16:00:00 +0100

Some time ago I’ve looked over my current company repositories. Surprisingly there was a lot of commits with emails that are not company ones. Instead of those - a lot of gmail.com, outlook.com and other free email providers!

That looks a bit unprofessional, isn’t it? Even if we do some freelance gigs - we probably want to put nicer email than private one used for social websites. And if, for some reason, we’re forced to use company email - we need to be sure that it will be used!

So, what we can do to make it better? Just configure it with couple lines of code ;-) Let’s assume that all our work-related stuff will live in ~/work folder and all other is personal. So, let’s start with a simple ~/.gitconfig configuration:

# ~/.gitconfig
[user]
name = Johny Mnemonic
email = johny@mnemonic.tld
[includeIf "gitdir:~/work/"]
path = ~/work/.gitconfig

Configuration in user section will be default one. We will overwrite it in other configuration files, like in folders with work.

Let’s then create an additional configuration for work, just in our work folder:

# ~/work/.gitconfig
[user]
email = johny@memory.courier.tld

We want to put our name in commits, yep? So only one thing that we overwrite will be the email address. Instead of private one, there will be company email.

And that’s it. Now all repositories, that didn’t have set up individual user settings, will use ones that are based on the folder, e.g.:

~/work/super-duper will use work configuration,
~/project/my-website will use private (default) one.

I hope that “short writeup” will help somebody in some way. :-) Also - did you have any comments? Drop me a line on Twitter!

MacOS - Kamil Banach

Building multi-architecture container images on GitLab CI

1. Install the required emulation support

2. Update GitLab Runner configuration

3. Configure the image step using Buildah

Using Cloudflare Tunnel to expose a local dev app

Export and import secret GPG keys from backup

1. Copy from the backup to the home directory

2. Verify that keys are there

3. Export keys from the backup

4. Import keys from the file

5. Verify and cleanup

Fixing suspend after login in KDE in clamshell mode

Adding SSH keys on autostart in KDE (for IntelliJ)

Creating bucket automatically on local MinIO with Docker Compose

Base Docker Compose

Service configuration for creating buckets

Final Docker Compose

Restricting access to specific Docker images in Nexus

Steps and assumptions

1. Configuring Content Selectors for Docker Login and accessing image

2. Creating privileges

3. Creating the role and assigning it to the user

End notes

Exposing local app (like Home Assistant) with autossh

Steps outline and assumptions

1. Install autossh

2. Terminal: Create user and key pair

3. Remote: Create a user and add the public key to the authorized ones

4. Test connection!

5. Create a service to run and manage the connection

6. Reverse proxy

End notes

When JavaScript regex can surprise you - a silly bug story

Accessing Kubernetes cluster using SSH tunnel

MongoDB sequences (auto-increment) - The Java Way

Reading JWT token claims without a library

How to customize Jetty in Spring - Custom Error Handler

How to expose local service using nginx and SSH

How to prevent running script if there are changes in local Git working space

How to put pom.xml version and build date in properties?

Solution! Almost…

And fin^H^H… another problem?

Final solution

Why my session is not persisted?! Another story of (de)serialising...

Need and sort of “background”

Problem

Solution!

Takeaways

Git config based on current (sub)folder

1. Install `autossh`