steps

3d printing parts

Just like for the numpad I designed the parts with openscad, the parts and bash scripts are in the same repository here.
The script keyboard60.sh can be used to generate the stl files for the backplate and case. They’re both cut in half to make them fit on my 3d printer plate.
If you want to 3d print the keycaps, there is a script too. But I personally used keycaps I already had on the side instead, mostly to see the letters better on the keycaps. The side engraving on my 3d printed keycaps is not that visible.
I printed the parts with my bambulab P1S 3d printer, I used a 0.4mm nozzle and a 0.16mm layer height, white PETG filament as the material.
I used T8000 glue to glue the parts.

The backplate looks like this before gluing the two halves:

With the switches mounted (I used MMD holy panda switches this time too):

handwiring the keyboard

Just like with the numpad we first need to bend the diodes so that it’s easier to solder them to the switches. I then soldered the rows with the legs of the diodes and cut the extra length after the anode.
The keyboard is handwired columns to rows, so the diodes are soldered with the anodes soldered to the switches pins (the red part here). I used 1N4148 diodes as they’re very cheap.

And then after a few hours of soldering, and gluing the two haves together:
(I also mounted the stabilizers, this time I used cheap plated mounted stabilizers.)

I used yellow and green wires alternating them between the columns to have an easier time soldering them to the microcontroller and writing the firmware after. I also used a pen to mark where to strip the wire to solder it to the pins. It was more convenient than just using my thumb to hold the wire where I have to strip it.

And this time too I used a Pro Micro NRF52840.

flashing the firmware

I used ZMK to flash the firmware, you can find the ZMK configuration in this repository and this one for github action to automate the build process. This keyboard is named keeb60_3d. Like in the previous blog post, I recommand flashing the firmware before clipping the backplate in the case as you might have to reset the microcontroller to flash a fixed firmware.

assembling the keyboard

I glued the two halves of the keyboard, taped the battery on the side of the case, soldered it to the microcontroller and the power switch of the keyboard.
Like last time the switch is a 15mm round switch like this one. And the battery is a 3.7V LiPo battery with a 320mAh capacity (for the bluetooth).

I then glued the microcontroller in its holder, clipped in the backplate to the holder and mounted the keycaps.

final result

The keyboard:

The power switch and USB C port in the back:

steps

3d printing parts

I designed the parts with openscad, the repository is available here.
I used the script keycaps_numpad.sh and the openscad script xda_keycap.scad to generate the stl files for the keycaps with an engraving on the side for each keycap. Then generated the stl files for the backplate and case with the files backplate_numpad.scad and case_numpad.scad.
I then printed them with my bambulab P1S 3d printer, I used a 0.4mm nozzle and a 0.08mm layer height. I used white PETG filament to print all the parts. All the parts took about 12 hours to print.
Here is the result for the 3d printed parts:

You’ll notice the backplate and the case changed between the two pictures. I changed the backplate design to be able to fit stabilizers instead of printing them myself. And for the case I changed the design to have stronger pillars and also enabled supports generation in the slicer.
You’ll also notice the keycaps were printed with the side, and not the bottom, facing the plate. It takes longer to print but gives a smoother top with a XDA keycap profile. The engraving was printed facing away from the plate to make the seam between the front and top of the key smoother.

mounting the switches and stabilizers on the backplate

I used MMD holy panda switches and cheap plate mounted stabilizers that I glued on the backplate. Just be careful not to glue the metal part to the stabilizer and pay attention to the orientation of the metal parts so that they don’t collide with the pillars in the case.

You’ll notice some switches have 2 additional legs, they’re the same switches apart from this variation which doesn’t matter in this build. These two additional plastic legs are for PCB mount builds but are still adequate for plate mount builds. Just buy the cheapest version, or the one in stock with your supplier.

handwiring the keyboard

bending the diodes

The diodes are just there to have the current flowing in one direction (in my build from the columns to the rows) so you can use whichever diodes you have. I used 1N4148 diodes myself as they’re very cheap.
We first need to bend the diode to have an easier time soldering them to the switches pins, I used the edge of my desk and then a small L shaped hex key to bend the diodes. For this build we need to prepare 21 diodes.
Pay attention to the orientation of the diode, the anode (red part here) needs to be where the bend is while we keep the wire after the cathode (black part) straight

soldering the diodes

We then need to solder the diodes to one pin for each switch, you can pick the “top” or “bottom” pin, it doesn’t matter as long as you’re consistent with your rows and columns wiring later. You can stay consistent and always pick the same pin to have an easier time wiring the rows and columns but electrically it doesn’t matter. After soldering the diodes you can cut the extra wire after the anode.

wiring the rows

I used the extra wire after the cathode on the diodes to wire the rows like this:

wiring the columns and the microcontroller

After wiring the rows, wire the columns using the other pin on each switch. And then wire each row and column to a pin on your microcontroller. I used a pro micro nRF52840 as it support bluetooth, is supported by ZMK, and is pretty cheap. I also wired a 3.7V LiPo battery with a 320mAh capacity to the controller to be able to use the keyboard wirelessly. The capacity doesn’t matter much, above 300mAh is good to have a long lasting battery. At least if you don’t plan to use RGB leds.
Also note to which pin you wire each row and column to adapt the ZMK layout later.

flashing the firmware

I recommend flashing the firmware before clipping the plate in the case so that you can easily access to reset pin to reset your microcontroller if you mess up the firmware and proceed with trial and error with ZMK.
I have this repository and this one on github as the build process is simplified with github action. The config for this keyboard is in zmk-config/boards/shield/numpad3d, in there you need to define the layout in numpad3d.keymap and the GPIO mapping for each row and column in numpad3d.overlay. You can also enable the bluetooth and tweak some features in numpad3d.conf. You then need to specify the keyboard to build and which microcontroller is used in zmk-config/build.yaml.
To flash the firmware you plug in the microcontroller and copy the firmware to the detected disk device, the microcontroller will then automatically reset itself.

assembling the keyboard

You can then assemble the keyboard. I used electrical tape to keep the microcontroller and the battery in place in the case. After that I clipped in the plate in the case and added the keycaps on the switches. Here is the final result:

possible improvements

Overall 3d printing and handwiring this keyboard was a fun project but, as always, there are possible improvements, I’ll list them here in no particular order.

• Adapting the github action automation to gitea action.
• Designing a screw in cover to hold the microcontroller and battery in place instead of using electrical tape.
• Multi filament printing and having a text in a different color instead of an engraving for the keycaps, though I don’t own an AMS yet. Currently the keycaps look okay during the day, but it’s harder to see the engraving in low light conditions.
• Adding a switch on one of the battery wire to be able to turn off the keyboard. Currently it’s constantly on.

Update 24/03/2026

I modified the case a little and added a switch for the battery to turn off the keyboard. The switch I used is a 15mm round switch like this one (sanitized and non affiliated link).

What is waydroid?

Waydroid is a container-based approach to boot a ful android system on a regular linux system with an x86 or ARM CPU, and so has less overhead than an android x86 virtual machine to run android apps on a linux system. Waydroid only works in a wayland session but it’s still possible to use a nested session if you use X11, which will be covered in this guide.

Installation guide

Requirements

A kernel which comes with the rust_binder module is necessary to run waydroid, linux-zen kernel includes this module.

Other kernels

If you’re using another kernel you can add it via DKMS (note that you can use another aur helper than yay).

yay -S binder_linux-dkms

Then you can manually load it:

sudo modprobe binder-linux devices=binder,hwbinder,vndbinder

Or load it automatically at boot:

echo "binder_linux" > /etc/modules-load.d/binder_linux.conf
echo "options binder_linux devices=binder,hwbinder,vndbinder" > /etc/modprobe.d/binder_linux.conf

Installing necessary packages:

sudo pacman -S waydroid

[On X11]

If using X11, you’ll need to run a nested wayland session, a simple solution is using cage. You could also use weston.

sudo pacman -S cage

Initializing waydroid:

sudo waydroid init

Or with google apps support:

sudo waydroid init -s GAPPS

Running waydroid

This command will automatically start the waydroid container and a session before showing the UI.

waydroid show-full-ui

Otherwise if you want a CLI, you have to start the container and then a session:

sudo systemctl start waydroid-container.service
waydroid session start

Useful commands

[On X11]

On X11 waydroid container can be started but then all waydroid commands need to be run inside a nested wayland session.
If you just need waydroid UI the simplest is with cage:

cage -- waydroid show-full-ui

If you need the command line then you need to have a console running inside a wayland session. For example with Konsole:

cage -- konsole

You can then type the commands the same as described above.

Firewall rules and packet forwarding

You need some additional rules in your firewall if you want the network to work inside waydroid. For example with nftables you need these additional rules in your tables:

table inet filter {
        chain input {
                # -------------------------------- waydroid
                iifname "waydroid0" accept comment "Allow incoming network traffic from WayDroid"

        }

        chain forward {
                # -------------------------------- waydroid
                iifname "waydroid0" accept comment "Allow incomming network traffic from WayDroid"
                oifname "waydroid0" accept comment "Allow outgoing network traffic from WayDroid"
        }
        chain output {
        }
}

You also need to enable packet forwarding. To check if it’s already enabled:

sysctl net.ipv4.ip_forward
sysctl net.ipv6.conf.all.forwarding

If it’s not enabled you can permanently enable it in the file /etc/sysctl.conf by uncommenting the lines net.ipv4.ip_forward=1 for IPv4 and net.ipv6.conf.all.forwarding=1 for IPv6. Please note that in most cases you can for now just enable the IPv4 packet forwarding and ignore the IPv6 one.
And to reload the configuration:

sudo sysctl -p /etc/sysctl.conf

Additional notes

1) clipboard sharing

If you want to share the clipboard between a wayland session and waydroid UI you need to install the packages python-pyclip and wl-clipboard.
It however won’t work with X11 and nested wayland sessions.

2) app stores

You might want to install aurora store, an open source google play store client not requiring a google account. And an F-Droid client like droidify.

3) GPU

If you have an Intel or AMD GPU it should work out of the box. But if you have a NVIDIA GPU you’ll need to enable software rendering. For that in /var/lib/waydroid/waydroid.cfg add the following:

[properties]
ro.hardware.gralloc=default
ro.hardware.egl=swiftshader

and then run:

sudo waydroid upgrade --offline
sudo systemctl restart waydroid-container.service

4) Running ARM apps

ARM apps won’t work at first if you have a x86 CPU, it’ll say the app is incompatible for your device when trying to install it. To use arm apps you need to install a translation layer. It’s recommanded to use libndk on AMD CPUs and libhoudini on Intel CPUs. To do that:

yay -S waydroid-script-git

sudo waydroid-extras install libndk 
# or
sudo waydroid-extras install libhoudini 

sudo systemctl restart waydroid-container.service

And if you’re interested in learning more about Intel houdini you can have a look at this presentation, and in video

5) Disabling on screen keyboard

By default waydroid shows AOSP on screen keyboard, which is useless on a computer with a keyboard already, to disable it the setting is in Settings > System > Languages & input > Physical keyboard > Use on-screen keyboard

6) SELinux

This module is necessary for waydroid to work:

module local-waydroid-nft 1.0;

require {
        type virtd_t;
        type iptables_t;
        class process { noatsecure rlimitinh siginh };
}

#============= virtd_t ==============
allow virtd_t iptables_t:process { noatsecure rlimitinh siginh };

You can compile it and load it with these commands (with the content above in a file local-waydroid-nft.te):

checkmodule -m -o local-waydroid-nft.mod local-waydroid-nft.te
semodule_package -o local-waydroid-nft.pp -m local-waydroid-nft.mod
semodule -i local-waydroid-nft.pp

And this script makes starting waydroid more convenient:

#!/bin/bash
sudo /usr/lib/waydroid/data/scripts/waydroid-net.sh start
cage -- waydroid show-full-ui

7) Additional troubleshooting

Finally you might want to check the archwiki directly if having issues with waydroid.
And although it’s quite old and contains some unecessary steps now, you can check this guide too.

Pre-requisite: packer and its plugins

On archlinux:

sudo pacman -S packer

then independently of your distribution:

packer plugins install github.com/hashicorp/qemu
packer plugins install github.com/hashicorp/chef

Steps:

1) Clone metasploitable3 repository

git clone https://github.com/rapid7/metasploitable3.git
cd metasploitable3

2) Disable Vagrant post-processor

The default template packages the build in a .box Vagrant file which is unnecessary. Backup the template and then edit it.

cp packer/templates/ubuntu_1404.json packer/templates/ubuntu_1404.json.bak

In packer/templates/ubuntu_1404.json remove the entire post-processors block.
You can check if the JSON file is valid with this command:

python3 -m json.tool packer/templates/ubuntu_1404.json >/dev/null && echo "OK"

If it doesn’t print OK the JSON is not valid

3) Docker fix

Modern docker is broken with metasploitable3.
Backup the original file:

cp chef/cookbooks/metasploitable/recipes/flags.rb chef/cookbooks/metasploitable/recipes/flags.rb.bak

Then remove the docker part from it:

sed -e "/^# 7 of Diamonds$/,/^end$/d" \
    -e "/^include_recipe 'metasploitable::docker'/d" \
    -e "/^directory '\/opt\/docker' do/,/^end$/d" \
    -e "/^cookbook_file '\/opt\/docker\/Dockerfile' do/,/^end$/d" \
    -e "/^cookbook_file '\/opt\/docker\/7_of_diamonds.zip' do/,/^end$/d" \
    -e "/^docker_image '7_of_diamonds' do/,/^end$/d" \
    -e "/^docker_container '7_of_diamonds' do/,/^end$/d" \
    -e "/^file '\/opt\/docker\/7_of_diamonds.zip' do/,/^end$/d" \
    chef/cookbooks/metasploitable/recipes/flags.rb > /tmp/flags.rb.$$ && mv /tmp/flags.rb.$$ chef/cookbooks/metasploitable/recipes/flags.rb

4) Build the image

packer build -only=qemu packer/templates/ubuntu_1404.json

It will open a GUI and start the installation, in the console you should see the installation process. It will connect to the virtual machine in SSH to install the vulnerable services.

5) Using the built image

You’ll find the built image in qcow2 format in output-qemu/, for example mine is output-qemu/metasploitable3-ub1404.
You can then import it in virt-manager.
Please note that the disk device bus type should be SATA, not VirtIO or the boot will fail as the initramfs inside the image does not have VirtIO drivers. Similarly the virtual network device model should be e1000e and not virtio. The default user and password will be vagrant.
Please also note that you should never connect this virtual machine to the internet as it’s intentionally made to have all sort of vulnerabilities. As such you should create an isolated network in virt-manager and connect it to this network only.
You can then study the vulnerabilities from an another virtual machine like a Kali linux or from your host using metasploit or other similar tools.

preparing installation media

Follow the initial steps from archlinux wiki to prepare your installation media, the most convenient solution is to copy the ISO to a ventoy USB key.
Then boot your archlinux ISO and first check you have internet access on your computer:

ping archlinux.org

If using WiFi, you’ll need to use iwctl

installation steps

1) setting up LVM and preparing volumes

1.1) loading the required kernel modules

modprobe efivarfs
modprobe dm-crypt 
modprobe dm-mod 

1.2) partition table

Find the disk you want to use to install your system with lsblk. For me it’s vda as I’m using a virtual machine to write this guide.
important: Select a GPT parition table type and not MBR.
Create a partition table with cfdisk /dev/vda (or your prefered tool) and create 2 partitions:

• /dev/vda1 as ef EFI (FAT-12/16/32) type, a size of 512MB is fine
• /dev/vda2 as 83 Linux filesystem type for the rest of the disk

Write the partition table to the disk.

1.3) setting up the encrypted volume

Create the encrypted volume, it will ask you for a confirmation and let you choose a passphrase. (Note that PBKDF2 key derivation algorithm is weaker than Argon2 but is required when using the default grub bootloader, the installation using systemd-boot will not be covered in this guide.)

cryptsetup luksFormat --type luks2 --pbkdf pbkdf2 /dev/vda2

Then open it with the passphrase chosen.

cryptsetup luksOpen /dev/vda2 luks

1.4) setting up LVM

We will create 3 volumes, one for the SWAP, one for the ROOT filesystem and one for the HOME filesystem. Adapt the sizes to what is appropriate for you, in my case I’m using a virtual machine with a 25GB disk so I won’t create a huge root volume.

pvcreate /dev/mapper/luks
vgcreate system /dev/mapper/luks
lvcreate -L 1G -n swap system
lvcreate -L 10G -n root system
lvcreate -l 100%FREE -n home system

1.5) formating and mounting the volumes

I’ll use a BTRFS filesystem but use the filesystem you prefer.

#formatting
mkfs.fat -F32 /dev/vda1
fatlabel /dev/vda1 BOOT
mkswap -L SWAP /dev/mapper/system-swap
mkfs.btrfs -L ROOT /dev/mapper/system-root
mkfs.btrfs -L HOME /dev/mapper/system-home

#mounting
swapon /dev/mapper/system-swap
mount -o compress=zstd /dev/mapper/system-root /mnt 
mkdir -p /mnt/{home,boot,boot/efi,etc}
mount -o compress=zstd /dev/mapper/system-home /mnt/home
mount /dev/vda1 /mnt/boot/efi

Then create the fstab.

genfstab -pU /mnt >> /mnt/etc/fstab

2) base installation

2.1) installing required packages

We’ll use reflector to generate the mirrorlist. Adapt the country code to pick the closest mirrors.

reflector -c FR -p https -a 12 --sort rate --save /etc/pacman.d/mirrorlist

Then install the required packages and some useful packages.

pacstrap -i /mnt base base-devel linux linux-firmware linux-headers pacman-contrib man-pages btrfs-progs vim git bash-completion

2.2) chroot

Chroot into the system to continue the installation.

arch-chroot /mnt /bin/bash

2.2.1) locales, hostname, clock and timezone

In the file /etc/locale.gen, uncomment your locales (for example en_US.UTF-8 UTF-8)
You can also set your preferences for the virtual console in /etc/vconsole.conf, for example for a QWERTY layout:

KEYMAP=us
FONT=lat9w-16

And in /etc/locale.conf (LC_COLLATE=C for case sensitive sorting):

LANG=en_US.UTF-8
LC_COLLATE=C 

And finally generate the locales:

locale-gen 

You can set your hostname in /etc/hostname.

For your clock and timezone: (adapt to your timezone)

ln -sf /usr/share/zoneinfo/Europe/Paris /etc/localtime
hwclock --systohc --utc

2.2.2) root password and user creation

Set your root password with passwd
Then create a user (named sam here) in the wheel group (to use sudo) and set its password with:

useradd -m -G wheel sam
passwd sam

and uncomment the line containing %wheel ALL=(ALL:ALL) ALL in /etc/sudoers

2.2.3) SELinux installation (from AUR)

Log in as your created user and install an AUR helper to make things easier:

su sam
cd
git clone https://aur.archlinux.org/yay.git
cd yay
makepkg -si
cd

Then install the required packages for SELinux to work. It will ask you for replacements with conflicting packages, answer yes every time.

yay -S libsepol libselinux checkpolicy secilc setools libsemanage semodule-utils policycoreutils selinux-python python-ipy mcstrans restorecond
yay -S pam-selinux pambase-selinux coreutils-selinux findutils-selinux iproute2-selinux logrotate-selinux openssh-selinux psmisc-selinux shadow-selinux cronie-selinux
yay -S sudo-selinux

Note: If sudo-selinux fails to build, build it with --nocheck option:

cd ~/.cache/yay/sudo-selinux
makepkg -si --nocheck

Then exit your user, remodify /etc/sudoers to uncomment the line containing %wheel ALL=(ALL:ALL) ALL and relog as your user. After that:

sudo pacman -S less
yay -S systemd-selinux systemd-libs-selinux util-linux-selinux util-linux-libs-selinux
cd ~/.cache/yay/systemd-selinux
makepkg -si --nocheck

Due to a cyclic dependency which won’t be fixed the complete build will fail at first, that’s why you need to manually build systemd-selinux again after. For some reason less is also required for the build but not a build dependency.
Then more SELinux packages and a policy:

yay -S selinux-alpm-hook dbus-selinux selinux-refpolicy-arch

If the check fails for dbus-selinux build it with --nocheck option:

cd ~/.cache/yay/dbus-selinux
makepkg -si --nocheck

If you want to apply a fedora-style user context (as root):

semanage login -m -s unconfined_u __default__

2.2.4) necessary packages

Network for next boot:

pacman -S networkmanager
systemctl enable NetworkManager

grub and lvm2:

pacman -S grub efibootmgr lvm2

Secure boot:
Note: If you don’t want to bother with secure boot, do not run sbctl related command, and later when generating the boot image with grub, remove --modules="tpm" --disable-shim-lock from the command

pacman -S sbctl
sbctl create-keys
sbctl enroll-keys -m

linking TPM and LUKS key

Without this step, the computer is still vulnerable to evild maid attacks and a software keylogger could be installed by disabling the secure boot (clear CMOS for example). To make sure the encrypted device is linked to the TPM, we need to run the following command:

systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+7 /dev/vda2 

systemd-cryptenroll also support hardware security keys like FIDO2 tokens, in this case you can refer to the archwiki for the command syntax.
systemd-boot is also the recommended option instead of using grub when linking the TPM and LUKS key, you can then only have a PIN and also be protected in more scenarios.

2.2.5) opional packages

If you have an intel CPU:

pacman -S intel-ucode

If you have a laptop and want battery optimization:

pacman -S tlp
systemctl enable tlp

If you need bluetooth:

pacman -S bluez
systemctl enable bluetooth

If you want 32bits apps (necessary for some packages), in /etc/pacman.conf uncomment these lines:

#[multilib]
#include = /etc/pacman.d/mirrorlist

2.2.5) generating boot images

in /etc/mkinitcpio.conf on the MODULES=() line, add dm-mod and in the HOOKS=() line you should have:

HOOKS=(base udev autodetect modconf block keyboard encrypt lvm2 filesystems fsck)

Then:

mkinitcpio -p linux

sbctl post-hook should automatically sign /boot/vmlinuz-linux. Otherwise run:

sbctl sign -s /boot/vmlinuz-linux

Then in /etc/default/grub

• uncomment the line GRUB_UNABLE_CRYPTODISK=y
• in GRUB_CMDLINE_LINUX="" add cryptdevice=/dev/vda2:system root=/dev/mapper/system-root
• in GRUB_CMDLINE_LINUX_DEFAULT="" add lsm=selinux,landlock,lockdown,yama,integrity,bpf

Then:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=arch_grub --modules="tpm" --disable-shim-lock --recheck
grub-mkconfig -o /boot/grub/grub.cfg
sbctl sign -s /boot/efi/EFI/arch_grub/grubx64.efi

Please note that in a virtual machine you’ll need an emulated TPM for the virtual machine to boot if you want secure boot enabled.

3) exit and reboot

exit    # until you exit the chroot
umount -R /mnt
swapoff -a
reboot

4) post reboot steps

4.1) relabel files

check SELinux status with sestatus, it should be in permissive with refpolicy-arch as the loaded policy.
Relabel all the files correctly with the following command:

restorecon -RFv /

you might want to clean yay cache before doing that to have less files to relabel:

rm -rf ~/.cache/yay/*

4.2) enable auditd

enable auditd service to read AVC denials from SELinux later.

systemctl enable --now auditd

4.3) create and load necessary policy

Create a file requiredmod.te with the following content:

module requiredmod 1.0;

require {
        type auditd_etc_t;
        type getty_t;
        type var_run_t;
        type tmpfs_t;
        type local_login_t;
        type systemd_tmpfiles_t;
        type init_runtime_t;
        type devpts_t;
        type kernel_t;
        type device_t;
        type udev_t;
        type hugetlbfs_t;
        type udev_tbl_t;
        type policy_config_t;
        type tmp_t;
        type unconfined_t;
        type var_lib_t;
        type systemd_userdbd_runtime_t;
        type systemd_user_runtime_dir_t;
        type systemd_sessions_t;
        type systemd_userdbd_t;
        type etc_runtime_t;
        type systemd_logind_t;
        type file_context_t;
        type semanage_t;
        type selinux_config_t;
        type initrc_runtime_t;
        type sshd_t;
        class dir { write add_name remove_name getattr open read search };
        class file { getattr open read write create getattr ioctl lock relabelfrom relabelto setattr unlink };
        class sock_file write;
        class unix_stream_socket { read write ioctl connectto};
        class capability2 block_suspend;
        class filesystem { associate quotaget quotamod };
        class key { link search };
        class process { noatsecure rlimitinh siginh transition };

}

#============= getty_t ==============
allow getty_t tmpfs_t:dir { getattr open read };
allow getty_t var_run_t:file { getattr open read };
allow getty_t initrc_runtime_t:dir { getattr open read };

#============= local_login_t ==============
allow local_login_t init_runtime_t:sock_file write;
allow local_login_t systemd_logind_t:unix_stream_socket connectto;
allow local_login_t var_lib_t:dir { add_name remove_name };
allow local_login_t var_lib_t:file { create getattr lock open read setattr unlink write };

#============= sshd_t ==============
allow sshd_t local_login_t:key { link search };
allow sshd_t systemd_logind_t:unix_stream_socket connectto;
allow sshd_t unconfined_t:process { noatsecure rlimitinh siginh };

#============= systemd_tmpfiles_t ==============
allow systemd_tmpfiles_t auditd_etc_t:dir search;
allow systemd_tmpfiles_t auditd_etc_t:file getattr;

#============= systemd_sessions_t ==============
allow systemd_sessions_t kernel_t:dir search;
allow systemd_sessions_t kernel_t:file { getattr ioctl open read };

#============= systemd_user_runtime_dir_t ==============
allow systemd_user_runtime_dir_t etc_runtime_t:file { open read };
allow systemd_user_runtime_dir_t kernel_t:dir search;
allow systemd_user_runtime_dir_t kernel_t:file { getattr ioctl open read };
allow systemd_user_runtime_dir_t systemd_userdbd_runtime_t:sock_file write;
allow systemd_user_runtime_dir_t systemd_userdbd_t:unix_stream_socket connectto;
allow systemd_user_runtime_dir_t tmp_t:dir read;
allow systemd_user_runtime_dir_t tmpfs_t:filesystem { quotaget quotamod };

#============= systemd_userdbd_t ==============
allow systemd_userdbd_t initrc_runtime_t:dir { getattr open read search };

#============= devpts_t ==============
allow devpts_t device_t:filesystem associate;

#============= hugetlbfs_t ==============
allow hugetlbfs_t device_t:filesystem associate;

#============= kernel_t ==============
allow kernel_t self:capability2 block_suspend;

#============= tmpfs_t ==============
allow tmpfs_t device_t:filesystem associate;

#============= udev_t ==============
allow udev_t kernel_t:unix_stream_socket { read write ioctl };
allow udev_t udev_tbl_t:dir { write add_name };
allow udev_t var_run_t:sock_file write;

Run the following command to compile and load the module:

checkmodule -m -o requiredmod.mod requiredmod.te
semodule_package -o requiredmod.pp -m requiredmod.mod
semodule -i requiredmod.pp

And set a few booleans:

setsebool -P allow_polyinstantiation on
setsebool -P systemd_tmpfiles_manage_all on
setsebool -P ssh_sysadm_login on

Then in /etc/selinux/config, set SELinux mode to enforcing instead of permissive and reboot.
And that’s it, you now have a minimal archlinux installation in UEFI with full disk encryption, secure boot, and SELinux in enforcing mode.

why you shouldn’t use discord

Discord is a spyware

Discord is proprietary doesn’t make its source code available which makes it impossible to tell if it’s a spyware or not, but it does behave like one.

Data collected

Discord collects a large amount of sensitive user data like:

• IP Address
• Devices UUID
• Email address and phone number
• all text messages, images and voice chats This is stated in their privacy policy

Discord also doesn’t explicitely says it contains a process logger and logs a list of all the programs running on your computer if you have the app installed and not sandboxed. As such if you’re forced to use discord for some reason, a mitigation is to use discord through your browser only and not install any app.
Since discord is closed source we have no way to know if the privacy toggles in the options to disable this data harvesting do anything at all.
Discord claims it doesn’t make money selling their user’s data, but the simple fact they gather this data in the first place is a good enough reason not to use discord.

Phone number

It is possible to create a discord account without a phone number, but discord will randomly lock out users from their account and ask for a phone verification, this is especially true for TOR and VPN users. This feature is designed to extract sensitive information and not for security. In fact using something based on asymetric cryptography, like a passkey, would be a lot more secure.
Phone verification is one of the weakest verification method and is designed just to extract information.
If you’re not convinced yet it’s for data harvesting and not security, discord also only accepts mobile phone numbers, and will refuse verification with a landline or VOIP number. It doesn’t make sense for a phone verification.

Messages

Discord refuses to implement end to end encryption for private messages or servers and as such has the ability to read any message sent. According to their ToS they read “reported” messages only and scan images for sensitive content. While end to end encryption doesn’t make much sense for a large public server, anyone could join and decrypt previous messages, there is no reason not to implement it for private messages.
Discord also pushes server admins to make their server “community servers”, and in their ToS they state that they actively scan messages sent in community servers.
But regardless of what their ToS says, discord has the ability to read and log any message sent anyway. And discord being an American company, they are compelled to provide access to messages to the NSA under the PRISM program.
And even if discord implemented end to end encryption at one point, which they likely won’t, the client being proprietary makes it impossible to verify they wouldn’t keep a copy of the decryption keys or of the messages before they’re encrypted.

Discord is a burning library of Alexandria

Discord is a slow burning library of Alexandria. Discord cannot be indexed by search engines unlike forums and information stays locked inside discord. Many communities, even open source project (like Lutris) moved their community to discord instead of using a forum like every community did before discord existed. It forces users to have a discord account and join all these community servers to have access to this information
There is a lot of information and documentation that should be on wiki or forums and just aren’t anymore. And this information is being lost in real time with discord sometimes randomly suspending server owners accounts. Discord is now the real owner and the one controlling all this information and documentation instead of the communities themselves.

Discord randomly suspends account

Discord sometimes randomly suspends accounts without providing any reason, and the support is usueless when it comes to account suspensions… Or anything really.

Speculation on discord business model

Discord claims it doesn’t sell user data but it doesn’t make sense they stay afloat with just discord Nitro subscriptions. They received a lot of money from investors over the years. Why investors give discord money is unclear. But what is clear is discord as the ability with its massive data gathering to sell valuable information, or use this datamining to produce statistical models for advertisement (like games recommendations).

Alternatives

Finding alternatives to discord is hard because as said previously, a lot of communities moved to discord, it makes it hard to fully leave discord if you have friends or are part of communities there. But there are several alternatives to discord, at least for private messages with friends. Here are a few alternative I think are good.

Matrix

Matrix is to me the best alternative to discord. It is adequate both for direct messages and communities.

• It is open source
• The Matrix protocol pushes end to end encryption implementation in the clients
• It is decentralized and federated, meaning you can self host your own instance and still be able to communicate with people using other homeservers.
• It has an ecosystem built around it, you’re free to chose the client you prefer, the homeserver you prefer if self hosting it. And you can also use bridges to exchange messages with other platforms. The last point is especially nice if you still want to communicate with people using discord, you can do that through your matrix client and not your discord client.

Mattermost

Mattermost is another open source alternative you can self host although a plugin is necessary for end to end encryption and there isn’t any federation.
It is adequate for communities. However I still personally think a forum is better for public communities so that search engines can index them.

Signal

signal is another open source alternative (although it’s slightly shady for the server part) with end to end encryption. However it’s centralized (meaning you’re forced to use Signal server) and a phone number is required for registration.
Signal is more adequate for direct messages or group with not too many people than for big communities.

Session

session is another open source alternative with end to end encryption and a blockchain based decentralised network. The underlying protocols are less mature than the Signal protocol but unlike Signal, it’s not centralised and doesn’t require a phone number or email adress to create an account.
Like signal it is adequate for direct messages, not communities.

steps

1. Preparing the base system

I decided to go with a minimal install of debian 13. In raspberry Pi imager it’s in the “Raspberry Pi OS (other)” category.

Unfortunately with the Pi 5, the configuration from the imager letting you configure a user and the SSH when flashing the micro SD card seems to be broken so I configured it manually after flashing the Pi 5 when booting it for the first time. It asks for the user creation and password and then I just enabled SSH with:

systemctl enable --now ssh

(the service is ssh and not sshd on the Pi, it’s not a typo)

2. installing the required packages

First we need to install kodi and some packages to have sound and a minimal GUI support.

sudo apt install kodi weston mesa-utils mesa-vulkan-drivers pipewire wireplumber pulseaudio-utils

3. running Kodi

3.1) I first created a dedicated user and added it to the required groups to run Kodi as a systemd service:

sudo useradd -m kodi
sudo usermod -aG video,audio,input,render kodi

3.2) Then I enabled autologin for kodi on TTY1

sudo mkdir -p /etc/systemd/system/getty@tty1.service.d

and in this folder I created this file:

#/etc/systemd/system/getty@tty1.service.d/autologin.conf
[Service]
ExecStart=
ExecStart=-/sbin/agetty --autologin kodi --noclear %I $TERM

3.3) Then I enabled lingering for Kodi (which is needed to start user systemd services even without a shell session)

sudo loginctl enable-linger kodi

3.4) Finally I created and enabled the service to start Kodi on boot:

First creating the folder:

sudo mkdir -p /home/kodi/.config/systemd/user

And then a service unit file:

#/home/kodi/.config/systemd/user/kodi.service
[Unit]
Description=Kodi Media Center (DRM/GBM)
After=systemd-user-sessions.service
Wants=systemd-user-sessions.service

[Service]
ExecStart=/usr/bin/kodi \
  --standalone \
  --drm \
  --tty=/dev/tty1

Restart=on-failure
RestartSec=3

[Install]
WantedBy=default.target

After this making sure the ownership is correct:

sudo chown -R kodi:kodi /home/kodi

And then to enable the service:

sudo systemctl --user --machine=kodi@.host daemon-reload
sudo systemctl --user --machine=kodi@.host enable kodi

And Finally:

sudo reboot

4. checking logs

To check Kodi related logs, we can use the following command:

sudo journalctl _UID=$(id -u kodi)

It’ll show all the journalctl logs from the kodi user.

Steps

1. switch the required booleans

For hardware acceleration we need to let containers access devices in /dev/dri. DRI means Direct Rendering Infrastructure, the devices there are all the GPUs.
By default containers are not allowed access to these devices, to allow it we need to change a boolean:

sudo setsebool -P container_use_dri_devices 1

2. container creation

I created a pod for the logic and then the jellyfin container inside it, with the systemd services it looks like this:

pod

# pod-jellyfin.service

[Unit]
Description=Podman pod-jellyfin.service
Documentation=man:podman-generate-systemd(1)
Wants=network-online.target
After=network-online.target
RequiresMountsFor=/run/user/1000/containers
Wants=container-jellyfin-app.service
Before=container-jellyfin-app.service

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=70
ExecStartPre=/usr/bin/podman pod create \
        --infra-conmon-pidfile %t/pod-jellyfin.pid \
        --pod-id-file %t/pod-jellyfin.pod-id \
        --exit-policy=stop \
        --name jellyfin \
        -p 8096:8096/tcp \
        --replace
ExecStart=/usr/bin/podman pod start \
        --pod-id-file %t/pod-jellyfin.pod-id
ExecStop=/usr/bin/podman pod stop \
        --ignore \
        --pod-id-file %t/pod-jellyfin.pod-id  \
        -t 10
ExecStopPost=/usr/bin/podman pod rm \
        --ignore \
        -f \
        --pod-id-file %t/pod-jellyfin.pod-id
PIDFile=%t/pod-jellyfin.pid
Type=forking

[Install]
WantedBy=default.target

The port 8096 inside the container is used for the web interface (http).

container

# container-jellyfin-app.service

[Unit]
Description=Podman container-jellyfin-app.service
Documentation=man:podman-generate-systemd(1)
Wants=network-online.target
After=network-online.target
RequiresMountsFor=%t/containers
BindsTo=pod-jellyfin.service
After=pod-jellyfin.service

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=70
ExecStart=/usr/bin/podman run \
        --cidfile=%t/%n.ctr-id \
        --cgroups=no-conmon \
        --rm \
        --pod-id-file %t/pod-jellyfin.pod-id \
        --sdnotify=conmon \
        --replace \
        -d \
        --name=jellyfin-app \
        --device nvidia.com/gpu=all \
        -v /home/data/podman/jellyfin/cache:/cache:Z \
        -v /home/data/podman/jellyfin/config:/config:Z \
        -v /home/data/movies:/media/movies:ro,z \
        -v /home/data/music:/media/music:ro,z \
        --label io.containers.autoupdate=registry docker.io/jellyfin/jellyfin:latest
ExecStop=/usr/bin/podman stop \
        --ignore -t 10 \
        --cidfile=%t/%n.ctr-id
ExecStopPost=/usr/bin/podman rm \
        -f \
        --ignore -t 10 \
        --cidfile=%t/%n.ctr-id
Type=notify
NotifyAccess=all

[Install]
WantedBy=default.target

Of course you’ll want to adapt these volumes with your own media directories:

        -v /home/data/movies/:/media/movies:ro,z \
        -v /home/data/music:/media/music:ro,z \

Then enable and start the container:

systemctl --user daemon-reload
systemctl --user enable --now pod-jellyfin.service 

note:

for hardware acceleration I used --device nvidia.com/gpu=all as I have a NVIDIA GPU
To check that it’s working you can run:

podman exec -it jellyfin-app nvidia-smi

I should output something like this:

Fri Dec 26 13:48:07 2025       
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 580.95.05              Driver Version: 580.95.05      CUDA Version: 13.0     |
+-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce GTX 1050        Off |   00000000:01:00.0  On |                  N/A |
| 45%   28C    P8            N/A  /   75W |      11MiB /   2048MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|  No running processes found                                                             |
+-----------------------------------------------------------------------------------------+

If instead you get:

Failed to initialize NVML: Insufficient Permissions

You’ll need to install the container toolkit and generate a CDI specification file:

sudo dnf install cuda-toolkit nvidia-container-toolkit-base
sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml

If this still doesn’t work you might need to also turn another boolean on:

sudo setsebool -P container_use_xserver_devices 1

note 2:

Jellyfin documentation recommends using --device /dev/dri/:/dev/dri/ in their podman example but this doesn’t seem to work, at least not for NVIDIA GPUs. and the method described in the hardware acceleration part of the wiki is also different.

3. enabling hardware acceleration in jellyfin

In jellyfin web interface after setting up the server, you’ll want to go to your dashboard (click on the hamburger menu in the top left and then dashboard), then playback, then transcoding and from there enable hardware acceleration, with a NVIDIA GPU you should choose Nvidia NVENC.

note: does the VPN provider matter?

The VPN provider, if we don’t take into account privacy, doesn’t matter much as long as port forwarding is supported. Without port forwarding downloading torrents might still be possible but don’t expect a good seeding/leeching ratio.

For BitTorrent, the protocol behind, to work, at least one peer has to be an active node (have a publicly open port) and the goal of port forwarding is to have this publicly open port. With port forwarding enabled you increase the number of peers you can communicate with. And since more peers will be able to initiate a connection with you (passive nodes can always initiate a connection), you’ll have a better seeding/leeching ratio.

On less active or older torrents, port forwarding matters even more as if you end up in a situation where one peer has all the files, another peer wants to download them, but both have their ports closed, they won’t be able to establish a connection between each-other and the second peer won’t be able to download the torrent.

Even with closed ports, peers are still able to discover each other with the trackers, DHT (Distributed Hash Table) or PEX (Peer Exchange). Only the connection establishement part is affected.

note: Why is a VPN prefered when torrenting?

A VPN is prefered when torrenting mainly for privacy and risks reductions.
BitTorrent is not anonymous by design, every peer in the swarm can see your public IP address. By the way it’s how copyright monitoring companies are able to identify seeders and send copyright infrigement letters.

A VPN hides your public IP by exposing only the VPN endpoint. It helps not getting identified by copyright monitoring companies, and also against direct attack to your home connection from malicious peers. Without a VPN your IP can be logged accross long time periods and multiple torrents which allows profiling and targeted harassment.

It also encapsulates and encrypts traffic further so BitTorrent usage isn’t visible. Obfuscating your traffic might be useful against throtling as some ISPs detects BitTorrent via DPI (deep packet inspection) to throttle it or even throttle any kind of P2P traffic.

But keep in mind that a VPN doesn’t guarantee anonimity, the VPN provider can still see (and potentially log) your real IP address as well as the packets going through it.

Disclaimer:

hiding your IP address from copyright monitoring companies obviously doesn’t make piracy legal, it just drastically reduces the risks of you getting identified and caught.

Disclaimer 2:

A VPN doesn’t protect you against malicious torrent payloads (a trojan disguised as media for example) and attacks over the existing torrent connection (exploit vulnerabilities in the client, sending malformed data and so on…)

Steps

Creating the containers

1. Pod creation

First I created a pod, without an infrastructure --infra=false because we’ll use gluetun network and not the host network (which wouldn’t go through the VPN connection). A pod is not required, you could just create the qbittorrent and the gluetun container. But I prefered to create one to logically group the containers and also see them with the command podman pod ls.

The systemd unit file will look like this:

# pod-qbittorrent.service

[Unit]
Description=Podman pod-qbittorrent.service
Wants=network-online.target
After=network-online.target
RequiresMountsFor=/run/user/1000/containers
Wants=container-torrent-qbit.service container-torrent-gluetun.service

[Service]
Type=oneshot
RemainAfterExit=yes
Environment=PODMAN_SYSTEMD_UNIT=%n
TimeoutStartSec=30
TimeoutStopSec=30

ExecStart=/usr/bin/podman pod create \
	--pod-id-file %t/pod-qbittorrent.pod-id \
	--exit-policy=stop \
	--name qbittorrent \
	--infra=false \
	--replace

ExecStop=/usr/bin/podman pod rm -f --pod-id-file %t/pod-qbittorrent.pod-id

[Install]
WantedBy=multi-user.target

2. Gluetun container

We will use gluetun for the VPN connection.

First you need to create the secrets for WIREGUARD_ENDPOINT_IP, WIREGUARD_PUBLIC_KEY, WIREGUARD_PRIVATE_KEY. Creating these secrets is not necessary but it avoids exposing sensitive information in your configuration files.

With ProtonVPN when downloading a wireguard configuration it’ll look like this:

[Interface]
PrivateKey = <private_key>
Address = 10.2.0.2/32
DNS = 10.2.0.1

[Peer]
# BE#67
PublicKey = <peer_public_key>
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = <endpoint_IP>:51820

To create the secrets you’ll need to first derive the public key from the private key:

echo -n "private_key" > privkey
wg pubkey < privkey

Then you can create the secrets

echo -n "private_key" > /tmp/secret
podman secret create wg_sk /tmp/secret
echo -n "public_key" > /tmp/secret
podman secret create wg_pk /tmp/secret
echo -n "endpoint_IP" > /tmp/secret
podman secret create wg_ip /tmp/secret

Then the container unit file will look like this:
Of course you’ll need to adapt the path for the volume

# container-torrent-gluetun.service

[Unit]
Description=Podman container-torrent-gluetun.service
Documentation=man:podman-generate-systemd(1)
Wants=network-online.target
After=network-online.target
RequiresMountsFor=%t/containers
BindsTo=pod-qbittorrent.service
After=pod-qbittorrent.service

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=90
ExecStart=/usr/bin/podman run \
	--cidfile=%t/%n.ctr-id \
	--cgroups=no-conmon \
	--rm \
	--pod-id-file %t/pod-qbittorrent.pod-id \
	--sdnotify=conmon \
	--replace \
	-d \
	--name=torrent-gluetun \
	-p 8080:8080 \
	--stop-timeout 60 \
	--tmpfs /tmp \
	--cap-add NET_ADMIN \
	--cap-add NET_RAW \
	--device /dev/net/tun:/dev/net/tun \
	-v /home/data/podman/gluetun:/gluetun:z \
	-e VPN_SERVICE_PROVIDER=custom \
	-e VPN_TYPE=wireguard \
	--secret wg_ip,type=env,target=WIREGUARD_ENDPOINT_IP \
	-e WIREGUARD_ENDPOINT_PORT=51820 \
	--secret wg_pk,type=env,target=WIREGUARD_PUBLIC_KEY \
	--secret wg_sk,type=env,target=WIREGUARD_PRIVATE_KEY \
	-e WIREGUARD_ADDRESSES=10.2.0.2/32 \
	-e VPN_PORT_FORWARDING_PROVIDER=protonvpn \
	-e VPN_PORT_FORWARDING=on \
	--label io.containers.autoupdate=registry \
	docker.io/qmcgaw/gluetun:latest
ExecStop=/usr/bin/podman stop \
	--ignore -t 30 \
	--cidfile=%t/%n.ctr-id
ExecStopPost=/usr/bin/podman rm \
	-f \
	--ignore \
	--cidfile=%t/%n.ctr-id
Type=notify
NotifyAccess=all

[Install]
WantedBy=default.target

Here I put “custom” in the VPN_SERVICE_PROVIDER environment variable instead of “protonvpn”, or whichever VPN provider you might be using, because port forwarding wouldn’t work otherwise. “protonvpn is then later specified in theVPN_PORT_FORWARDING_PROVIDER environment variable.
You can have a look at the wiki in the option section for port forwarding if you use another VPN provider.

When looking at the logs from gluetun container with the command:

podman logs torrent-gluetun

you should see a line like this:

INFO [port forwarding] port forwarded is 45497

It’s the port you’ll want to use in qbittorrent. However check it again when you restart the container as this port can sometimes change.

3. Qbittorrent container

After the gluetun container, we can create the container for qbittorrent, we’ll make this container bind to gluetun container in order to use the network provided by it and correctly route the traffic through the VPN.
Don’t forget to adapt QBT_WEBUI_PORT to the one you prefer

# container-torrent-qbit.service

[Unit]
Description=Podman container-torrent-qbit.service
Wants=network-online.target container-torrent-gluetun.service
After=network-online.target container-torrent-gluetun.service
RequiresMountsFor=%t/containers
BindsTo=pod-qbittorrent.service container-torrent-gluetun.service
After=pod-qbittorrent.service

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=1860
ExecStart=/usr/bin/podman run \
	--cidfile=%t/%n.ctr-id \
	--cgroups=no-conmon \
	--sysctl net.ipv6.conf.all.disable_ipv6=1 \
	--rm \
	--pod-id-file %t/pod-qbittorrent.pod-id \
	--sdnotify=conmon \
	--replace \
	-d \
	--name=torrent-qbit \
	--network container:torrent-gluetun \
	--stop-timeout 1800 \
	--tmpfs /tmp \
	-e QBT_LEGAL_NOTICE=confirm \
	-e QBT_WEBUI_PORT=8080 \
	-v /home/data/podman/qbittorrent/config:/config:z \
	-v /home/data/podman/qbittorrent/data:/downloads:z \
	--label io.containers.autoupdate=registry docker.io/qbittorrentofficial/qbittorrent-nox:latest
ExecStop=/usr/bin/podman stop \
	--ignore -t 1800 \
	--cidfile=%t/%n.ctr-id
ExecStopPost=/usr/bin/podman rm \
	-f \
	--ignore -t 1800 \
	--cidfile=%t/%n.ctr-id
Type=notify
NotifyAccess=all

[Install]
WantedBy=default.target

managing the containers

All my unit files are in ~/.config/systemd/user

When you create new unit files, or change them, don’t forget to run

systemctl --user daemon-reload

Then you can start the pod like this:

systemctl --user start pod-qbittorrent.service

(or start it and enable it with enable --now instead of start)

And to stop it:

systemctl --user stop pod-qbittorrent.service

In case qbittorrent doesn’t get an external IP because it started before the VPN connection was established you can restart it like this

systemctl --user restart container-torrent-qbit.service

note:

You might have noticed that I use the option :z on my containers, this is because I use SELinux. You can read my post about SELinux here for more details.

note 2:

You might also have noticed I use a label on my containers:

--label io.containers.autoupdate=registry

This label is used to automatically pull the latest image and update the container whenever a new latest image is released. It is not necessary for this setup to work but is useful to have your containers automatically updated.

Purpose

The advantage of having a bridge for the virtual machines is the router sees each virtual machine as a separate machine. Each virtual machine is visible on the LAN and has an independent IP address. It also has the advantage of not requiring any additional configuration on the host firewall, when using a NAT network attached to a device forward rules are required to make it work.
For example for NATed connections I have the following additional rules in my nftables configuration:
note: I purposefully ommited the rest of the configuration and only left the rules for the NAT connection.

define qemu_bridge_if = "virbr0"
table inet filter {
        chain input {
                # -------------------------------- qemu
                iifname $qemu_bridge_if accept  comment "accept from VM"

        }

        chain forward {
                # -------------------------------- qemu
                iifname $qemu_bridge_if accept  comment "accept VM interface as input"
                oifname $qemu_bridge_if accept comment "accept VM interface as output"
        }
        chain output {
        }
}

Steps

1. Identify physical NIC:

First we have to identify the NIC (Network Interface Card) used by the host to connect to the internet.

To do this we can use the command ip a and look for the line with the IP address we have on the LAN:

Example output:
note: I purposefully ommited the other interfaces and anonymized the output

3: enp4s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
    altname enxAABBCCDDEEFF
    inet 10.0.0.42/24 brd 10.0.0.255 scope global dynamic noprefixroute enp4s0f0
       valid_lft 3600sec preferred_lft 3600sec
    inet6 fd00:dead:beef::1234/64 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fe80::abcd:ef12:3456:789a/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

The interesting information for us here is the interface name: enp4s0f0

2. Create the bridge

Once we have identified the interface we can proceeed with the bridge creation.

First creating the bridge: note: here it’s named br0, but name it how you prefer

sudo nmcli connection add type bridge ifname br0 con-name br0

Then attach the bridge to the interface:

sudo nmcli connection add type ethernet ifname enp4s0f0 master br0 con-name br0-enp4s0f0

Then move the IP configuration to the bridge:

sudo nmcli connection modify br0 ipv4.method auto ipv6.method auto
sudo nmcli connection modify br0-enp4s0f0 ipv4.method disabled ipv6.method ignore

With

$ nmcli connection show

You should see something like:

NAME                UUID                                  TYPE       DEVICE   
Wired connection 1  a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d  ethernet   enp4s0f0 
br0                 f0e9d8c7-b6a5-4987-9abc-1234567890a9  bridge     br0   

You can disable the old connection:

sudo nmcli connection down "Wired connection 1"

And optionally delete it:

sudo nmcli connection delete "Wired connection 1"

After that bring up the bridge:

sudo nmcli connection up br0

Then with

ip a show br0 | grep "inet "

You should see something like:

    inet 10.0.0.125/24 brd 10.0.0.255 scope global dynamic noprefixroute br0

And enp4s0f0 should no longer have an IP address.

note:

If you have an IP address reservation in your router using the MAC address from your NIC, you should now replace it with the MAC address from br0. The virtual machines will still appear as different machines and get their IP address with the DHCP.

3. Creating virtual machines

Then with virt-manager when creating virtual machines, skip the network configuration and don’t add a virtual network, instead in the virtual machine informations, add new hardware, go to network and select bridged device (here the device name will be br0).