Durch sorgfältige Materialauswahl und patentierte Bearbeitungstechnik ist ein Hackenriemen überflüssig! Statt dessen halten tausende hölzerne Widerhaken die Fußsohle garantiert rutschfest an Ort und Stelle, ganz natürlich und biologisch. Genial!
Gyroplast
- 0 Posts
- 29 Comments
Joined 10 months ago
Cake day: June 22nd, 2024
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
71·15 days agoConsider a key pair, consisting of two brutally large numbers, but otherwise pretty much identical. Magical math exists that makes it so that if you math your data with one of these brutally large numbers, you get the original data back only if you math it with the other large number. That’s basically it.
Now we slap convention onto this, and keep one of the paired, large numbers a secret, and call it our private key, the other number is disseminated and called the public key for that reason.
Now everyone can math data with your public key, so that only the paired private key, which only you know, can de-math it. This is encryption/decryption.
Signing is very similar, but now you use your private key, which only you know, to math a digest of your data, and all the world can de-math this correctly only with your public key, thus proving it was indeed your private key used to math the data in the first place, and by extension attribute the signature to your public key identity. Your private key is never known to anyone but you, which is an essential difference to “classical” symmetric encryption with a shared secret.
You may realize how easily a code signature can become a liability, if you fail to keep your private key secret for any reason. You can be trivially impersonated, with basically no chance of recourse or deniability with an SSH key, while you can at least invalidate a GPG key publicly and mark it as “stolen” that way. This is potentially very important, if there’s any legal meaning attached to your signature, and if not, why bother with code signing in the first place, if “trust me bro” is well enough.
FOR NO REASON!!?! 🔥 🔥 That “barista” 🫤 deliberately spelled the name of my 😍 daughter 🥰 Brettly wrong on the cup, and did not appreciate her 🦄 uniqueness AT ALL when I demanded them to correct their stupid mistake! The nerve of some people! 🤯
A study on 6 (six!) people? That’s not a study, that’s less than I get asking around during any lunch break. [this is worthless! meme] Wonderful trolling of some unpleasant cow-orkers, though, chapeau!
Da steht “Zehn Traktoren”. HTH, HAND, SCNR.
Trollen ist ein Kunst, und ich applaudiere.
*föderal, verdammte Hacke! Außer natürlich, das bezieht sich auf die verlängerte Bisamratte als Erbe reicher Minenbetreiber, dann ist’s perfekt so.
mit Drohnen ahnden
Zivile Verwendung von unbemannten Flugkörpern mit Wirkleistung zur einstweiligen Erschießung, bis die Schuld zweifelsfrei festgestellt werden konnte.
81·3 months agoCrusty, cynical folks, entirely unlike and unrelated to myself, could be tempted to name it the Beginning of Eternal October for Linux.
2·3 months agoThat’s listed in the
makedependsarray of the PKGBUILD, like here. You might want to look into the query options-din combination with-tfor pacman’s-Q, to list packages installed as dependencies, but “Restrict or filter output to print only packages neither required nor optionally required by any currently installed package.”Bonus cleanup pro-tip:
alias pacorphans='sudo pacman -Qtdq | sudo pacman -Rns -'as explained in the wiki, mentioning makedepends in particular.
Probably molly-guard.
I did not need this to hit so hard right now. Time to start a new therapeutic rye sourdough.
Wise decision! Best of luck for when you give it another try, with fresh eyes and a clear mind, and enjoy your XP gain dopamine on the way.
Yeah, that’s normal, intended, and does not prevent general lookups taking the global DNS first. Do you see an issue with this?
I gave this setup a try real quick, to make sure I’m not overlooking something, with dnsmasq for testing on 127.0.0.1:9053:
[gyroplast@e15g4 ~]$ dnsmasq --listen-address=127.0.0.1 --port=9053 --address=/testme.localnet/127.42.0.69 --no-daemon --no-hosts --no-poll --log-queries dnsmasq: started, version 2.90 cachesize 150 dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth cryptohash DNSSEC loop-detect inotify dumpfile dnsmasq: warning: no upstream servers configured dnsmasq: cleared cacheWhen triggering a query on that test record, f. ex. with
ping -c1 testme.localnet, you’ll see it’s directed to the dnsmasq instance and working as intended:dnsmasq: query[A] testme.localnet from 127.0.0.1 dnsmasq: config testme.localnet is 127.42.0.69 dnsmasq: query[AAAA] testme.localnet from 127.0.0.1 dnsmasq: config error is REFUSED (EDE: not ready) dnsmasq: query[AAAA] testme.localnet from 127.0.0.1 dnsmasq: config error is REFUSED (EDE: not ready)The DNS setup with systemd-resolved is pretty confusing, and outright contradicts many, MANY previously correct instructions of how to set your
/etc/resolv.conf. I’m not surprised if it is giving you a headache right now, but all I can say is to diligently work through its configuration, and understand how systemd-resolved is supposed to work. From experience, make sure your tests are sound and representative, or you’ll continue looking for errors in your setup despite everything actually working just fine, maybe because you missed a reload or had a typo or misunderstanding in your wireshark filter.In the same vein, make sure your DNS listening on :9053 is really working as intended, otherwise you can bark up the wrong tree all day long. Debug logging is your friend, and more accessible and less error prone than tcpdump/wireshark.
You’ll figure it out from here, I’m sure.
I ran the command with sudo and got the error.
Yes, that’s why I said don’t do that. It’s a common, non-intuitive interaction with sudo and shell redirections. Don’t stress over it, I shouldn’t have done it all that fancy in the first place.
Regarding your problem: Your setup is likely inconsistent now due to your experiments and previous setup attempts. HOLD THE REINSTALL, learn to fix it, it’s not that complex. First off: you’re not running in the recommended “stub mode” where
/etc/resolv.confis symlinked to/run/systemd/resolve/stub-resolv.conf, and where the configuration you did is actually actively used. Fix that first. Have some docs. This is my stub/etc/resolv.conf, for example, so you know what to look for, roughly:[root@e15g4 gyroplast]# cat /etc/resolv.conf # This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8). # [...] nameserver 127.0.0.53 options edns0 trust-ad search fritz.boxDon’t create that file with these contents manually. Read the docs, follow the instructions, don’t ruin your day.
Assert you have no lingering, conflicting setup in the
/etc/systemd/resolved.confmain config. The default file is effectively empty / commented out, to allow for automatic system updates without conflicts. You could reinstall the package to get the original file back if you’re unsure.Make sure the
systemd-resolved.serviceis enabled and started:systemctl enable --now systemd-resolved.serviceYou might want to installsystemd-resolvconfas well if you commit to a systemd-resolved setup, for maximum compatibility.Make use of
resolvectl statusto verify the status:Global Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Current DNS Server: 127.0.0.1:9053 DNS Servers: 127.0.0.1:9053 Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net 8.8.8.8#dns.google 2606:4700:4700::1111#cloudflare-dns.com 2620:fe::9#dns.quad9.net 2001:4860:4860::8888#dns.google [...]If that’s still not what is expected, crank up debugging and check the logs of the service to see if for some reason your config file isn’t loaded due to a typo somewhere, or if it’s loaded, any other reason that may override your settings later. It’s practically guaranteed there’s an inconsistency left somewhere, and reading the debug log points you at the actual problem.
It’s worth fixing this in that way. With stub mode, you gain a lot of flexibility in your setup, and it works well in tandem with NetworkManager, DHCP, VPNs, and libvirt/qemu networking. You have to make sure you’re not inadvertently setting up some broken “hybrid” of old-school /etc/resolv.conf manual config and systemd-resolved, this will drive you mad, and it’s a pain to diagnose. Read that wiki page, do not intermingle with crap you pick up on stackoverflow or AI bullshit, and you’ll end up with a DNS config that actually works like magic.
Don’t slap a sudo in front where it doesn’t belong. Run this as root, or the shell redirection will fail. Or just create that file with these contents in any other way you like and feel comfortable with, it’s not a magic incantation you have to use verbatim, after all.
DNSis aresolved.confonly setting. systemd docs are comprehensive and help navigating what to put where, no need to throw shit at the wall and see what sticks. :)man resolved.conf:
OPTIONS The following options are available in the [Resolve] section: DNS= A space-separated list of IPv4 and IPv6 addresses to use as system DNS servers. Each address can optionally take a port number separated with ":", a network interface name or index separated with "%", and a Server Name Indication (SNI) separated with "#". When IPv6 address is specified with a port number, then the address must be in the square brackets. That is, the acceptable full formats are "111.222.333.444:9953%ifname#example.com" for IPv4 and "[1111:2222::3333]:9953%ifname#example.com" for IPv6. DNS requests are sent to one of the listed DNS servers in parallel to suitable per-link DNS servers acquired from systemd-networkd.service(8) or set at runtime by external applications. For compatibility reasons, if this setting is not specified, the DNS servers listed in /etc/resolv.conf are used instead, if that file exists and any servers are configured in it. This setting defaults to the empty list. Added in version 213.TL;DR: Create a drop-in for resolved and put the DNS= line there, with colon separating the port. Reload the config of the service to activate.
install -o0 -g0 -dm755 /etc/systemd/resolved.conf.d install -o0 -g0 -m644 <(cat <<EOF [Resolve] DNS=127.0.0.1:9053 EOF ) /etc/systemd/resolved.conf.d/90-dns_port.conf cat /etc/systemd/resolved.conf.d/90-dns_port.conf [Resolve] DNS=127.0.0.1:9053 systemctl reload systemd-resolved
6·4 months agoI’ve had so much trouble with tooling
Obvious skill issue. /s
I don’t feel like I can make any impact
Assuming you don’t just want to vent, but maybe get some sort of unfounded and useless opinion from a total stranger to go along with your misery, let me oblige. I’ve never been a cog in a truly large company, but I’ve been rubbing shoulders with managers and C-level just barely enough to begin seeing “their side”, and consider it in my interaction with cOwOrkers and management to effectively act as a conduit or translation layer between camps. It’s a metagame you’ll have to want to play, but it can be rewarding to finnagle the systems of human psyche to have a positive impact, not only for yourself.
From a manager’s perspective, everything has a cost. It’s called tech debt for a reason. As long as paying the interest on your tech debt outweighs the perceived cost of paying off the debt, you’re doing the right thing from a business perspective. In addition, be keenly aware of the fact that you personally will impossibly know the huge dark-company iceberg that is the existing tooling and its context. I guarantee you that there’s so much unknown to you, which makes the proposition “I would fix this in a few days, just let me!” seem rightfully preposterous, and thus actively dangerous, as you obviously don’t fathom the full complexity of the larger issue and would necessarily break things for others, despite your best intentions and competence.
Yes, the tooling certainly is utter garbage, and they should never have locked themselves in such a horribly broken situation, but there they are, and you can’t just “fix this” without understanding the implications. Many devs, myself certainly included, easily fall into the trap of seeing an obvious and clear way of fixing everything™ in a matter of minutes, and realizing too late that “just one more patch” is an endless pursuit, all while breaking user-space for others on the way. It’s a meme old as dirt among hackers.
Assume you don’t know all the details, and really nobody does anymore, and you’ll live a happier life if you leave this (business) decision of letting code rot to others. It’s their money they’re wasting.
What you can do, however, is gold-wrapping the pile of shit you need to work with. Find creative ways to wrap byzantine processes into a bunch of scripts for yourself to automate and generalize your tasks specifically, and watch your productivity soar and your mental health rise, and offer that as a working band-aid to your peers and manager. That’s not only a better use of your time than seething over how shitty everything is, but also plays very well into a devops mindset and is actually kind of fun. It also comes across way better than being the “new guy who knows everything better, but actually hasn’t seen nothing, yet”, which leads to people not listening you in the first place. That vibe is an instant turn-off for any lead, and leads to shadow-banning you from interesting, fruitful conversations you seem to look for.
Obviously I’m confabulating all of this, and this may very well not apply to you or your situation at all. This is just a behavioral pattern I’ve seen way too often, and it’s helpful to detect this in oneself to prevent unnecessary frustration all around.
My plan
is possibly your best option. Go ahead. You have no obligations or “loyalty” towards an uncaring entity holding you back.
Da hat jemand Mutti gestört.