No idea about the Lemmy hosting bit, but I highly doubt that .com you got will renew at $1 going forward. Judging by this list it’ll most likely be $9+ after the first year.
At $1/year, the registrar you used is taking a loss because they pay more than that to the registry for it. They might be fine with that for the first year to get you in the door, but they’d presumably prefer to be profitable in the long term.
You don’t actually have to set all the modification dates to now, you can pick any other timestamp you want. So to preserve the order of the files, you could just have the script sort the list of files by date, then update the modification date of the oldest file to some fixed time ago, the second-oldest to a bit later, and so on.
You could even exclude recently-edited files because the real modification dates are probably more relevant for those. For example, if you only process files older than 3 months, and update those starting from "6 months old"1, that just leaves remembering to run that script at least once a year or so. Just pick a date and put a recurring reminder in your calendar.
1: I picked 6 months there to leave some slack, in case you procrastinate your next run or it’s otherwise delayed because you’re out sick or on vacation or something.
If you don’t mind using a gibberish .xyz domain, why not an 1.111B class? ([6-9 digits].xyz for $0.99/year)
Any chance you’ve defined the new networks as “internal”? (using docker network create --internal on the CLI or internal: true in your docker-compose.yaml).
Because the symptoms you’re describing (no connectivity to stuff outside the new network, including the wider Internet) sound exactly like you did, but didn’t realize what that option does…
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:
crypto/tls from the Go standard library (which has its own implementation, it’s not just a wrapper around OpenSSL).
There was some kind of incident between the artist and a camera woman. The exact details aren’t public, AFAIK.
In a rather large part of the world (the solid green parts of that map).
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.
There may not have been much to tell until it actually started, which was one day before the start of this month (modulo time zones, it was held in UTC+04).
It’s an annual thing apparently (except during the height of the pandemic) and this was the 28th time, hence the “28” in the name. Presumably they’ll hold COP29 next year, and now you’ve heard of that one about a year beforehand! 😛
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 free1.
1: Assuming you have a public domain name, but for ActivityPub that’s already a requirement due to the push nature of the protocol.
There are FOSS licenses (notably the GPL) that say that if you do resell (or otherwise redistribute) the software, you have to do so only under the same terms. (That is, you can’t sell a proprietary fork. But you could sell a fork under FOSS terms.) But none that say “no selling.”
For many companies (especially large ones), the GPL and similar copyleft licenses may as well mean “no selling”, because they won’t go near it for code that’s incorporated in their own software products. Which is why some projects have such a license but with a “or pay us to get a commercial license” alternative.
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:
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.
My Linux laptop is set to check for updates daily, which I then apply manually when I notice the tray icon. I sometimes procrastinate when it comes to reboots though.
My Android phone is on auto-update, which seems to mean whenever it’s being charging for a few hours (so typically when charging overnight). Because the battery is still pretty good and I don’t need to charge daily, that comes down to once every 2-3 nights or so.
My personal Linux servers (which run my self-hosted apps) are configured to automatically apply all updates (and reboot if necessary afterwards) at the time of day I’m most likely to be awake and available to manually fix stuff if anything goes wrong. The Docker-containers that run on them mostly get auto-updated to the latest version every 6 hours by Watchtower. A few containers have more cautious policies though, ranging from pinning a major version (but auto-upgrading to new minor versions within that) to pinning a specific version and at most sending a notification if there’s an update. The latter is limited to stuff that has broken before and/or where newer releases are known to be buggy or incompatible.
When it comes to major updates (i.e. new distro releases) of my Linux machines, I typically wait about a month before upgrading because I’ve been bitten by release-day bugs before.