In order to have AVIF support in Digikam in Debian, you need to install kimageformat-plugin.
$ sudo apt install qt5-avif-image-plugin kimageformat-plugins
Alternatively, similar support is offered via qt5-avif-image-plugin, but Debian recommends the kimageformat-plugin for general users.
Many corporate environments have internal DNS servers that are required to resolve internal resources. However, you might prefer a different DNS server for external resources, for example 1.1.1.1 or 8.8.8.8. This allows you to use more secure DNS features like DNS over TLS (DoT). The solution is to set up systemd-resolved as your DNS resolver, and configure it for split DNS resolving.
Starting with systemd 251, Debian ships systemd-resolved as a separate package. If it isn’t installed, go ahead and install it.
$ sudo apt install systemd-resolved
$ sudo systemctl enable --now systemd-resolved.service
Create the following configuration file under /etc/systemd/resolved.conf.d/99-split.conf:
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
Domains=~.
DNSOverTLS=opportunistic
Domains=~. gives priority to the global DNS (1.1.1.1 in our case) over the link-local DNS configurations which are pushed through DHCP (like internal DNS servers).
DNSOverTLS=opportunistic defaults to DNS over TLS but allows fallback to regular DNS. This is useful when corporate DNS doesn’t support DNS over TLS and you still want to resolve corporate internal domains.
Restart systemd-resolved to reload the configuration:
$ sudo systemctl restart systemd-resolved
The final step is to redirect programs relying on /etc/resolv.conf (possibly through the glibc API) to the systemd-resolved resolver. The recommended way according to the systemd-resolved man page is to symlink it to /run/systemd/resolv/stup-resolv.conf.
$ sudo ln -rsf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
F5 VPN doesn’t play well with the above configuration. First, F5 VPN tries to overwrite the DNS configuration in /etc/resolv.conf, by removing the existing file and replacing it with its own (pushing corporate DNS server configuration through it). The solution is to prevent F5 VPN from deleting the /etc/resolv.conf, by setting it to immutable. However, we cannot chattr +i a symlink. We have to resort to copying the configuration statically, and then protect it.
$ sudo cp /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
$ sudo chattr +i /etc/resolv.conf
Finally, because now F5 VPN can’t update the DNS configuration, we would have to manually configure the corporate DNS servers and the search domains.
$ sudo resolvectl dns tun0 192.168.100.20 192.168.100.22
$ sudo resolvectl domain tun0 ~example.corp ~example.local
Update: See Automating DNS Configurations for F5 VPN Tunnel using Systemd-resolved and NetworkManager-dispatcher for a script that automates the configuration.
By default, Debian packages aren’t symbolized, resulting in unreadable stacktraces:
#0 0x00007fb9d7a3a774 in ?? ()
#1 0x00005574a4450ea0 in ?? ()
#2 0x00005574a42cea60 in ?? ()
#3 0x00005574a3f8bd20 in ?? ()
#4 0x00007ffe0d782200 in ?? ()
The first step is to determine the right package containing the debug symbols for your binary. This can be done using find-dbgsym-packages from the debian-goodies packages:
$ find-dbgsym-packages /usr/bin/gnome-control-center
Install the relevant *-dbgsym packages, for example:
$ sudo apt install gnome-control-center-dbgsym libglib2.0-0-dbgsym
And now you can have symbolized stacktrace:
#0 0x00007fb9d7a3a774 in g_type_check_instance_cast (type_instance=0x100000002, iface_type=93959409689392) at ../../../gobject/gtype.c:4122
#1 0x00005574a0d1382f in private_key_picker_helper (self=self@entry=0x5574a3f8bd20, filename=filename@entry=0x5574a42cea60 "*******************************************", changed=changed@entry=1)
at ../panels/network/wireless-security/eap-method-tls.c:252
#2 0x00005574a0d13a34 in private_key_picker_file_set_cb (chooser=<optimized out>, user_data=0x5574a3f8bd20) at ../panels/network/wireless-security/eap-method-tls.c:297
#3 0x00007fb9d7a173b0 in g_closure_invoke (closure=0x5574a4302fb0, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7ffe0d782200, invocation_hint=invocation_hint@entry=0x7ffe0d782180)
at ../../../gobject/gclosure.c:832
#4 0x00007fb9d7a2a076 in signal_emit_unlocked_R (node=node@entry=0x5574a1335ba0, detail=detail@entry=1327, instance=instance@entry=0x5574a3f91350, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffe0d782200)
at ../../../gobject/gsignal.c:3796
#5 0x00007fb9d7a30bf5 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7ffe0d7823a0) at ../../../gobject/gsignal.c:3549
By default, Debian doesn’t create core dumps. This can be changed (for the current running terminal session) with
$ ulimit -c unlimited
You can create more sensible core dump names using:
sudo sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t
Three years ago, I bought the Xiaomi AIoT AX3600 Router. Back at the time, only the Chinese version was available, and that one only supported Chinese as an interface language for the admin panel, which isn’t great. Time passed, and the international variant came out. Both versions have different firmwares, so the Chinese version remained pegged to the Chinese interface. Luckily, someone over at OpenWRT found out that you can install the internation firmware on the Chinese variant. The firmware is available over here.
$ sha256sum miwifi_r3600_all_6510e_3.0.22_INT.bin
67881cea85f8452bb63b3067d3100796a9c1b4f65aaa3479dcb4d01216bc6ce4 ./miwifi_r3600_all_6510e_3.0.22_INT.bin
Once you install it, you’ll have an option to change the language to English.
A recent change introduced in GNU coreutils changed the default dircolors for backup files to make them less conspicuous. However, despite having stated that it works on dark backgrounds, this change made it impossible to see backup files such as .tar, .swp, .bak, .old when using the dark variant of the Solarized color scheme of the terminal. It can be seen in the following screenshots:
To fix it, we’ll override the colors by creating ~/.dircolors file:
$ dircolors -p | sed "s/00;90/00;30/g" > ~/.dircolors
$ eval $(dircolors -b ~/.dircolors)
This will set the color of backup files to black, which makes them not stand out, but still readable.
This is the bash function I used to pretty-print all ls colors:
( # Run in a subshell so it won't crash current color settings
dircolors -b >/dev/null
IFS=:
for ls_color in ${LS_COLORS[@]}; do # For all colors
color=${ls_color##*=}
ext=${ls_color%%=*}
echo -en "\E[${color}m${ext}\E[0m " # echo color and extension
done
echo
)
Another option, albeit more verbose, would be
$ dircolors --print-ls-colors ~/.dircolors | paste -sd ''
Almost 14 years ago, I wrote a [small utility, named tarsum, to calculate checksums on files inside a tar archive. It was useful for verifying data inside backups. Recently, I decided to rewrite it in Rust. It’s available from https://github.com/guyru/tarsum.
Installation using cargo is straight forward:
$ cargo install --git https://github.com/guyru/tarsum
Surprisingly, testing on a large tar archive (recent Linux tarball, 1.3Â GB), the performance of both Python and Rust implementation is very similar.
$ pip list --user --outdated --format=json | jq ".[].name" | xargs pip install --user --upgrade
pip list --user --outdated will list all user-installed packages that are outdated. We use jq to extract the package names from the output, and feed it to xargs.
If your LibreOffice UI looks ugly and not following your GNOME theme, you might be missing a package.
After installing the libreoffice-gnome package (which also pulled the libreoffice-gtk3 package), LibreOffice looked much better and the UI was properly themed.
You can use MOTD (message of the day) to let you know if a Debian server requires reboot and why upon login.
Create a new file named /etc/update-motd.d/98-reboot-required and add to it the following lines:
#!/bin/sh -e
#
# helper for update-motd
if [ -f /var/run/reboot-required ]; then
echo "*** System restart required ***"
cat /var/run/reboot-required.pkgs
fi
Make the file executable:
$ sudo chmod +x /etc/update-motd.d/98-reboot-required
Now, you can test the new MOTD script using:
$ run-parts --lsbsysinit /etc/update-motd.d
If you have any installed updates that require reboot, you will get a message stating so, with a list of the packages that require the reboot.
*** System restart required ***
linux-image-5.10.0-19-cloud-amd64
Some time ago, I needed to use the v4l2loopback module. It can be installed via:
$ sudo apt install v4l2loopback-dkms
Normally, after installing a module, you can just modprobe it, and it will load. However, due to Secure Boot, it will fail.
$ sudo modprobe v4l2loopback
modprobe: ERROR: could not insert 'v4l2loopback': Operation not permitted
The problem is that the v4l2loopback isn’t signed. For example, compare the output of:
$ /usr/sbin/modinfo -F signer v4l2loopback
which is empty, versus
$ /usr/sbin/modinfo -F signer xor
Debian Secure Boot CA
The solution would be to sign the v4l2loopback module ourselves.
The update-secureboot-policy script available in Ubuntu’s shim-signed package is able to generate Machine Owner Keys (MOK) by itself. However, the currently available in Debian Unstable doesn’t have the key generation functionality. We can either fetch the Ubuntu version or generate the keys ourselves.
$ wget https://git.launchpad.net/ubuntu/+source/shim-signed/plain/update-secureboot-policy
$ chmod +x ./update-secureboot-policy
$ sudo ./update-secureboot-policy --new-key
Or through generating the keys ourselves:
$ sudo mkdir -p /var/lib/shim-signed/mok
$ cd /var/lib/shim-signed/mok/
$ sudo openssl genrsa -aes256 -out MOK.priv
$ sudo openssl req \
-subj "/CN=`hostname -s | cut -b1-31` Secure Boot Module Signature key" \
-new -x509 -nodes -days 36500 -outform DER \
-key MOK.priv \
-out MOK.der
Write down the passphrase for your private key. You will need it whenever you want to sign drivers.
Now we enroll the newly created key:
$ sudo mokutil --import MOK.der
You will be prompted for a password. This password will be required after reboot in order to complete the key enrollment, you will not need it afterwards.
After reboot, check that your key was indeed enrolled:
$ mokutil --list-enrolled
We need to put the passphrase for the private key in the KBUILD_SIGN_PIN env variable:
$ read -s KBUILD_SIGN_PIN
$ export KBUILD_SIGN_PIN
Now we can do the actual signing:
$ cd /usr/lib/modules/$(uname -r)/updates/dkms
$ sudo --preserve-env=KBUILD_SIGN_PIN /usr/lib/linux-kbuild-$(uname -r | cut -d. -f1-2)/scripts/sign-file sha256 /var/lib/shim-signed/mok/MOK{.priv,.der} v4l2loopback.ko
You will need to repeat this step for every new kernel that you install.