ls colors broken under Solarized dark theme

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 ''

Display reboot required message on Debian

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

Rewriting EXIF tags in JPEGs

Some out-of-camera JPEGs have bad metadata that digiKam doesn’t parse correctly. The problematic photos have the same characteristics:

  1. In the Properties tab, there is no Photograph Properties section, instead digiKam has a digiKam Properties section with the caption set to None.
  2. In the Metadata tab, not metadata is shown under Exif. However, full details are available under Exiftool.

The solution is to rewrite the EXIF tags using exiftool. This fixes the bad metadata and allows digiKam to properly read the photo’s metadata.

exiftool -overwrite_original -all= -tagsfromfile @ -all:all *.JPG

For the files with bad EXIF metadata, the command will report the following warning:

Warning: [minor] Error reading PreviewImage from file - DSC06635.JPG

Connecting to WP2 Enterprise network with EAP-TLS authentication

Recently, I had to connect to a hidden WiFi network with an EAP-TLS authentication. When configured via the NetworkManager UI on Ubuntu, it would work. However, on Debian Unstable running Gnome 42 and on Arch, the same process didn’t work. The problem seems to be an empty configuration line for domain-suffix-match that gets created. To solve it, you can remove the domain-suffix-match using nmcli:

$ nmcli connection modify CorpSSID 802-1x.domain-suffix-match ""

Alternatively, you can configure the WiFi network directly with nmcli without setting the problematic property>:

nmcli connection add type wifi ifname wlp0s20f3 \
  con-name CorpSSID \
  802-11-wireless.ssid CorpSSID \
  802-11-wireless-security.key-mgmt wpa-eap \
  802-1x.eap tls \
  802-1x.identity guyru \
  802-1x.client-cert /absolute/path/wifi-certs/signed-certificate.cer \
  802-1x.private-key /absolute/path/wifi-certs/private.key 

It’s important to have absolute paths to both the client certificate and the private key.

GIO can’t mount SMB

When trying to mount SMB share using gio you might encounter the following error:

$ gio mount smb://ptnas1.cellebrite.local
gio: smb://nas.corp.local/: Location is not mountable

This error might be due to a missing gvfs backend. The smb backend should be located in /usr/share/gvfs/mounts/smb.mount. If it is missing, you should install the gvfs-backends package and it should resolve the mounting issue.

If the mount was successful, but you can’t see it under $XDG_SESSION_DESKTOP/gvfss/, you are probably missing the FUSE server that makes the mounted filesystem available to all applications and not only to GIO aware applications. You can install the FUSE server by installing the gvfs-fuse package. The server will automatically run after reboot. If you want to start the server immediately, you can start it manually:

$ /usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs

PipeWire showing only dummy output

After the latest PipeWire upgrade on Debian, sound stopped working for. The bluetooth headset would not connect, and in the output options I had only one device labeled dummy output.

This was caused by a recent upgrade of the pipewire-media-session package to version 0.4.1-3. Debian decided that media-session is deprecated in favor of WirePlumber. As part of the package installation, the /usr/share/pipewire/media-session.d/with-pulseaudio file, signalling media-session it should handle audio, gets removed. As I didn’t have WirePlumber installed, nothing managed the audio configuration. The solution is to recreate the file and restart the relevant PipeWire servcies.

$ sudo touch /usr/share/pipewire/media-session.d/with-pulseaudio 
$ systemctl restart --user pipewire pipewire-media-session pipewire-pulse