Notices by MacLemon (maclemon@chaos.social)

@leyrer That was a few years ago… but back then already the header part was larger by quite a margin compared to a text body part without attachments.

Given that today everything is sent as completely bogus HTML and marketing department force people to add company logos, etc to each and every email … the meaningful-content to other-useless-bullshit ratio is fubared.

@dalias

macOS #Sequoia continues Apple’s efforts to dumb down each and every application into uselessness to achieve feature parity between #macOS and their other platforms.

I‘ve been using the #Keychain application to store secure notes since the days of classic Mac OS. Still, there is no way to export these secure notes besides manually copy passing them one by one.

I need an alternative solution for securely encrypted text notes with a search function.

What are you using and why exactly that?

@neuron I'm running self-hosted Vaultwarden instances (with the official Bitwarden Clients). They're a nice combo for a company that needs to ensure that all passwords are documented and access controls can be put in place.

That's not *my* use-case. I need this to work *offline*, which is barely possible with Bitwarden. (I tried… it's unusable.)

CLI access is optional for me, but I wouldn't refuse the opportunity.
A GUI for macOS though is a strong requirement and iOS would be nice.

@silverwizard @wts It certainly is an interesting problem.

The container host gets its network config via DHCP, which also assigns a proper recursor. That nameserver is correctly reflected in /etc/resolv.conf and it is used correctly. I verified that successfully.

The problem is not reaching the jumphost itself, it’s the part where the jump to the target occurs. *Some* jumps fail, while others work just fine. (Neither a routing nor firewall issue. Verified!)

Today‘s SideQuest involves debugging an #OpenSSH connection via a containerized #jumphost where some jumps fail.

In that case sshd on the jumphost logs that it cannot resolve the target host. Checking on the host shows that it can correctly resolve that hostname and even successfully connect to it.

I guess somewhere between the container and the container host, some hostname resolutions seem to fail causing SSH jumping to fail.

It involves #DNS and #SSH, yet keeps me puzzled.

#SysadminLife

The jumphost container is correctly able to resolve that hostname. Likewise is the container host. So #DNS works correctly in both cases. (I'm still not convinced it's not DNS, yet. Because it's always DNS.)

When I try to `ssh target.example.org` on the container host, that ssh connection works.

When I try to `ssh target.example.org` in the jumphost container, ssh tells me

ssh: could not resolve hostname target.example.org: Name does not resolve

Likewise sshd when jumping.

#SysadminLife

@wts When creating a ~/.ssh/config

Host nickname
Hostname <IP>

it can successfully connect. (So not a routing problem, not a firewall issue. I am absolutely certain on that.)

I can successfully ping that IP as well from within the container. When I try to do the same with the hostname, I get a „bad ip“ response.

So at least that seems consistent.

Seems to be related to the capitalization of parts of the hostname.

If I had any clue what I‘m doing it would probably be much easier to port this project from the #Arduino IDE to #PlatformIO.
Either way this one requires some wiggle room.

It compiles!

But I cannot upload it because #PlatformIO doesn’t seem to support this specific type/version/variant of ESP32.
Also the print on this board probably does not match the actual hardware.

I hate microcontrollers, especially when they‘re fake-fakes and not even genuine fakes.
And how can I find out what chip this actually is and how to get it into programming mode?

Betrachten wir mal die #CriticalMass der Bahnnerds: