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:

1. you delete a valuable file by accident
2. a bad actor deletes or encrypts the data (ransomware)
3. the device gets stolen, or destroyed (hardware failure, power surge, fire, flood, hosting provider closing your account)
4. anything you can think of

For these different scenarios try to find a working backup/restore strategy. For me they go like

1. 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.
2. 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)
3. 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.

If you’re interested I wrote a quick HOWTO to migrate TT-RSS data from Mysql to Postgres a while ago. Ctrl+F search for Migrating tt-rss data to Postgresql from a MySQL-based installation here

I still use that same migrated database 4 years later

upgrades:

• distribution packages: unattended-upgrades
• third party software: subscribe to the releases RSS feed (in tt-rss or rss2email), read release notes, bump version number in my ansible playbook, run playbook, done.

vulnerabilities:

• debsecan for distribution packages
• trivy fort third-party applications/libraries/OCI images
• wazuh for larger (work) setups

Sometimes you need to understand the basics first. The points I listed are sysadmin 101. If you don’t understand these very basic concepts, there is no chance you will be able to keep any kind of server running, understand how it works, debug certificate problems and so on. Once you’re comfortable with that? Sure, use something “simpler” (a.k.a. another abstraction layer), Caddy is nice. The same point was made in the past about Apache (“just use nginx, it’s simpler”). Meanwhile I still use apache, but if needed I’m able to configure any kind of web server because i taught me the fundamentals.

At some point we have to refuse the temptation to go the “easy” way when working with complex systems - IT and networking are complex. Just try the hard way first, read the docs, and if it’s too complex/overwhelming/time-consuming, only then go for a more “noob-friendly” solution (I mean we’re on c/selfhosted, why not just buy a commercial NAS or use a hosted service instead? It’s easier). I use firewalld but I learned the basics of iptables a while ago. I don’t build apache from source when I need to upgrade, but I would know how to get 75% there - the docs would teach me the rest.

By default nginx will serve the contents of /var/www/html (a.k.a documentroot) directory regardless of what domain is used to access it. So you could build your static site using the tool of your choice, (hugo, sphinx, jekyll, …), put your index.html and all other files directly under that directory, and access your server at https://ip_address and have your static site served like that.

Step 2 is to automate the process of rebuilding your site and placing the files under the correct directory with the correct ownership and permissions. A basic shell script will do it.

Step 3 is to point your domain (DNS record) at your server’s public IP address and forwarding public port 80 to your server’s port 80. From there you will be able to access the site from the internet at http://mydomain.org

Step 3 is to configure nginx for proper virtualhost handling (that is, direct requests made for mydomain.org to your site under the /var/www/html/ directory, and all other requests like http://public_ip to a default, blank virtualhost. You may as well use an empty /var/www/html for the default site, and move your static site to a dedicated directory.) This is not a strict requirement, but will help in case you need to host multiple sites, is the best practice, and is a requirement for the following step.

Step 4 is to setup SSL/TLS certificates to serve your site at https://my_domain (HTTPS). Nowadays this is mostly done using an automatic certificate generation service such as Let’s Encrypt or any other ACME provider. certbot is the most well-known tool to do this (but not necessarily the simplest).

Step 5 is what you should have done at step 1: harden your server, setup a firewall, fail2ban, SSH keys and anything you can find to make it harder for an attacker to gain write access to your server, or read access to places they shouldn’t be able to read.

Step 6 is to destroy everything and do it again from scratch. You’ve documented or scripted all the steps, right?

As for the question “how do I actually implement all this? Which config files and what do I put in them?”, the answer is the same old one: RTFM. Yes, even the boring nginx docs, manpages and 1990’s Linux stuff. Each step will bring its own challenges and teach you a few concepts, one at a time. Reading guides can still be a good start for a quick and dirty setup, and will at least show you what can be done. The first time you do this, it can take a few days/weeks. After a few months of practice you will be able to do all that in less than 10 minutes.

I wrote my own, using plain HTML/CSS. Actually the final .html file gets templated by ansible depending on what’s installed on the server, but you can easily pick just the parts you need from the j2 template

1. You can verry well share bind mounts between containers
2. named volumes are actually directories too, you know? Under /var/lib/docker/volumes/ by default

Still, use bind mounts. Named or anonymous volumes are only good for temporary junk.

• step 1: use named volumes
• step 2: stop your containers or just wait for them to crash/stop unnoticed for some reason
• step 3: run docker system prune --all as one should do periodically to clean up the garbage docker leaves on your system. Lose all your data (this will delete even named volumes if they are not in use by a running container)
• step 4: never use named or anonymous volumes again, use bind mounts

The fact that you absolutely need to run docker system prune --all regularly to get rid of GBs of unused layers, test containers, etc, combined with the fact that it deletes explicitely named volumes makes them too unsafe for my taste. Just use bind mounts.

One has a total powered-on time of 51534 hours, and the other 49499 hours.
As for their actual age (manufacturing date), the only way to know is to look at the sticker on the drive, or find the invoice, can’t tell you right now.

$ for i in /dev/disk/by-id/ata-WD*; do sudo smartctl --all $i | grep Power_On_Hours; done
  9 Power_On_Hours          0x0032   030   030   000    Old_age   Always       -       51534
  9 Power_On_Hours          0x0032   033   033   000    Old_age   Always       -       49499

Follow the official documentation, nothing else comes close.

I have automated this process in my nextcloud ansible role

• simple: rsyslog: all local logs to a central syslog file (using the imfile module), all syslogsfrom all server to a central rsyslog server (over TCP/SSL, example here). Use lnav or something similar to consume the logs
• more complex, resource-heavy: Graylog Open as a replacement for the central rsyslog server, setup pipelines/alerts/whatever… Currently considering replacing my Graylog instance with Wazuh but I don’t know yet if it will be able to replace it completely for me

security

with containers, software maintainers also need to keep their image up-to-date with latest security fixes (most of them don’t) - whereas these are usually handled by unattended-upgrades or similar in a VM. Then put out a new release and expect users to upgrade ASAP. Or rebuild and encourage redeploying the latest image every day or so, which is bad for other reasons (no warning for breaking changes, the software must be tested thoroughly after every commit to master).

In short this adds the burden of proper OS/image maintenance for developers, something usually handled by distro maintainers.

trivy is helpful in assessing the maintenance/vulnerability level of OCI images.

https://lemmy.world/comment/13349298

homebank (desktop app) + weekly import of new transactions using woob/bank and a basic shell script. Homebank database synced via Nextcloud.

Please not these posts again

This thread is pinned for a reason: https://lemmy.world/post/60585

You are right. Quadlets require 4.4, Debian 12 has 4.3

Podman

• rootless by default
• daemonless
• integration with systemd, made even easier by podman-generate-systemd
• no third-party APT repository required, follows the same lifecycle as my LTS (Debian) distro
• podman and docker command-line are 100% compatible for my use cases

podman-compose is packaged in a separate podman-compose package in Debian 12 (did not try it though). The only thing missing (for me) in Debian 12 is quadlets support (requires podman 4.4+, Debian 12 has 4.3)

I use tt-rss and the android app