Looking for a good RSS Reader
vegetaaaaaaa @ vegetaaaaaaa @lemmy.world Posts 8Comments 253Joined 2 yr. ago
vegetaaaaaaa @ vegetaaaaaaa @lemmy.world
Posts
8
Comments
253
Joined
2 yr. ago
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:
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
- You can verry well share bind mounts between containers
- 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 --allas 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
imfilemodule), all syslogsfrom all server to a central rsyslog server (over TCP/SSL, example here). Uselnavor 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.
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
podmananddockercommand-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
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 installationhereI still use that same migrated database 4 years later