If your comments have been federated to other instances, they will be there until they are deleted locally. If someone clicks on your user profile, they will get a DNS error if the domain is no longer there. Images in the comments pointing to you instance will be broken too. Nothing terrible actually happens.

Migrating accounts a la Mastodon is not happening soon in Lemmy.

My advice is: Go on and save some money.

Sorry to read that.

I’ve dded an external drive instead of an SD card once by mistake. I’ve never felt more stupid than that day.

It’s running NetBSD, isn’t it?

Some security tips:

Firewall should block everything by default, and you start allowing incoming and outgoing connections when you need them or if something fails.

Disable passwords and root access in ssh daemon.

Use fail2ban or something similar to block bots failing to log-in.

Use random long passwords for everything (eg: like databases). And put then in a password manager. If you can remember the database password, it’s not strong enough. If you can remember the admin password for a public web service, it’s weak.

Don’t repeat the passwords. Everything should have its own random long password.

.env files and files with secrets should be readable only by its service user. Chmod them to 400.

Monitor logs from time to time to see if something funny is happening.

Random ports are easy to discover and there are tools to discover what service is behind a port.

It’s annoying for the legitimate user and easy to bypass by an actual attacker.

Also, if you use a random port above 1024 it could be a security issue since any user could star listening if the legitimate process crashes.

See this

Nothing illegal is being discussed.

But I’m happy to talk about Jolly Roger.

https://workaround.org/

Wow! this is exactly what I needed. Although, I didn’t exactly ask for it.

Thank you very much

Thanks to both of you.

I had the hope that DMARC, SPF and DKIM was stuff I could just ignore if not sending email. It seems I was wrong about that.

I’ve got 3 tricks for ya:

• backups
• backups
• backups

You may have one psql server per region and then use Bucardo to synchronize them.

I’ve never done this in production, so take my advice with a grain of salt.

Since you posted it in a selfhosting community, this is the feeling I get:

I don’t know any product that matches your requirements.

If I had to deal with that today I’d buy a rasberry pi, a USB sim card dongle and some raspberry hat with GPS receiver.

You can write a small API that listens to the raspberries, who sends periodically their positions, and save it to a database.

But it’s a quite large project. There’s a lot of aspects to consider. The GUI, security, batteries, and a way to attach it to an animal without being lost or destroyed.

Sorry for not giving a useful answer lol. If you come out with an actual solution I’ll be glad to hear it, so I can track my cats in case they get lost.

Are you using Docker Desktop? It uses a headless virtual machine inside host, so connecting to host is tricky.

You may use hostname host.docker.internal from the container to access host.

edit: link to the docs https://docs.docker.com/desktop/networking/#i-want-to-connect-from-a-container-to-a-service-on-the-host

Kubernetes is useful if you have gone full cattle over pets. And that is very uncommon in home setups. If you only own one or two small machines you cannot destroy infra easily in a “cattle” way, and the bloatware that comes with Kubernetes doesn’t help you neither.

In homelabs and home servers the pros of Kubernetes are not very useful: high availability, auto-scaling, gitops integrations, etc: Why would you need autoscaling and HA for a SFTP used only by you? Instead you write a docker-compose.yml and call it a day.

You installed nextcloud with snap? HOW DARE YOU!

It looks like system is thrashing. Because of the high disk usage and very low amount of physical memory available previous the incident. Look what dmesg says. Maybe you’ll see some OOM errors.

The solution, I believe, should be to limit the amount of resources your services can use. In their config or something, or put them inside containers with limited amount of memory, or migrate one of the services to other machine.

A posible attack from an untrusted client, is to create a lots of VMs in a short period of time.

1440 VMs running for a minute cost the same as a single one running for a day. 43200 VMs running for a minute cost the same as a single one running for a month.

Therefore, attacks are kinda cheap, specially if you are paid by the competence.

So, for an untrusted client, the best is to limit the maximum number of VMs she can create.

AWS does something similar. I recall something like 20 VMs as the limit for a new client.

Edit: Here are AWS docs about that: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html

deleted by creator