Cobra's bits (Posts about linux)

Let's not encrypt?

Cobra — Mon, 30 Dec 2024 14:24:34 GMT

This blog is powered by Hiawatha, a light-weight webserver designed for security and ease of use. Consequently, Hiawatha comes with a script that allows one to easily request certificates from the Let's Encrypt initiative and (in conjunction with a daily cron job) to automagically renew them when the time has come.

This setup has worked almost flawlessly for several years. In 2021, I've received an information from Let's Encrypt that they would modify (as planned) their chain of trust, requiring corresponding changes in the LE_ISSUERS option in the configuration file of the script designated for requesting or renewing certificates.

I should have known that this change will happen every three years, but since I didn't receive any mail this time, it never occurred to me that the failure of renewal had this simple reason. Instead, I've searched everywhere for nonexisting error messages until I had run out of ideas. Without any options left, I've asked Haui for help, convinced that he would see light where I could see only dark. And it indeed didn't take him long to identify an outdated LE_ISSUERS value in the configuration file as the culprit.

We can easily look up the common name of the current certificate's issuer:

openssl x509 -in /etc/hiawatha/tls/pdes-net.org.pem -noout -text | grep CN

But that won't help if the current certificate is not renewed because of an outdated issuer. The present situation was different in that I've requested new certificates in September as a temporary (HOHOHO) workaround. These new certificates were issued with the new CN of R10, as compared to the old R3 in the configuration file, making it clear that the latter is outdated. It would have been so easy if I hadn't been such a fool and categorically ruled out this possibility. 🫥

Well, I may get old and useless, but I hope to recall once and for all that the authoritative instance for looking up the current issuer for Let's Encrypt can be found here: https://letsencrypt.org/certificates/. And if I don't, I'm sure to remember that I can find this information in my own blog. 🫩

Digital signatures

Cobra — Wed, 01 May 2024 12:12:11 GMT

Our administration now requests all documents to be digitally signed, with a certificate that each employee receives from the DFN. Windows and Mac users employ Acrobat Reader for this purpose, but what software can be used under Linux?

My first choice was LibreOffice, which has offered this functionality already for several years. Signing a pristine pdf works well indeed, apart from the fact that LibeOffice does not create a placeholder for the signature. However, signing a document that has already been signed by Window users turned out to be simply not possible (here's the 12 years old bug report – and here's the inverse one that is just as old).

The next candidate was Okular, the PDF viewer of KDE, which has been sponsored by the University of Dresden to implement this functionality. But only half-way, it seems to me. I could sign most (but not all) documents, but I couldn't configure the placeholder at all. As the font size in the signature box does not scale with the size of the box, the name of the person signing is often cut off. How difficult can it be to implement such a very basic and obvious requirement?

Finally, I turned to Master PDF Editor, which I've occasionally used in the past for annotations when Evince did not yet offer this possibility. I was actually not surprised that this feature-rich PDF editor also offers digital signatures, but I was pleased that the software comes with its own certificate storage and that the signature placeholder is highly configurable. For example, one can configure the placeholder to include one's own analogue signature as a background.

Alas, using the Master PDF editor without any restrictions requires purchasing a license. The free version is unlimited, but leaves a watermark in documents that have been digitally signed or otherwise altered with the software. The licence is very fairly priced, but as the software is developed in Russia, even asking for one is frowned upon and politically inopportune. Fortunately, nobody has yet complained about the watermark in documents I have digitally signed. 😈

Backdoor in xz

Cobra — Mon, 01 Apr 2024 11:50:12 GMT

The upstream xz repository and the xz tarballs have been backdoored.

This backdoor is very indirect and only shows up when a few known specific criteria are met. Others may be yet discovered! However, this backdoor is at least triggerable by remote unprivileged systems connecting to public SSH ports.

This supply-chain attack targets .deb- and .rpm-based distributions, but the backdoored versions of xz or xz-utils (5.6.0 and 5.6.1) have made it only into rolling-release distributions such as Fedora Rawhide, Debian Testing/Sid, OpenSuse Tumbleweed, and Archlinux (where it is inactive).

The server of this blog is running Debian Testing and had the compromised version of xz-utils installed since March 17. The backdoor was reported last Friday, March 29. I've installed the patch provided by Debian on Saturday, March 30, and examined the system logs, which do not show any evidence that the system has been compromised in any way. In fact, according to my current understanding, the system did not meet all the requirements for the backdoor to be executed. However, I will remain vigilant and let the users of the server know if further action needs to be taken.

More links (in German): Heise 30.03.2024 09:35, Heise 30.03.2024 22:28, Heise 02.04.2024 17:10

Kernel 6.6.9

Cobra — Fri, 05 Jan 2024 16:24:37 GMT

Yesterday, I've updated my systems to kernel 6.6.9 – two Intel-based desktops and one AMD-based notebook. When rebooting the latter, I immediately noticed that something was wrong. Logging in, for example, seemed to take twice as long, and the desktop needed much longer than the usual two or three seconds to come up. My Intel desktops, in contrast, behaved exactly as before.

To substantiate my feeling that my notebook's performance had degraded significantly since the update, I used sysbench, or, more precisely, the command sysbench cpu run. I would normally see a performance of about 4800 events per second on one core. But with kernel 6.6.9, all I've got were 440 events per second, more than a factor of 10 lower than the Ryzen 5800H in my notebook is supposed to deliver, and even three times lower than my 10-years old Intel desktops. No surprise the notebook felt so sluggish!

I didn't bother to investigate this issue further, and I don't know the underlying cause, like whether it's related to the AMD processor or the maker of the notebook. I just rolled back to kernel 6.6.8 (sudo pacman -U /var/cache/pacman/pkg/linux-6.6.8.arch1-1-x86_64.pkg.tar.zst) and the problem was gone.

I expected problems with kernel 6.6.6, but the devil is in the details.

Update: The performance is back to normal with kernel 6.6.10.

Don't worry, be happy

Cobra — Sat, 29 Jul 2023 13:12:40 GMT

It's Friday evening, 18:30. My fourth video meeting in a row has just concluded. Now I could finally work on the revision of a manuscript I wanted to get resubmitted during the weekend. This last revision was purely technical: the production editor requested that we move the present addresses of the authors to the back of the manuscript, instead of leaving them beneath the list of authors on the title page as destined by the LaTeX class from the publisher. Now, any such request that forces me to work around or against the journal style provided by the publisher means that the reputation of the journal (ACS Appl. Nano Mater., in case you are curious) takes a steep dive. But anyway, I had to do it, and I was looking into the footmisc package to get all footnotemarks I needed when I realized that I hadn't done my ritual update in the morning for the lack of time. Starting it, I only peripherally noticed that the update involved TeXLive and brought a new kernel. In any case, this information didn't stop me from compiling the manuscript I was working on during the update. Repeatedly. Incessantly.

At a certain point, the build command of Sublime Text didn't produce any reaction. No error message, nothing. I began to have a bad feeling. Indeed, while I could still move the mouse around, the entire Window system was unresponsive, and the update process – which was just about to build the fmt files – was hanging. I started to suspect that I had just committed the greatest blunder of this year, and indeed, when I rebooted, the system greeted me with the message that the kernel could not be found:

Loading Linux linux...
error file /boot/vmlinuz-linux not found
loading initial ramdisk
error: you need to load the kernel first

Well, I knew that this SNAFU looked worse than it actually is. But since I was suddenly very tired, I decided to call it a day and do the repair on Saturday morning.

On Saturday, I first needed a live Arch installation on a USB stick. The ISO ist just 813 MB (as of release 2023.07.01) and downloaded in 30 s. There are several options to write the ISO to the stick, but I prefer dd:

dd bs=4M if=archlinux-archlinux-2023.07.01-x86_64.iso of=/dev/sdd conv=fsync oflag=direct status=progress

Note that the stick must not be mounted, and one writes to the stick (sdd), not a partition (sdd1).

After booting from the thus created live media, I was just a few commands away from a restored system. I first wanted to have my WiFi working:

iwctl --passphrase PASSPHRASE station DEVICE connect SSID

After that, I just needed to mount my drives (have a look with lsblk before), delete the stale lock file from the previous failed update, and do an update in the mounted root directory:

mount /dev/nvme01p2 /mnt
mount /dev/nvme01p1 /mnt/boot
mount -t proc /proc /mnt/proc
mount --rbind /sys /mnt/sys
mount --rbind /dev /mnt/dev

rm /var/lib/pacman/db.lck

pacman --sysroot /mnt -Syu

Took all in all half an hour, but I would still have preferred to avoid this situation altogether. The lesson is: avoid working on the system when you're all stressed out. Particularly on Friday night.

Ich glotz TV

Cobra — Sun, 29 Jan 2023 14:00:13 GMT

Well, actually I've essentially stopped watching linear TV about 20 years ago. My Loewe CRT TV set I'd bought in 1994 didn't take kindly to that and twice suffered from dried-up electrolyte capacitors. “You have to switch on the TV at least sometimes”, said the electronics guy who repaired the set. When it happened the third time, I didn't bother anymore, but lived without dedicated TV set for the next 5 years. My first flat-screen TV purchased in 2010 suffered the same fate when it all of a sudden developed dead pixel rows, resulting in a rapidly increasing number of black lines across the display.

It was not until 2018 when I finally gave in and bought a new TV set with the explicit purpose to enjoy the FIFA World Cup held this year. You all know that from a German perspective, this word cup was as much of a disaster as the following one in 2022. Regardless, the 65" QLED panel with three-sided ambilight is perfect for enjoying the occasional movie from my NAS or Amazon Prime Video.

This panel creates a high level of immersion due to its sheer size and the light surrounding it, providing a near cinematic experience for movies in FullHD and 4K resolution. For anything else the immersion may be a bit overwhelming, particularly if one is not willing to fully focus on the action displayed. For me, that's often the case when watching a football match, or a documentary on publicly broadcasted TV, and I would prefer to be able to watch the TV channel on my notebook with one eye while doing other stuff in the background.

Instead of a flull-fledged IPTV application such as hypnotix, I thought that a simple script may be more suitable to my needs. The script I've found on archlinux.de was basically just what I needed. I've merely integrated the download of the current URLs (done by a python script by Axel-Erfurt I've reproduced below), cleaned up a bit, and formatted it for zenity. I've also excluded some redundant channels to keep the list from cluttering.

#!/bin/bash

# Original livetv script by tuxnix and Mis,
# see `https://wiki.archlinux.de/title/Live-Tv <https://wiki.archlinux.de/title/Live-Tv>`_
# liveiptvstations.py by Axel-Erfurt,
# see `https://gist.github.com/Axel-Erfurt/5106f9bbef1fca1d63bb74a849607128 <https://gist.github.com/Axel-Erfurt/5106f9bbef1fca1d63bb74a849607128>`_
# Also see `https://wiki.ubuntuusers.de/Internet-TV/Stationen/ <https://wiki.ubuntuusers.de/Internet-TV/Stationen/>`_

script_path="$(dirname "$0")"
script_name="$(basename "$0")"

# Pull down a current list of IPTV channels
liveiptvstations.py > channellist.txt

# Basic formatting
sed -i -e 'N;s/:\n/ /' -e 's/^/FALSE /' channellist.txt
sed -i -e "s/ARD Alpha/ARD.alpha/" -e "s/ARD ONE/ARD.one/" -e "s/MDR Sachsen/MDR/" -e "s/BR Süd/BR/" -e "s/NDR Hamburg/NDR/" -e "s/RBB Berlin/RBB/" -e "s/SWR BW/SWR/" -e "s/WDR (Deutschland)/WDR/" channellist.txt

# Remove some redundant channels (optional, but beware they need formatting if included)
sed -i -e "/Tagesschau/d" -e "/ARTE.FR/d" -e "/ORF/d" -e "/Brandenburg/d" -e "/Anhalt/d" -e "/Thüringen/d" -e "/Mecklenburg-Vorpommern/d" -e "/Niedersachsen/d" -e "/Schleswig-Holstein/d" -e "/Lokalzeit/d" -e "/weltweit/d" -e "/BR Nord/d" -e "/SWR RP/d" channellist.txt

#create oneliner for zenity
channel_list=$(paste -s -d ' ' channellist.txt)

stream_url=$(zenity --list --title "Live IPTV channels" --text "Choose a channel:" --radiolist  --column "" --column "Channel" --column "URL" --print-column=3 $channel_list)

if(($? == 0)); then
        mpv "${stream_url}"
        exec "${script_path}/${script_name}"
else
        echo "Leaving LiveTV"
fi

#!/usr/bin/python
# -*- coding: utf-8 -*-
import requests
import json

# see https://gist.github.com/Axel-Erfurt/5106f9bbef1fca1d63bb74a849607128

url = "https://raw.githubusercontent.com/mediathekview/MServer/master/dist/live-streams.json"

data = requests.get(url).text

js = json.loads(data)

def parse_object_pairs(pairs):
        return pairs

decoder = json.JSONDecoder(object_pairs_hook=parse_object_pairs)
obj = decoder.decode(data)

for value in obj[2:]:
        print(f'{value[1][2].replace(" Livestream", "")}:\n{value[1][8]}')

Units

Cobra — Sun, 19 Jun 2022 12:17:54 GMT

As a physicist, it is very useful to be able to perform calculations quickly, whether it is by pure mental arithmetic or on the back of an envelope. I'm immensely grateful for the training I've received in school that allows me to perform such calculations with relative ease. When I see my students struggling with even the most trivial of these calculations and having to rely on their smartphones to get a result, I get the impression that the education system is dismissing these skills as obsolete in our digital age. A big mistake, if you ask me.

Don't get me wrong: when I need accurate results, I also resort to calculators or calculator apps on Android or Arch. And as an added benefit, some of them handle not only numbers, but also the units. This is really helpful, because converting numerical results from all sorts of obscure units to SI is often necessary when consulting older references, and it's as tedious as it is frustrating - just look at the Wikipedia page of the cgs system.

Apart from Mathematica, I know of three command-line programs (one of which, namely, qalc, is also available with a graphical user interface) for doing calculations with units: the veteran units, the modern qalc, and the new and hip insect. Here's an example of these three tools dealing with the conversion of the surface tension (in N/m) of water to surface energy (in eV/Å²), which for a liquid is one and the same despite the different units.

Uptime

Cobra — Sun, 01 May 2022 13:41:26 GMT

This blog runs on a very affordable vServer hosted by netcup. For such low-end servers, no uptime guarantees are given by any hoster. Nevertheless, I always get mails whenever the server is down either for maintenance or because its temporarily out of order, and my feeling is that this happens only rarely. But just out of curiosity, I'd like to know what the actual uptime is.

A two page article in c't 26/2021 introduced me to uptime-kuma, which seemed to fit nicely what I was looking for. The only part I didn't like was the statement “Der einfachste und schnellste Weg Uptime-Kuma zu installieren, führt über Docker und Docker-Compose” followed by an installation procedure that I would call anything else then simple and fast. Fortunately, this statement applies only to the distributions favored by the c't. On Arch, the following two commands install and start uptime-kuma as a service:

yay -S uptime-kuma
systemctl enable --now uptime-kuma.service

After configuring the services to monitor and a day of collecting data, their uptime status is displayed on https://localhost/3001 as shown below for the web and IRC servers on pdes-net.org:

Too many meetings

Cobra — Sun, 13 Mar 2022 13:01:13 GMT

The number of meetings I'm requested to attend has increased by roughly a factor of five over the last two decades. Instead of five meetings per week I'm currently having five per day on average. It thus doesn't come as a surprise that I depend on an electronic calendar to organize and get reminded of all these appointments.

On my desktops, I'm using the integrated calendar of evolution since seven years. Over the time, this implementation of a PIM for the Gnome desktop has proven itself to be reliable and stable, in contrast to Kontact, its KDE counterpart I've tried to use before.

In any case, having a calendar on my desktops is not sufficient anymore, as future appointments are typically arranged after Zoom meetings that I usually attend with my notebook. And even that is not enough: I may want to check my appointments on a whim in the middle of the night, where only my smartphone is immediately accessible. In either case, I do not need a full-blown PIM, but just a calendar client synchronizing with both owncloud/nextcloud and zimbra.

On Linux/GTK, I thought that gnome-calendar would be the natural candidate with this functionality. To my surprise it's straightforward to add an owncloud/nextcloud account with the associated calendar, but zimbra is not part of the online account collection of Gnome, nor is a generic CalDAV server. I found that almost impossible to believe, but it's in fact a longstanding bug (eight years!) that has still to be acknowledged and addressed by the developers. Fortunately, there's a simple workaround: after installing evolution and adding the zimbra CalDAV server there, it also shows up in gnome-calendar. Apart from this issue, gnome-calendar delivers exactly what I wanted.

This entire affair is a whole lot easier on Android. Davx5 available on F-Droid provides a convenient backend for any number of CalDAV servers, and any calendar app will serve as frontend. It works just as well as gnome-calendar on my notebook, but without any unexpected obstacles during the configuration of the calendars.

I'm now reminded of outstanding appointments wherever I walk and talk. That's progess! Or is it?

Upgrading virtualenvs in fish

Cobra — Wed, 29 Dec 2021 15:55:32 GMT

Python major version upgrades such as the one from 3.9 to 3.10 a few weeks ago require rebuilding any virtual environments created earlier. The generic one-liner I gave in an earlier post works in all shells, but as an avid user of the fish shell, I'm of course employing virtualfish for managing my virtual environments. And upgrading them in fish is even easier than with the one-liner above:

vf upgrade --rebuild

Prior to that, one also needs to rebuild the virtualfish for the python version upgrade:

yay --rebuild -S virtualfish

Afterwards, one can see to the update of the content of the virtualenv as documented in my earlier post. Compared to the entire recreation of the virtualenv, this whole procedure is as painless as fast – which makes the whole concept of virtualenvs an eminently practical one.