Characters from the Murderbot Dairies, mostly main laptop (t480 currently) -- Murderbot; previous main laptop (x270) -- MB20; homeserver -- ART; a TV box running armbian -- Miki; t440p is currently Behemoth (from Bulgakov's "Мастер и Маргарита"), although I'll probably rename it to Holism; x230t -- Three; a random thin client I occasionally use to test stuff is yogurt (from" love, death & robots"), not sure if I'll rename them.

Mine were great. Still going. Honestly as you did just contact support they should take care of it.

I started using it and I really like it. Easy to use and very practical.

Update to version 6 on two raspis has been less than stellar for me since the beginning. I don’t know why it wasn’t great. I setup docker and AGH, first time for both. AGH has less setup for more features than pihole. I’m now using both AGH and Pihole; but as soon as I get a WireGuard container up, the pihole/pivpn is probably going to be history.

Thank you for the information! Since Proxmox does this by itself with those templates it uses, I never did this process. I guess I'll check some guide...thanks a lot!

It honestly depends on how you run things. If everything is in containers, chances are you're already getting the benefits of a firewall. For example, with podman or docker, you already explicitly expose ports, which is already a form of firewall. If you're running things outside of containers, then yeah, I agree with you, there's too much risk of something opening up a port you didn't expect. Everything I run is with podman, which exposes stuff with iptables rules. That's the same thing a basic firewall does, so adding a firewall is superfluous unless you're using it to do something else, like geoip filtering. When in doubt, use a firewall. But depending on the setup, it could be unnecessary.

So far it's been an interview show. I have enjoyed the interviews so far.

Not to mention: Snapshots.

Very nice! Now posted here: https://github.com/mag37/dockcheck/discussions/146

Lol, a lot, but not that many. Mostly docker shit filling up /var from containers I'd tried running or run for a while and got bored of. Just needed a good docker prune -a --volumes.

not everything is through API, initial setup has to be done manually and then API for other things. Having said that I will move some of the important things to API soon

OK, yah, that's good point about swarms. I've generally not used any swarmed filesystem stuff where I needed persistence, just shared databases, so it hasn't come up.

Data loss is not a problem specific to self-hosting. Whenever you administrate a system that contains valuable data (a self-hosted network service/application, you personal computer, phone...), think about a backup and recovery strategy for common (and less common) data loss cases: you delete a valuable file by accident a bad actor deletes or encrypts the data (ransomware) the device gets stolen, or destroyed (hardware failure, power surge, fire, flood, hosting provider closing your account) anything you can think of For these different scenarios try to find a working backup/restore strategy. For me they go like Automatic, daily local backups (anything on my server gets backed up once a day to a backups directory using rsnapshot). Note that file sync like nextcloud won't protect you against this risk, if you delete a file on the nextcloud client it's also gone on the Nextcloud server (though there is a recycle bin). Local backups are quick and easy to restore after a simple mistake like this. They wont protect you against 2 and 3. Assuming an attacker gains access to your machine they will also destroy or encrypt your local backups. My strategy against this is to pull a copy of the latest local backup, weekly, to a USB drive, through another computer, using rsync/rsnapshot. Then I unplug the USB drive, store it somewhere safe outside my home, and plug in a second USB drive. I rotate the drives every week (or every 2 weeks when I'm lazy - I have set up a notification to nag me to rotate the drive every saturday, but I sometimes ignore it) The USB strategy also protects me against 3. If both my server and main computer burn down, the second drive is still out there, safely encrypted. It's the worst case scenario, I'd probably spend quite some time setting up everything again (though most of the setup is automated), and at this point I'd have bigger problems like, you know, burned down house. But I'd still have my data. There are other strategies, tools, etc, this one works for me. It's cheap (the USB drives are a one-time investment), the only manual step is to rotate the drives every week or so.

Depending on what you need either first or second solution may be better. In my company we use Netbox fork Nautobot along with Ansible. It's Ansible that initiates the change and fills all the data properties in Nautobot. This way Ansible can also raise and close relevant change ticket at the right time. With your second solution it would be more difficult for us to properly work with change tickets in compliant way. If you ever intend to take compliance and ticketing system into account, then I would recommend going with first solution, otherwise both solutions are fine to me.