Raspberry pi4 Docker:- gluetun(qBit, prowlarr, flaresolverr), tailscale(jellyfin, jellyseerr, mealie), rad/read/sonarr, pi-hole, unbound, portainer, watchtower.

Raspberry pi3 Docker:- pi-hole, unbound, portainer.

  • 2 Posts
  • 64 Comments
Joined 2 years ago
cake
Cake day: June 26th, 2023

help-circle
  • Fedegenerate@lemmynsfw.comtoSelfhosted@lemmy.worldMini pc arriving tomorrow
    link
    fedilink
    English
    arrow-up
    9
    arrow-down
    1
    ·
    edit-2
    3 days ago

    Op I was you 12 months ago. +1 installing proxmox. The ability to make mistakes in an LXCs and always having the nightly back up right there was worth it alone. Helper scripts get you close to where you want to go fast. As for guides, there’s a bunch, raid owl, technotim both have initial proxmox setup guides. There are many like them, just two I remember.

    It might just be me, I struggled with every step of every guide I followed, mostly because I skip to copy paste the commands… Don’t do that. Chatgpt, plug the command in there and start quizzing it: “what does this do, what are the flags doing, I want to do x will command work”. Then don’t copy chatgpt either, take its output back to the documentation and make sure it makes sense. Then take a snapshot. Then paste the thing. It at least forced me to slow down.

    In the beginning I was about a month, just on a pi, getting a pihole and a servarr installed and configured. Then I nuked it and rebuilt in a couple weeks. Then I messed up again and rebuilt in a couple days. I dedicate 1hr to try fix what I broke using Chatgpt as mentor/rubber duck, if I can’t make progress on a fix in that time I load the snapshot. Troubleshooting is a great skill, however, everything you need gets installed at least once, so get good at installing things. Back ups need testing and you should be familiar with the process, get good at recovering from back ups. Chatgpt solves most of the problems surface level problems. You’ll get to a point when you get stuck chatgpt won’t be any help either, but let gpt get you there quickly.

    I genuinely prefer Dockge to Portainer, learn Portainer. As a rule learn the industry standard then migrate. Tonnes of articles and resources for Portainer, almost everyone using Dockge can help you with Portainer, not the other way around. The only difference is when the non-industry standard is specifically made to solve problems you have with the IS, I went with nginx proxy manager over nginx for example. GUIs are nice and I can see things working, unlike pasting a massive config and hoping. Now I have huge compose.yaml stacks for docker that I used to install one by one in Portainer.

    Security is hard. Outsource all you can. Your ISP firewall is perfectly serviceable don’t punch holes in it (for now). Tailscale is perfectly serviceable don’t try make your own tunnels (for now). One of my earliest posts was me installing a firewall on my pi, separate from the my router, and then going into a blind panic about punching holes in my firewall. Funny to look back on, my isp firewall is still completely intact, I picked a different path.

    Each iteration add one layer of complexity and take easy wins for everything else. I set up pihole bare metal, messed up the unbound install, go again. I used docker starter to set up pihole+unbound, messed up [something]… go again… Prioritise “working” over “perfect”. You don’t know what perfect is anyway. I don’t know what perfect is, but just getting something working teaches me what would be better for next go around. If what you did is “wrong” it’s going to break sooner rather than later so you get to go again. If what you did works forever be happy and enjoy the thing you built.

    Oh I forgot. No big updates right before bed, before a big event or when you’re out of the house. I once had an auto updater [watch tower] go off and delete my access to the internet [pihole] before downloading the new image, on my fiancée’s first day off, and while I was at work. I learned a lot about redundancy for essential infrastructure to Facebook that day, rightly so. If you can’t/won’t want to fix broken things right then, don’t be doing stuff that might break things.



  • I did think about cron but, long ago, I heard it wasn’t best practice to update through cron because the lack of logs makes things difficult to see where things went wrong, when they do.

    I’ve got automatic-upgrades running on stuff so it’s mostly fine. Dockge is running purely to give me a way to upgrade docker images without having to ssh. It’s just the monthly routine of “apt update && apt upgrade -y” *5 that sucks.

    Thank you for the advice though. I’ll probably set cron to update the images with the script as you suggest. I have a “maintenance” homarr page as a budget uptime kuma so I can quickly look there to make sure everything is pinging at least. I made the page so I can quickly get to everyone’s dockge, pihole and nginx but the pings were a happy accident.


  • On my home network I have nginxproxymanager running let’s encrypt with my domain for https, currently only for vaultwarden (I’m testing it for a bit for rolling it out or migrating wholly over to https). My domain is a ######.xyz that’s cheap.

    For remote access I use Tailscale. For friends and family I give them a relay [raspberry pi with nginx which proxys them over tailscale] that sits on their home network, that way they need “something they have”[the relay] and “something they know” [login credentials] to get at my stuff. I won’t implement biometrics for “something they are”. This is post hoc justification though, and nonesense to boot. I don’t want to expose a port and a VPS has low WAF and I’m not installing tailscale on all of their devices so s relay is an unhappy compromise.

    For bonus points I run pihole to pretty up the domain names to service.swirl and run a homarr instance so no-one needs to remember anything except home.swirl, but if they do remember immich.swirl that works too.

    If there are many ways to skin a cat I believe I chose to use a spoon, don’t be like me. Updating each dockge instance is a couple minutes and updating diet pi is a few minutes more which, individually, is not a lot on my weekly/monthly maintence respectfully. But on aggregate… I have checklists. One day I’ll write a script that will ssh into a machine > update/upgrade the os > docker compose pull/rebuild/purge> move on to the next relay… That’ll be my impetus to learn how to write a script.



  • Get a domain and set about moving over to HTTPS with Let’s encrypt and Nginx.

    Learn to write an Nginx config. NPM just works so good though.

    Fix my permission issues. I have my media zpool on 777 so all the LXCs work and I have to run Libation in a VM as root. I’ve been banging my head against this on and off for a while.

    Figure out why paperless isn’t saving to the correct place. Also, figure out where Paperless is saving to.

    Containerise Libation.

    I give friends and family access to my server via a relay, just a raspberry pi 0 with Tailscale, pihole and nginx on it. I have reasons for going this route. Anyways, get a couple more of those into the wild. Also streamline the process somewhat.

    Learn to and create an ACL config for tailscale so I can have services access nothing, users access services, and admins access everything.



  • Pareto’s law is universal: ~80% of the work is done by ~20% of the staff. Either find a place where managers recognise who the 20% are and act accordingly, or don’t be one of the 20%.

    I’ve done both, I aim to be the 20% and see if it’s valued, if not I aim to be one of the 80%. Successfully moving from 1 to the other isn’t too challenging, you’ll find a lot of the extra work load wasn’t noticed anyway and a little weaponised incompetence sheds the rest. Just be better than the current worst person and you’ll be fine.




  • On mobile so you’ll have to forgive format jank.

    It depends how each image handles ports if C1 has the ports set up as 1234:100 and C2 has the ports set up as 1234:500 then:

    service:

    gluetun:

    ports:

     - 1234:100 #c1
     - 1235:500 #c2
    

    […]

    Will solve the conflict

    Sometimes an image will allow you to edit it’s internal ports with an environment so

    service:

    gluetun:

    ports:

      - 1234:1000 #c1
      -1235:1234 #c2
    

    c1:

    environent:

    - UI_PORT=1000
    

    […]

    When both contsiners use the same second number, C1: 1234:80, C21235:80, and neither documents suggest how to change that port, I personally haven’t found a way to resolve that conflict.






  • My initial inception of this box was to have it request a static IP so I knew “box.ip”. Then tape then tape some thing like this:

    Box.ip Service1:port Service2:port …

    Onto the case. Then in NPM have it proxy requests to “box.ip:8096” to “tailscale.ip:8096”. But alas, I couldn’t figure it out. I could get 1 service to work but not multiple.

    I couldn’t ask someone to write the config for me, but if you’re certain it’s doable then I’ll learn to write a config. Thank you for the offer. I’m guessing for each service I tell nginx to “listen” at “port” instead of only listening to ports 80,443 and 81.

    MDNS seems like an interesting solution though, I’m going to read about that now actually, thank you for highlighting that solution to me. If I could get that working that would be ideal. I’ll have to check if the expected devices are compatible but that would make everyone’s life easier if I could just setup a cronjob on startup.


  • Thank you for the reading material, it’ll be tonight project. I think I’m just going to tell people if they want to join in the family immich/mealie/etc they’ll just have to let me into their router. They’ll get memorable addresses out of it and adblocking too. I’m pretty sure that setup is comfortably within my skill set. I thought long and hard about opening ports but the security needed is beyond me currently. Down side is cost and I’ll be managing a bunch of boxe. But I can add updating them into the monthly maintenance and if/when they come back they can be repurposed into other projects.


    I tried /locations but my service would rewrite the URL and break itself. I’d navigate to “box.ip/immich” and immich would change the address to “box.ip/login” and hang.

    I’d need to learn how to have npm lock “box.ip/immich” and let immich append “/login”. I’ll leave my test VM up and just chip away at it. I think I need the “rewrite” flag but I’m getting dangerously close to just learning how to write an nginx config instead of having npm do it for me.

    Thanks again for the pointers





  • 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.