68 lines
4.3 KiB
Markdown
68 lines
4.3 KiB
Markdown
|
# Configuration file versioning
|
||
|
|
|
||
|
|
By now it's no news to you anymore that there are *a lot* of text files on a Linux system and that you'll be editing them often when administrating a server.
|
||
|
|
Over time you'll develop your own personal tool preferences for *how* you like these tools to behave.
|
||
|
|
That behavior is almost always done with more text files and which tool is best for keeping track of your changes over time?
|
||
|
|
That's right, [git](https://git-scm.com/book/en/v2)!
|
||
|
|
|
||
|
|
There are multiple *strategies* to keep track of your personal preferences and I would like for you to try one out for yourself.
|
||
|
|
You'll find quite a few tutorials online but first some hints to help your search queries.
|
||
|
|
The concept of version controlling your personal configuration files is often referred to as **dotfiles versioning**.
|
||
|
|
Why *dotfiles*?
|
||
|
|
Well, most user configuration files are hidden so they start with a `.`, hence dotfiles.
|
||
|
|
You can also version control your **system configuration** with git but there is a handy tool out there called [etckeeper](https://etckeeper.branchable.com/).
|
||
|
|
There are other tools as well and I urge you to research and try out whichever looks good to you.
|
||
|
|
As always, it's a journey of discovering and testing!
|
||
|
|
|
||
|
|
## Strategies
|
||
|
|
|
||
|
|
Below I briefly outline two strategies I know off in no particular order.
|
||
|
|
|
||
|
|
### Strategy "one big git"
|
||
|
|
|
||
|
|
By initializing a git repository in you `$HOME` folder you can track **every** file inside your home directory.
|
||
|
|
If you do a `git status` you'll see you can add all your configuration files but what about the *other* files you don't want to track?
|
||
|
|
A clever solution to this is to add a .gitignore file to this repository and set it so that it ignores *every* file.
|
||
|
|
Remember wildcards?
|
||
|
|
Now `git status` will not complain about untracked files anymore because not a single file matches the pattern.
|
||
|
|
So how on earth can you add files to this repository then?
|
||
|
|
Have a look at `man git add`, maybe you can *force* it somehow?
|
||
|
|
|
||
|
|
### Strategy "symlink all the things!"
|
||
|
|
|
||
|
|
The first strategy is a quick and easy one but some people do not like the messy folder structure it creates.
|
||
|
|
As it's basically a copy of your home folder, you'll have directories all over the place.
|
||
|
|
A solution to this would be in two parts.
|
||
|
|
|
||
|
|
First you create a new folder called something like `mkdir ~/.dotfiles`.
|
||
|
|
You're free to call and place it wherever seems logical to you.
|
||
|
|
Inside this folder you initialize a git repository.
|
||
|
|
|
||
|
|
From now on you'll `mv` all configuration files you want to track into this folder, or into subfolders per program.
|
||
|
|
*How* you organise is completely up to you.
|
||
|
|
Some people like folders per program, others like folders per type of program, you choose!
|
||
|
|
|
||
|
|
But how will your programs *know* where to look for their configuration files?
|
||
|
|
This can be solved with **symbolic links**!
|
||
|
|
I would advise you to use soft links and doing some tests and/or follow a [tutorial](https://linuxconfig.org/how-to-create-symlink-in-linux) to get the hang of how they work.
|
||
|
|
|
||
|
|
The quick ones among you will see a potential problem with this method.
|
||
|
|
Imagine you arrive on a freshly installed system and clone your dotfiles repository the symlinks will be missing and you'll have to manually create them yourself.
|
||
|
|
As this is way to labour intensive for us *lazy* folks, most people who follow this strategy also add a shell script to their repository that creates them automatically.
|
||
|
|
|
||
|
|
## What to include?
|
||
|
|
|
||
|
|
If you share your dotfiles publicly, remember sharing is caring, keep in mind that if your files contain sensitive information such as **usernames**, **passwords** or **email addresses** you might want to rethink your strategy a bit.
|
||
|
|
Most programs that require *sensitive information* can be configured to pull this information for other files you don't include or have this information hashed.
|
||
|
|
|
||
|
|
## Now the fun stuff
|
||
|
|
|
||
|
|
I challenge you to start working on some unixporn worthy configurations!
|
||
|
|
To get you going here are a few links.
|
||
|
|
|
||
|
|
* general tmux [configuration](https://www.golinuxcloud.com/tmux-config/)
|
||
|
|
* general vim configuration [tutorial](https://linuxhint.com/vimrc_tutorial/)
|
||
|
|
* [powerline](https://powerline.readthedocs.io/en/master/overview.html#screenshots)
|
||
|
|
* quick options for your [bashrc](https://www.ivanglinkin.com/useful-bashrc-configuration-file/)
|
||
|
|
* why not try [zsh](https://www.howtogeek.com/362409/what-is-zsh-and-why-should-you-use-it-instead-of-bash/)?
|