Yes. It doesn’t outright kill an instance, but it’s definitely a major inconvenience and a learning opportunity.

It’s my understanding that this isn’t possible. Migrating domains in Lemmy is not supported though it is possible with some very hacky solutions like you’re describing. But the old domain needs to be retained indefinitely as a pointer to the new domain or it will break federation with other instances. If they lose control of the domain or can’t keep it basically forever then federation will break. They can potentially migrate users and posts, but it is effectively like resetting and starting over as a new instance.

Most of the hacky ways around it involve retaining ownership of the old domain and leaving it up indefinitely as a pointer to the new location. If your domain is taken from you though there is not much you can do.

Seriously dumb to have used this TLD considering there are a ton of choices these days.

I’m now wondering what happens if the Mali government (or someone else) begins using those domains with their own lemmy instance, potentially with malicious content.

Would the instances they’ve federated with begin ingesting and serving that content automatically? Or would that be blocked due to key mismatch?

I’m not sure how this would work, but what about the concept of cross-instance communities? For users it would be a bit like a multi-reddit where you group various communities together into one aggregate list but when posting content you’d have to choose which instance it lands on. Mods would have to agree on a set of rules (and you’d have some communities split off due to differences), but otherwise it seems somewhat plausible.

That would be one way to solve the problem of every instance having a version of one specific type of community.

Do you realize that boomers are the ones who literally made the Internet?

Not the ones that I work with.

Ansible vault. All my config files and scripts are deployed with Ansible. Usually they are pushing those into a file or environment variable but if you scope permissions narrowly and don’t run services/containers as root you should be somewhat safe. If someone has filesystem access you’re already in big trouble.

Instead I’d focus on keeping your attack surface as small as possible. Keep services behind a VPN or segment public facing services to a separate VLAN or docker network.

Spiderman is what got me to purchase a PS4. I’ve rebought almost everything on PC though so I think I learned my lesson this time (still waiting on Bloodborne and Ghost of Tsushima 😞).

Back in 2016 or so you could get a RaspberryPi 3 for $35. Add a $5 power supply, $5 SD card and $10 case (or 3d print your own) and you’ve got a nice little piece of hardware for running a tiny project at home for ~$50. More than enough for hosting some simple web services, backup software or something like Home Assistant.

Plus it was popular (which makes it even more popular). It’s always been very easy to find guides written specifically for the hardware, despite it’s limitations.

I think the value proposition has been dropping steadily though. They cost more, are hard to find and there are now a lot more competing SBCs on the market. RaspberryPi still has name recognition though, for now.

There is a community Ansible module for the Uptime-Kuma API that I’ve been trying to get working so I can trigger the maintenance window when I run my playbook to update services but I haven’t quite figured it out yet.

I’m in the same boat though, I start updating containers and my slack channel blows up for like five minutes straight.

I’ve got Uptime-Kuma internally for watching all my internal services and then I’ve got one running on a VPS that watches all the external services and public endpoints.

Such a great project and so easy to use…

FreeDNS requires you to log in to their website once a month or so to keep your DNS name active or they will revoke it. DuckDNS doesn’t require that. It’s free and it works. I set it up forever ago and never have to touch it, with FreeDNS I was risking losing my name or having my services go down if I missed their nag email.

I’m starting to think we just need to rebrand green energy projects to sound more like a tech concept to trick people into liking it more.

It’s not solar, it’s LightWave.

( ͡° ͜ʖ ͡°)

It’s going to be really difficult to get most people used to the idea of decentralized federated services.

My dongers have never been higher.

I think a combination of 3d animation and ‘ai postprocessing’ is probably the most effective result.

As much as I respect the rights of extras, they are expensive and easier to replace than lead actors. Disney already has things setup so extras never have to be on set with your lead actors, although you get a lot of backgrounds with ‘people just walking back and forth with no purpose’, but a bit more effort will mean those prefilmed backgrounds wont even require human actors, they barely do already.

ansible-nas

Wow, yeah this is exactly the sort of roles/playbooks that I’ve been building. I’m definitely using this as a source before starting my own from scratch. Thanks for sharing.

I’m actually doing both right now since I had quite a huge compose file that I haven’t converted to ansible yet. The biggest frustration I have is that there doesn’t seem to be an ansible module that works with compose v2 (the official plugin) which means I’m either stuck on the old version of compose or I have to use shell commands to run stuff like ‘docker compose up -d’.

One nice thing I’ve gained though is for services like Plex. I have an ‘update’ playbook that I use and it will check to see if Plex is actively streaming before updating the container which isn’t something I could do easily with compose.

Hahaha, I’ve been using ChatGPT in the exact same way. It requires a bit of double-checking but it really speeds things up a lot.