Perhyte

It also means that ALL traffic incoming on a specific port of that VPS can only go to exactly ONE private wireguard peer. You could avoid both of these issues by having the reverse proxy on the VPS (which is why cloudflare works the way it does), but I prefer my https endpoint to be on my own trusted hardware.

For TLS-based protocols like HTTPS you can run a reverse proxy on the VPS that only looks at the SNI (server name indication) which does not require the private key to be present on the VPS. That way you can run all your HTTPS endpoints on the same port without issue even if the backend server depends on the host name.

This StackOverflow thread shows how to set that up for a few different reverse proxies.

If there happens to be some mental TLS handshake RCE that comes up, chances are they are all using the same underlying TLS library so all will be susceptible…

Among common reverse proxies, I know of at least two underlying TLS stacks being used:

• Nginx uses OpenSSL.
  • This is probably the one you thought everyone was using, as it’s essentially considered to be the “default” TLS stack.
• Caddy uses crypto/tls from the Go standard library (which has its own implementation, it’s not just a wrapper around OpenSSL).
  • This is in all likelihood also the case for Traefik (and any other Go-based reverse proxies), though I did not check.

Small correction: Pi lies between 2^1 and 2^2, so its floating-point exponent is 1. With all the mantissa bits cleared you’d be left with 1 * 2^1, not 1 * 2^0.

Aurora is no longer maintained, but it still works just fine. It’s a Windows app, so not web-accessible or anything, but it’s free. It only contains the SRD content by default (probably for legal reasons), but there’s at least one publicly-accessible elements repository for it that you can find using your favorite search engine.

That domain currently hosts a “this domain may be for sale” page, but it’s been registered since 2005 so it’s definitely not because of this post.

In fact, unless you post your domain somewhere online or its registration is available somewhere, it’s unlikely anyone will ever visit your server without a direct link provided by you or someone else who knows it.

If you use HTTPS with a publicly-trusted certificate (such as via Let’s Encrypt), the host names in the certificate will be published in certificate transparency logs. So at least the “main” domain will be known, as well as any subdomains you don’t hide by using wildcards.

I’m not sure whether anyone uses those as a list of sites to automatically visit, but I certainly would not count on nobody doing so.

That just gives them the domain name though, so URLS with long randomly-generated paths should still be safe.

Just checked, registered since at least 2018. The .org and .net variants are still available though!

Additionally, HTTPS if very easy to set up nowadays and the certificates are free¹.

¹: Assuming you have a public domain name, but for ActivityPub that’s already a requirement due to the push nature of the protocol.

AFAIK docker-compose only puts the container names in DNS for other containers in the same stack (or in the same configured network, if applicable), not for the host system and not for other systems on the local LAN.

I have a similar setup.

Getting the DNS to return the right addresses is easy enough: you just set your records for subdomain * instead a specific subdomain, and then any subdomain that’s not explicitly configured will default to using the records for *.

Assuming you want to use Let’s Encrypt (or another ACME CA) you’ll probably want to make sure you use an ACME client that supports your DNS provider’s API (or switch DNS provider to one that has an API your client supports). That way you can get wildcard TLS certificates (so individual subdomains won’t still leak via Certificate Transparency logs). Configure your ACME client to use the Let’s Encrypt staging server until you see a wildcard certificate on your domains.

Some other stuff you’ll probably want:

• A reverse proxy to handle requests for those subdomains. I use Caddy, but basically any reverse proxy will do. The reason I like Caddy is that it has a built-in ACME client as well as a bunch of plugins for DNS providers including my preferred one. It’s a bit tricky to set this up with wildcard certificates (by default it likes to request individual subdomain certificates), but I got it working and it’s been running very smoothly since.
• To put a login screen before each service I’ve configured Caddy to only let visitors through to the real pages (or the error page, for unconfigured domains) if Authelia agrees.

I believe on the free ARM instances you get 1Gbps per core (I’ve achieved over 2Gbps on my 4-core instance, which was probably limited by the other side of the connections). What you say may be correct for the AMD instances though.

For the ARM instances they’re a gigabit per OCPU, which you can get 4 of for free (assuming you’re lucky enough with availability), so you can theoretically get 4Gbps for free.

I recently got temporarily IP-banned from a site, apparently for subscribing to one of their RSS feeds and occasionally opening a post. The error page they served me (instead of the content I wanted to read) accused me of “botting”. Why even have RSS feeds then? 🤷‍♂️

My family shares a fairly uncommon surname with a professional athlete we are (as far as we can tell) completely unrelated to.

My father always joked that we should answer “we don’t discuss that” when asked about it, as if there had been some huge falling-out.

You produce a hundred 24 core cpus, then you test them rigorously. You discover that 30 work perfectly and sell them as the 24 core mdoel. 30 have between one and eight defective cores, so you block access to those cores and sell them as the 16 core model. Rinse and repeat until you reach the minimum number of cores for a saleable cpu.

Except the ratios of consumer demand do not always match up neatly with the production ratios. IIRC there have been cases where they’ve overproduced the top model but expected not to be able to sell them all at the price they were asking for that model, and chose to artificially “cripple” some of those and sell them as a more limited model. An alternative sales strategy would have been to lower the price of the top model to increase demand for it, of course, but that may not always be the most profitable thing to do.

It’s possible your e-mail account was compromised, and that’s how they were able to click that confirmation link you ignored. Change your e-mail password.

I tried it on Linux Mint and I’m directed to FlatHub, which states:

★★ You’ll need a Plex Media Server and an active Plex Pass to use this app ★★

Installed it anyway, but:

I guess they didn’t update that version yet?

Edit ~24 hours later: I just got the update. It works now.
Edit 2: … but media keys don’t seem to work :(

Someone already made one 3 hours ago. Though apparently it won’t help by itself, since their robots.txt disallows indexing anyway (and that same issue also requests that to be adjusted).

According to their develop pages, they do look for that:

There are a handful of factors that play a role in canonicalization: […], and rel="canonical" link annotations.

(but Google considers it a hint, so they don’t have to honor it)

Also, that change was just for Lemmy. Other Fediverse sites may not do the same, which would lessen the effect. For example, from a quick look at a random federated post on kbin.social, there was no such <link rel="canonical"/> element present in the page source.

As of v0.18.2, Lemmy marks the “original URL” as the canonical URL so search engines know which page is the “real” one. Shouldn’t that help?