mschae
@mschae@discuss.mschae23.de
- Comment on Forgejo Scraping Protection: Nginx and Anubis 4 days ago:
Unrelated to the actual anti-bot topic discussed here, but I would just like to mention this point:
PROTOCOL = http+unix: because UNIX sockets are said to be faster locally but also because this avoids the painful management of ports. Also feels safer [as] there is no way to connect from outside.This is really underrated. I try to use this for all the server software I host, and not having to manage ports is absolutely great, along with knowing that nothing can connect to the service internally when it’s not supposed to.
Except I actually go a step further and use systemd’s socket activation feature, which has a few additional benefits (like seamless restarts, no need for
CAP_NET_BIND_SERVICE(my webserver and reverse proxy runs as a completely unprivileged user!), only starting the service once there is a request (this one is admittedly less useful), and having a quick overview of bound ports and Unix socket paths listed in the.socketfile). Unfortunately, most programs need to be patched to support this, including forgejo (outdated codeberg link here because I had to set the forgejo repository on my own code forge to private earlier today because of scrapers…). - Comment on How do people handle authoritative DNS redundancy for their self-hosted workloads? 1 week ago:
Interesting, that’s much more sophisticated than my setup (though to be fair, I host my services on a rented VPS instead of home)!
The issue only occurs with my externally-facing DNS, which is needed to, for example, to reach my Lemmy backend instance (lemmy.pootis.network) and the pictrs deployment. But yeah, internal DNS works perfectly for me and it easily survives a node failure.
Could still set up a recursive resolver for external DNS, but I guess that wouldn’t help other people who use a bad resolver. Tricky situation.
- Comment on How do people handle authoritative DNS redundancy for their self-hosted workloads? 1 week ago:
But even if I query
1.1.1.1directly formy-website’s record, it just doesn’t work most of the time because the resolver pins itself tons1which is currently failing, or it selectsns1and does not even care to tryns2.That sounds bad. They really shouldn’t do that.
moving my DNS infra somewhere else (Cloudflare, for example)
And it would also mean this isn’t a solution either. If the problem is on the resolvers’ side, moving to a different DNS hoster would not change anything. Hm. And the other two potential solutions you’ve listed would be extremely overkill for this use case…
Personally, I only host one authoritative namserver and do redundancy by using some free secondary DNS services (although a friend has also recently set up an authoritative nameserver, so maybe we’ll host secondary DNS for each other in the future). I haven’t encountered this issue before, but my server also hasn’t been down a lot.
There’s a lot of custom machinery that keeps my workloads running and accessible after a node failure, but all of this becomes completely moot when authoritative DNS is the bottleneck.
If it’s only necessary for your own stuff, maybe you should set up a local DNS resolver that works correctly which your services can use?
- Comment on Proposal: old.discuss.tchncs.de 1 month ago:
Hmm, I’m searching for the name of a project though, not my own. Wonder if that should be called differently
- Comment on Proposal: old.discuss.tchncs.de 1 month ago:
I just search for
mlmymhere sometimes, just in case someone posts a thread like this :)Haven’t seen it called that before, though (I’ve heard “name searching” before, but also only once. I wonder if there’s an established term for this).
- Comment on Proposal: old.discuss.tchncs.de 2 months ago:
Oh, true, that’s completely understandable. I don’t even know myself how long I can keep this up. Though I also don’t plan on disappearing entirely :)
Though to be fair, mlmym doesn’t require much maintenance (with the exception of the upcoming API v4 migration, of course). Most instances of it are still on rystaf’s build, even, and I guess that’s ‘good enough’.
And it’s not critical. If need be, it can be shut down and users will just switch back to the main interface.
The worst part of hosting mlmym you’ll have to consider is that it causes a lot of unwanted bot traffic to the lemmy server, because it’s so easily scrapeable. Whether that’s worth it for the few users who prefer the old reddit design is your call.
- Comment on Proposal: old.discuss.tchncs.de 2 months ago:
Ah, that must’ve been from when I was doing a refactor of the HTML templates. I split that over multiple commits, so there was one where I got creating communities working again, for example.
- Comment on Proposal: old.discuss.tchncs.de 2 months ago:
Funnily enough, the three features you mentioned as an example were already in rystaf’s version :)
I have a changelog that lists all the new features, changes, and bugfixes compared to the FHF fork: code.mschae23.de/mschae23/mlmym/…/CHANGELOG.md
The reason for this chain of forks is that the original version (rystaf/mlmym) has been abandoned and the maintainer is unreachable. The FHF, running old.lemmy.world, made a fork to support their instance, but they understandably don’t have a lot of time to maintain it.
And I basically just started improving the project and fixing bugs a few months ago, using their version as a base.