pcouy

With all the botting going on on Reddit, this whole Google AI deal makes me think of the recent paper that demonstrates that, as common sens would suggest, deep learning models collapse when successive generations are trained on the previous generations' output

It does not seem to be the case. Was it the full domain for this instance ?

This is an old post, but I've only recently (I'd say a few months ago) started to see Google's indexing bots pop-up in my instance's server logs, so this may be about to change

never stopped POSTing, even though I configured nginx to always respond 403 to anything from them for about a year now.

Lol, there are definitely some stubborn user agents out there. I've been serving 418 to a bunch of SEO crawlers - with fail2ban configured to drop all packets from their IPs/CIDR ranges after some attemps - for a few months now. They keep coming at the same rate as soon as they get unbanned. I guess they keep sending requests into the void for the whole ban duration.

Using 418 for undesirable requests instead of a more common status code (such as 403) lets me easily filter these blocks in fail2ban, which can help weed out a lot of noise in server logs.

Your sensitive data and logins are tied to email addresses, which are tied to domains. Lose your domain, someone can access everything.

I recently stumbled upon an article showing how bad this can be when the expired domains were used for important/serious stuff

I think they do get marked as dead after the Bodis subdomain does not act as a Lemmy instance. But I was wondering if a large number of instances "waking up from the dead" and acting maliciously could cause some trouble. Or would such "undead" instances pose no more threat to the fediverse than the same number of newly created malicious instances ? I'm mainly thinking about stuff like being in a privileged position to DoS most instances at once, or impersonation of accounts that used to actually exist on these "undead" instances

Is named actually running as the bind user inside the container ? Maybe a USER bind line below the RUN lines will help.

I'll probably look into newer fancier options such as Caddy one day, but as far as I remember Nginx has never failed me : it's stable, battle tested, and extremely mature. I can't remember a single time when I've been affected by a breaking change (I could not even find one by searching changelogs) and the feature set makes it very versatile. Newer alternatives seem really interesting, but it seems to me they have quite frequent breaking changes and are not as feature rich.

That being said, I'd love to see side-by-side comparison of Nginx and Caddy configs (if anyone wants to translate to Caddy the Nginx caching proxy for OSM I shared earlier this week, that would make a good and useful example), as well as examples of features missing from Nginx. This may give me enough motivation to actually try Caddy :)

(edit : ad->and)

I started working on a PR right after cross posting this.

Since I believe this is mainly a documentation issue, I'm trying to gather some feedback on this guide in parallel of submitting the pull request in order to have it merged into the official documentation

I don't use nginx-proxy-manager, but if you want to share what you tried, I will try to help you figure what's not working

It's the clients (web/android app, probably iOS too) that are making these requests.

To the best of my knowledge, the Immich server inside the container is not making requests to the outside. It is merely sending a style.json to the client displaying a map, which then fetches tiles from the Cofractal URL inside this JSON.

Or you can quite easily configure nginx as your personal caching proxy with an arbitrarily long TTL/retention duration (you can check out my follow-up post for instructions on doing that)