Selfhosted

39271 readers

216 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago

MODERATORS

[email protected]

Change tracking ideas (lemmy.procrastinati.org)

submitted 6 months ago by [email protected] to c/[email protected]

22 comments fedilink hide all child comments

I'd like to start doing a better job of tracking the changes I made to my homelab environment. Hardware, software, network, etc. I'm just not sure what path I want to take and was hoping to get some recommendations. So far the thoughts I have are:

A change history sub-section of my wiki. (I'm not a fan of this idea.)
A ticketing system of some sort. (I tried this one and it was too heavy. I'd need to find a simple solution.)
A nextcloud task list.
Self-host a gitlab instance, make a project for changes and track with issues. Move what stuff I have in github to this instance and kill my github projects. (It's all private stuff.)

I know that several of you are going to say "config as code" and I get it. But I'm not there yet and I want to track the changes I'm making today.

Thanks

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 5 points 6 months ago (1 children)

It can be in git even if you're not doing 'config as code' or 'infrastructure as code' yet/ever.
Even just a text file with notes in markdown is better than nothing. Can usually be rendered, tracked, versionned.
You can also add some relevant files as needed too.

Like, even if your stuff isn't fully automated CI/CD magic, a copy of that one important file you just modified can be added as necessary.

[–] [email protected] 1 points 6 months ago

It can be in git even if you’re not doing ‘config as code’ or ‘infrastructure as code’ yet/ever.

I have some of this. I have an ansible playbook I use to do initial vm/lxc setup and I've built out a number of roles. But none of my systems are to a point were I could just delete the vm, spin a new one up, point ansible at it, and pickup where I left off.

The one thing I have that probably closest to this is my internal BIND zones, which double as my IPAM. I've been fairly diligent about committing changes and documenting what the change was.