Like soup-to-nuts. I know I need to document what I’m doing and I’ve started several times, but then I never go back and make updates. I don’t know if it’s just the ADHD or if I’m just going about it or thinking about it in the wrong way.

So I’m curious about:

  • what you use for your documentation
  • how you organize it
  • what information you include
  • how you work documentation into your changes/tinkering flow

Edit: Dang, folks! You all have given me a lot to read through, think about, and explore. Thank you!

  • Nibodhika@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    18 hours ago

    The moment you think you might possibly need documentation is the moment you should seriously consider using Ansible or similar to orchestra things. Sure, it’s annoying for a single server, but it is the best form of documentation there is.

  • Mobile@leminal.space
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 day ago

    Man I’m as basic as it comes. I have a .txt file that I update with today’s date and write what I’m working on. I try to write as much as needed on what I’m working on. I write commands down and save links to reading material.

    It’s not the best but it’s better than nothing.

  • lightnsfw@reddthat.com
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 day ago

    When I set something up I write all the steps I’m doing in obsidian as I do it. The pages get tagged so they’re searchable in the future.

  • VexLogic@feddit.online
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 day ago

    I’m actually in the middle of rebuilding my entire setup right now and one of my major goals is to actually document my processes this time.

    I use Obsidian which is a Markdown editor and I have a couple plugins alongside that for QoL stuff and extra features.

    I document processes, problems and fixes I encounter, list of active services alongside where/how to access them, and plans for future additions/changes.

    As far as working documentation into your flow, realistically that is just a matter of discipline. It is explicitly up to you to stay on top of documentation.

    Hope that helps, and good luck with your endeavor! 😁

  • DetachablePianist@lemmy.ml
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 day ago

    I run Adguard Home containers (the primary auto-syncs to the secondary) and use redirect filters to assign hostnames to each of my containers. I have a “services” folder of bookmarks for each container host so I don’t have to remember each service’s port number. I use KeePassXC to track all my passwords and certificates so authentication is a breeze (someday I’ll get around to setting up an SSO solution). I also keep a .txt file with my basic network info that doesn’t always translate well to dns hostname redirects in adguard. I occassionally remember to update my hosts listed in the file. My individual config files aren’t backed up beyond my automated container backups, but so far none of my services have been that complicated I couldn’t just rebuild from scratch.

    It’s not perfect, but combined with my automated backups I have barely enough to rebuild if/when my hardware fails.

  • Scrath@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 day ago

    I have a bare minimum of documentation as markdown files which I take care to keep in an accessible lovation, aka not on my server.

    If my server does ever go down, I might really want to access the (admittedly limited) documentation for it

  • starshipwinepineapple@programming.dev
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 day ago

    what you use for your documentation

    Hugo (markdown) files that i host on my internal server.

    how you organize it

    I use basic directory structure. Top level directories are like “dev”, “home”, “general”. Self hosting is a dev/ subdir.

    what information you include

    Depends on how familiar i am with it and how often I’ll be referencing it. Something i know well or access often will be more high level. Things like an annual process i have documented in more detail

    how you work documentation into your changes/tinkering flow

    My site has an “edit this page” feature which i use to open my IDE and make the change as I’m doing things. Sometimes I’ll be lazy and just add in what i did this time and then let future me reconcile the differences 🙃

  • AMillionMonkeys@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 day ago

    I use Obsidian with a folder for hardware and a folder for software, then an entry for each device or service. I’ve been pretty good about maintaining cross-links.
    I kind of wish I used Docker Compose more, but I haven’t run into a situation where it’s been a problem yet.

  • bizdelnick@lemmy.ml
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 day ago

    It is hard, if even possible, to keep documentation up-to-date. Better use a configuration management system (salt, ansible etc.) for your servers. Yes, you need to learn how to use it. Yes, it will take a longer time to make changes in your configuration. But as a result you’ll have a self-documented configuration-as-a-code that will allow you to scale your setup as you need. Reproducing something won’t require reading your notes, remembering your actions etc.

    • IratePirate@feddit.org
      link
      fedilink
      English
      arrow-up
      0
      ·
      1 day ago

      But as a result you’ll have a self-documented configuration-as-a-code that will allow you to scale your setup as you need. Reproducing something won’t require reading your notes, remembering your actions etc.

      Until you realise that

      • you don’t really need to scale a homelab that much
      • if something breaks, you just want to quickly fix it manually because “doing the Ansible” is more of a pain
      • now idempotency and documentation-as-code is out of the window. ;)

      (I’m being tongue-in-cheek here. I don’t doubt this may work for you, but it takes much more discipline than I have.)

      • bizdelnick@lemmy.ml
        link
        fedilink
        English
        arrow-up
        0
        ·
        1 day ago

        you don’t really need to scale a homelab that much

        Maybe. But you never know this beforehand.

        if something breaks, you just want to quickly fix it manually because “doing the Ansible” is more of a pain

        In most cases you just need to replay a playbook for quick fix. But I agree that the proper fix will likely take a longer time (while downtime is much shorter).

        now idempotency and documentation-as-code is out of the window.

        Let @[email protected] decide.

        P. S. I don’t like Ansible, other tools can be easier to use. But I don’t want to recommend something concrete.

      • magic_smoke@lemmy.blahaj.zone
        link
        fedilink
        English
        arrow-up
        0
        ·
        1 day ago

        Yeah as someone who does both ansible is for repeatable multi-system commands like telling everything to update or configuring a local agent on every machine at once.