• 0 Posts
  • 19 Comments
Joined 11 months ago
cake
Cake day: August 7th, 2023

help-circle





  • I thought about setting one up for my main server because every time the power went out I’d have to reconfigure the bios for boot order, virtualization, and a few other settings.

    I’ve since added a UPS to the mix but ultimately the fix was replacing the cmos battery lol. Had I put one of these together it would be entirely unused these days.

    It’s a neat concept and if you need remote bios access it’s great, but people usually overestimate how useful that really is.




  • Wow, I had no idea that there was a quote out there that aligns so well with my beliefs. I grew up in a semi religious household but was never forced to go to church. My parents encouraged me to go, not only to theirs but even go with friends that were different religions.

    After going to various churches through some really vulnerable times I still don’t subscribe to any religion, but I also can’t bring myself to go full atheist.

    Too bad that quote is way too long for a tattoo 🤣



  • Yikes! I pay a couple bucks more for uncapped gigabit. I’m fortunate in that there’s two competing providers in my area that aren’t in cahoots (that I can tell.) I much prefer the more expensive one and was able to get them to match the other’s price.

    My wife has been dropping hints she wants to move to another state though and I’m low key dreading dealing with a new ISP/losing my current plan.


  • I do a separate container for each service that requires a db. It’s pretty baked into my backup strategy at this point where the script I wrote references environment variables for dumps in a way that I don’t have to update it for every new service I deploy.

    If the container name has -dbm on the end it’s MySQL, -dbp is postgres, and -dbs would be SQLite if it needed its own containers. The suffix triggers the appropriate backup command that pulls the user, password, and db name from environment variables in the container.

    I’m not too concerned about system overhead, but I’m debating doing a single container for each db type just to do it, but I also like not having a single point of failure for all my services (I even run different VMs to keep stable services from being impacted by me testing random stuff out.)






  • You can already do this. You can specify an env file or use the default .env file.

    The compose file would look like this:

    environment:
          PUBLIC_RADARR_API_KEY: ${PUBLIC_RADARR_API_KEY}
          PUBLIC_RADARR_BASE_URL: ${PUBLIC_RADARR_BASE_URL}
          PUBLIC_SONARR_API_KEY: ${PUBLIC_SONARR_API_KEY}
          PUBLIC_SONARR_BASE_URL: ${PUBLIC_SONARR_BASE_URL}
          PUBLIC_JELLYFIN_API_KEY: ${PUBLIC_JELLYFIN_API_KEY}
          PUBLIC_JELLYFIN_URL: ${PUBLIC_JELLYFIN_URL}
    

    And your .env file would look like this:

    PUBLIC_RADARR_API_KEY=yourapikeyhere
    PUBLIC_RADARR_BASE_URL=http://127.0.0.1:7878
    PUBLIC_SONARR_API_KEY=yourapikeyhere
    PUBLIC_SONARR_BASE_URL=http://127.0.0.1:8989
    PUBLIC_JELLYFIN_API_KEY=yourapikeyhere
    PUBLIC_JELLYFIN_URL=http://127.0.0.1:8096
    

    This is how I do all of my compose files and then I throw .env in .gitignore and throw it into a local forgejo instance.