It depends on what it is. I do not have a singular documentation-platform or wiki for those things. I'm more of the keep the docs where the code is guy. I also try to keep complexity to a minimum.
All my linux server setups are done with ansible. ansible itself is pretty self-documenting, as you more or less declare the desired outcome in YAML form and ansible does the rest. This way, I do not need to remember it, but it's easier to understand when looking it up again.
Most of my projects have a git repository, so most of what I need to know or do is documented
- in a
README.md - as pipeline-instructions inside
.gitlab-ci.yml
This way, I was able to reduce complexity and unify my homelab projects.
My current homelab-state is:
- most projects are now
docker-based - most projects have a GitLab CI for automated updating to newer versions
- the CI itself is a project and all my CI-docker-based deploys use this unified pipeline-project
- most projects can be tested locally before rolling out new versions to my VMs
- some projects have a
productionand astagingserver to test - those which cannot be dockerized or turned into a CI are tools and don't need that (e.g.
ansibleplaybooks or my GitLab CI)
On what to include, I always try to think: Will I still be able to understand this without documentation if I forget about the project for 6 months and need to make a change then? If you can't be sure, put it in writing.
If it's just a small thing regarding not the project itself or the functionality or setup itself but rather something like I had to use this strange code-block here because of XXX, I'll just put a comment next to the code-line or code-block in question. These comments mostly also include a link to a bug-report if I found one, so i can later check and see if it's been fixed already.
Since I allowed signal to always-run-in-background I have seemingly never missed a signal notification.
Do they just not show up for you?