Athanasius
Long-time Linux user (SLS something, using ~0.98 kernel back in 1993, Debian these days), occasional FOSS developer, gamer. Born in the 1970s.
Pronouns: He/Him
Previously on Mastodon: @AthanSpod@techhub.social
The next space telescope is launching in ~40 minutes. It's the Nancy Grace Roman Space Telescope ( https://en.wikipedia.org/wiki/Nancy_Grace_Roman_Space_Telescope ).
There are several places to watch the launch:
NASASpaceflight (third-party channel): https://www.youtube.com/watch?v=-8yDQhVgypw
NASA official stream: on YouTube ( https://www.youtube.com/watch?v=9wq3VHsL_bE ), or on Twitch ( https://www.twitch.tv/nasa )
Everyday Astronaut: https://www.youtube.com/watch?v=J6Ww6kQN4Qw
Hours later and it mostly went smoothly.
-
postgresql 15 -> 17 cluster upgrade required an astounding amount of extra disk space. Ended up doubling that partition size from 10G to 20G (despite only 6.6 GB used beforehand, 15G wasn't enough).
-
Ah, so that's the fun and games with dovecot config grammar changes.
-
Why did rsyslog.service fail to listen to a TCP port (logging from my desktop) at boot ? A restart had it work fine....
-
No, OpenSSH, I don't need you to ban 'bad' IPs, I use fail2ban for that.
Now for the grind of updating/adding logcheck ignore lines for new and changed bits of logging....
Well, look at that.
I was looking forwards to playing "Resonance: A Plague Tale Legacy" today, having pre-ordered it pretty much as soon as that was possible. Yes, this is another game in the world as "those two rats games".
But, they were not initially offering a preload of the game on Steam. This lead to a community post there asking about it, a developer confirming they weren't offering it, lots more people piling on, asking "why not?".
I note the initial developer post said something bizarre about "some people will be able to download it faster than they could decrypt a preload". We dis-abused them of this notion.
And now they enabled preloads! Woot! I might even just about have it downloaded by the time it releases in ~1h42m (16:00 UTC).
Ref: https://steamcommunity.com/app/2713000/discussions/0/591813722889028891/?ctp=3#c592939664045890930
@neverpanic@chaos.social Yes, Debian is using:
ii openssl 3.5.4-1~deb13u2
But I've looked very closely at the two sets of negotiations, and there were only very minor differences. I had tried configuring off the hybrid post-quantum ciphers/etc, but it made no difference.
It's just something about openssl 3.5 negotiation causes Azure to generate larger packets, and only IPv6 had this cause an issue. As else-thread, likely because something in Azure is eating the icmpv6 "message too long" packets before they make it to whatever the TLS is terminating on.
The working negotiation, from my Debian 12/bookworm host, has it re-assembling 3 TCP fragments of size: 1219, 1420 and 1062. With the broken 13/trixie setup my end only ever sees a 2nd fragment of length 1326, the first fragment is never seen.
So, whilst a different openssl version might not help the packet size, this really is about the path back to Azure not getting the "message too long" message and thus it never retries with viable fragment sizes.
@neil@mastodon.neilzone.co.uk Before I switched to BitWarden for my passwords I was storing them using kickpass.
kickpass gives you an encrypted file per thing/site, and there's no requirement to actually be storing a password in that part of the data. The metadata just opens up in $EDITOR.
I've not looked at it closely, but I assumed it was doing a better job of handling things like "don't leave a plain-text temporary file lying around if you crash" than my previous home-brew script based on GPG.
The one downside is that the file(s) will need to be in ~/.kickpass
Anyone happen to know what's going on with kernel.org today?
First my RSS reader thought there were some new releases, but they were old 6.15 series ones.
Then I checked the www.kernel.org - it was originally only showing outdated (no longer listed usually) kernel series, e.g. no 6.18.
Now it's gotten up to showing longterm: 6.18.37 ... again (after showing earlier 6.18 revisions for that), and also shows a mainline: 6.18 ... line.
7.0 and 7.1 have gone MIA.
I'm hoping this is just some backend rebuild that they've chosen/had to run on the live service... and not indicative of some compromise with bad actors trying to generate infected tar balls or the like.
@Epaphus@mastodon.lo0.uk I was literally getting SIOCSIFMTU: Invalid argument for anything below 1500 with ip link set eth0 mtu 1500 in the telnet shell.