You can create a canonical name (CNAME) record to point to your old domain, you don’t need to recreate the LE if you don’t want to.

Assuming I understood your scenario, Canonical name record pointing one DNS name to another domain, then recreate your letsencrypt on the host.

“18% of car owners don’t know their brake fluid DOT rating.”

I thought I was being clear that I have audited some of the scripts. They are built referencing other scripts instead of functions, and these rely on URLs. It’s difficult to follow.

Don’t ask chatgpt to audit code.

Have you ever looked at what was once ttek scripts? They’re a spaghetti of calls to other scripts. It’s not pretty. And not intuitive to audit.

The ds211j is on synology DSM 6, which is ancient. I’ll look again, but I don’t think it supports btrfs.

I don’t use access control, I lock down with networking and filters.

But those are concerns for all containers, and not really an immich issue.

I agree, NFS is eazy peazy, livin greazy.

I have an old ds211j synology for backup. I just can’t bring myself to replace it, it still works. However, it doesn’t support zfs. I wish I could get another Linux running on this thing.

However, NFS does work on it and is so simple and easy to lock down, it works in a ton of corner cases like mine.

My issue with mgmt.config is that it bills itself as an api-driven “modern” orchestrator, but as soon as you don’t have systemd on clients, it becomes insanely complicated to blast out simple changes.

Mgmt.config also claims to be “easy”, but you have to learn MCL’s weird syntax, which the issue I have with chef and its use of ruby.

Yes, ansible is relatively simple, but it runs on anything (including being supported on actual arm64) and I daresay that layering roles and modules makes ansible quite powerful.

It’s kind of like nagios… Nagios sucks. But it has such a massive library of monitoring tricks and tools that it will be around forever.

Running the k8s in their own VM will allow you to hedge against mistakes and keep some separation between infra and kube.

I personally don’t use proxmox anymore, but I deploy with ansible and roles, not k8s anymore.

You’re fine with this setup, and in many respects it’s overkill.

I run 33 containers including jellyfin, frigate, and immich as the hardest working ones across 2 HP elitedesk g4 with 48 GB ram, and a 3rd low power system hosting 8gb NFS for storage on simple gigabit lan. Even that is overkill for these tasks.

The apps most commonly run in a self-hosted env are really quite lightweight and spend most of their time at idle.

So you know that this is the lesser of the two evils? Seems like you’re viewing it from client’s perspective only.

No one wants to burden clients with Anubis, and Anubis shouldn’t exist. We are all (server operators and users) stuck with this solution for now because there is nothing else at the moment that keeps these scrapers at bay.

Even the author of Anubis doesn’t like the way it works. We all know it’s just more wasted computing for no reason except big tech doesn’t give a care about anyone.

I think the big deciding factor is how many folks will be watching remotely.

For my case, I use a VPN to tunnel back to my network and watch jellyfin that way. My son also lives away and watches jellyfin, but for him I simply punch a hole in my firewall for only his public ip, which doesn’t change much.

This works for me, but if I had to host for any more ppl, I would likely go the caddy route.

It’s not about the list of things wrong with (in this case) systemd. I don’t like systemd’s approach either, and I think poettering is a pompous ass. But we’re here now.

The great thing about Linux is that when someone comes around and wants xfce with i3 instead of xfwm, they can have that. Most of us might think it’s a stupid idea, but if they want it, they can do it.

So when it came to systemd, no one ran up and said “I don’t like this”, they just didn’t use it, mostly cause it was half-baked. And hey, if some guy wants to build an all-systemd box, go for it.

The crime of systemd is forcing most of us to use it by shipping it by default with Ubuntu, then Debian, then red hat, etc. I see menus in the debian install that ask what DE to use, whether SSH should be installed, etc, but no sysV/OpenRC/systemd menu choice.

The problem isn’t “what’s wrong with systemd”, it’s “why are you removing my choice to pick”. That’s why this list misses the point.

I had to get my glasses to re-read this comment.

You know why anubis is in place on so many sites, right? You are literally blaming the victims for the absolute bullshit AI is foisting on us all.

That is incus. But similar in other implementations of LXC. Docker has similar ratios, but I suspect you know this already.

Also, I fucking hate the person that decided it wasn’t going to do search domains properly or DNS over TCP.

That has been fixed since 3.18.

Look, I’m not sure why you’re challenging me so hard on this, I’m not a superfan of Alpine or anything. I use it when I can because it’s really, really light on memory and so do others. There are lots of cases that don’t work with Alpine, like mongodb, sql, etc. because of what ships with alpine and their philosophy. But there are lots of great uses for alpine as well, like networking or anything that works well with busybox tooling.

Have a better one.

Glibc matters on desktop, but the speed advantage doesn’t really matter to services running in cgroup2 containers borrowing the host’s kernel and namespaces.

For op’s purposes, memory density is important, and alpine base images will need about 10x less memory than their Debian counterparts, mostly due to a very pared-down service layout.

There’s a reason a huge portion of docker images are alpine-based.

Alpine is a fair amount lighter in memory consumption than Debian.

I’m no systemd fan, but this is wacky.