arc/notes
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

vault backup: 2024-09-10 20:41:36

Browse Source
This commit is contained in:
zleyyij 2024-09-10 20:41:36 -06:00
parent b771016fc6
commit 8fe10c3bd2
1 changed files with 6 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
software/Versioned config files.md
View File

@ -1,11 +1,15 @@
## Solutions ## Solutions
- Create a directory, eg `/etc/config` and store all of your config files there, then use a makefile to automatically generate symlinks and install them in the appropriate locations. A command is also created for removing said symlinks. (https://forums.freebsd.org/threads/version-control-for-configuration-files.70312/) - Create a directory, eg `/etc/config` and store all of your config files there, then use a makefile to automatically generate symlinks and install them in the appropriate locations. A command is also created for removing said symlinks. (https://forums.freebsd.org/threads/version-control-for-configuration-files.70312/)
- I like this so far, it seems like one of the better options. - I like this so far, it seems like one of the better options. If I'm allowed to be quirky, I'd rather use `just` than `make`, Makefile syntax makes my tummy hurt.
- Using a filesystem that supports snapshots like zfs/btrfs and then creating snapshots (https://forums.FreeBSD.org/threads/version-control-for-configuration-files.70312/post-423330). - Using a filesystem that supports snapshots like zfs/btrfs and then creating snapshots (https://forums.FreeBSD.org/threads/version-control-for-configuration-files.70312/post-423330).
- I don't like this very much, it depends too much on OS specific configuration and doesn't seem like it'd be as easily portable between machines. - I don't like this very much, it depends too much on OS specific configuration and doesn't seem like it'd be as easily portable between machines.
- Using a configuration management system like Ansible, Chef, or Puppet (<https://www.dolthub.com/blog/2023-12-12-configuration-version-control/#isnt-this-just-configuration-management>) - Using a configuration management system like Ansible, Chef, or Puppet (<https://www.dolthub.com/blog/2023-12-12-configuration-version-control/#isnt-this-just-configuration-management>)
- I feel like this would require a fair bit of initial setup but it seems robust - I feel like this would require a fair bit of initial setup but it seems robust
- Using a database like - Using a database like Dolt or Terminus DB <https://www.dolthub.com/blog/2023-12-12-configuration-version-control/#isnt-this-just-configuration-management>
- I think this would require a lot of work and we wouldn't reap the benefits at our scale.
- Using an orchestration system like kubernetes or hashicorp nomad to centralize config file/deployment management, from there version controlling configs would be easy (<https://medium.com/netcracker/version-control-of-configuration-files-using-kubernetes-21673766203>).
- I think this would be a good idea, but it's *a lot of work*, and I think maintaining it would continue to be a lot of work.
## Notes ## Notes
I think one major issue with storing configs in a solution like git, is that you need to remember to push changes after every single config change. Maybe a cronjob could be configured to commit daily/weekly? I think one major issue with storing configs in a solution like git, is that you need to remember to push changes after every single config change. Maybe a cronjob could be configured to commit daily/weekly?