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 about
PS1String
, 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 in
chezmoi
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 file
chezmoi
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 file
chezmoi
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 by
chezmoi
, 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?