I think one of the issues inherent to the node ecosystem is that the coast is never clear. When the ethos is to never reinvent the wheel, and instead pull in a dependency chain of thousands of tiny things made by thousands of people (not necessarily a bad thing, it saves time and lets developers focus on what they really want to do), you’re going to have supply chain attacks that go undetected, because nobody has time to vet every single change to all those thousands of things.

The rclone fuse mount is essentially running in the memory of the container, and doesn’t translate back into the filesystem that the host presents from itself into that container.

Since rclone is available in the debian repos, the simplest and easiest option would be to do the rclone mount on the host and then pass that via bind mounting into the Plex container.

If you want to keep the rclone mounting containerized though (or if your Proxmox host is clustered, you want to mount it on the host, and you want the mount to be shared between your nodes), you can use rclone’s experimental but built-in nfs server feature: https://rclone.org/commands/rclone_serve_nfs/

Make sure your 2 containers can talk to each other over a secure network (“this server does not implement any authentication so any client will be able to access the data”), start the nfs server in the rclone container, and mount it via nfs in the Plex container.

Good luck!

apt-get clean will clear the apt cache and should give you enough temporary storage headroom on /var to do things, but if you’re bumping up on this limit often, you’ll need to reconfigure your storage.

/var is often where processes dump a lot of data (logs, databases, etc), and subpartitioning of /var sets a cap so that when too much data is dumped there, the application crashes instead of the whole system. /var/log is often recommended to be subpartitioned separately as well, so that logging can still go on if the application data fills up and crashes.

These kinds of overruns can be intentional DOS attacks, also, so the subpartitioning is often a security recommendation. NIST 800-171 requires separate partitions for /var, /var/log, /var/log/audit, and /var/tmp

Forgejo (Gitea fork used by codeberg.org) is a lightweight self-hostable option, and has a web-ui-based file editor. It’s got an official docker image, and it’s packaged for freebsd, as well, which makes it very easy to deploy and maintain either containerized or on a server.

With the size of modern linux kernels, I think 1GiB for a /boot partition is the absolute minimum I would go for a current full-sized distributuon. You’ll run into these out-of-space issues on updates all the time otherwise.

I’ve used an old, out-of-support phone as a permanently plugged-in homeassistant control panel. Not quite self-hosting as in phone-server, but a fun easy project and a great way to keep an old device in use.

The bang syntax makes duckduckgo easily the best search engine - it’s a shortcut to everything, the perfect gateway to the internet.

Can you give us the full output of the following commands?

ip addr

sysctl net.ipv6.conf.all.disable_ipv6

It’s kind of a dead square, since it’s hard to be arch-based without being pacman-based, and I figured “well, it still technically fits” haha 🤷‍♀️

“alpine as arch” is the kind of radical anarchy that deserves its own alignment chart, so here’s the best I could do on my phone.

I tried to buy a drink on a united flight once, and the poor guy had to tell me the only way I could pay for it was to download the united airlines app via the in-flight wifi and enter my card details there. Which I couldn’t do, so fuck me I guess.

The ups has data output to my firewall/router via usb, which the baremetal servers all connect to via apcupsd. When the ups loses or regains AC power, it broadcasts a message to all of them and they’re each scripted to act accordingly: laptops run on their own batteries, vms migrate over to laptops, non-vital hardware shuts down, etc.

Some laptop battery firmware allows you to force discharge even when connected to AC, and if your laptop can use the tlp recalibrate or tlp discharge commands then yours is supported.

I use this to power my thinkpad servers off of their own batteries during a power outage, to reduce load on my UPS. Great feature.

TL;DR: someone goes on Tucker Carlson’s podcast and claims that nearly the entire GDP of the US (Trillion with a T was not a typo) was spent building secret underground cities.

In my experience, mounting some thinkpad servers to the wall above the rack gives the homelab a very International Space Station feel.

I switched a workstation to Secureblue for the very specific security priorities targeted by that project, but I think for the majority of users, the main reason for not switching to atomic is one you mentioned: why fix what isn’t broken? The main selling point promoted to potential new users seems to be that updates don’t break anything, but I can’t remember a single time since Debian Sarge that an update broke anything for me, and I actually find the rpm-ostree package layering and updating process to be far more of a headache than otherwise.

Unless it’s prepackaged like a steam deck, moving from the traditional way of doing things to atomic is a major change. Like any major change, people need a good reason to make it, and I think right now the only compelling ones are either hyper-specific (switching to okd and needing to build it on coreos, wanting to move to a specific atomic project, etc.), or just general curiosity.

That’s why you can adjust swappiness, or designate a different high-endurance storage device for it.

I throw dust jackets away immediately, because I think they’re an abomination and books look and feel better without them. And then I dog-ear the pages because it gives them character.

I must be extra chaotic extra evil.

Unless “read-only” is being enforced by hardware (reading from optical media, etc), a compromised sudo user can circumvent anything, and write anywhere. A read-only flag or the root filesystem being mounted from somehwere else are just trivial extra steps in the way.

Improved security != extremely secure, is all I’m saying. There are a lot of things that go into making a system extremely secure, and while an immutable root filesystem may be one of them, it doesn’t do the job all on its own as advertised in this post.