Omg dude, you can still use coreutils on Ubuntu:

sudo apt-get remove coreutils-from-uutils --allow-remove-essential

You can also opt out before you upgrade:

/etc/apt/preferences.d/uutils:

Package: coreutils-from-uutils
Pin: release a=*
Pin-Priority: -10

NO ONE IS FORCING YOU TO SWITCH!

I’m sorry, I must have not said this loud enough. JUST KEEP USING COREUTILS.

Literally no one is forcing you to switch. Just keep using coreutils.

Why do you say that? Docker Hub is, of course, susceptible to supply chain attacks, as are the official containers of each of these projects, but how is that all that different from installing these projects on bare metal? That’s still relying on some supply chain. In that case, the package maintainers for your distro. What you might trade in slightly more vulnerable to supply chain attacks, you get back in timely security updates from the project maintainers themselves and every service running in a sandboxed environment. Also, how are any of them “extremely” vulnerable?

I didn’t suggest anything that isn’t either an official build from the project maintainers, or a very well supported community build from a reputable source.

Every once in a while, you should run these commands in each services folder:

docker compose pull
docker compose up -d

# check if everything is still good

docker system prune -a

You should also back up your services folder regularly. That’s beyond the scope of this Lemmy comment, though

If you have anything open to the internet (not using that local only access list), you need to be very vigilant about updating it frequently. If you’re not, you could have vulnerabilities that are exploitable.

By setting it up where NPM is blocking access to everything that isn’t local, you won’t really need to pay much attention to it. Just do the updates every few months and you’ll be fine.

In NPM, set up an access list like this:

Last one should be your public IP address, with “/32” on the end.

Use this access list for all services you don’t want the wider internet to see (probably all of them for you). With this setup, you can still open a service, if you want, but normally you’ll need to be on your VPN to see it from outside your house.

Here’s an example of what a proxy host should look like:

(Except your access list should be the local only one you set up earlier.)

And the SSL tab:

From now on, whenever you set up a service, you’ll use a subdomain just for that service (eg nextcloud.example.com), and you’ll point it in dns as a CNAME record at your apex domain (usually just an @ symbol in the input box). You’ll then (if it’s a web service) create a proxy in NPM pointed at whatever port you give it.

So now you wanna create a WireGuard vpn, so you can securely access your own stuff from your own devices outside your house. (I’d recommend not opening every service up to the internet.)

https://github.com/linuxserver/docker-wireguard

That one can be tricky, but ultimately you should have a file (or QR code) that you can put on your phone in the WireGuard app that will give you vpn access. Remember to set up a CNAME for your subdomain (something like vpn.example.com). Although, for this, it would be fine to use the apex domain.

So now you can set up a Nextcloud and an Immich stack. Put them on an unused port, then point a proxy for their subdomain at that port (http://127.0.0.1:2201/ or whatever), add your SSL cert, and you’re good.

[continued…]

Edit: I just saw you said your router supports WireGuard, so you don’t need to worry about setting that up or forwarding that port. :)

It sounds like you just wants Nextcloud and maybe Immich. So here’s my suggestion:

If you don’t have a domain yet, buy a domain. Preferably through Cloudflare because their API is good, and you’ll need that. Point an apex A record at your public IP address.

Set up something like Kubuntu on the box itself. Make sure it has a static IP address (you can also do DHCP reserved through your router, which is safer), and forward ports 80 (TCP), 443 (TCP), and 51820 (UDP) to that box.

Now comes the magic. Install docker through the official installation docs for Ubuntu (don’t use Ubuntu’s packages). Create a folder in your home directory called “services”. Inside this folder, you’re going to set up a folder for each service you need. The first one you should set up is “nginx-proxy-manager”. Inside each folder you’ll have a “docker-compose.yml” file. Inside that file, set up your docker compose stack. Nginx Proxy Manager’s is pretty simple. Just one service. But change the network mode to “host” (network_mode: host), and remove the ports section.

https://nginxproxymanager.com/setup/

Now, from a terminal, in that folder, run docker compose up -d. Get used to that command, you’ll run it a lot. Then go to localhost:81, and create an account for NPM. Use a real email address, because that’ll be your contact email for Let’s Encrypt ssl. Go into the ssl settings and create a certificate. You’ll need an api key from Cloudflare, or whatever other place you bought your domain from. It needs access to change the dns settings for your domain. Use this format to create your certificate:

example.com, *.example.com

And use the dns challenge option where you’ll put your api key.

[continuing in next post]

They make about as much sense as cubits.

I’m pretty sure it’s just a fuzzy context match.

DDG is just a people pleaser. 🤷‍♂️

Ok, but also

Read The Victorian Internet by Tom Standage.

I had the same issue a while ago. :) I think the docs tell you to do it the way you had it, which is why it causes confusion.

Just mount /dev/dri.

Generally I think when Ubuntu makes big moves, they’re pretty bad, but these rust reimplementations are actually pretty good. Good job, Canonical.

The worst thing is when it is right about something, and then it explains why it concluded that, and the process is wrong in every way.