By DMing me you consent for them to be shared with whomever I wish, whenever I wish, unless you specify otherwise

  • 1 Post
  • 40 Comments
Joined 2 years ago
cake
Cake day: June 26th, 2023

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


  • Fedegenerate@lemmynsfw.comtoSelfhosted@lemmy.worldWhat's the deal with Docker?
    link
    fedilink
    English
    arrow-up
    16
    arrow-down
    1
    ·
    edit-2
    1 year ago

    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.





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




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



  • 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