![](https://lemmy.dbzer0.com/pictrs/image/c23b9f49-6abc-429c-8cdb-dd80e644f83d.webp)
![](https://lemmy.world/pictrs/image/8286e071-7449-4413-a084-1eb5242e2cf4.png)
Because using a containerization system to run multiple services on the same machine is vastly superior to running everything bare metal? Both from a security and a ease-of-use standpoint. Why wouldnt you use docker?
Because using a containerization system to run multiple services on the same machine is vastly superior to running everything bare metal? Both from a security and a ease-of-use standpoint. Why wouldnt you use docker?
Mp4 is a video container. Do you mean mp3?
Just use yt-dlp instead of relying on websites that shove ads in your face and may do what ever they want to the files you’re downloading?
AdGuard Home supports static clients. Unless the instance is being used over TCP (port 53, unencrypted), it is by far the better way to use clientnames in the DNS server addresses and unblock the clients over that.
For DoT: clientname.dns.yourdomain.com
For DoH: https://dns.yourdomain.com/dns-query/clientname
A client, especially a mobile one, can simply not guarantee always having the same IP address.
If you dont fear using a little bit of terminal, caddy imo is the better choice. It makes SSL even more brainless (since its 100% automatic), is very easy to configure (especially for reverse proxying) yet very powerful if you need it, has a wonderful documentation and an extensive extension library, doesnt require a mysql database that eats 200 MB RAM and does not have unnecessary limitations due to UI abstractions. There are many more advantages to caddy over NPM. I have not looked back since I switched.
An example caddyfile for reverse proxying to a docker container from a hostname, with automatic SSL certificates, automatic websockets and all the other typical bells and whistles:
https://yourdomain.com {
reverse_proxy radarr:7878
}
The demo instance would be their commercial service I suppose: https://ente.io/. Since, as are their own words, the github code 1:1 represents the code running on their own servers, the result when selfhosting should be identical.
Theres a Dockerfile that you can use for building. It barely changes the flow of how you setup the container. Bigger issue imo is that it literally is the code they use for their premium service, meaning that all the payment stuff is in there. And I don’t know if the apps even have support for connecting to a custom instance.
The settlement addresses any and all people who were ever involved in any fashion with the production or distribution of yuzu. Quoting the Settlement:
against Defendant enjoining it and its members, agents, servants, employees, independent contractors, successors, assigns, and all those acting in privity or under its control
So yeah, the devs are all individually targeted, not just the LLC as its own entity. And if any of the devs is ever caught doing anything like this again, they’re gonna face charges much more serious than this i fear.
Ive wanted one of these for a while to replace my ISPs modem+router+switch+wifi-AP. But apparently these devices can be funky to get a good wifi going, and I don’t feel like adding three (mini pc, switch, AP) new devices to my “we don’t talk about it” corner where all the IT is stored. Do you know anything about wifi on these?
its on none of the large trackers
if predb.net is anything to go by, there has not yet been any scene release for that series: https://predb.net/search/rey mysterio?page=1. Either it’s too new, interest is too low, or a mix of both. Or something else entirely, who’s to say.
I heard about tailscale first, and haven’t yet had enough trouble to attempt a switch.
I use Hetzner, mainly because of their good uptime, dependable service and being geographically close to me. Its a “safe bet” if you will. Monthly cost, if we’re not counting power usage by the homelab, is about 15 bucks for all three servers.
That’s a tough one. I’ve pieced this all together from countless guides for each app itself, combined with tons of reddit reading.
There are some sources that I can list though:
I’d love to have everything centralized at home, but my net connection tends to fail a lot and I dont want critical services (AdGuard, Vaultwarden and a bunch of others that arent listed) to be running off of flakey internet, so those will remain in a datacenter. Other stuff might move around, or maybe not. Only time will tell, I’m still at the beginning of my journey after all!
Pretty sure ruTorrent is a typical download client. The real reason is that it came preinstalled and I never had a reason to change it ¯_(ツ)_/¯
Glad to have gotten you back into the grind!
My homelab runs on an N100 board I ordered on Aliexpress for ~150€, plus some 16GB Corsair DDR5 SODIMM RAM. The Main VPS is a 2 vCPU 4GB RAM machine, and the LabProxy is a 4 vCPU 4GB RAM ARM machine.
The rclone mount works via SSH credentials. Torrent files and tracker searches run over simple HTTPS, since both my torrent client and jackett expose public APIs for these purposes, so I can just enter the web address of these endpoints into the apps running on my homelab.
Sidenote, since you said sshfs mount
: I tried sshfs, but has significantly lower copy speeds than with rclone mount
. Might have been a misconfiguration, but it was more time efficient to use rclone than trying to debug my sshfs connection speed.
Allow me to cross-post my recent post about my own infrastructure, which has pretty much exactly this established: lemmy.dbzer0.com/post/13552101.
At the homelab (A
in your case), I have tailscale running on the host and caddy in docker exposing port 8443 (though the port matters not). The external VPS (B
in your case) runs docker-less caddy and tailscale (probably also works with caddy in docker when you run it in network: host
mode). Caddy takes in all web requests to my domain and reverse_proxies them to the tailscale hostname of my homelab :8443. It does so with a wildcard entry (*.mydomain.com
), and it forwards everything. That way it also handles the wildcard TLS certificate for the domain. The caddy instance on the homelab then checks for specific subdomains or paths, and reverse_proxies the requests again to the targeted docker container.
The original source IP is available to your local docker containers by making use of the X-Forwarded-For
header, which caddy handles beautifully. Simply add this block at the top of your Caddyfile on server A:
{
servers {
trusted_proxies static 192.168.144.1/24 100.111.166.92
}
}
replacing the first IP with the gateway in the docker network, and the second IP with the “virtual” IP of server A inside the tailnet. Your containers, if they’re written properly, should automatically read this value and display the real source IP in their logs.
Let me know if you have any further questions.
Correct me if im wrong, but if you play a 1080p video on a 4k screen, that would be upscaled. If you put a 1080p video in a 4K stream, then play that 4k stream on the 4k screen, no post-processing would be applied to the video on the screen. All the upscaling happens during encoding, where you have far more control over the upscaler quality.