Oh, routing, I remember watching an “off site back up” video where they set up IP tables, or IP forwarding, or some such, so when their parents tried to access jellyfin locally it was routed over tailscale. Maybe I’m misremembering though, I’m not confident enough to start thinking about it seriously, so I logged it as “that’s possible” and moved on.

That way I just have to keep one instance of jellyfin/immich/etc up to date. It’s all a bit beyond my ken currently but it’s the way I’m trying to head. At least until I learn a better way.

Ideally, I give someone a pi all set up. They plug it in go to service.domain.xyz and it routes to me. Or even IP:Port would be fine, I’ll write them down and stick it to their fridge.

My parents and I run each others’ off-site back up (tailscale-syncthing), but their photo and media services are independent from mine. I just back up their important data, and they return the favour, but we can’t access or share anything.

Guides like yours are great for showing what’s possible. I often find myself not knowing what I don’t know so don’t really know where to start learning what I need to learn.

What a write up, thank you for documenting this.

I understand a lot of people in this hobby do it professionally too, so a lot is assumed to be common knowledge us outsiders just don’t have.

While my system of using tailscale’s magic dns to use lxc:port works fine for my fiancée and I, expanding this a family wide system would prove challenging.

So this guide is next step. I could send my fiancée to <home.domain.xyz> and it’ll take her to homarr, or <jellyseerr.domain.xyz>

The ultimate dream would be to give family members a pi zero and a <home.domain.xyz> and then run a family jellyfin/immich.

Someone identifying with Homelander would. That’s the real meme here.

I remember Watchtower helpfully stopping Pihole before pulling the new image when I only had the one instance running… All while I was out at work with the fiancée on her day off. So many teaching moments in so little time.

You gotta TAWK TUAH to get to know 'er.

The firestick is what I chose as my TV’s, a 10yo LG, jellyfin client. Works as intended, better really. One day I’ll block the stick’s internet connection, and it’ll be the almost perfect device, in that it plays almost anything natively. My server is a rpi4 so anything I can do to stop transcoding, I do.

Aoostar n100 2 Bay nas is what I’m currently thinking about. Or the same device but rebadged.

Pros: n100 for quicksync. 2 bays of HDD for media storage. Low power at idle. Cheap for a box with all relevant codecs + sata storage. High WAF compared to other HTPCs

Cons: Unknown brand for build quality and bios updates. General Chinese security anxieties. Idle power, while low, is higher than other n100 options. Fan isn’t pwm. Personally don’t like the aesthetics.

I guessed it was a “once bitten twice shy” kind of thing. This is all a hobby to me so the cost-benefit, I think, is vastly different, nothing on my setup is critical. Keeping all those records and up to date on what version everything is on, and when updates are available and what those updates do and… sound like a whole lot of effort when currently my efforts can be better spent in other areas.

In my arrogance I just installed Watchtower, and accepted it can all come crashing down. When that happens I’ll probably realise it’s not so much effort after all.

That said I’m currently learning, so if something is going to be breaking my stuff, it’s probably going to be me and not an update. Not to discredit your comment, it was informative and useful.

When I asked this question

So there are many reasons, and this is something I nowadays almost always do. But keep in mind that some of us have used Docker for our applications at work for over half a decade now. Some of these points might be relevant to you, others might seem or be unimportant.

• The first and most important thing you gain is a declarative way to describe the environment (OS, dependencies, environment variables, configuration).

• Then there is the packaging format. Containers are a way to package an application with its dependencies, and distribute it easily through the docker hub (or other registries). Redeploying is a matter of running a script and specifying the image and the tag (never use latest) of the image. You will never ask yourself again “What did I need to do to install this again? Run some random install.sh script off a github URL?”.

• Networking with docker is a bit hit and miss, but the big thing about it is that you can have whatever software running on any port inside the container, and expose it on another port on the host. Eg two apps run on port :8080 natively, and one of them will fail to start due to the port being taken. You can keep them running on their preferred ports, but expose one on 18080 and another on 19080 instead.

• You keep your host simple and empty of installed software and packages. Less of a problem with apps that come packaged as native executables, but there are languages out there which will require you to install a runtime to be able to start the app. Think .NET, Java but there is also Python out there which requires you to install it on the host and have the versions be compatible (there are virtual environments for that but im going into too much detail already).

I am also new to self hosting, check my bio and post history for a giggle at how new I am, but I have taken advantage of all these points. I do use “latest” though, looking forward to seeing how that burns me later on.

But to add one more:- my system is robust, in that I can really break my containers (and I do), and to recover is a couple clicks in Portainer. Then I can try again, no harm done.

Finally got it set up, pointed Prowlarr at it which synced to Sonarr and Radarr, not readarr or lidarr though. I couldn’t manually point readarr at it either without getting a

Query successful, but no results in the configured categories were returned from your indexer. This may be an issue with the indexer or your indexer category settings

which is a shame. Still a potentially powerful bit of kit regardless.

Cheers

My unbound is on v1.13.1 (Raspbian) after update/upgrade. I’ve read it lags behind the main release by alot, should I trust the process that everything is fine.

Ah, I knew it was bypassing the pi-hole, I thought it was IPv6. I think I made the mistake of changing more than one thing at once, what I did worked and I moved on to the next functionality I was chasing. I’ll try enabling IPv6 on the pihole, I know at least if I get Ads with it on its not IPv6.

You have cleared up a lot of misconceptions for me, I have not been port forwarding, I have not learned how yet. I think I’m good. I don’t mind breaking functional stuff, and have a lot already, but I really don’t want to explain to my fiancée that the reason someone is in her bank is because I wanted to watch Samurai Jack.

I have been keeping it as insular as possible for this reason, and the next thing I intent to learn is to make it more insular by putting the pi on a subnet of its own. Actually, thank you for writing that up. I have been actively resisting using people for IT support, as I know it takes time. I have been trying to find everything I can, there isn’t much or what there is assumes knowledge I don’t have.

There’s a comment with a list of stuff to do that I’ve saved. So I’ll probably start knocking that out one by one.

When it was active I was getting ads. I disabled the pi-hole registered an increase in traffic and there were no more ads. I don’t know why. It’s working as it is and I’ll tinker when I know more.

That’s a relief. Thank you.

Both pi’s have static IPs.

I asked the *arrs to talk to each other, and when they didn’t work (and only when they didnt work) I "ufw allow"ed the relevant port.

I just want to patch up my firewall layer as best I can, and then start building security layers on top/below it as I learn how.

So I told Sonarr that qBit it at 192.168…:port. The test failed, “ufw allow port”, then the test passed. Could I instead have told Sonarr qBit is at 172.18…:port(dockers network address) and then close up the firewall. Or can I set them all to “ufw limit”. Or set the firewall to only allow local local traffic… You get the idea, I know enough to be dangerous but not enough to ask the right questions.

I don’t know, what’s more I don’t know how to check.Which ever most likely?

ISP plastic box didn’t allow custom DNS, I disabled DHCP and IPv6. On pihole I enabled DHCP with IPv6 disabled.

I know, I know enough to be dangerous now, and I’m trying to get the system through my dangerous phase. I don’t think I know enough to ask intelligent questions yet…

ISP modem. I have a pi3 running pihole-dhcp-unbound, ufw and log2ram.

My system is a pi4 running *arrs, qBit, fail2ban, portainer in docker and ufw for now. Use case is: via mobile phone access *arrs, let them do their things and manually play files via hdmi or move files via thumbdrive. I was thinking giving up the phone access to put them on their own network, but subnets are beyond my ken for now.

Hoping to increment my security, and then the system as my skills develop.

Edit, qBit and prowlarr are behind gluetun set up for mullvard. I’m in the UK so had to put the indexer behind a VPN. UFW

Just trying to keep outside/malicious actors from entering my stuff while also bring able to use my stuff. More safer is more better, but I’m trying to balance that against my poor technical ability.

My priority list is free>easy>usable>safe. Using UFW seemed to fit, but you’re right, punching holes in it defeats the purpose Which is why I wanted to only allow local network and have only the necessary ports open. You have given me lots of terms to Google as a jumping off point so thank you.