Idk, I explicitly set up Postgres, which took extra work since the default is SQLite. I use Postgres for my day job, so it makes sense to me to keep everything the same.

I use Postgres, because MySQL touched me inappropriately as a kid and MariaDB is too similar. Oh, and also because it’s what I use at work.

If you need to fix something, you should know what it is.

No prob! Glad you got it to work, permissions can be a huge pain.

Passing that in basically overrides the [USER field in the Dockerfile](docker run -it --user $UID:$GID). Make sure that user/group combo has access to the render device.

Basically this:

docker run -it --user $UID:$GID

Pass it a user and group that have the appropriate access, and no more. You can also set this in Docker compose or whatever other abstraction you’re using.

This is totally fine for testing, but there are almost always better solutions.

And you can map internal users to external users. This isn’t as common with Docker since things tend to run as root, so maybe look up Podman docs where it’s more common since it’s whole schtick is running with minimal permissions.

I guess we have different ideas of what “enterprise tools” means. At the company I work at, we use Docker and Kubernetes on AWS ECS. Everything is in the cloud so there’s no hardware for something like Proxmox to abstract over, just Docker hosts running Docker containers.

That’s what I’m familiar with, and Docker containers are really well documented for a lot of services, so it made a ton of sense for me to start there. I think LXCs and VMs encourage the same types of bad behaviors that can complicate maintenance, whereas Docker containers encourage good behaviors that simplify maintenance (specifically one app per container). LXCs and VMs have their place, but I’m convinced Docker/Podman containers are the best default choice.

We also use waiter/waitress, maître d’, and sometimes steward/stewardess (esp. on airplanes). There’s technically a difference:

• waiter/waitress - brings food
• server - person the customer interacts with (i.e. takes orders)
• maître d’ (hotel) - head of wait staff
• steward/stewardess - serving customers is usually a secondary duty

I think “server” has become more popular because it’s gender neutral, but “waiter/waitress” is still quite common and most don’t make the distinction between the two.

I personally like the overlap between computer server and restaurant server because both exist to provide things upon request. The term “wait” that “waiter” comes from is pretty archaic.

Yeah, Windows isn’t that bad, but it’s not that good either. On servers, everything requires a million clicks or some random terminal command that’s impossible to find documentation for (was just passed down from senior to junior over the ages). I had to configure one for testing (embedded product that needed to work in Windows environments as well as Linux), and it took hours to do the most basic task. Granted, none of us were sysadmins, just devs, but we weren’t familiar with Linux or Windows servers, just desktops, and Linux was by far easier to configure.

Don’t pick Windows for your server without a good reason, you’ll get much more value from learning Linux than Windows.

What’s wrong with “server”? They serve you food, much like a computer server serves files.

I think it’s much better than “waiter” (which we also use) because I want them to bring food, not wait.

Yup, that’s the form I’m familiar with. Most idioms avoid gender entirely.

Sure, Docker is more or less an abstraction layer on top of LXC. It’s the same tech underneath, just a different way of interacting with it.

It’s the same underlying technology. Yes they’re different, but they are comparable.

Many ISPs don’t provide a publicly accessible IP, so for those, it’s not included and would cost extra (for me it’s $10/month IIRC. Fortunately, that’s not the norm, and that’s what I was getting at.

Are you claiming that paying for internet service is “paying for an IP”? If so, that’s a really pedantic point.

For snapshots, you can use filesystem features, like BTRFS or ZFS snapshots. If you make sure to encapsulate everything in the container, disaster recovery is as simple as putting configs onto the new system and starting services (use specific versions to keep things reasonable.

I think that’s also really lazy, it’s just a different type of lazy from virtualization.

My main issue with virtualization is maintenance. Most likely, you’re using system dependencies, and if you upgrade the system, there’s a very real chance of breakage. If you use containers, you can typically upgrade the host without breaking the containers, and you can upgrade containers without touching the host. So upgrades become a lot less scary since I have pretty fine-grained control and can limit breakage to only the part I’m touching, and I get all of that with minimal resource overhead (with VMs, each VM needs the whole host base system, containers don’t).

Obviously use what works for you, I just think it’s a bit overwhelming for a new user to jump to Proxmox vs a general purpose Linux distro.

If you just want LXCs, use Docker or Podman on whatever Linux distro you’re familiar with. If you get extra hardware, it’s not hard to have one be the trunk and reverse proxy to the other nodes (it’s like 5 lines of config in Caddy or HAProxy).

If you end up wanting what Proxmox offers, it’s pretty easy to switch, but I really don’t think most people need it unless they’re going to run server grade hardware (i.e. will run multiple VMs). If you’re just running a few services, it’s overkill.

You pay for internet service, and some do that by providing leases on publicly accessible IPs, and some do that by providing internal IPs and routing things themselves. Some block specific incoming ports (often anything other than 80 and 443), whereas others block nothing. Most services offer an extra “static IP” service that gives you a fixed publicly accessible IP.

Source: I had the former for years and now I’m stuck with the latter.