One thing i’ve learned over the years is the way I did something when I was learning is usually not the best way of doing it, and I later go back and redo everything now that I have gained experience and knowledge. I have decided to ditch google photos, and was lucky enough to snag a free rackmount 2017 server from work with an i7 installed and 2 6tb drives on the way. But now comes the hard part of deciding what software I am going to end up learning on and hopefully living with. First and foremost I want a photo backup service, and I have debated between immich and xpenology, I also know that I want to run Pihole and would really like to self host my own website documenting my projects, even if no one will ever look at it.

If you had to start from the beginning, which OS, which container manager and which containers would you build. I would love the recommendations from those who walked so that I can run

  • Ursa_Solaris@alien.top
    cake
    B
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    I already apply these rules myself, but these are the five major things I emphasize to everyone.

    1. Don’t overcomplicate things. You don’t need Proxmox on every machine “just in case”. Sometimes, a system can be single purpose. Just using Debian is often good enough; if you need a single VM later, you can do that on any distro. This goes for adding services, too. Docker makes it very easy to spin things up to play with, but you should also know when to put things down. Don’t get carried away, you’ll just make more work for yourself and end up slacking and/or giving up.

    2. Don’t put all your eggs in one basket if you can avoid it. For instance, something like Home Assistant should run on its own system. If you rely heavily on your NAS, your NAS should be a discrete system. You will eventually break something and not have the time or energy to fix it immediately. Anything you truly rely on should be resilient so that your tinkering doesn’t leave you high and dry.

    3. Be careful who you let in. First, anybody with access to your systems is a potential liability to your security, and so you must choose your tenants carefully. Second, if others come to rely on your systems, that drastically reduces your window to tinker unless you have a dedicated testbench. Sharing your projects with others is fun and good experience, but it must be done cautiously and with properly set expectations. You don’t want to be on the receiving end of an angry phonecall because you took Nextcloud down while playing around.

    4. Document when it’s fresh in your mind, not later. In fact, most of the time you should document it before you do it. If things don’t go according to plan, make minor adjustments. And update docs when things change. What you think is redundant info today might save your ass tomorrow.

    5. Don’t rely on anything you don’t understand. If it works, and you don’t know how or why it works on at least a basic level, don’t simply accept it and move on. Figure it out. Don’t just copy and paste, don’t just buy a solution. If you don’t know it, you don’t control it.