Linux Kung Fu Style: Synchronize Settings

One of the best qualities of Linux and similar operating systems is their deep customization. If you don't like something, chances are high that you can easily change it by tweaking some file. For example, consider bash, a command shell that is popular by any measure. If you need to change the command line prompt, this is quite feasible. If you want a key Tab



to allow for case-insensitive auto-completion of filenames, that's not a problem either. Typically, these settings are performed in one of the so-called "profile files", sort of .bashrc



located in the user's home directory. If someone works at a single computer, then he does not have any problems with the settings. It contributes to the file







.bashrc



, and in other similar files, the necessary changes, customizes the system for himself, and works in an environment that behaves the way he wants. Problems arise when someone has to use multiple computers. Perhaps we are talking about a web server, a desktop computer, a machine that plays the role of a firewall, and a few dozen Raspberry Pi. How do you configure all of these systems the same way? And how, after they are all configured the same way, do you keep the settings up to date?



Several options for syncing settings



In fact, there are several ways to synchronize settings on Linux systems. Since these settings are usually stored in some kind of files, almost any synchronization mechanism can be used to solve our problem. This will take some time, but as a result you can achieve what you want. Suppose you can put all your config files in one directory, and then place symbolic links to those files in the right places in your home directory. Further, you can, using rsync



, synchronize this folder between different systems.



If you are familiar with Git, then you already guessed about another option for solving this problem. Here, in addition to the ability to synchronize settings, you will also have the opportunity to know what and when changed in your configuration files. In fact, I'm in a material of unusual ways to use the Git, has talked about it, showing my system settings synchronization, based on Git. Recently, however, I discovered that there was a system called chezmoi , which is written in Go, and uses an approach to syncing settings that is completely different from mine.



Chezmoi features



According to the data from the project repository, it chezmoi



offers the user the following options:



  • A declarative description of the desired state of the home directory files.
  • Using templates to create files.
  • Security of work is ensured by integration with Bitwarden, with LastPass and with some programs for local storage of keys.
  • Support for atomic update handling. This protects the system from falling into an "intermediate" state.
  • Support for multiple operating systems.
  • The user is informed about the actions that are planned to be performed, the "test run" mode is supported.
  • High speed of work, the ability to choose which is used in conjunction with chezmoi



    the version control system.


It all looks very interesting. The procedure for installing the utility in different operating systems has its own peculiarities, the corresponding instructions can be found in the project repository.



Using chezmoi



The executable file that gives access to the capabilities chezmoi



, not surprisingly, repeats the name of the project. It supports several commands, among which I would like to note the following:



  • add



    - adding a file to the files managed by the system.
  • edit



    - file editing.
  • diff



    - finding out what changes, if any, are pending inclusion in the working version of the file.
  • apply



    - inclusion of changes pending approval in the working version of the file.


When a new file is added to the system, a copy of it is placed in the directory ~/.local/share/chezmoi



. For compatibility with version control systems, chezmoi



ignores files in this directory whose name begins with a period. Therefore, if you add, for example, a file to the system .bashrc



, it will automatically be renamed to dot_bashrc



.



If only the possibilities were chezmoi



limited to this, then there would be nothing remarkable in this utility. The most interesting thing here is the synchronization of file copies. To solve this problem, it chezmoi



uses an external version control system. But what happens if some of the computers whose settings are being synchronized need some special settings?



Support for special settings



For example, on a desktop computer, you need to use a custom command line prompt. And on the server, on the firewall, and on the Raspberry Pi computers, you will be satisfied with the usual invitation. This means that on each of the computers, in the file .bashrc



, a special parameter value must be present PS1



.



This can be done by adding the appropriate entries to the section of the data



file chezmoi.yaml



. In fact, you can use various formats here, in particular - JSON



and TOML



. This file is unique for each computer. It allows you to make changes to template files. For example, a chezmoi.yaml



desktop computer might contain an entry aboutPS1String



, describing the complex settings for the command line prompt, and in the same file for the Raspberry Pi, a similar entry will already be arranged much easier.



In order to add a certain file to the system that will be used as a template (for example, a file .bashrc



), you need to use the -T



command option add



. The template file based on .bashrc



will have a name dot_bashrc.tmpl



. The standard Go templating mechanisms give the user chezmoi



a variety of options. In addition, chezmoi



it allows you to use variables, which, for example, allow you to work with the computer name and username, with OS and architecture identifiers.



Thanks to the capabilities used inchezmoi



template language, the user has a lot more freedom than just using variables. In templates, in particular, you can use conditionals. For example, it can look like this:



#  
export EDITOR=vi
 
# ,    
{{- if eq .chezmoi.hostname "work-laptop" }}
#     ~/<code>.bashrc</code>  work-laptop
{{- end }}

      
      





Safety



Chezmoi



recognizes private files and processes them accordingly. So, a directory is private chezmoi



, the system uses a prefix private_



when assigning names to private files (for example, the name of such a file may look like private_dot_bashrc



).



It is assumed that some version control system will be used to organize file synchronization. In other words, when setting up a new computer or updating the settings of a certain machine, you synchronize the contents of the directory chezmoi



with a copy of the settings stored in the version control system. Then everything that needs to be configured in the configuration file and the changes are applied, possibly with a preliminary check of which changes will be applied.



This means, of course, that the stored files will be as "private" as the version control system allows. If you publish your configuration files to a public system, it means that there is no longer any question of "privacy". One way to solve this problem is to use a templating system, and not to process the configuration file with the version control system. And it, since it is unique for each computer, in any case should not be processed using the version control system. This means, among other things, that it must be stored differently from other files.



Suppose you have an entry like this in your config file:



hackaday:

   password: 0xdeadbeef

      
      





The password must be kept secret. And in public files, the following construction can be used:



password = {{ .hackaday.password }}

      
      





When working with chezmoi



, you can still use configuration files encrypted with gpg



.



Version control system



If we talk about version control systems, then chezmoi



there are commands for sending materials to supported version control systems and, accordingly, commands for loading data. The default is used git



, but there are other options, like hg



. The corresponding settings are made in the configuration file.



There are also commands that allow you to simply get the full set of configuration files or export the configuration. You can read about these commands in the project repository. By default, all work is done in the home directory, but if necessary, you can configure the program to work with a different target directory.



Outcome



Overall, it can be noted that chezmoi



it seems like a well thought out project. But I didn't see anything here that would force me to switch to chezmoi



from my settings synchronization system. If I had stumbled upon chezmoi



when I was just thinking about how to solve the problem in question, then I probably would have used this particular project, and not created my own. I do not argue that the templating system is chezmoi



very good, but my system achieves a similar effect by choosing different files depending on the environment.



Unique settings filechezmoi



difficult to handle with version control. Yes, users usually do not tend to do this. If the repository used to store the settings is private, or if private information is not included in the configuration files, you can put options for the settings file into this system chezmoi



(say, there may be a version of this file for the Raspberry Pi and for ordinary computers). Then, when you first set up your computer, you can rename the appropriate file. But it is more likely that the system settings file will simply be copied. The approach according to which the config filechezmoi



are not handled by source control, there is the advantage that, if configured correctly, you can safely use a public repository to store data.



And for the operation of my system, it is very important to use a private repository - if only the one who uses it does not care about getting his configuration files into the public domain. However, all files are processed using a version control system. The system allows you to keep abreast of all changes without the need to use templates, which take time to master. You just need to place the settings in the appropriate files. The only feature that I can quite add to my system, inspired bychezmoi



, this is the ability to add new files to it, which are monitored. Although my system allows you to synchronize settings, now you need to add files to it manually. The file is moved to a special directory, after which the file entries are added to the system and a symbolic link is created.



But this is what Linux is good for. There are many ways to solve the same problem. If you don't like one thing, you can find something else. And if you don’t like anything, you can create something of your own without much difficulty. This, however, creates certain problems when using Linux by many ordinary people who are not used to this. They do not seek to choose from many options, they want a simple and clear working solution. And in the Linux community, on the contrary, it is customary to constantly compare everything with everything and argue with fervor about which is better - emacs



either vi



C or Python.



How do you sync the settings across Linux machines?










All Articles