waldek
/
linux_course_doc
1
0
Fork 0
Code Issues 2 Pull Requests Projects Releases Wiki Activity

adds config versioning

This commit is contained in:
waldek 2021-04-20 20:57:42 +02:00
parent 91cfa57082
commit dc9a70ab95
1 changed files with 67 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

67
modules/resources/exercise_config_versioning.md Normal file
View File

@ -0,0 +1,67 @@
# 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/)?