Hello everyone!

I did it. I reached a point where I got everything exactly how I wanted and now… Now I am dissatisfied as I look over my home lab’s chaotic mess of a setup. This was my first time selfhosting things, and I learned a ton of stuff. I’ll probably want to tear it down and start anew in the near future, being much tidier and mindful of what goes where.

Does anyone have any tips they want to impart to someone who’s not an entire newbie but still learning stuff? Kind of a “If I could tell myself this before I set everything up, I would say…”

  • ominous ocelot@leminal.space
    link
    fedilink
    English
    arrow-up
    2
    ·
    2 hours ago

    Make it maintainable.

    Documentation. Or implicit documentation with ansible or the like (opentofu).

    Separate things with LXCs or VMs or OSI containers. Maybe firewalls (ufw) and VLANs to separate them. Incus is nice. As someone already said: Leave the host system mostly vanilla. Services go in the virtual boxes and containers.

    Btw: Nix looks promising, too. But I have not opened that can of worms, yet.

    Backups…

    Automation. unattended-upgrades, watchtower(unmaintained) or the like. So you don’t have to do it yourself and then forget about it. Claude is looming on the horizon. It will bring many bugs to light and code the exploit for it in no time if someone asks for it nicely.

  • conrad82@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    4 hours ago

    Proxmox

    I went from a server distro (ubuntu server i think) to Proxmox and it was a very nice upgrade. Leave the core system alone and put your “mess” in LXC containers and VMs. When you know what you want, set up a new one with the good config, and delete the old one whem you are confident you no longer need it.

  • freeman@feddit.org
    link
    fedilink
    English
    arrow-up
    2
    ·
    4 hours ago

    I am not in a position of giving big helpful advice but habe just built my system for the second time. This time with Docker compose.

    I cam recommend the yams.media script. I’d recommend learning linux permissions and docker and maybe a bit of networking before starting setting everything up. I had people help me as well as AI chats which helped me more than expected.

  • rako@tarte.nuage-libre.fr
    link
    fedilink
    Français
    arrow-up
    4
    ·
    12 hours ago

    Be at peace with the mess. All the software you’re using have beend developed on their own, each has a different setup, maintenance work, they don’t fit with each other they just kinda not bother each other. Unless you’re using all the software included in a bsd or 9front base install, where everything is made to carefully fit, it’ll be crappy to look at.

    Be at peace with the mess, which also means be at peace with burning some/all of it and starting fresh when something new comes up or you want to “simplify” a part.

    The selfhosting, much like art, isn’t so much in the output: it’s in the process of trying, failing, succedding with a crappy solution, and then goind on with the learning. If you wanted a robust beautiful stack you’d be paying professionals to do that :)

  • nomad@infosec.pub
    link
    fedilink
    English
    arrow-up
    6
    ·
    16 hours ago

    Don’t just self host for yourself. Help out friends and family that can’t themselves. Infrastructure is for people not just for the fun of building it. :)

  • surewhynotlem@lemmy.world
    link
    fedilink
    English
    arrow-up
    5
    ·
    15 hours ago

    “If I could tell myself this before I set everything up, I would say…”

    … don’t stress too hard. This won’t be the last time you tear it up and start over.

  • irmadlad@lemmy.world
    link
    fedilink
    English
    arrow-up
    13
    ·
    20 hours ago

    “If I could tell myself this before I set everything up, I would say…”

    TAKE PROLIFIC NOTES! Do it as you go. Then, when you have whatever you were working on the way you want it, go back and clean your notes up, and make them a part of your 3,2,1 back up policy. Make a road map of how you want everything to operate. That way, as you add to your server/network, all the pieces will be much tidier and easier to troubleshoot.

    • other_cat@piefed.zipOP
      link
      fedilink
      English
      arrow-up
      6
      ·
      16 hours ago

      haha, this goes along with my husband’s comments when I asked him this question too. He said that nobody does documentation the first time.

      • irmadlad@lemmy.world
        link
        fedilink
        English
        arrow-up
        4
        ·
        6 hours ago

        Most likely reasons people don’t document right out of the gate is excitement of the moment, and I’ve got this tutorial I found…why would I need to document? However, I’ve found that writing it down in your own words seems to make it stick more for me. The way I have my notes, I could format the entire drive, and using notes alone, have the server back up and running full production in a solid day’s effort. Don’t be lulled into the notion that you’ll be able to remember everything 6 months down the road. That’s the devil talking Bobby Boucher.

  • frongt@lemmy.zip
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    1
    ·
    15 hours ago

    You’ll never be happy with it. Even if you get it 100% perfect, someone will release an update or new toy that changes things. But that’s life. Don’t stress about it. Just get the parts you want working in the free time you have.

    Readarr stopped working months ago. It finally went offline just a few weeks ago. I hadn’t done anything about it until then. I still haven’t replaced it with anything. Maybe I’ll get to it eventually.

  • eodur@piefed.social
    link
    fedilink
    English
    arrow-up
    4
    ·
    16 hours ago

    Lots of notes.

    GitOps. Either FluxCD if you are on Kubernetes, or doco-cd if using docker compose. You will thank yourself later.

    Use an external secret manager. Its worth figuring out, and then you have one source of truth, and one place to update the credentials.

    Figure out your backup strategy, document it really well, and test it regularly.

  • hendrik@palaver.p3x.de
    link
    fedilink
    English
    arrow-up
    10
    ·
    20 hours ago

    … don’t forget about the backups.

    And if your major issue is putting things in wrong locations… Maybe learn about some abstraction layers, so next time you’re able to just move it, instead of tearing it down?