I’m not sure which clients are used to connect. Perhaps some proof of work challenge for the connecting client to solve first? Anubis does this for http(s) and browsers. I’ve seen it in the wild quite often in the last weeks, so it seems to be effective (until the scrapers learn to use selenium to mimic browsers or so).

Thanks.

Since virtiofs has been developed for this scenario, it would be sane to use it for VMs. Thanks for the hint.

I will look into it. Some users had issues to get it running with incus - older unsupported libvirtd versions in the distri. Also dxa isn’t supported, yet. But maybe it is still better than NFS performance wise.

Moot point. I do not really need the distributed storage part for my scenario. Not right now.

Maybe I start with NFS and explore gluster as soon as storage distribution is needed. Looks like it could be a drop-in eplacement for NFSv3. Since it doesn’t access the block devices directly, I still could use the respective fs’ tool set (I.e. ext4 or btrfs) for maintenance tasks.

Thanks. I will take a closer look into GlusterFS and Ceph.

The use case would be a file storage for anything (text, documents, images, audio and video files). I’d like to share this data among multiple instances and don’t want to store that data multiple times - it is bad for my bank account and I don’t want to keep track of the various redundant file sets. So data and service decoupling.

Service scaling isn’t a requirement. It’s more about different services (some as containers, some as VMs) which should work on the same files, sometimes concurrently.

That jellyfin/arr approach works well and is easy to set up, if all containers access the same docker volume. But it doesn’t when VMs (KVM) or other containers (lxc) come into play. So I can’t use it in this context.

Failover is nice to have. But there is more to it than just the data replication between hosts. It’s not a priority to me right now.

Database replication isn’t required.

Thanks for asking. I left that detail out. An SSD which is attached to the virtualization host via SATA. I plan to use either a LVM2 volume group or a BTRFS with subvolumes to provide the storage pool to Incus/LXC.

Doesn’t work for me. Self inflicted DDOS?

Tripwire and auditd can monitor a filesystem and notify you about changes. I don’t know the tools myself, because i never needed them. Maybe these can give you a hint on the responsible service.

If you suspect a certain service to be responsible: what do the logs of the service say? If nothing: increase the loglevel to info or debug?

Sorry. No solution. Just ideas. Good luck.

Good.

Exposing Jellyfin/ plex through routing or SNAT plus dyndns would be a cheap option.

As soon as one rents a VPS (to expose the selfhosted at home service through routing/ tunneling) it would cost at least 2€/ month?

Damn. Another rabbit hole to dive into. Thanks… I guess. :)

The lua queries look promising.

Have fun. :)

Side note: Never look at LXC/incus or home assistant or esp32 to attach. Rabbit holes everywhere.

In your case: no need for a fw if you can trust your local network.

Generally: services can have bugs - reverse proxy them. Not everybody needs to access the service - limit access with a firewall. Limit brute-force/ word-list attempts - MFA / fail2ban.

Needs more scrolling wall of text for my liking. ;)

Thanks.

Works with my plasma6, too. It feels a bit like unintended behaviour. 🙂

It does? Multiple desktops and activities or something else? (Link doesn’t load)

It really depends on the use case. 😏

:) the hardware is still more capable than a brick:
Plug in favourite installation media stick, push reset button (if there is one), reinstall.

Can an OS be bricked?:

A brick (or bricked device) is a mobile device, game console, router, computer or other electronic device that is no longer functional due to corrupted firmware, a hardware problem, or other damage.[1] The term analogizes the device to a brick’s modern technological usefulness.[2]

Edit: you may click the tiny down arrow if you think it can’t. ;)

One aspect is how interesting you are as a target. What would a possible attacker gain by getting access to your services or hosts?

The danger to get hacked is there but you are not Microsoft, amazon or PayPal. Expect login attempts and port scans from actors who map out the internets. But I doubt someone would spend much effort to break into your hosts if you do not make it easy (like scripted automatic exploits and known passwords login attempts easy) .

DDOS protection isn’t something a tiny self hosted instance would need (at least in my experience).

Firewall your hosts, maybe use a reverse proxy and only expose the necessary services. Use secure passwords (different for each service), add fail2ban or the like if you’re paranoid. Maybe look into MFA. Use a DMZ (yes, VLANs could be involved here). Keep your software updated so that exploits don’t work. Have backups if something breaks or gets broken.

In my experience the biggest danger to my services is my laziness. It takes steady low level effort to keep the instances updated and running. (Yes there are automated update mechanisms - unattended upgrades i.e. -, but also downwards compatibility breaking changes in the software which will require manual interactions by me.)