I use Lidarr to watch for new releases and try to get some bootleg albums, while main way of getting things is trough some websites or just pulling stuff from qobuz directly.
All the music is FLAC with a small percentage in mp3 320. also, man sometimes wants to get that 300GB discography pack with 6 different releases of the same album 😁
when people have too much free time
Do you have sample of what kind of errors you’re getting? are they docker related or service related? as in jackett can’t connect/reach sonarr for example?
I got a used mini pc to run as a media center, running the arr stack and torrent client that’s bound to the VPN interface. For usenet stuff I don’t care is it on VPN or not. Its running headless.
If you make sure that the torrent client is set to be bound on the VPN interface, you are fine, if VPN is not up, it should not start, since the interface is not up. For VPN I use wireguard and set the VPN to be brought up by via wg-quick command and use systemd to start it during boot.
You’ll be fine using it for personal stuff along with pulling stuff from high seas.
I’m running it trough docker with VNC, and it works fine for my use case.
Navidrome over wireguard, and music library in folders and proper tagging trough beets and picard. using subsonic as a client for it. tried plex and plexamp but I’m moving away from them.
First of all, this might now answer your question fully, but…
spotify-dl uses youtube music to download stuff, and if you have youtube premium you can get higher quality downloaded, I think it does opus 128 or 156 kbit, and the sound is quite good.
tidal, deezer, or qobuz have cd or hi-res quality songs, and there are utils that help you get stuff from their service. qobuz-dl's the one I have been experimenting with. Obviously you need subscription for it, but spotify is generally shit.
Apart from that I used few other sources to get my music.
I was hit aggressively by HC sales team last year, we are using TF and Vault, and were looking to add consul, now it is pretty vauge how it will all pan put
Check netmaker for wireguard vpn if you want a ui, but its straightforward to set it up manually.
I’d say, what kind of security are you talking about? Apart from standard HTTPS to keep things encrypted, there are other layers if you want to keep your service exposed to the internet.
Also how things are installed and if they are correct, proper file permissions. nothing different than having it on the server somewhere. You just need to keep thing up to date and you’ll be fine.
I like it here on Lemmy as there are quality talks from people and not too much circlejerking same concepts around. I actually like going trough here.
Yes, very active, there is the #introduction tag there where you can find people (and people find you).
About 6 year uptime on one machine before we shut it down and relocated.
Yes, thats exactly it.
Make sure your HAProxy is listening on the wireguard interface as well.
Once you have the wireguard tunnel working, do a quick test, like curl -H "Host: domain.tld" https://router_wireguard_ip/ and if that works, add in the iptables roules and you should be all set.
Thanks for the reply, flux is pretty good, I’m using ArgoCD, but both are basically following gitops priciples.
I might give k3s a look and see how ot all work together.
What would be a benefit to run k8s at home, apart from bit dealing with it, compared to docker-compose on a single or two nodes? or docker swarm? Unless there is a big load of services that are selfhosted, which I get, and the autohealing from k8s as the orchestrator.
Just courious, not taking a swing. Thanks!
Yes, that would be possible with this setup. Port on which HAProxy listens just needs to be publicly accessible, and just DNAT traffic from the VPS to your $IP:$PORT .
Technically everything is possible, I just don’t have context if you have a static IP with your ISP or it changes every so often (daily, weekly, every n months). If it’s not, you might consider using a VPN connection between VPS and your router to keep the connection open at all times, and also not exposing HAProxy directly to the live internet.
I’m running both, via docker.
Here’s the basic setup:
NGiNX is standard installation, using certbot to manage the SSL certificates for the domains. Setup is via Nginx virtual hosts (servers), separate for Lemmy and Mastodon. Lemmy and Mastodon run each in their Docker containers, with different listning ports on localhost.
lemmy.domain.tld+------------------------+
+------------------+ |
| | Lemmy |
| | 127.0.0.1:3000 |
| +------------------------+
|
+--------------+----+
|NGiNX with SSL | mastodon.domain.tld
|and separate VHOSTS+--------------+-----------------------+
| | | Mastodon |
+-------------------+ | 127.0.0.1:3001
+------------------------
No problem. I’ll just go with a oversimplification.
The idea is that you just take whatever traffic hits port 443 and use iptables rules to route the traffic elsewhere, or in this case
Client --> [port 443] --> [iptables] --> [ port 443 home server]
So, it’s basically just traffic forwarding from the VPS directly to your home server, being directly to your ISP IP address, or via wireguard IP address.
So all the traffic you are sending back from the VPS is in its original state, and the actual processing happens on your local/home server.
On the home server you have a Web Server of your choice listening on port 443 with, loaded with your SSL certificates. So, request is made to the VPS IP address, iptables just forward the packets to your home server, and there is where the SSL/TLS termination happens. The client negotiates the TLS connection directly with your home server, and web server on your home server then sends the request where you tell it to ( reverse proxy to a docker container, or it serves the content directly).
With this, you basically turn the VPS into a passtrough for traffic.
Here’s a quick test I did… the two servers are connected with Wireguard mesh.
On the VPS you need have net.ipv4.ip_forward=1 .
net.ipv4.ip_forward=1
Your iptables rules should be. Obviously on the home server you can run the webserver on any port you like, doesn’t have to be 443. But let’s keep it 443 for the sake of argument.
iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination HOME_SERVER_IP:443
iptables -t nat -A POSTROUTING -j MASQUERADE
If you want to drop the rules:
iptables -t nat -F
did it before my smoke break