From dc9a70ab9515b400e2e70ebc0aef434fc20d48a5 Mon Sep 17 00:00:00 2001 From: waldek Date: Tue, 20 Apr 2021 20:57:42 +0200 Subject: [PATCH] adds config versioning --- .../resources/exercise_config_versioning.md | 67 +++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 modules/resources/exercise_config_versioning.md diff --git a/modules/resources/exercise_config_versioning.md b/modules/resources/exercise_config_versioning.md new file mode 100644 index 0000000..22af7b6 --- /dev/null +++ b/modules/resources/exercise_config_versioning.md @@ -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/)?