~/Sync/scripts/
├── lock.sh
├── argo-translate.sh
├── backup.sh
└── applications/
    ├── lock.desktop
    ├── argo-translate.desktop
    └── ...

Rofi's drun mode uses XDG desktop entry directories. To include my custom applications folder, I used XDG_DATA_DIRS:

XDG_DATA_DIRS="$HOME/Sync/scripts:$XDG_DATA_DIRS" rofi -show drun

FIPS (which stands for Federal Information Processing Standards) mode will not allow you system-wide to use any hashing algo that is considered to be insecure. But vanilla Flask (and it's batteries) often using sha1. We have stumbled upon two cases.

A standard Flask stack often uses sha1 by default in two key places

flask sessions

The default secure cookie sessions are using itsdangerious for signing, which can default to sha1. The fix was easy: fask's session interface is designed to be subclassed. We can create a custom session class inheriting it from SecureCookieSessionInterface and tell it to use sha256 as the digest method

flask-wtf

Serializing and signing CSRF token here also uses itsdangerious, that again, defaults to sha1. This is the trickier part. As for now, flask_wtf does not provide a simple config option to change the digest method. We have to create a custom CSRFProtect implementation forcing it to use sha256 serializer.

.hword 0x012c  // htons(300)

The server would bind fine, but to an odd port like 11265. The issue was byte order (endianness?).

My “discoveries” are:

• Network byte order is big-endian
• ARM64 is little-endian

I was storing 0x012c as .hword on ARM64 The kernel reads bytes 2c 01 as big endian, interpreting it as 0x2c01 = 11265

The solurtion was to explicitly define the order:

.byte 0x01, 0x2c

The htons() function will handle it properly, but with assembly you have to do it manually.

When I tried to use curl I got this error:

Could not resolve host: my.local.hostname

But when I used other tools:

dig my.local.hostname
nslookup my.local.hostname

They both returned the correct IP address for my.local.hostname.

Understanding the Cause

I learned that different tools resolve DNS in different ways: – dig and nslookup: They query DNS servers directly, bypassing the system's settings. – curl: It uses the system's resolver library, which follows the configuration in /etc/nsswitch.conf. I checked my /etc/nsswitch.conf file and found this line:

hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns

This line tells the system how to resolve hostnames. The [!UNAVAIL=return] part means that if the resolve method (which uses systemd-resolved) doesn't find the hostname (and doesn't return UNAVAIL), the system stops looking and doesn't try the dns method. That's why curl couldn't resolve the hostname, even though DNS was working.

The Solution

I changed the hosts line to remove the [!UNAVAIL=return] part and reorder the methods to prioritize DNS:

hosts: files dns myhostname mymachines resolve

and restarted all DNS realted

sudo systemd-resolve --flush-caches
sudo systemctl restart systemd-resolved

Afterthoughts

If you don't need systemd-resolved, you can disable it:

sudo systemctl disable --now systemd-resolved

Then update /etc/nsswitch.conf:

hosts: files dns myhostname

$ bat --version                                                                ~
bat: error while loading shared libraries: libgit2.so.1.4: cannot open shared object file: No such file or directory

The fix was easy: rebuild a binary

$ cargo install exa bat --force

Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist

So now we have the same issues that we had for Centos 6. And therefore we can fix it like it was described in previous post.

$ sed -i 's,baseurl=http://vault.centos.org,baseurl=http://vault.epel.cloud|g' /etc/yum.repos.d/CentOS-Linux-*

Alternative (AlmaLinux)

The issue with the fix above is that now we have a frozen repo that never will be updated. If your want to have the latest security updates you may consider a migration to one of Cento's successors. An AlmaLinux migration script is located here. Basically, it looks like this:

$ sudo dnf -y upgrade
$ curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh
$ sudo bash almalinux-deploy.sh

• SSD disks become read-only or other IO errors
• Video card do not start while power on. Had to restart each time.
• Other system freezes of unknown origin.

It happened for a month, and I tried to replace SATA cables, disable “spoiled” disks, do memory checks, use the rest of the voodoo too. Started scaring myself with a shopping list if the motherboard broke.

It was a power unit. No visible signs like an inflated capacitor or burn marks, though. Took a chance and bought a new PU. All problems are gone.

About a year ago I've started the process of migration from Dropbox to Syncthing. The structure of a new files synchronization flow was simple: one always online node, and a bunch of consumers. It was fine at first, but after a couple of months, I've noticed an increased amount of updated-file notifications. Files in the notification were not modified at any device that I'm aware of. Another strange thing is that my tools, which dotfiles were in synching folder started to complain about the lack of config files and reset it to the initial state.

First of all, I blamed the android app and excluded it from the flow. I'd had no luck and mess with my dotfiles continued. Nodes were often unsynchronised, logs showed a lot of deleted-created status for the files that nobody touched. A file could be deleted and reappeared again in a matter of hours. After days of troubleshooting, I was able to locate the source of the issue. It was my main node setup. The Syncthing process in the node was dockerized and the mounted sync folder was also an NFS mount. Changing it to SMB did no effect.

So my current solution is a structural change. Now each node is synced with all others and with no master. Each node uses it's own local filesystem. Works like a charm.

That place is a nice tool for writing by the way. It could be a neat tool to draft post ideas and tidy up formatting. But such short posts should not exist as a blog post and it fits tweet format which is not my intention.