There’s a nice explanation on how to restore text that has been pixelated, blurred or swirled. They’ve also open-sourced a tool for it.
Needless to say if you want to censor or obfuscate text you should always block those sections out completely.
There’s a nice explanation on how to restore text that has been pixelated, blurred or swirled. They’ve also open-sourced a tool for it.
Needless to say if you want to censor or obfuscate text you should always block those sections out completely.
Recently my monitoring service warned me that my Raspberry Pi was not syncing its time any more. I logged into the devices and tried restarting systemd-timesyncd.service
and it failed.
The error it presented was:
ConditionVirtualization=!container was not met
I was confused. Although I was running containers on this device, this was on the host! 😯
I checked the service definition and it indeed had this condition. Then I tried to look up the docs for the ContainerVirtualization setting and found out Systemd has a helper command that can be used to find out if it has been run inside a Container/VM/etc.
To my surprise running systemd-detect-virt
determined it was being run inside a Podman container, although it was run on the host. I was totally confused. Does it detect any Container or being run in one? 😵💫
I tried to dig deeper, but the docs only tell you what known Container/VM solutions can be detected, but not what it uses to do so. So I searched the code of systemd-detect-virt for indications how it tried to detect Podman containers … and I found it: it looks for the existence of a file at /run/.containerenv. 😯
Looking whether this file existed on the host I found out: it did!!! 😵 How could this be? I checked another device running Podman and the file wasn’t there!?! 😵💫 … Then it dawned on me. I was running cAdvisor on the Raspberry Pi and it so happens that it wants /var/run to be mounted inside the container, /var/run just links to /run and independent of me mounting it read-only it creates the /run/.containerenv file!!! 🤯
I looked into /run/.containerenv and found out it was empty, so I removed it and could finally restart systemd-timesyncd.service
. The /run/.containerenv file is recreated on every restart of the container, but at least I know what to look for. 😩
Update 2025-03-23: I’ve created a bug report: https://github.com/containers/podman/issues/25655
Word! … you know, because of 16-bit … 🥸
Miezefratze, die
➡ siehe Grumpy Cat
Brian Sletten presents an overview of the WebAssembly landscape, the development direction and applications it enables. I can’t but notice that we’re really on the path to WebAssembly becoming the JavaScript-derived universal runtime Gary Bernhardt promised in 2014. 🤯
Denkwürdiger Wortwechsel zwischen einer Fünf-jährigen, ihrem drei-jährigen Bruder und der Oma. So sieht es aus, wenn Eifersucht auf Kinderlogik trifft. 🤭🤣
5 zur Oma: ich habe Hunger!
3: ich will auch Hunger haben!
Traumtauchen, n.
Metaphysische Erklärung für Schlafapnoe.
Dream diving, n.
a metaphysical explanation for sleep apnea.
Imagine you’re using dropbear-initrd to log in to a server during boot for unlocking the hard disk encryption and you’re greeted with the following error after a reboot:
root@server: Permission denied (publickey).
🤨😓😖 You start to sweat … this looks like extra work you didn’t need right now. You try to remember: were there any updates lately that could have messed up the initrd? … deep breath, lets take it slowly.
First try to get SSH to spit out more details:
$ ssh -vvv server-boot [...] debug1: Next authentication method: publickey debug1: Offering public key: /home/user/.ssh/... RSA SHA256:... explicit debug1: send_pubkey_test: no mutual signature algorithm [...]
That doesn’t seem right … this worked before. The server is running Ubuntu 20.04 LTS and I’ve just upgraded my work machine to Ubuntu 22.04 LTS. I know that Dropbear doesn’t support ed25519 keys (at least not on the version on the server), that’s why I still use RSA keys for that. 🤔
Time to ask the Internet, but all the posts with a “no mutual signature algorithm” error message are years old … but most of them were circling around the SSH client having deprecated old key types (namely DSA keys). 😯
Can it be that RSA keys have also been deprecated? 😱 … I’ve recently upgraded my client machine 😶 … no way! … well, yes! That was exactly the problem.
Allowing RSA keys in the connection settings for that server allowed me to log in again 😎:
PubkeyAcceptedKeyTypes +ssh-rsa
But this whole detour unnecessarily wasted an hour of my life. 😓