Maybe a silly question, but is simply having the thing doing the sailing running on what might be a docker container that only has access to the internet via a VPN connection okay? my friend told me this is his set up

like, logically speaking this seems to be basically fine, since the sailing ship’s data is not visible to the ISP

“retrieving” from ripping my personal DVD and BluRay collection?

are you me haha?

i assume that’s just for free podcasts?

does a wild card cert essentially mean i have use one cert which will cover all my subdomains as well as the primary domain?

Cool.

In other news, Swiss law makers claim opening and reading all mail sent to make sure it doesn’t include the phrase “monty bojangles” is “not a privacy concern”

My point is that in order to block a specific domain, you necessarily need to check it against a list of all legitimate domains being accessed

As in why is a post about VPNs on a self-hosted forum?

really? like what? i’ve been using docker completely free and unrestricted - at i think so haha

Here’s my approach to documentation. It’s about habits as much as it’s about actually writing anything down:

1. Never setup anything important via naked terminal commands that you will forget you did

2. Always wrap important commands in some kind of “setup-xyz.sh” script and then run that script to see if your install worked.

3. If you need to make a change to your service, ensure you update your script and so it can be re-run without braking anything

Get into the habit of this and you are documenting as you go

i second this

i haven’t gotten around to looking into something like terraform/ansible yet, and currently rely on a series of setup.sh scripts and docker-compose files

i have a single master setup.sh at the root of my homelab which basically just outlines which scripts i need to run and in what order in order to get things back up and running from zero

i only user my README.md for any non scriptable stuff (such as external services i rely on such as cloudflare/vpn providers, etc)

i mean charitably you could say that your code / architecture should be self documenting, versus having to rely on READMEs / wikis

in effect, if you change the code you are by definition also changing the documentation, since the file names/function names/hierarchy is clear and unambiguous

while security might be compromised if an attacker found your documentation, it could equally be compromised by having zero documentation

the easier it is for you to get things back up and running in the event of a data loss / corrupted hard drive / new machine / etc, the less likely you are to forget any crucial steps (eg setting up iptables or ufw)

this is basically what i ended up doing to - glad to see my approach verified somewhat ha ha!

but yeah, in general whenever i make a change / add new service, i always try and add those steps to some sort of setup.sh / docker-compose

supports podcasts too? what tool are you using to download those? and does ABS handle the sorting/meta data the same way it does for audio books?

maybe silly question but does tailscale tunnel operate in a similar fashion to a cloud flare tunnel? as in you can remotely access your internal service over https?

i have nginx proxy manager set up all as well, but haven’t worked out the SSL part yet, so all my internal docker services are still on http

out of interest, how did you set up https with npm?

Why would Cloudflare warn me against a service they themselves offer? The email authentication is all managed by them

So i’ve been trying to set this up this exact thing for the past few weeks - tried all manner of different Nginx/Tailscale/VPS/Traefik/Wireguard/Authelia combos, but to no avail

I was lost in the maze

However, I realised that it was literally as simple as setting up a CloudFlare Tunnel on my particular local network I wanted exposed (in my case, the Docker network that runs the JellyFin container) and then linking that domain/ip:port within CloudFlare’s Zero Trust dashboard

Cloudflare then proxies all requests to your public domain/route to your locally hosted service, all without exposing your private IP, all without exposing any ports on your router, and everything is encrypted with HTTPS by default

And you can even set up what looks like pretty robust authentication (2FA, limited to only certain emails, etc) for your tunnel

Not sure what your use case is, but as mine is shared with only me and my partner, this worked like a charm